On Fri, 2005-09-16 at 22:12 +0200, Olof Bjarnason wrote:
> On 9/16/05, Patrice Mandin <mandin.patrice at wanadoo.fr> 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 :-).
>> Hey, I *DON'T* think SDL is strictly PC. As Ovid comments, beeing able
> query "system configuration information" is even more usable in
> "lesser" hw environments where knowning details means all-or-nothing.
>> On a more fundament level though, I for one *want* to know these
> details, call me a power-monger or plain low-level minded (SDL is
> still a low-level library, right?) - as a games programmer you want to
> know what is "in your hands". And sometimes I simply don't want my
> game to run in a "zoomed out" mode as is SDLs basic behaviour given a
> non-existent resolution - *I* want to be the one controlling that
> behaviour. If SDL did have a query system, it would be up to the
> application programmer to decide whether to go the "broad"
> ("run-on-any-high-end-or-low-end-platform") or "narrow"
> ("this-is-my-fresh-3d-opengl-game-on-a-high-end-pc") road. Then the
> decision would be up to the programmer and his preferences.
>> That is NOT the situation today. The library forces a certain
> "philosophy" on the programmer.
>> In a similar trail of though, this is why I don't like to build
> java-games for mobile phones for instance - you are given a set of
> tools which "may" work the way you tell them to, or "may not". Not
> fun. I like an up-front "sorry, but I can't do that" better than a
> sneaky "Yup, I might do that, but you'll never know cuz' I'll decide
> myself".
>> How do Sam and Bob or other "authoritative voices" feel about this?
Thanks for the compliment Olof, but I am hardly authoritative on any of
this. Not to mention that my mind is not made up. I just posted saying
why I don't like the idea and then I read several good reasons for doing
it. My main worry is that not all platforms will support all the things
people want to query and then you can wind up with a recursive query
about queries situation.
Until I read about the situation on PDAs and cell phones (which I knew
but wasn't thinking about) I was thinking that most of the problems can
be solved by using OpenGL's query system. But, clearly that doesn't
work.
What I want to know is how do you implement it? If you want to know if
the version of OpenGL you are using supports full screen antialiasing,
you can check for a set of extensions that are commonly used to provide
that feature. (Which may require frequent updates to SDL.) If you want
to check for hardware alpha blending, what do you do? Keep a database of
vendor strings in SDL and note which ones do not provide hardware alpha
blending? Is this ability so valuable that it is worth adding to SDL?
Or, should we let programmers who need it, do it them selves? Or, could
someone who cares deeply write an add on library to do the job?
What about available video sizes? What are you going to do that is
better than what you already get with SDL_ListModes(),
SDL_VideoModeOK(), and SDL_GetVideoInfo()? SDL_GetVideoInfo() is really
nice because if called before SDL_SetVideoMode() gives you the "best"
video mode to use. Maybe these are not being properly implemented on
PDAs and cell phones. In that case, complain to the folks who did those
ports.
I can see why people want a lot of information, but I can't always see
how to implement it.
Bob Pendleton
>> /Olof
>> >
> > 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.
> >
> > --
> > Patrice Mandin
> > WWW: http://pmandin.atari.org/> > Programmeur Linux, Atari
> > Spécialité: Développement, jeux
> >
> >
> > _______________________________________________
> > 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 +
+--------------------------------------+