Curse of the SDL

[itix]

Is it so, that making SDL port, makes native port easier? After that it is alredy 68k and you just replace SDL code slowly to native code??? <- Question

Maintaining port is impossible. When there is new version you have to start from scratch again.

Some projects are modular allowing you to write your own backend... but for example Freeciv 2 is huge and replacing SDL GUI with MUI is lot of work...

My personal wish to get native would be Netsurf

It still does not change the fact that Netsurf is designed for RISC OS which does not have proper multitasking and not taking full advantage of Amiga.

[itix]

Talking about 68k apps and games, sound many time like it would be impossible to do anything to 68k amigas. Wich makes me wonder, how good they were, I mean those who made amaizing apps and games to amiga years ago?? Were they humans or some kind of super creatures with big brains and super natural skills??

It is pretty difficult squeeze true colour JPEG graphics with tons of Javascript into Amiga 500. Even simple tasks like decoding JPEGs is very slow on anything less than 68060 and quality is still quite poor on some 640x200 with 16 colours...

[itix]

todays games use alphachannel for all objects.
this mean before calc a pixel, the pixel data need read, the object data is add and then the pixel is written.

but because amiga GFX card access is so slow, and a gfx card read is more slower than write, this slowdown alot.

It is only slow if you dont have HW accelerated alpha blits.

[itix]

today OS use 3D features of GFX Card for that.

Is it a problem? There are 3D gfx cards for Amiga.

[itix]

Unless you are going to extend Warp3D API it is probably too painful to use with SDL for 2D acceleration. SDL allows locking HW sufraces (Amiga bitmaps allocated from VMEM) and let programs directly manipulate HW bitmaps.

VMEM probably is not problem on old Amigas. Most users there are using 1024x768 low-res.

[itix]

I suspect it is so far behind now that it would be easier to start again.

Indeed. Two years ago (!) I started work to merge MorphOS changes to SVN but it was already too late... so much had changed already.

Luckily porting it over is not that much work... old UI can be reused and many deps have been ported already. And when I ported it years ago I reused some of your code and I guess I could do that again =P

@bernd_afa

Btw ports are never done. They need continuous maintenance or they fall behind quickly were they official ports or not. One example is Freeciv port years ago when it had decent MUI GUI. It was never finished and since Freeciv 2.x it has been obsolete.

[itix]

@bernd

In my opinion biggest drawback in Netsurf is it is designed for non-multitasking RISC OS. It is single threaded application blocking UI when it is waiting for network or disk activity.

Please also keep in mind API must change in this kind of application. It is unavoidable in cross platform development and C language perhaps is not the best possible choice there...

[itix]

btw RISC OS is a a multitasking OS, it just happens to be co-operative instead of pre-emptive.

Ah, right. My mistake. But anyway it leads to single threaded application design. If something blocks UI it also blocks downloading task in background. And vice versa.

[itix]

Are you using MMU to avoid performing c2p and redrawing the non updated parts? IIRC ADoom had some code to do that and it could be quite helpful on machines with MMU. Scrolling would be slow but other scenes would be fast. Perhaps you could add some optional frameskipping in games that use 640x480 (and with MMU onlyenable it on scenes with many changes -let's say more than 50%-, I guess that looking at MMU code from ADoom it would be possible to add a counter of modified chunks and if more than half of chunks have been modified activate frameskipping).

IIRC ADoom didnt use MMU to avoid drawing non-updated parts but instead marked frame buffer as non-cacheable. Could be I remember wrong but ADoom indeed ran faster on certain setups.