@djrikki

Are you sure that you want TW , but not OWB for example ? TW are very buggy must to say for now, so i need to reboot everytime after i visit more or less heavy sites :) (OWB in that terms very stable, and can render all that FaceBooks, Youtube and alt).

Anyway, if you do not have aos4 by hands, but want to see some more stuff, check some of my videos on youtube here.

That one imho most interesting one (aos4.1 update 1, with all that Youtube in action and such).

(Will make some other-different shots later)

@djrikki

Quote:
Yes, inbuild (but not default) from aos4.1 update 1 and later (if i remember right), and called SilverTheme (not sure about). For now, i can't found or see any other more or less good looking by design and colors theme. Sometime design ok, color bad, sometimes color good , but design bad. But that one more or less "ok" (imho of course)

Btw, did it make any sense, if .so plugins have stack cookie inside, or not ?

One image from me (TW on some normal site + visibly amidock).
Here is

@MickJT

Not works from RAM ?

@JosDuchIt

AISS it's native amigaos4 format icons done by Mason. That ones which come with AOS4 are not full (only basic ones). So, you need to download full archive from his page to make all programms happy.

Also there is pretty offten present PNG icons (just png image, without anything specific inside), and you can download png.module from os4depot, which will allow to you to have all png icons works (that module not part of basic aos4 setup, so you need install it manually).

Just install that png.icons module, and all icons will works for you with no problems.

@MickJT

Tested (peg2/1ghz/aos4.1u2) With first binary (from full archive) "options" in menu was DSI and some problems was with network, but with new binary everything seems ok. Good that we now have window mode support. Also game itself looks better than before, with all that animation, music and alt. Thanks for :)

@MickJT

Will test it in next few hours. Btw, did you fix that "sql-base problemm" ? If i remember right, something in data-base code of xmoto, stop you before from releasing it. Or that was fixed by author ?

@DAX
Quote:

For sure possible to do everything faster than LodePaint do, but it done already in that way (not by me), so there is nothing what we can to do with (only complite rewrite, which a huge-huge job and will make no sense, better done one from scratch). I do not know how Blender do his rendering, but i think its not rerender every frame as in modern computer 3d games (as LodePaint do), and because of it it faster. Its just real world :) No one want to think about 500-800mhz machines in all the world (mostly), and we can be only happy, that something even run more or less ok for us :) Of course i ask main coder about some speedups, but not sure that he will in interest to do complite rewrite of rendering code, only because amiga-users have slow hardware (in compare) and bad relisation of OpenGl (sad truth). He even say that "he not make it as multiplatform in mind", and its just some luck, that we have "contact" and he help us with some amiga-related modifications and bugs which i report for him.

Of course if anyone will found the same quality by functionality and design opensource ppaint app , which we can easyly port to aos4 - it will be cool. But for now that all what we have. Imho tha even better -> we see problems of aos4 in full.

@Chris

Still its strange, becasue on linux it works fine. I mean usage of .so plugins from the main, statically linked, programm. For now i test it like that:

compilation of main programm:
Quote:

compilation of plugin:
Quote:

Then, when i try to run plugin from programm, i have such error:


If i add just -use-dynld for the main programm, all works fine. But still i in interst: it is possible somehow make it works when main programm static, or not.

From the PDF on which ssolie point me, i see that is possible, but strange why for me it crashes then (i passed all those -fPIC and -Wl.-export-dynamic flags)

@Chris
Yes, for now i compile its as -use-dynld, but still in interest why (techically) it not works when i call .so from static binary.

Quote:

So, it's indeed have place. Why it happens ? Bug, or aos4 implementation of shared objects ?

@ssolie
Thanks, found something interesting for tests.

The question comes from my problems comes when i add plugins support to LodePaint. LodePaint just use .so plugins , and in main code do such thinks like:


I compile plugins with such string:

Quote:

The problem is: When i compile main program (lodepaint) with static linking (without -use-dyndl), then, when i choice plugin it crashes , on libc.so (can provide crash log if its need it).

If i compile main program with -use-dyndl, then everything works fine. But still i curios, why it crashes when main programm are static, and, should it be like that or not.

Maybe need some kind of flags passed to gcc for amiga-specific support or kind ?

For example for linux, the same program compiles statically, and plugins dinamically as should, and all works fine.

Can also provide little example codes, crashlogs and alt if anyone in interest.

@ALL
Plugins works now ! Thanks to AOS4 with their Shared Objects support !

@Arcane5150
Quote:

Warp3d its the same as DirectX 5.0 (only pipeline, without any mathematic or kind). And in general , it works in hardware mode, just some basic and modern fucntions still works in software (such as Transformation, Lighting and Clipping). Why some in HW and other in SW ? Because warp3d was designed 10 years ago, for old classic machines, and i think it was not big sense to make these transformation/lighting and clipping (or no time and motivation). Main warp3d coder on aos4 its Rogue (as i think), and he just have no time for adding that features to Warp3d for now, and more of it, that make no sense anymore (because better just forget about warp3d at all for future).

Current problem, that our realisation of OpenGL (minigl) works not directly with hardware (or deep-system based drivers like readeon.resource (its not driver, but like that) ), but over that old-designed Warp3D.

So, we need to write any opengl realisation, which will just works with harware directly. Minigl it will be, or Mesa does not matter (Mesa will be imho easy, because its already done, and need to port it). Ove rwhat will works MiniGL or Mesa - its all up to programmers. MiniGL based on warp3d imho becasuse it was more easy to code. Mesa also can be based on warp3d (but i hope it will never based on it anymore, because it will be bad), or use hardware directly , or, over some drivers subsystem (gallium for example).

AROS developers (mostly one of them - deadwood), porting Gallium + Mesa to AROS even over they also old-bad video subsystem. But deadwood start to works on Mesa about 2 years ago, then drop it on long time, then works on it again. And after he finished mesa port (software one) then he start to works with Gallium, then redirect Mesa over Gallium and alt. For now its all work in progress.

Related to MESA in old times, yes, some company (Haage and Parthner it was if i remember right) port MESA and call it StormMesa, and more of it, it also works over Warp3D, and was way buggy in that terms (for example, it not works over voodoo3 with mediators on classic amigas in HW mode, but works with Permedia2 based graphics cards (like cybervision and blizzardvision) in HW mode). For now, some ppls (Alain and others) are works on "fixes" of exactly that StormMesa, to make all current old 68k users happy, to have Mesa and Warp3d without bugs (they also try to fix bugs in warp3d, which are a lot too).

Everything is possible of course, just matter of time. For now i not recieve any answer from Rogue, about what will be best for making the bounty.

@Rogue
Alive ?:)

@DAX
Well, any OS based on parts: drivers, API, video subsytems, kernel and alt. On aos4 we have bad relisation of video subsystem (p96, which not modern and have problems by design in general (about which Rogue already say to me) ), slow relisation of 3d drivers (warp3d, which are old and maybe not so good designed), and realisation of opengl done without any drivers, just over warp3d (which all in all bad idea too), some AOS4 api (i am not sure, but imho) are old and because of 68k support still old (and slow).

So, some parts of AOS are slow. Then i think we can say "aos4 slow in that and that parts if compare with winxp". I am sure that for some parts, aos4 are better (because if not, strange that we all here). But that topic is about programm based on OpenGL, which can be _much_ faster , and we not need to say different, we just need found the solution and make it fast.

@Mason
I uploaded new version of LodePaint, and Skin system was introduced => so, it will be more easyly for you to create a aos4-mason style skin for :) (in skin directory also specification on the images are present)

@all

New version in upload query on os4depot. Changes:

-- Added "Pointillism" filter, the first artistic filter
-- Added Morphology filters: dilate, erode, open, close, gradient and top hat
-- Changed some more GUI graphics (the style of the menus)
-- Fixed multiple GIF image import bugs (was endieanes issues and some typo mistakes).
-- Beginnings of skins support. It can now switch between 3 built-in skins (default, negative, old). So, for now, Mason (or everyone else) can create aos4 related skin for.

Hope in next few versions add ASL reqester for all file operations , and plugin support (because aos4 have .so support, it can be pretty easy, will see).

@Arcane5150

As far as i understand for now, there is not so big nuances, except of free time for doing that. Yes, as Rogue explain: p96 are pretty limited , and was designed without all those new-good features. But also and morphos's CGX5 and AROS's video subsystem are limited too.

The main question here: what will be better, make a Gallium for current (bad-old) p96 subsystem (and later, when video subsystem will changes, again change Gallium for, because changing of video subsystem are in plans). Or removing warp3d layer from minigl.

If making the Gallium (even with having in mind p96), then in future it will be "a start" when p96 will be rewriten/changed. But when that "future" will coming, we do not know , and very possible that 3-4-5 years.

Also making Gallium, will not speedup everything. We need again rewrite minigl , for usage the Gallium, or, port the Mesa, which will works over Gallium (mesa will be not faster solution, but shaders are good feature, which minigl definatelly will never have (pretty big job to add shaders from scratch) ).

So, for me (at the moment), looks better (and faster) removing of warp3d layer from minigl, and recoded minigl to works directly with radeon.resource. That will give us speedup about 40-50% imho.

Rogue say, that he will provide necessary documentation on radeon.resource , and also will make in it changes when it will need. But for first, need to understand what way will be better.

For me (as for end user), removing warp3d from minigl looks a bit more "easy", if comparing with making Gallium, rewriting minigl (or porting mesa) and alt.


@Radov
MiniGL sources are open-source already, and everyone can grab it, and trying to remove Warp3D layer from it. That will already give us speed up about 50% (imho). Hanz are used Warp3D in minigl, just because minigl initially was warp3d based, and its easy to code if compare with directly coding of radeoncp.resource.

We not need to exchange warp3d at all, we need removing it at all. Of course, maybe the most faster solution will be if Rogue will give us warp3d sources, and skilled coders can just speedup it, but, still, while we have warp3d layer beetwen, it will slow down everything in twice, because minigl copy texture to warp3d, warp3d copy to hw => 2 times the same.

@Mrodfr
I think it's different story, and if you want you can try to talk with him yourself :)

@Radov
Right now i talk with Rogue, about what can be done (he explain me details about), after founding the good solution (and best one for now), bounty will be created and alt.

@joeled
Quote:
Problem for now it's not only about porting mesa, but deeply in the system itself. Still not so clear what way will be best: imporovng minigl (with removing warp3d layer from it at all), or making a gallium (which also can be used by minigl, with removing warp3d, or by mesa).