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

Bob Pendleton bob at pendleton.com
Fri Sep 23 09:41:59 PDT 2005


On Tue, 2005-09-20 at 19:52 -0400, Antonio SJ Musumeci wrote:
> You do not need to understand the reason someone would want to use the 
> library in that way... but in my opinion not forbid them to do so. I see 
> no good reason to hide things from the developer. If the library chooses 
> between several methods to do something... I aught to be able to find 
> out which it chose and if i want override it. If he wants to shoot 
> himself in the foot I would gladly give him the gun and bullet. Steven 
> Johnson was correct... it's a difference in philosophy. I am an embedded 
> developer. 

Interesting. I suppose this is a philosophical difference. You see, the
whole reason for having a library like SDL, in fact, the *only* reason
for having a library like SDL, is to hide all these decisions so that
the developer can get on with writing his applications without having to
worry about how things actually get done. Without that philosophy SDL
could not be machine and OS independent. 


> When I develop libraries which have any flexibility built in 
> I provide querys to find out as much info about how the library is 
> working as possible... as well as hooks to allow the user to override 
> anything which doesnt break the core design. I've run into way too many 
> situations where i hack around something or had to redesign something 
> because an underlying library hid functionality or didnt provide a 
> robust enough interface. If SDL checks for certain CPU extensions to 
> decide which memcpy would be the best... it can easily give me the 
> knowledge as to which it chose and the ability to override or replace.

I suppose that might make sense for the kind of embedded programming you
do. It doesn't make much sense to me.

		Bob Pendleton

> 
> 
> Stephane wrote:
> > Antonio SJ Musumeci wrote:
> > 
> >> 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.
> > 
> > 
> > Think about it for a second. Why do you need that ? If all you want to 
> > know is whether the platform is fast enough for your stuff, benchmark 
> > it. That's the only way. MMX on a 166Mhz CPU is going to be slower that 
> > plain C on a 3Ghz one. Also, MMX is intel-specific, so looking at this 
> > flag will make it look like that G5 is slow.
> > 
> > To prove my point I'll cite the similar example of an old OpenGL 
> > application that runs on windows.  That application used the 
> > windows-specific bits to query whether hardware acceleration was used, 
> > and refused to run if it wasn't. That was back in the days when a 200Mhz 
> > CPU was fast. Nowadays this application could very well run on a 3Ghz 
> > machine using software emulation, but the author was stupid enough to 
> > prevent it.
> > 
> > Stephane
> > 
> > 
> > _______________________________________________
> > SDL mailing list
> > SDL at libsdl.org
> > http://www.libsdl.org/mailman/listinfo/sdl
> > 
> 
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
> 
-- 
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob at Pendleton.com             +
+ web: www.GameProgrammer.com          +
+ www.Wise2Food.com                    +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+





More information about the SDL mailing list