Curse of the SDL

[matthey]

Conclusion:

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

With or without hardware Warp3D support? Since Bernd's version of SDL uses StormMesa->Warp3D, that could make a huge difference. The CPU and gfx card could also make a large difference to the percentage. It would be more useful information to post your specs and settings with the results.

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

Yea, a couple of frames per second difference is a lot when below 15 fps. There are plenty of possibilities for speed up of that amount. CyberPatcher type "missing" instruction patches can be valuable on 68040 and 68060 and CopyMem and other system patches and enhancements can help with 2D or 3D. For Warp3D hardware acceleration, there is faster 68k enhanced Warp3D libraries (originals are poorly optimized) and setting the Queue size larger in indirect mode (default with StormMesa and SDL I believe) with an environmental variable can help significantly. QuakeGL/BlitzQuake in 640x480x16 runs at good speed once the textures are cached on my 060@75MHz Amiga. The slow Mediator bus speed isn't as much of an issue then. Fast games are certainly possible at 640x480x16 on high end Amigas but usually require some attention to optimizing and most Amiga compilers don't generate very optimal code.

[matthey]

Clickboom's quake doesn't do warp3d. I belive that with warp 3d support result would similar, ie. sldquake / glquake

Hardware 3D support gives a significant speedup. Here are my results with CSMK3 060@75MHz and Mediator with Voodoo 4 but no Cyberpatcher type patcher...

640x480x16
-----------
Frank Wille's Quake 3-4 fps
Clickboom Quake060 4-5 fps
QuakeGL 20-25 fps (looks best too)

640x480x8
----------
Frank Wille's Quake 4-5 fps
Clickboom Quake060 5-6 fps
QuakeGL No 8 bit hardware 3D support on Voodoo 3+

Hardware 3D acceleration does matter. It's probably more important with a slow bus.

It is 060 version, it much faster than original exe with 040 also.

It's not that most compilers do a good job of optimizing for the 060 but rather that 040 compiled code doesn't run very well on the 060.

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

Yea, 3D hardware acceleration isn't going to help much with Netsurf unless it can be used like kas1e does for his disk mag which is fast and nice on the Voodoo.

Maybe 80% todays classic amigas has at least 030 and 64mb ram? Maybe 50% has 040/060 with at least 64mb ram? 40% has a somekind of RTG card? 20% has a mediator or similar with at least 8mb ram on their garphics card?

Those are plausible guesses of what power classic Amiga users use. Hopefully the new fpga Amigas will help out those numbers and give some additional 3D accelerated hardware options.

[matthey]

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

20-25 fps is too slow for Quake? I think it's pretty playable. Putting the textures on the 3D gfx card avoids most of the gfx bus bottleneck. This can be used for bitmaps in 2D also as kas1e did with the Vague mags where the graphics are fast and crisp. SDL could do this transparently for 2D also so users with a 3D card get a fast and pretty display while users without get slow and ugly . There is plenty more room for speedups in W3D too. I would be more motivated to optimize if there were more programs using W3D.

@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

Yes. I used the version of SDLQuake you linked. It didn't seem to use StormMesa->Warp3D even when I selected 640x480 16 bit PC. It was slow and ugly (like 8 bit). Shouldn't it use  StormMesa->Warp3D automatically if the version of SDL linked is new enough, SDL 3D is used, and the screen mode supports hardware acceleration?

Also, Why hasn't the SDL library as an Amiga shared library caught on? It doesn't make much difference for games but there is a huge advantage to share code when it's used in utilities (e.g. a web browser) as a gui.

[matthey]

sdl_quake was not much slower as clickboom quake on gfx card, see test from matthey.
and sdlquake on my system was too not much slower as quake68k.

Actually, my test was with Frank Wille's version of Quake also. I tried the SDLQuake once but figured Frank's Launcher was a Launcher for SDL_Quake that allowed options. It looks like SDL_Quake uses 640x480 by default. It may be 16 bit as it looks better than Frank's Quake in 8 bit. Here are the results I get with defaults...

SDL_Quake 3.3fps 3.4fps
SDL_Quake_3.4 3.8fps 4fps

This is with timedemo demo1 like my other results. The second number is with MuRedox that avoids trapped instructions. Notice that the GCC 3.4 compiled version is faster despite possibly using more trapped instructions.

[matthey]

@bernd
Why not use Warp3D on Amiga's with 3D hardware for 2D SDL? Use textures for 2D bitmaps and then there is MUCH more control of what is "blitted". Once the textures are on the card and if there is enough memory for all of them, then the gfx are as fast as the 3D card instead of being limited by the gfx bus or the 68k CPU. The Vague magazine works great in 2D using Warp3D. It's fast and flawless. kas1e has given tips to using Warp3D like this. I bet he would even let you see the source.

[matthey]

I have suggest that earlier in thet thread, and i tell, i have no to time to do it with warp3d.i never use warp3d and i want not learn it.its obsolete.maybe somebody can do a poll how many amiga users with a Voodoo 3 card are here with enough memory and how many of them are intresting on SDL games.

Warp3D is easy to use and logical but I hear you about becoming obsolete. I expect that Warp3D.library will use Gallium at some point instead of talking to the hardware directly. Using Gallium directly would probably make better sense when it's ready in AROS. Classic users aren't going to use AROS until it's better optimized though. It's always the chicken and the egg problem on the Amiga isn't it? I think some Natami users will use a PCI gfx card also until the 3D engine in Natami is ready and maybe afterward. I expect the gfx card will be faster but less flexible. There is also talk Karlos releasing a 68k version of his Warp3D Radeon driver over on Amigaworld.net. My point is that the user base of 3D gfx cards on the Amiga should grow. I can see your hesitation to develop for an unknown future direction though. There's no big hurry anyway.

I guess not very much.Problem is also that new SDL games use mostly more than 8 megabyte that have voodoo 3 as texture memory.

The Voodoo 3 has 16MB and Voodoo 4-5 32MB usable. This actually goes pretty far with 2D bitmaps as there are no mipmaps necessary. The Voodoo 3 256x256 texture limit is a pain though. I think I can get the Voodoo 4-5 Warp3D library to do large textures but I'm waiting until the Voodoo 3 driver is more complete and optimized before making a Voodoo 4-5 (Napalm driver). I'm currently working on ADis at the moment though.

its also not clear what problems happen with warp3d. Some programs want direct access to the bitmap and poke in some data.

Poking the data is a bad idea. Warp3D takes the bitmap/texture in the format given and converts and creates a texture on the gfx card in a native and efficient format to use. The original data can be poked if Warp3D is made aware of it but then the data has to be converted and copied through the slow gfx bus again. It's probably not a good idea to try and poke the texture directly in memory even with the hardware locked. I don't think Warp3D provides any interface for that either.

[matthey]

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.

True, Warp3D currently has no API for this.

I remember from winuae native warp3d, that freespace 68k too poke in graphics memory(the cockpit and video).if you can debug warp3d function calls, maybe you can look how freespace do that.
but how this must program in warp3d i dont know.there need somewhere a buffer flush that all polygons are draw and then the program do a lock of the buffer with CGX function.

It would probably work to do something like this...

W3D_SetState(context, W3D_AUTOTEXMANAGEMENT, W3D_DISABLE);
texture = W3D_AllocTexObj(context, &error, tags);
W3D_LockHardware();
if (texture)
  poke (texture->texdest);   // texture location on card defined in Warp3D.h
W3D_UnLockLockHardware();

This is a violation of the API but it would probably work with most gfx cards. There may be gfx card specific reasons why this would not work though. It would be much safer and more flexible but slower to alter the source texture/bitmap and call W3D_UpdateTexImage() to convert and copy it to the gfx card as a texture. Converting could be avoided if all the texture/bitmap data was converted to the display format. This should still be advantageous if most textures/bitmaps don't change.

[matthey]

I guess they do not alloc a texture and do just render, after 3d is draw to the P96 screen. Thats the easiest way.

That is basically what is done if no conversion of texture format is necessary. A pointer to the texture data and a tag for the data format is passed to W3D_AllocTexObj(). That texture data is copied to the gfx card as needed if no conversion is necessary. A native version is created by converting first if needed. Most Warp3D programs use W3D_AUTOTEXMANAGEMENT which swaps textures in and out as needed but it can be turned off allowing the programmer to control when textures are put in or removed from gfx mem.

I see a simple program that too have problems on winuae quarktex.its
the warp3 test demo of warp3d dev .the text is not see.

Here can see, in source warptest.c in DrawWall func.they just put text in the window rastport.I test with wazp3d the software warp3d. strange is the text is draw after

W3D_UnlockHardware

 Hardware and always draw below 2 triangles for 3d quadrat(zoom full with cursor up).but the 3d is draw before, so text should normally always on top.what happen with your voodoo 3 ?

The coordinates are drawn correctly here. I believe it's proper to draw after W3D_UnLockHardware(). I believe W3D_LockHardware() waits for the gfx card to be idle and then blocks (Forbid or Disable) any other programs from using the gfx card. The debugger won't even work after a W3D_LockHardware(). Holding this lock for too long will likely cause the machine to freeze.

but luckily opengl programs are not written in such a way, that it access data in screen direct, so its not big problem.but for SDL need direct access, either before or after render.
and maybe warp3d work, when call warp3d unlockhardware every time a sdl program call a SDL  lock.should not too slow, because SDl programs call only every frame a look

It's safe to change the original texture data and inform W3D of the update. It's probably NOT safe to change the texture in gfx memory. It's probably possible if carefully done but it violates the W3D API and may not work on all versions of W3D or all gfx hardware. Doesn't SDL go through OpenGL or DirectX to access the gfx hardware?

[matthey]

you seem not understand the example program, the program do not modify a texture data, it do write text in same way as any Amiga program do.Text is a AOS graphics library function, and no warp3d specific

Text(window->RPort, buffer, strlen(buffer));

when you look on init you see that window variable is the result of a AOS openwindow Call.

struct Window *window;  

That looks fine to me. There isn't any W3D screen or window calls. Bitmaps are the target of W3D function calls. Intuition screens and windows are supported. This allows function calls like graphics.library/Text() to be used where there is a RastPort pointing to the same bitmap.

[matthey]

if this is legal, then its maybe possible to get SDL 2D working with warp3d and also direct access to bitmap can work.when a program want get a SDL lock to access the surface direct, warp3d need tell that it should draw all currently added quads.and if a user not call SDL lock, then all is draw in SDL_redraw commands.

I think that's close to working but...

1) Would SDL try to access the SDL surface memory outside of this bitmap? Warp3D would provide clipping of the SDL surface that is off the bitmap but once clipped, there isn't any bitmap memory outside of the clipped bitmap.

2) The SDL surface "changes" would not be alpha blended. Accesses to the SDL surface (now bitmap) would only work where the surface replaced (pasted over) what was in the bitmap.

[matthey]

Poking the native texture surface in warp 3d is a bad idea. It's abstracted away for a good reason. The permedia alone will do your head in, you have subpatched addressing that makes any simple linear sequence of texels considerably more awkward to access.

I know it's a bad idea. I was just pointing out that it's easy to figure out where the textures "probably" are on the card. If the Permedia can't access the texture in VMEM as a linear "bit map" then it's highly probable that SDL doesn't do that either. It probably allows access to a copy of the texture in main memory and copies it to VMEM through the gfx bus much as would be needed with Warp3D. It's just that it's slower on classic Amiga's with a slow gfx bus . I think it would still be faster than copying the whole visible bitmap from main memory to VMEM every frame in cases where the textures/bitmaps are small, seldom poked, and don't need to be converted).

Are you the author of the 68k Warp3D Permedia drivers? If you are, there is a floating point rounding bug with at least one variable of Warp3D which kas1e (author of the Vague magazine) pointed out to me. Any chance of getting a fix for that or are you prohibited again? I guess wrong colors with the Permedia driver isn't as bad as trampling innocent memory trying to write the Zbuffer with the Avenger driver.