Is there any way to yield in an SDL thread? Why isn’t there an
SDL_YieldThread() function?
SDL_Delay(0) has that same effect.On Sat, Mar 05, 2005 at 06:11:34PM -0600, braddabug wrote:
Is there any way to yield in an SDL thread? Why isn’t there an
SDL_YieldThread() function?
–
Petri Latvala
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050306/a2755277/attachment.pgp
Nope, that’s an undocumented side effect of the way the underlying
Win32 call works.
For example, SDL_Delay(0) on Linux does precisely nothing. (At least,
that was the case last time I checked.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 06 March 2005 02.56, Petri Latvala wrote:
On Sat, Mar 05, 2005 at 06:11:34PM -0600, braddabug wrote:
Is there any way to yield in an SDL thread? Why isn’t there an
SDL_YieldThread() function?SDL_Delay(0) has that same effect.
Nope, that’s an undocumented side effect of the way the underlying
Win32 call works.For example, SDL_Delay(0) on Linux does precisely nothing. (At least,
that was the case last time I checked.)
David’s right, but an SDL_Delay(10) (or perhaps even an SDL_Delay(100),
depending on the thread in question) works wonders in most places.
–ryan.
Nope, that’s an undocumented side effect of the way the underlying
Win32 call works.
For example, SDL_Delay(0) on Linux does precisely nothing. (At least,
that was the case last time I checked.)David’s right, but an SDL_Delay(10) (or perhaps even an
SDL_Delay(100), depending on the thread in question) works wonders in
most places.
Since SDL only supports pre-emptive multithreading, the OS is already
going to switch between threads as best as it sees fit. What use is
delaying for some arbitrary fixed time going to do, other than make
sure that some CPU slices end up somewhere else? Also, delaying for
some fixed time interval is going to mean different things to different
machines. A slower machine is going to want less of a delay and a
faster machine is going to want more.
If you design your application to be event driven, so that it’s
processing when it needs to be, and sleeping otherwise (waiting for an
event or some specific time), then you don’t have to worry about this
because you’re using the CPU only when you need it.
-bobOn Mar 7, 2005, at 1:33 AM, Ryan C. Gordon wrote:
Is there any way to yield in an SDL thread?
Sure. Use event variables. Have the yielding thread wait on an event
variable. As long you make sure the event will eventually be triggered
you can build a nice thread yielding system this way. You can make it as
sophisticated as you want it to be.
Why isn’t there an SDL_YieldThread() function?
Like everything else in SDL, only features that are supported everywhere
are included. If there is even a chance that a function can’t be
implemented on some platform then it probably didn’t get included in
SDL. The result is that SDL is works just about everywhere, but you
don’t always get your favorite feature.
Bob PendletonOn Sat, 2005-03-05 at 18:11 -0600, braddabug wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
cough With the merry exception of SDL_WM_ToggleFullscreen which can
only be implemented on X11… coughOn Mon, Mar 07, 2005 at 12:02:55PM -0600, Bob Pendleton wrote:
Like everything else in SDL, only features that are supported everywhere
are included. If there is even a chance that a function can’t be
implemented on some platform then it probably didn’t get included in
SDL. The result is that SDL is works just about everywhere, but you
don’t always get your favorite feature.
–
Petri Latvala
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050308/76ce99ab/attachment.pgp
Petri Latvala wrote:> On Mon, Mar 07, 2005 at 12:02:55PM -0600, Bob Pendleton wrote:
Like everything else in SDL, only features that are supported everywhere
are included. If there is even a chance that a function can’t be
implemented on some platform then it probably didn’t get included in
SDL. The result is that SDL is works just about everywhere, but you
don’t always get your favorite feature.cough With the merry exception of SDL_WM_ToggleFullscreen which can
only be implemented on X11… cough
Not to mention SDL_WM_* (requires some sort of window manager), SDL_GL_*
(requires OpenGL), SDL_LoadObject and friends (requires dynamic loading
support), the entire CDROM subsystem (requires cdrom)…
=)
- Gerry
cough With the merry exception of SDL_WM_ToggleFullscreen which can
only be implemented on X11… coughNot to mention SDL_WM_* (requires some sort of window manager), SDL_GL_*
(requires OpenGL), SDL_LoadObject and friends (requires dynamic loading
support), the entire CDROM subsystem (requires cdrom)…
Joking aside, ToggleFullscreen() doesn’t need X11, it just needs to
guarantee that the SDL_Surface->pixels field won’t change. For shadow
surfaces, we should probably be able to implement this on damned near
every platform.
Although, truthfully, this is a silly requirement; we should probably
not guarantee that at all, and if you’re caching the pixels field
elsewhere, you should probably be flogged anyhow.
I haven’t really thought this out, though.
–ryan.
cough With the merry exception of SDL_WM_ToggleFullscreen which
canonly be implemented on X11… cough
Not to mention SDL_WM_* (requires some sort of window manager),
SDL_GL_*
(requires OpenGL), SDL_LoadObject and friends (requires dynamic
loading
support), the entire CDROM subsystem (requires cdrom)…Joking aside, ToggleFullscreen() doesn’t need X11, it just needs to
guarantee that the SDL_Surface->pixels field won’t change. For
shadow
surfaces, we should probably be able to implement this on damned
near every platform.
…except that it (AFAIK) more often than not means that SDL will just
have to close and reopen the display. That means some more backends
get this DirectX “oops, I happened to lose your surfaces” thing that
already leaks through to the SDL API for the DirectX backend…
Unless SDL caches all surfaces on backends that might lose them, of
course. (glSDL already does that, but that has more to do with the
fact that modifying surfaces would be extremely expensive otherwise.)
Speaking of which, how about making caching application controlled? If
the application says “don’t cache”, it may get these surface lost
errors on backends that can lose h/w surfaces. If the application
requests caching, this will never happen, but some backends will have
to cache all h/w surfaces in system memory and re-upload them
automatically as needed.
Hmm… Just as I thought it’s that simple, I realize the next problem
is, where does ‘pixels’ point to if you lock a cached h/w
surface? 
Only one option for glSDL, but for DirectX and maybe
some others, there are two alternatives; the cache/shadow buffer, or
the VRAM area.
Although, truthfully, this is a silly requirement; we should
probably not guarantee that at all, and if you’re caching the pixels
field elsewhere, you should probably be flogged anyhow.
Well, the API docs say that you should lock a surface before messing
with ‘pixels’. Though it doesn’t really say that (unless I’ve missed
that part), I always took for granted that that implies both that the
memory may not be safe to access without locking, and that the
pointer may change unless it’s locked.
Either way, why should it be any different for the screen - especially
considering that that’s the single one surface that is most likely to
need to do stuff like that?
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 08 March 2005 08.56, Ryan C. Gordon wrote:
Like everything else in SDL, only features that are supported everywhere
are included. If there is even a chance that a function can’t be
implemented on some platform then it probably didn’t get included in
SDL. The result is that SDL is works just about everywhere, but you
don’t always get your favorite feature.cough With the merry exception of SDL_WM_ToggleFullscreen which can
only be implemented on X11… cough
ROFLMAO. Skewered with my own assertion!
Why isn’t SDL_WM_ToggleFullScreen() implementable on Windows? That has
always bothered me, but not enough to look into it.
Bob PendletonOn Tue, 2005-03-08 at 02:08 +0200, Petri Latvala wrote:
On Mon, Mar 07, 2005 at 12:02:55PM -0600, Bob Pendleton wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hello, Petri!
??>> Like everything else in SDL, only features that are supported
??>> everywhere are included. If there is even a chance that a function
??>> can’t be implemented on some platform then it probably didn’t get
??>> included in SDL. The result is that SDL is works just about
??>> everywhere, but you don’t always get your favorite feature.
PL> cough With the merry exception of SDL_WM_ToggleFullscreen which can
PL> only be implemented on X11… cough
And SDL_Flip() function too I’ve looked all video drivers to find how to
implement it under QNX, half platform drivers doing just page flip (setting
new visible video address), others blits all visible page contents to the
back surface and doing the flip. So many games assuming that after
SDL_Flip() call ->pixels contain the current filled frame and continuing the
drawing. Wolf3D port from icculus site is that game that thinks after
flip() ->pixels contains original filled frame as before flip. So on libsvga
driver you’ll get blinked 35 times per second frame I think the RIGHT
behavior of the SDL_Flip() must be documented.
With best regards, Mike Gorchak. E-mail: @Mike_Gorchak
[…]
I think the RIGHT behavior of the SDL_Flip() must be documented.
I don’t think there is any “right” behavior. What Flip() does is what
happens to be the best option on the platform at hand, which includes
(in order of preference, for “normal” applications):
- True h/w page flip; ie “change a pointer”
- Hardware accelerated back->front blit
- Software back->front blit
(And then there’s glSDL, which doesn’t really behave like any of those
if you look at it through the SDL API.)
While one can of course just decide on one behavior to be strictly
required, and emulate it on all backends that do not comply by
nature, the problem is that applications have different needs, so one
way of emulating the “correct” Flip() behavior is not optimal for all
applications.
Just because some applications don’t care what’s in the buffer after
a flip doesn’t mean it’s safe to just assume that’s what all SDL apps
want. Similarly, if you assume that all applications expect the back
buffer to be unaffected by Flip(), you have to hardwire all backends
that do true page flipping to use a shadow surface as rendering back
buffer.
I think the only useful way to handle it is to allow applications to
find out how Flip() works, and then decide how to deal with it.
Applications that repaint the whole screen every frame can just
ignore the problem. “Smart update” applications (using dirty rects or
other forms of incremental updating) will have to adjust accordingly.
As it is, all you can do is to assume the “worst reasonable” case. For
example, you can assume that the display is always double buffered
with true page flipping. That means one has to merge the dirty rects
for the current and previuous frame for each update - which is of
course a waste cycles and bandwidth on a backend that “flips” by
means of back->front blits. More seriously, it won’t even work on a
triple buffered page flipping display, or one of these weird things
that thrash the back buffer (doing in-place pixel format conversion,
I assume) when flipping.
The API to solve this would be simple:
int SDL_GetFlipCycleCount(SDL_Surface *screen);
which returns the number of Flip()s you need to do to get back to the
buffer you started with, 0 for “infinity”, if the buffer is
irreversibly thrashed, or -1 if the behavior is unknown. With a
back->front blit backend, it would return 1, whereas it would return
the number of pages (2 is the only option currently, AFAIK) for a
page flipped display.
However, the bad news is that this call would have to return -1
(“behavior unknown”) most of the time, since the behavior is
undefined with some APIs. (OpenGL would be one example.) At best, the
call could sometimes avoid asking the user if the rendering looks ok,
but you’d still need that logic if you rely on page flipping
behavior.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 10 March 2005 08.45, Mike Gorchak wrote: