Curse of the SDL

[utri007]

I can't run tests now, need to wait tomorrow. I feel hard to belive that clickboom's quake would reduce screen size. Double buffering is not eneabled by default, if I want to use it, I need to turn it on.

Edit:. Sorry, yes double sized pixels, same thing, if I want to use them I need to turn that feature on.

[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.

[utri007]

Thanks matthey it is actually nice to see that somebody else is making same mistakes than me

But it seems that SDLQuake is doing same results, than Frank's quake port with hires screemodes.

BUT as have been said, this is quite useless test. Is it so that you have used Frank's engine with your SDL port? So you know how small SDL role is with this test.

[unusedunused]

Thanks matthey it is actually nice to see that somebody else is making same mistakes than me

But it seems that SDLQuake is doing same results, than Frank's quake port with hires screemodes.

BUT as have been said, this is quite useless test. Is it so that you have used Frank's engine with your SDL port? So you know how small SDL role is with this test.

If you believe what a user tell that seem have not done any test on SDL and CGX or P96 its up to you.

If some of the "cgx/p96 is faster as SDL" experts can tell me exact how i need write the testprogram i can do so.

But i never will spend time to write a own testprogram, because i am 100% sure, the "experts" bring the excuse when show that SDL is faster as P96/cgx that i have written the program wrong.

The performance of a game depend on the speed of mask blitting, because all game objects are not simple rectangle with no transparent.only the large background can blit without mask.

And mask blitting is on P96 not very fast, and is done with the CPU.when you have the bitmap in gfxcard, then the background is multiple overwritten. bad for this extreme slow GFX Card Bus of amiga that is used on mediator and A1200.

SDL is the best and fastest Game Engine for C on amiga, i have at least done enough tests to verify that.

My first idea was too, just wrap the the SDl blitfunctions to P96 Blit functions.but it was slow as hell then, mostly on mask blit.

i use for test openredalert, that do many small blits of the small soldierm cars etc, with mask blit.

and use of a real alpha channel is not possible with CGX/P96, no hardware and CPU support
real alpha calc is extrem slow to do with CPU.o games that use real alpha are more unusable on a classic.

>BUT as have been said, this is quite useless test. Is it so that you have used Frank's engine with your SDL port?

sdl_quake is only a quick compile of Linux Version on amiga, no changes.sound is done too with sdl.

[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.

[unusedunused]

@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.

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.

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.

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

[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.

[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.

[unusedunused]

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.

there are many programs that poke data direct.for example to draw dots of a starfield, or lines or arcs a lock is call for SDL surface and it use the surface address to put data into.

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 programm do a lock of the buffer with CGX function.

[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.

[unusedunused]

True, Warp3D currently has no API for this.



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.

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

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 normaly always on top.what happen with your voodoo 3 ?

Code: [Select]

....
W3D_UnLockHardware(context);

SetAPen(window->RPort, 249);
RectFill(window->RPort, 638,0,639,1);

// If the user flipped the bflag on, draw the coordinates at the
// polygon vertices

if (bflag) {
SetAPen(window->RPort, 255);
for (i=0; i<4; i++) {
#ifndef __STORM__
Move(window->RPort,(long)TempSquare[i].x, (long)TempSquare[i].y+(1-bufnum)*480);
sprintf(buffer, &quot;%3.2f,%3.2f&quot;, TempSquare[i].z, TempSquare[i].iz);
Text(window->RPort, buffer, strlen(buffer));
#else           /* compiler bug workaround */
float temp, temp2;

temp = TempSquare[i].iz;
temp2 = TempSquare[i].z;
Move(window->RPort,(long)TempSquare[i].x, (long)TempSquare[i].y+(1-bufnum)*480);
sprintf(buffer, &quot;%3.2f,%3.2f&quot;, temp2, temp);
Text(window->RPort, buffer, strlen(buffer));
#endif
}

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, becsause SDl programs call only every frame a look
 
I think use for MOS warp3d in SDl is too usefull, because the efica CPU is slow, and so efica can play fast SDL 2D games too

[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?

[unusedunused]

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.



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.



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?

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 variabale is the result of a AOS openwindow Call.

struct Window *window;  

......

// Open window
   // While this is not strictly nessessary, we use it because
   // we want to get IDCMP messages. You can also use the screen's
   // bitmap to render
   window = OpenWindowTags(NULL,
      WA_CustomScreen,    (ULONG)screen,
      WA_Activate,        TRUE,
      WA_Width,           screen->Width,
      WA_Height,          screen->Height,
      WA_Left,            0,
      WA_Top,             0,
      WA_Title,           NULL,
      WA_CloseGadget,     FALSE,
      WA_Backdrop,        TRUE,
      WA_Borderless,      TRUE,
      WA_IDCMP,           IDCMP_CLOSEWINDOW|IDCMP_VANILLAKEY|IDCMP_RAWKEY|IDCMP_MOUSEBUTTONS|IDCMP_MOUSEMOVE|IDCMP_DELTAMOVE,
      WA_Flags,           WFLG_REPORTMOUSE|WFLG_RMBTRAP,
   TAG_DONE);

[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.

[unusedunused]

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.

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.

[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.