[SDL] SDL_Mixer help
grellin-igp at hotmail.com
Mon Sep 25 13:46:52 PDT 2006
On Mon, 2006-09-04 at 09:58 +0200, David Olofson wrote:
> On Monday 04 September 2006 04:13, Bob Pendleton wrote:
> > David, I do this kind of stuff all the time. The SDL API *must* push
> > all attributes, set what it needs, do the job, and restore the
> > attribute and return.
> The "opengl" renderer doesn't in the version I have, at least. It sets
> the state up once, and assumes that no one is messing with it after
> > This way the context stays the same from the
> > end users point of view.
> This has clearly never been the intention. Just like glSDL, the SDL
> renderers are not intended to be used together with other code using
> the same contexts.
> > Someone is going to say that pushing and popping the context is to
> > time consuming, I don't believe it.
> Well, nothing is free, but all other alternatives seem more or less
> nonsensical, or plain do not work, so...
> The current initialization takes 9 calls or so. No big deal for
> "normal" operation, but push, init, render, pop for every single
> SDL_Render*() call...? (For comparison; each SDL_RenderCopy() call
> generates around 15 OpenGL calls as it is.)
> > The alternative is to put in a wedge layer to capture OpenGL context
> > changes (a shadow stack) so that the context can be saved and
> > restored out side of OpenGL. And I think that is an even worse idea
> > that having a notification API. :-)
> Yeah, seems like yet another way to "avoid" overhead by introducing
> extra logic that costs more than it can ever save. :-D
> > It is better to drop the whole idea than to put in the kind of
> > notification API you were talking about. Us mere mortals don't want
> > to deal with it and will get it wrong all the time. Consider how few
> > people actually check return codes from C standard library
> > calls. :-)
> Good point. (It only affects people that hack SDL or use OpenGL and/or
> Direct3D directly, and want to use SDL 2D libs over it, but that's
> bad enough.)
> So, I guess it's either hardwiring state saving and restoring into the
> SDL renderers, or possibly (if it actually matters) making it
> optional by means of an "I want to share the OpenGL/Direct3D context
> with the renderer" flag?
> > If anything this is an argument for having a higher level SLD3D API
> > that can take care of all of this stuff correctly no matter what the
> > lower level API is. And, I know how popular that idea is! (Not at
> > all.)
> And, this layer would still have to actually implement a solution
> (explicit support for multiple "clients" per context?), which means
> in the end, we'd probably have about the same amount of overhead,
> only it's generated by more complex code.
Apologies for not editing this post down, but I wasn't sure what to edit
out :-) My suggestion is that the advanced SDL 2d/3d (what ever) should
just cause and error termination if they are called on an OpenGL
surface. There is *never any reason* to use them on an OpenGL surface.
OTOH No reason they can't work on software surfaces. But, it is clear
that they will mess up the rendering context on an OpenGL surface. The
alternative is to post a context lost event (which is something Windows
users have wanted for a long time) and do what ever they do. But, that
is asking for problems. Another alternative behavior is to error off
unless the programmer has asked for context lost events. Then you know
the programmer is ready to handle the context problems caused by using
the SDL APIs when they really should not use them.
> //David Olofson - Programmer, Composer, Open Source Advocate
> .------- http://olofson.net - Games, SDL examples -------.
> | http://zeespace.net - 2.5D rendering engine |
> | http://audiality.org - Music/audio engine |
> | http://eel.olofson.net - Real time scripting |
> '-- http://www.reologica.se - Rheology instrumentation --'
> SDL mailing list
> SDL at libsdl.org
+ 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