[SDL] Follow up (more details, test results, replies)

[Kein-Hong Man]

Leon Marrick wrote:
>      SDL isn't a complete solution for me and my project.  The major reason is 
> speed.  To attain anything close to the performance of the several single-
> platform ports of my project (Mac, X11, and Win32 being three), I must solve 
> at least one of two problems:  Get text onto the application SDL surface 
> faster, or figure out why SDL_Update_Rects is so bloody slow on all tested 
> machines and using all tested drivers.

For your case, 4.0ms per frame on the first test seems plenty fast 
to me. That's 250 frames per second. For my tests, running your 
code using directx mode gives about 4.0ms as well. Exactly why 
does your app needs performance in the hundreds of frames per 
second range?

If blitting is accelerated, no problem. But if it is not 
accelerated, then I don't think much magic can be done, but I 
still got about 60 frames per second. I can live with that, or 
else perhaps it can be run in directx mode by default...

> =======================================
> 
> Test results, with source as supplied (no changes to code, 64 stored update 
> rects)
> [snip]
> ======================================
> 
> [snip] Text output results for that method were almost twice as slow when the 
> application was run in 8-bit mode (256 colors), and quite a lot worse when it 
> was run in any other color depth.  As you can see from the above results, a 
> doubling of the time needed to output text has a significant effect on total 
> performance on my test machines.  

Doubling of the time sounds about right, based on scaling my 
timing data.

>      When I replaced the pre-rendered blitting code with the current pixel 
> offset code, my SDL app went from "it hurts my eyes it flickers so much" 
> to "just barely acceptable ... on fast machines".  If this improvement hadn't 
> happened, I might not have offered an SDL version at all.

How much does it really affect playability? I mean, 250 fps vs 125 
fps for text_speed.c ... What kind of app or game is it anyway? If 
it is real time, you don't need 250 fps, while if it is an 
angband-type game, does the keyboard repeat rate allows 250 fps? 
How many fps is your actual app or game getting anyway (which I 
think is more important than trying to optimize text_speed.c to 
the hilt)?

> [snip]
> Sorry for yelling.  It's just that I am /so/ frustrated.  I don't pretend to 
> be an expert.  Any help or ideas are much appreciated.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia