[SDL] Feature Query System (Was: Some multithreaded improvement to the event queue...)

Antonio SJ Musumeci asm3072 at njit.edu
Fri Sep 16 16:28:38 PDT 2005


the SDL_Surface flags dont give you the full story. Just because you 
dont get a HW surface if you ask for one doesnt mean the platform or 
driver doesnt support it. Or finding out which blitter is being used on 
a specific platform would be nice... anything SDL hides doesnt need to 
be completely hidden. You only lose flexability and limit the developer. 
On a x86 machine I want to know if a MMX or SSE accerated functions are 
being used or if I run in fullscreen i MAY be able to get a hardware 
surface. Honestly I think anything hardware accelerable should be 
wrapped up in some way and simulated on platforms which dont support 
that feature. Maybe i'm starting to sound like i want something like X 
with accelerated primitives loadable drivers... but thats not far from 
what i'd like to see. Some of these things are just core concepts of 
graphic hardware and programming... and in that field where in some 
cases every cycle counts... especially on older machines... hiding 
things limits its flexability.

Patrice Mandin wrote:
> Le Fri, 16 Sep 2005 15:32:41 +0200
> Olof Bjarnason <olof.bjarnason at gmail.com> a écrit:
> 
> 
>>I agree; I would love a robust runtime query system in SDL, maybe
>>
>>char* SDL_SystemQuery(char* capability);
>>...
>>if(atoi(SDL_SystemQuery("DESKTOP_RESOLUTION_W") == 1024) {
>>  printf("I don't like people using 1024x768 desktop resolution,
>>  bye.\n"); return;
>>}
>>
>>or
>>
>>if(!SDL_SystemQuery("ALPHABLEND_HW_HW_ACCEL")) {
>>  printf("Alpha blending is not hardware accelerated, get some new gfx
>>  h/w!\n"); printf("I will run the program anyway, I've warned
>>  you.\n");
>>}
>>
>>or whatever. Lots of flags, yes :)
>>
>>Best of both worlds would be if SDL used the current
>>"fall-back-to-closest-match" system of today, but add APIs for
>>querying reliably also. Then an application programmer could choose to
>>play it the portable way and continue to run the program even if the
>>best match isn't available, or quit if he pleases.
> 
> 
> This is the type of example I would not like to see in SDL applications.
> It is too much PC-centric. You forgot that SDL run on some hardware
> console (ps2, dreamcast) or on PDAs. I don't know how people will
> upgrade their
> PDA :-).
> 
> Also, in modern apps, you should be able to adapt to what has been given
> to you. For example, OpenGL programs should be runnable in whatever the
> video resolution is (from 320x240 to 2048x1536, etc...). And 2D programs
> can be adapted the same way (zooming is easy to do). The only difference
> will be speed.
> 
> I agree that querying (and selecting) what driver SDL should use, from
> the ones available for the platform, would be nice, but this is all that
> is needed. Everything else is present, like flags in screen's
> SDL_Surface.
> 
> Also I read many questions from people, about various things, who still
> think SDL is running *ONLY* on a win32 system (or this what you could
> think when reading these messages). This is the first mistake not to do
> when writing an SDL application. If you mix win32 code with SDL code,
> you lose portability, don't forget it.
> 




More information about the SDL mailing list