Curse of the SDL

[unusedunused]

>68k software developement is totally halted, or all new software for 68k amigas is >useless SDL ports.

I dont know wy you write this for 68k
do you see on other AOS or PPC AOS  more than SDL Ports ?

when we look on aminet you can see on 68k most native programs/ games  that are only on amiga 68k develop and run not on Linux.

>So what kind of apps and games could theoritically run 040/060? Quite much any PC >game that that has requiremt something like 486

because of the slow amiga GFX Bus only 320*240 games.

and thats the problem.SDL get popular in Linux when PC Hardware was able to do 640*480 Pixel games in true colors, so most games run only with 640*480 and only very few of the SDL developers make their games running on 320*240 Pixels.new written SDL games need lots more Power, many of them are not very fast to run on a OS4 or MOS system.
the reason is that today pixelshader fast CPU is very very cheap.Most users have them now.

And write programs for slow hardware cost lots more programing time.time is short, but if you have time maybe you can do new games that run on slow hardware.But i guess if you maybe learn to program you like to buy a cheap CP for 300 Eur and code on this the program.you save time to speed optimize or live with ugly graphic ;-)

that sdl does not slowdown, you can see when you look at the speed of netsurf.68k version is more than 3* faster with SDL.

tha only problem is the Amiga GFX bus access is too slow to transfer the data of a 640*480 screen.

when you want render 640*480 16 bit screen with 25 fps you must transfer 15 megabyte /sec.

But mediator with a Voodoo 3 transfer only 8 megabyte /sec.
The CPU is fast enough, only a faster GFX Bus is need.
hope that natami come some day, then can see that SDL games run lots faster due to faster GFX Bus.

[unusedunused]

>Certainly there were Amiga coders back in the day who dazzled with raw skill, but a large >part of why things seemed to work so well is that programmers were willing to tailor and >compromise their designs in order to work well on the hardware.

that always happen.there is still no Hardware out that is fast enough to run all in that way designers want.also remember the play consoles.

But in the past, amiga Hardware Limits are state of the Art and most users have it.so games are develop for amiga in 32 colors enhanced with copper lists to more color instead of EGA 16 color of PC.

but later PC get faster and faster users buy them more and PC market grow..devleopers see less limits on PC or game consoles and so go to PC or game consoles and di more complex games.

and so nobody want to strip down something that it run on a AOS.nobody pay enough money for the stripdown.

If this is 68k or MOS or OS4.All ist too slow in compare to modern Systems as playstation 3 or xbox 360 or PC and have only a market of a few hundret users.

Netsurf is designed to run 16mhz system, is it low-end enough

but the problem is, the internet pages today are not designed to run with 16 MHZ well.
Pages use CSS truecolor images, lots images and some other performance huge features.and if the web designer use no A500 to develop the page, he did not notice that his page is show too slow.

if you want show only a simple html page with text antialiasing netsurf is fast and can show such a page in below 1 sec.try it out with the ibrowse history.html file

[unusedunused]

Netsurf SDL problem for me is that it requires true type fonts.

Amiga chip / zorro bus is sure slow, but have you tried FBlit? Games like simcity 2000 and napalm get huge speed up to vertical/horzontal scrolling with it, if you promote them to fast mem with FBLit.

But ofcourse there is limitations with 68k amigas, programmers just neet to live with them.

all does not help, because the simple fact, the screen resolution used in modern games is 640*480*16 bit at least.

nobody enhance the images for 8 bit usage and 256 color.

and so its a simple calculation.to run a 640*480 * 16 bit image game at same speed with full scrolling as a 320*240*8 bit image game, you need a Hardware that is 8* faster.

I dont know what the Problem is for you with truetype Fonts.

speedtests on large Text html files show, that antialias truetype fonts do things not slowdown.so the internal fonts version is not need

the CPU expensive stuff is loading and decoding the jpg process the page with CSS.
when you use a page without CSS and big images all go faster.

[unusedunused]

>Yep, with a native gui you would get things like menuitems and scrollbars visible with any >screenmode (now they're cut off on anything < 1024*768).

you need press the resize button.then the scrollbars are set correct.

>But would the program itself be any faster ?

the SDL Port is when look at performance /MHZ lots faster as on OS4, so seem no speedup possible.

See here the time results.

http://www.amiga.org/forums/showpost.php?p=649724&postcount=146

but its intresting to see how fast it is in performance /MHZ on a Acorn RISC OS.

>Quite many SDL apps are slow 68k amigas, even when they shouldn't be.

I can only repeat the Fact, when a game developer develop his game for full scroll in 640*480 16 bit or at larger screen resolution, the data is too much for a Amiga.

another big problem is audio.old amiga games music have only samplerate of 7 khz and 4 channels.

but most games today use more than 4 channels and at least a sample rate of 22 khz but most 44 khz.

So you need all sounds convert to 7 khz and that sound is ok if only 4 channels are use.


wy you do not learn a little programming, and change all graphic and game coordinates in a program so it can show on 320*240 16 bit screen.

this is possible.
then a sdl game is too playable on classic.

On the othe side when you just use a SDL game as it is and try it without use of SDL, the game is still lots too slow.the screen resolution or audio channels are lots too much for a classic

So we need only guys who have time that strip down SDL games to 320*240 16 bit screen and 4 channel audio with 7 khz.

[unusedunused]

Quite a few RTG 060 users have said the AGA version of ScummVM is much faster on their RTG boxes than the SDL based RTG release so yes, I hope when I do a 'native' RTG version we'll see the speed increase a bit (it should of course run faster than the AGA version at the same resolution/color depth).

The AGA version may get a chance to catch up again with the RTG version if I can get direct-chunky working (eg Graffiti) and skip the C2P step
 
I don't the 68k SDL is a curse though, it was very helpful to me when I did my intial port (the 68k SDL source code was made open source).   Most of the performance issues are probably down to the fact that it's no longer maintained.

scumm games are no action games that need frequently update all graphic.How is it possible to measure the speedup ?

a better test to compare between a native port and sdl is maybe quake
try a test with sdlquake and quake.set your workbench to 8 bit to run sdlquake.fullscreen do not work on old SDL
fullscreen 640*480 8 bit screen.

or use window mode so it run on workench in quake68k.

http://aminet.net/package/game/shoot/sdlquake-1.0.9

http://aminet.net/package/game/shoot/Quake68k

free shareware files are here.You need a PC to install it and then copy the wad files.

http://quakeone.com/freequake/en.html

and presse esc and go to menu option and choose open console

Now type in console
timedemo demo1

this you can do in both quake and you get a fps value.what results you get with native Port and sdl port ?.you van also test on AGA.here can see that AGA is unusable slow
And if sdlquake is really slower as native version, i compile it with newest sdl, this is faster as the old sdl that is used in this port, and fullscreen can work too

I often see that think something is faster, but when measure time no speedup can notice.
A good example you can see on netsurf thread(link above).first it was report, older netsurf is faster as new netsurf.but when the user measure time he see that new netsurf is lots faster.

maybe its really possible to speed up without SDL around 50%, but thats near nothing and nobody notice it, when remember that new games have more than 8* more graphic data and more sounds date, the game is still unplayable if it use SDL or not.

>This doesn't work.

ah yes i see on new netsurf is because of gadgets not possible to use smaller screens as 1024.maybe you write to Artur, if he have add the limit, and if so he can remove.

but currently most pages need 1024 show in full width and you need not scroll in X
I test on a older netsurf, and when use 800*600 with amiga.org, you can not see all in width.

so also for amiga pages 1024 width is good

[unusedunused]

On both cgx/p96/sdl you could lock the bitmap and draw directly to it, most of times you'll get a nice speedup (although with SDL you may have slowdowns compared to cgx/p96 if you use doublebuffer functions). If you could tune up rendering to write chunks of 4 or more pixels it would be even faster :-)

sdl is able to work in same way as you told, when use HWSURFACE.but then many modern games run slower.

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.

[unusedunused]

Amiga sample playback is at 28khz. If you open and close a double scanned screen, that allows 56khz playback. Also, even the A500 is capable of channel mixing.There have been 8 channel MOD's since the late eighties. The problem as I have mentioned, is that ports from other platforms do not use Amiga tricks to increase the speed/quality of sound and graphics fidelity.

try a old amiga game and a sample ripper.in winuae you can too rip samples-
you see sample rate is not often larger as 7 khz, because on A500 memory was low and memory need save

also transpose a sample with paula have very ugly sound quality.amiga have a 7 khz filter so it sound not so ugly as when disable the filter.

modern systems as sdlmixer use linear transpose this cost more CPU power but have good sound quality so you can get CD quality sound

so the first thing you can do, when you want play a sdl game on a slow amiga, is switch music and sound off.

[unusedunused]

>The first thing you want to do if you play a game on Amiga is not use SDL, and use as >many amiga hardware tricks as you can. Many Amiga demo's run in HAM modes and have >14bit sound. SDL would not allow this on such a limited platform, and I would it even >allow you to reach such a low level? I doubt it.

I do now compare on my winuae system and notice the SDL version is only 10 % slower.in numbers it is 91 fps sdl_quake and 99 fps quake68k on a 1920*1080 fullscreen 8 bit

so there is no hope that you can

>There are decent games like Diablo, Age of Empires or Starcraft that run happily on a >640x480 8bit screen.

this are not so speed critical stuff, as a action shooter or jump and run with scrolling.
If there is a SDL version here, then there are good chances that it is playable, maybe with low samplerate

>I quite happily play 14bit multi channel ADPCM music on my A1200/030, and it sounds >brilliant. And the machine has plenty of bandwidth for other tasks.

can you post a link of such a song and player ?.and the 7 khz filter of your amiga need set to off.have you hear the music over headphone or a good stereo sound system ?

maybe with the 1084 monitor speakers it sound ok, but with a good loudspeaker it sound very bad.

for amiga the only player which can do good quality is octamed soundstudio when you enable in mixing routine stereo and filter and can reach better quality.but then a simple 4 channel song use full cpu load on a classic.try it out, if you not believe.

but its possible to change sdl mixer that it do crappy nearest soundmixing to be faster.maybe there is a option so nearest sound mixing is possible.

but this give only little speedup, actual games are design that there are at least 11 channels here.11 channels is the default of sdl_mixer.if a developer need more he can enhance.

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

As far i know no 2D gfx card have HW accelerated alpha blits.Or do you know any for amiga ?

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

@Crumb
>what? sorry, I strongly disagree because Quake on classics is mostly cpu limited and >its use of SDL is limited to:
>a) locking display bitmap, writting the pixels directly to gfx ram or...
>b) performing a raw copy (just like WritePixelArray on RTG)

thats true, netsurf SDL work the same way, but when you look how games work, then you see that code do only copy some bytes to gfx buffer.

and this copy operations are limit by GFX Bus access.
sdl is very fast, it convert any bitmap format to screen bitmap format.
if somebody want write a game for amiga RTG, he must write code for do this.P96 or CGX functions are not so fast, because i test what happen when i use instead of SDL blit operations the CGX functions direct.was slower seem CGX do also have more calling overhead.a simple 1 pixel blit was slower in P96 too

also SDL use runlength encoding for 1 bit alphamasks and prepare the images to faster blit.this is too faster, it avoid lots of mem access and check for mask operations

and when you write a game that run on RTG you have of course no copper or can do some display tricks smooth scroll etc.

[unusedunused]

>The problem is coding 2d games using graphic card as a big framebuffer instead of taking >advantage of accelerated blitting and scrolling. And the problem for modern games is >that you could be using Warp3D to move 2D images using hardware resources instead of >transfering one dozen of megabytes per second. Just upload your gfx to RTG ram >configured as textures and move them using Warp3D instead of cpu: you'll reduce bus >bandwitch required to move the gfx and will require a less powerful cpu

thats theory, who have a fast RTG system that is able to use warp3d ?
when you use SDL 3D Games then all can do with GFX card.but when 3d games are written for SDl, PC have speed at 500 MHZ and more and much faster GFX bus and no limit of 256 Pixel texture size of Voodoo 3.

wawa have work much to port some usable 3D games to classic.but the 256 pixel texture limit was the problem in voodoo 3 and the limit mem in compare to modern systems, because every game use a background texture of screen resolution.this mean at least 640*480.

and last very few users own a voodoo 3.most users have a GFX card with only 2 or 4 megabyte of RAM.thats too few

I have written a game engine for amiblitz and storm mesa, but nobody write a fast working game for it, and Thilo choose his own 2d engine that can do some blits on 2d Card.

but  also this is not able to play a modern game fast on a classic.for example the game amega one

http://www.a1k.org/forum/showthread.php?t=18578

or panzers

http://www.a1k.org/forum/showthread.php?t=14115

is too slow to play on 640*480 on classic

any help is welcome to make this games playable on a classic.in amiblitz you can write asm code and some routines are asm optimized.but if the GFX bus can not transfer more data is the main problem

[unusedunused]

Bern is author of SDL version of Netdurf, so in this case 3d tests are useless.

I am not the author of netsurf SDL.Artur do a alot and great work on netsurf to add features that netsurf sdl version(in mains source do not have).In newest netsurf artur use agar GUI for GUI in some gadgets

http://libagar.org/

, i do not like the mix, i have told Artur, because i fear some hang problems due to message lost.I am not familar with that

But the sdl version can better update with new core, and if the standard core not run on amiga, i help Artur.

All other do Artur alone in great work.He have done lots work to bring a browser to amiga.

when no Artur was here, i only compile from time to time the sdl version and release it and before no java script is in, i do not do any work to enhance it.

[unusedunused]

Ah sure. It might work with 8 bit graphics.


Is your engine publicly available? If so, then where? I wouldn't mind doing some experimenting with it.

its in sourceforge for amiblitz 3.it work in amiblitz 3, there is a demo in the amiblitz3/sourcecodes/includes/gl.bb2 include.

amiblitz execute the example if the file is not include and is use standalone.
see here the syntax of that example program.its easy to bring 2d games to 3d, because you can choose a virtual coordinate system.I decide to use stormmesa, but native PPC stormmesa do not work with new OS4 warp3d.because OS4 devs remove a feature in warp3d that stormmesa need.If it work on MOS, i dont know, because no intrestet user have MOS and want test.

The code below produce this testimage.later version should load milkshape objects make out of 2d easy 3d with depthmap etc.but because stormmesa is not go to a standard GL API, i give up, because i dont want do special native versions.and thilo do continue his 2d engine  

CNIF #__include=0
  ;Amiblitz 2 test for opengl
  Syntax 2  ;the relax declare mode
  optimize 7

  WBStartup


  .begin
  width.l=320:height.l=200
  gl_init{width,height,16,0}  ;the screen open
  gl_2dview{640,480}          ;need to set coord leftedge=0 rightedge=640 and hold size of pics
                              ;depent on this resolution
                              ;topedge=0 and buttom edge=480
                              ;on default ogl use leftedge=-1 rightedge+1 top +1 buttom -1
  gl_load {0,"data/pattern"}
;  Stop
  gl_load {1,"data/ball64x64",0}
  gl_load {2,"data/reflect.jpg",0}
  gl_load {3,"data/times32.png",0}

  gl_sphere {4,40,0,15,15}            ;create the sphere at beginning for more speed.But possible on all place
  gl_cylinder{5,110,30,50,0,15,15}    ;a cylinder with texture 0
  gl_cylinder{6,110,30,50,2,15,15}    ;another cylinder for the reflection with texture2
  gl_quad{7,50,50,50,0}
  gl_quad{8,50,50,50,2}

  .startvals
  zval.f=0:xval.f=320:yval.f=240:trans.f=255:yvallight.f=yval:rot.f=6:tsize.f=1:rot.f=84
  Repeat
    ev.l = Event
    Select ev
    Case #IDCMP_RAWKEY
      Select EventCode
      Case $4e : xval+10
      Case $4f : xval-10
      Case $4c : yval-10
      Case $4d : yval+10
      Case $13 : rot.f+6
      Case $45 : ev=#IDCMP_CLOSEWINDOW
      End Select

      Select EventVanillaKey
      Case @"q" : zval-10
      Case @"a" : zval+10
      Case @"t" : trans.f+10
      Case @"g" : trans.f-10
      Case @"m" : tpos.l+2
      Case @"Q" : yvallight.f-10
      Case @"A" : yvallight+10
      Case @"s" : tsize.f*1.01
      Case @"S" : tsize.f*0.99
      ;Case @"r" : rot.f+6
      End Select
    End Select
    FlushEvents
    ;If light Then glEnable_ #GL_LIGHTING: Else glDisable_ #GL_LIGHTING


    ;this example Show all what is possible with that 3dlib
    gl_blit{0,xval,yval} ;simple blit a image
    gl_light{ 0,320,yvallight,0,255,255,160} ;switch on a yellow spotlight
    gl_color{255,150,150}         ;tint texture red
        ;blit this image
    gl_texcoord{0,tpos,0,128*tsize,128*tsize} ;for scroll the texture with m key
    gl_blit{0,xval+128,yval}      ;and blit


    gl_light{0}                   ;now use the default light.
    gl_blit{1,200,yval,zval,-1,0,0,rot} ;another image but rotatable -1 mean make that not transparent

    ;now blit a reflective object
    gl_blit{7,xval-128,yval-128,zval,-1,rot+15,rot+15,0}
    gl_texmode{3}       ;now switch on the spherical mode for the reflect effect
    gl_blit{8,xval-128,yval-128,zval,255,rot+15,rot+15,0} ;blit the reflection map

    gl_light{ 0,220,yvallight,0,255,255,160} ;switch on a yellow spotlight for the font

    gl_usefont {3,32,32,0.3} ;use picture 3 with 32*32 tile and scale the font by 0.5
    gl_textcolor {220,220,220,200} ;we dont want the color of the bitmap
    gl_print{"test",48,200}        ;print 2 lines
    gl_nprint{" 2. Part"}          ;print 2 lines
    gl_textcolor {0,200,255}       ;change color again
    gl_print{"This is a line scale to 0.4",65,230,0.4}
    gl_light{0}                    ;default light

    gl_color{160}           ;make 2. ball a little darker only 1 color mean r g and b is set to 160
    gl_scale{2.4,1.0,1.0}   ;size the ball in x
    gl_blit{1,300,yval,zval,trans,0,0,rot} ;make the ball transparent choose with g and t
    gl_blit{4,300,100,0,-1,rot}

    gl_color{255,200,0}
    gl_scale{0.3,1,1}
    gl_blit{4,320,250,zval,-1,-1,rot,-1}     ;blit another sphere but diffrent color and size


    gl_color{140,70,140}                     ;blit a reflective cone
    gl_scale{0.5,1,1}
    gl_blit{5,180,370,zval,-1,-1,rot,-1}
    gl_scale{0.5,1,1}
    gl_texmode{3}
    gl_blit{6,180,370,zval,255,-1,rot,-1}

    gl_texmode{3}
    gl_blit{6,320,270,zval,150,-1,rot,-1}    ;blit the transparency cone

    gl_nprint{"Key r=Rotate "+Str$(rot),360,0}
    gl_nprint{"m=Move Texture",360}
    gl_nprint{"s=Size Texture",360}
    gl_nprint{"Crsr = move",360}
    gl_nprint{"q    = z +",360}
    gl_nprint{"a    = z -",360}
    gl_nprint{"Q    = Light y +",360}
    gl_nprint{"A    = Light y -",360}


    Delay_ 1
    gl_show {}  ;show the render and clear all realtime effects (it call gl_reset)
  Until ev=#IDCMP_CLOSEWINDOW
  End
CEND

[unusedunused]

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

this give me the idea, to create for the SDL display a Warp3d context and implement for SDL hardware alpha blit function a function that paint a rectangle with texture in warp3d.
or look at other SDL implementation that use for this opengl.
so the Limit is not SDL.When a natami have a alpha blit function, natami can do too all blits lots faster with the blitter.and the CPU can init in the time the blitter work, the next alpha blit.so all work in same way as amiga blitter but with alpha channel

As i write before, SDL is not bad written, it have less calling overhead in blit functions as P96 and CGX.
Only on Amiga there is no hardware alpha support, and all need done in software.

On classic is 256 pixel texure limit, but the blit can split in diffrent calls automatic.

maybe i should ask natami devs, if i can get a natami to add SDl and hardware alpha support for natami. ;-)

But i am really lazy, maybe somebody else can do it.

Here is an old video from AmiTopiaTV which has a clip of me at the start playing Day of the Tentacle on my 8MB 68020 A1200 through WarpSDL. Just to show that an AGA-native SDL library can work, and that it's not too slow at all (this version of SCUMMVM runs far faster than any other, DOTT isn't playable even on my 030 unless I use WarpSCUMM).

[youtube]E9uGOOv6uxA[/youtube]

Video: http://www.youtube.com/watch?v=E9uGOOv6uxA
WarpSDL: http://www.algonet.se/~chaozer/warpsdl.shtml

the good thing on scumm is, that not the whole content of the display need redraw with 20 or more fps /sec(SDL can check to only redraw changed parts), and scumm games are very old.most games do not more as 320*240

Remember when the last lucas arts adventure with scummvm is release, and how much CPU power was here.

because when lucasarts scumm script system was program, PC are not fast.

but look when most SDL games are written.

SDL support alpha in Hardware, so if maybe the natami support a OS function that can blit alpha in hardware with blitter, then SDL can run lots faster.

SDL blit have less call overhead as P96.

I forget to write before

sdlquake and quake68k use only software render

[unusedunused]

Conclusion:

SDLquake is 37%-22% less speedy than clickboom's quake

Such a low spec machines every frame is important. Good result any way, I would ques that it is much more worse.

then try the test.let somebody else start sdlquake or quake68k in random order.
Now you need tell in 20 tries correct what version is faster.If you can tell this in 100% of the tries if the game run in 3 fps or 5 fps, then you are really good.

I know from my own tests, it doesnt matter, the game feel too slow.so you can see a classic is not able to do games in 640*480 16 bit

and quake is a good case test, remember quake have only 8 bit screen.When you use a 16 bit screen all go slower

@matthey

have you use for sdlquake the version i upload ?
the old version is lots slower.

Artur have use for all his games new SDl

[unusedunused]

I think both of you are doing a good job but I wonder why you don´t adapt OS4 Reaction/ClassAct code as that would probably bring a notable improvement in usability and a good speed up in GUI too. In addition to that I would get rid of nasty ixemul and would use libc2 or libnix instead.

Uploading dependencies sources to Aminet would be helpful too I guess, perhaps that way somebody gets more interested in helping.

Reaction GUI look very ugly, itix have done years ago a MUI interface for netsurf.thats the better choose, and we begin to port MOS MUI netsurf and it work a little.

But netsurf team change the backend interface lots, so itix version do not work with newer netsurf core.

itix does not want change code to new backend interface and give up netsurf for MOS.
I can understand him, its really not nice what netsurf developers do, they often change their API

So netsurf 68k use SDL, because SDL is mainted by a netsurf developer and all backend API changes he add in the SDL code.so amiga version can more easy keep upto date.
and when netsurf developers get not the idea to change backend api lots, then netsurf 68k have a MUI interface. ;-)

but netsurf dev change backend API, so netsurf 68k use SDL. ;-(

and only when java and doom work in netsurf, i have motivation to do more time spend on netsurf.

[unusedunused]

Reaction is not that ugly and it would be much easier task than start from scrats with MUI

the reaction flat non shaded GUI elements from reaction i find more ugly as the current GUI elements in Netsurf
But when use zune MUI programs can look nicer.there is a MUI GUI for netsurf too here.
and OS4 reaction work diffrent as OS3 reaction.and OS3 reaction is a dead end.no enhance possible.MUI can enhance in zune.

also reaction can program really bad, class render is done in input device task.this mean if something fail to render in netsurf class, the whole amiga is dead, because when input device crash, no program can get mouse messages, or keyboard messages.

debuggers can not work to show correct errors.
all in all i see Reaction as a bad design.I do not like MUI too, because i want a GUI system that need not compile in the program code, and i want a GUI Editor, but at least MUI does not render in input device task.

Why not make better screen support? 8 bit screens? Amiga fonts? That should be possible wit SDL also. It would make lots of more useability to it and with Reaction/MUI gui it would feel like native amiga program.

the answer is simple. no sense see to spend alot work for this.and for something that make not fun, money is maybe a motivation.

Here can look on OS4, user pay for lots that is on other systems free(for example firefox and other bounties).But on 68k nobody do bounty, but whine when netsurf not run on a non gfx card system faster as on a fast PC.

I have the feeling some classic users want not pay any cent to upgrate their hardware.
But they want that developers work day and night for free, so that software that run on fast hardware run on their slow hardware too, so they need not put any cent to upgrade the amiga.

Instead the developer should spend work for free to strip the software down so it work on a Amiga.

what advantage should bring to use amiga fonts.I see only lots more work.
the fonts look ugly for inet pages.and noticable faster it not get.

I have written in older post, compare the netsurf load time with internal fonts(internal fonts work  lots faster as amiga fonts) and truetype fonts.
If it really get faster with internal fonts, its possible to disable the antialiasing of the fonts.this cost most speed.

but as i told before, in real world pages, font render time is not very speed critical.most time is need for CSS layout, image decode and image show.

Software development cost lots time, so a good developer need to choose, time to add a feature and the usability of a code.
because time is short, then time need spend for features that bring a really good and usefull enhancement.