Curse of the SDL

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

[unusedunused]

There are some pointless projects (about www), I don't want to say what and others doesn't know what kind of web broweser Netsurf is, so they think that A-Web is more usefull.

Here http://eab.abime.net/showthread.php?t=43738 somebody said that that "I maybe would consider doing an OS3 ReAction-based port, I'd have to be convinced that it was much better than AWeb though, which I'm not. There's no menus on this version (!) so I'm not sure what features it offers, if any."

I don't have enough knowledge and english is not my motherlanguage, so I woun't bother to arguing him.

So Bern do you know where is Netsurf feature list?

1. Get smaler memory footprint, 8bit screens would help?
2. Disable requirement of true type fonts so that it would work with AGA
3. Give it a native GUI

Boynty is allways possible and I belive that many would take a part in it. BUT somebody who have needed knowledge should do it.

PS.

Clickboom's Quake outperforms SDLQuake and with 060 and AGA more than 6FPS, 14,58/FPS. I couldn't get SDLquake run  AGA screen on my 060 machine.

you have forget to switch clickbooms AGA Version to 640*480

Or maybe when AGA is choose there is only a very limitet screen used.maybe 200*160 so that it is playable.

please make a screenshot, that show clickboom quake on aga  

>True, but there are also people who want chipset+680x0. People who aren't interested in >PPC+GFX card. I'm one of them. If I want more speed then I'll just use my peecee. If I >want better graphics then I'll just use my peecee. And so on.

yeah and then you can use winuae faster and all this stuff on amiga OS too.
this help the programmer for 68k that they can faster develop.

But thats what i guess too. All that have no gfx card and slow amiga use mainly a PC and only want to test if a program can run.maybe they have fun to tell their friends look my amiga can run firefox.

And when the friend is gone the amiga guy use his PC to do that faster or in case of games in better image quality.

But its really frustrating for a amiga developer when guys have a fast PC, but want that the amiga developer should spend lots additional work, to get that on a real amiga working, so that the slow amiga guys have the feeling that they need no faster amiga and its possible with their old machine

Wy do the guys that want the software on real amiga working, not develop to get the softwarer working here on here loved system, or do a bounty ?.

Guys  on slow amiga are not very active, big amiga only stuff as amiblitz, netsurf, hd-rec etc, all is done from developers with winaue.at least on 68k there develop some on good competite to PC Soft programs.On other AOS platform there are only Linux Ports, or some small and not comparable to PC Software projects

important for me and many more is use the software on amiga OS to have the look and feel of amiga OS window handling, desktop etc.I like dopus magellan and amiga window management (i configure click window to front with mid mouse key and back with shift mid key.)

On what hardware it run, doesnt matter for me.

this can see that most users use emulator or systems as vmware to run more OS on same Hardware together.

I need no extra Hardware when i know my PC can do it

[unusedunused]

@utri007
>SDLquake allows with aga only choose PAL/NTSC, and NTSC is choosed, otherwise I've >choosed CGX screen 320x200 8bit

i dont understand you, sdlquake work not with AGA and default in 640*480.
if you mean clickboom quake and AGA ntsc is 320*200 and pal setting is 320*240.
when you choose ntsc setting, the width is not really 320.it is 266 Pixels.so there is some black gap on side.

its because quake is a 4:3 aspect ratio Game.this mean 200/3*4=266 width.

so its of course faster as in PAL in NTSC.

but you not find any SDL game that run in 266*200 Pixels.
266*200 53200 Pixels the computer need calculate and transfer to GFX Card.

320*240 =76800 Pixels.

640*480 are 307200 Pixels.

this mean 307200/53200 = 5.7

So a computer that play the game at same framerate at 640*480 need 5.7* faster as a computer that play the game at 266*200

quake is because of opengl able to run on all resolution because it use 3d and scaling.but you see quake graphic is more ugly as a amiga game for 320*200

2D games are written for a fixed resolution, so you have lots work to do all graphic for lower resolution.

>For me is important to have actual hardware, tune it to limits

then tell me a reason wy somebody should spend alot of time to get software on your slow amigas working ?

another solution is, you learn programming and spend the time to do it yourself.wy do you not do this.It is not so hard.only you need lots time.if you have no time for this, wy other should have time for this ?

I like too when all this modern software can run on a A500, but i know its just impossible to run it in same quality as on a faster system.Time is short, life is short, there can lots more and more intresting do, as make software running on a slow system

In the early amiga days no computer was able to run games as good amiga can do.so all must live with the 320*240 quality.but when today can play the same game in 640*480 16 bit or more, wy should play it in 266*200 in AGA ?

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.



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.

sdlquake use no 3D.only software render.
Normaly need link with a libsdl that open not stormesa when a program not use SDL GL.but i have compile the version only for my tests.see the date, its some years old.

I only want see if SDL is fast now.and it is fast, speed is near same as quake68k.how fast clickboom quake is and if it have some optimized 68k asm routines i dont know.sdlquake have of course no asm code.

If you have time and knowledge to do a amiga shared library for sdl you are welcome to do that.Problem is SDL have more than 300 calls to opengl.thats alot of work

the old shared SDL do not support opengl.so there need new lib files and stubs create for GCC.

sdl is not big, only around 70 kb.that the files are larger is because i release all libs with debugging symbols.if somebody really want save some kb, he can strip the exe with the strip command.

>20-25 fps is too slow for Quake? I think it's pretty playable.

this i think too good playble.

But i dont think if you notice a diffrence when you not measure it, when quake run a few frames faster.for example 24 instead of 21 fps.

[unusedunused]

>If you are so interested in comparing CGX&SDL performance it´s not complex to write a >small app that performs operations colour conversion, blitting with different sizes, blitting >with mask... and then compare the results.

color conversions are not need in SDL Blit.SDL games should convert all loaded image to screen format first.

if((temp = SDL_LoadBMP(filename.c_str())) == NULL)
object = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);

SDL_DisplayFormat do the Job.

so a blit is only a memory copy.and sdl 1 pixel alpha blit(mask) software func is lots faster as P96 or CGX can do.read the theory

http://old.nabble.com/RLE-Compression-td22985131.html

P96 and CGX can not do this mask blits in Hardware on amiga GFX Cards on cgx screens.all is done in software with the CPU.i see that with debug the functions.
P96 speed offer no test for mask blit.they know wy, because its realy slow on amiga.or do you know a amiga speed test that test mask blits.here you can see if this is slower as normal blits it work not in Hardware

more than 1 bit alpha(mask blitting) support does CGX or P96 not support.but this is much more slow.today all SDL games need more than simple mask blitting.

because blits are simple memcopy operations, all depend from memspeed and gfx card speed.thats the weak point of the amiga.also that amiga GFX Cards have not much RAM

>If you are so interested in comparing CGX&SDL performance it´s not complex to write a >small app that performs operations colour conversion, blitting with different sizes, blitting >with mask... and then compare the results.

I know SDL is faster with RLE, but when i spend time to show that, there are for shure guys that wont believe the Fact and say the benchmark is wrong written.

So the best thing a developer can do, if amiga users dont want SDL games because they call it as slow, do nothing.

maybe this guys learn a little program and see in a own written benchmark, that SDL is not slow.

 

>But please stop trying to reach conclusions about CGX&SDL performance using Quake >because it´s the worst game you could use to compare.

Yes quake is not best, but i do not know a better game that is here for sdl and amiga native.

so the speed brake is not SDL, its the game design, use of alpha channel etc.too much data for a classic.the 68k need wait lots for blitting.

On archive that you linked has a GUI / Launchtool for SDLQuake, I used it and it worked. I woun't belive that it could accidentally launch any other Quake.exe.

Or is there already one? How have you configured it? I need to check it tomorrow, when I get back to home.

It must be SDL quake, it requires assing TMP and it is needed no matter do I use gui or not.

I linked the full source of sdlquake.I see no quake launcher file in this.what name it have ?

I look in the source, there is a option -winwidth. when choose -winwidth 320  200 it use a 640* window and run in window mode.this is slower as fullscreen

when quake really run in 320*200 there should the display not wider as the status bar at bottom.

quake defaults in source are 640*480

// The original defaults
//#define    BASEWIDTH    320
//#define    BASEHEIGHT   200
// Much better for high resolution displays
#define    BASEWIDTH    (320*2)
#define    BASEHEIGHT   (200*2)

......


 vid.width = BASEWIDTH;
    vid.height = BASEHEIGHT;
    vid.maxwarpwidth = WARP_WIDTH;
    vid.maxwarpheight = WARP_HEIGHT;
    if ((pnum=COM_CheckParm("-winsize")))
    {
        if (pnum >= com_argc-2)
            Sys_Error("VID: -winsize \n");
        vid.width = Q_atoi(com_argv[pnum+1]);
        vid.height = Q_atoi(com_argv[pnum+2]);
        if (!vid.width || !vid.height)
            Sys_Error("VID: Bad window width/height\n");
    }

[unusedunused]

This one:

name is Quake, hmmm could it be actually quake,exe with gui? I thought it was laucnher? Size is 468kb

I test the quake file, oh, sorry, this was the native quake68k from Frank Wille.you need start sdl_quake.exe(which is compile with gcc 4.3) .or you can try sdl_quake3.4.exe which is compile with GCC 3.4

seem i move this quake file to dir for more easy test in my sdl_quake source.normaly need remove the archive, but i dont save the link to remove the archive.

I have send a report hope zshare remove this archive soon.

[unusedunused]

OK now we know that Franks's quake is not optimized as Clickbooms's quake is, but at least it has a nice gui

please look if the image quality is really the same.not that clickboom quake do reduce the calc from 320 to 160 and do pixel doubling to be faster.

or can you make a screenshot of both and upload them ?

I guess quake68k is only on AGA slow.clickboom maybe have better optimized chunky to planar code

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.

this look more, that slowdown is only in AGA.

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

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

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

[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

[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);

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

[unusedunused]

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.

when a SDL program call a lock, the cgx function for a lock is called.cgx can not do alpha blendet too.no system do alphablend when write data to a bitmap direct with sdl.

Code: [Select]

int CGX_LockHWSurface(_THIS, SDL_Surface *surface)
{

if (surface->hwdata)
{
// D(bug("Locking a bitmap...\n"));
if(!surface->hwdata->lock)
{
Uint32 pitch;
           if (surface->hwdata->bmap)
  {
if(!(surface->hwdata->lock=LockBitMapTags(surface->hwdata->bmap,
LBMI_BASEADDRESS,(ULONG)&surface->pixels,
LBMI_BYTESPERROW,(ULONG)&pitch,TAG_DONE)))
return -1;
  }

.......


[unusedunused]

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.

I dont know many programs, maybe i think too much in theory but its too hard for the coding style netsurf is do, and it can not work in praxis when every system have a native GUI, so that the backend can be as much unchanged as blender or firefox or other programs with a fixed GUI have.

it was really not good that netsurf API interface was change so many years after netsurf so much.

when they change their lots backend API functions earlier before MUI Version come, i think now we have a MUI version.

so we can say bad luck ;-)

maybe if netsurf get java script and libdoom, there come other changes.So i prefer to wait, because when netsurf support all browser features, risk that backend API need change alot, is not high so high i think