SDL audiospec thread priority should be higher than the main

SDL Development
1

James Haley wrote:

What’s the status on 1.3? Is it stable enough to be used in serious apps now? Is the range of supported platforms the same? I’ve been out of the loop on it pretty much from the beginning. We’re currently using 1.2.14 and the newest available version of the satellite libraries (SDL_mixer and SDL_net).

I am using SDL 1.3 for a project right now. I’m finding it very easy to use, and most of the issues remaining deal with features that simpler projects don’t need to use (texture as a render target/updating textures, fullscreen, cursor ‘magic’ for a few examples). That said, the API is not frozen yet and is quite subject to change.
All satellite libraries maintained by Sam or Ryan should work just fine, as long as they are built against SDL 1.3. Can’t make the same guarantees about others like Sprig, SDL_gfx, MixBox, etc; although most of those have lost their main uses anyway.

SDL 1.3 dropped some unmaintained platforms and picked a few new ones up (most notably, Android and iOS). It still works just fine under Windows, OS X, and most major POSIX/X11 systems; but as Rene pointed out, you will need to build and distribute it yourself as it’s not yet available in any distro’s repository (not surprising as it’s still not an official release. And heck, most distros only have a 4 year old version of boost C++ libraries available, too).------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

2

I am seeing things in this thread that I must disagree with.

  1. Don’t call SDL_Delay in the main loop? No, you should be sleeping in the main loop. Otherwise, your thread is (almost) always running for its full quantum, which is bad. You’ll also notice that sleeping for that 1ms in the main loop decreases CPU usage of your program significantly, which means that you’re using less power. This is especially important on an embedded system like an iOS or Android device, but it’s still important on a desktop system too. Greener is better.
    Also, the symptom you’re receiving isn’t from SDL’s audiospec loop being too slow relative to the main thread. It’s the two threads competing with eachother for processor time, and the main loop happens to be winning out (the audiospec loop probably sleeps or waits on some OS-provided synchronization primitive at some point, whereas the main thread does not).

  2. If you have >30fps, you’re “okay”. Visual stutter may occur occasionally, but generally frames will blur together just fine for the human eye. If you’re >60 frames, you’re “perfect”. There is no way to make it any better quality than 60fps. Ever hear of vsync? It exists for a reason. Trying to max out your framerate at >200fps is completely frivolous, as aside for that nice little number that you may optionally show to your end-user, the end-user wouldn’t notice the difference between 60 and 6million. Take the 20fps hit if it fixes your problem.

Well, that’s it for now. Enjoy.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

3

In performance testing it is useful to disable such sleeping, to see if you can reach 500fps on your (typically higher end) development computer and thus have a good bet that your lowend targets will
get 50fps, but this is purely a hypothetical performance measure.

For production (read: release), always sleep at least once per render, otherwise you are indeed just wasting power, the user won’t notice the sleep time in each frame, and at low framerates the extra
loss is very slight (it may even overlap with the GPU grinding away on your frames, and hence not have any impact at all).

vsync is somewhat of an alternative way to achieve this, where it waits on a signal from the graphics hardware and thus only renders at the monitor sync rate.

There are some 120hz LCDs out there designed for stereo shutter glasses, which are quite competent for gaming at 120hz without stereo glasses, and the visual effect of 120hz gaming is hard to beat
(whether it’s a combination of “real” motion blur in the brain or not, it looks completely unlike 60hz).

Summary: always sleep each render, it doesn’t hurt, and often helps.

P.S. another curiosity to do with thread synchronization is that some users have input processing apps running on their computer and this can cause extreme “mouse lag” if your app never sleeps because
it is causing issues with the input application.On 04/20/2011 11:01 AM, Nathaniel J Fries wrote:

I am seeing things in this thread that I must disagree with.

  1. Don’t call SDL_Delay in the main loop? No, you should be sleeping in the main loop. Otherwise, your thread is (almost) always running for its full quantum, which is bad. You’ll also notice that
    sleeping for that 1ms in the main loop decreases CPU usage of your program significantly, which means that you’re using less power. This is especially important on an embedded system like an iOS or
    Android device, but it’s still important on a desktop system too. Greener is better.
    Also, the symptom you’re receiving isn’t from SDL’s audiospec loop being too slow relative to the main thread. It’s the two threads competing with eachother for processor time, and the main loop
    happens to be winning out (the audiospec loop probably sleeps or waits on some OS-provided synchronization primitive at some point, whereas the main thread does not).

  2. If you have >30fps, you’re “okay”. Visual stutter may occur occasionally, but generally frames will blur together just fine for the human eye. If you’re >60 frames, you’re “perfect”. There is no
    way to make it any better quality than 60fps. Ever hear of vsync? It exists for a reason. Trying to max out your framerate at >200fps is completely frivolous, as aside for that nice little number that
    you may optionally show to your end-user, the end-user wouldn’t notice the difference between 60 and 6million. Take the 20fps hit if it fixes your problem.

Well, that’s it for now. Enjoy.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

4

Forest Hale wrote:

In performance testing it is useful to disable such sleeping, to see if you can reach 500fps on your (typically higher end) development computer and thus have a good bet that your lowend targets will
get 50fps, but this is purely a hypothetical performance measure.

I try to develop on low-end hardware so that rather than being hypothetical, I can be certain. I recommend this for anyone intending to target low-end systems.

Forest Hale wrote:

There are some 120hz LCDs out there designed for stereo shutter glasses, which are quite competent for gaming at 120hz without stereo glasses, and the visual effect of 120hz gaming is hard to beat
(whether it’s a combination of “real” motion blur in the brain or not, it looks completely unlike 60hz).

Maybe I should invest in one of these some time, as I’ve never heard of that. Regardless, if you’re rendering to a 60hz display there’s no point in notably exceeding 60 fps (same with 75 fps on a 75hz display, although the user likely wouldn’t notice a difference of 15fps as long as its consistent anyway).

Forest Hale wrote:

P.S. another curiosity to do with thread synchronization is that some users have input processing apps running on their computer and this can cause extreme “mouse lag” if your app never sleeps because
it is causing issues with the input application.

To quote a friend, "nobody truly understands concurrent programming."
The case happening here is essentially an infrequent deadlock on the processor itself.

@OP: Another alternative to sleeping on the main thread, if you’re completely against it, is to simply ensure that the two threads are not running on the same processor [core]. This is easy enough on Windows, but I’m not sure whether or not thread affinities exist in the POSIX standard. Because basically what this bug is caused by is that the main thread is starving the audiospec thread out of the common, shared resource of the processor itself. However, this issue will still exist on single-core machines.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

5

Sleeping in a rendering thread would be good if you could control it better
than “it might sleep for 1 - 10 msec”. There is no point rendering faster
than your display device can update the screen, so either rely on vsync or
don’t sleep at all. Here’s the fun one for you guys:

src/audio/SDL_audio.c(334)

/* The audio mixing is always a high priority thread */
SDL_SetThreadPriority(SDL_THREAD_PRIORITY_HIGH);

There are a few SDL_Delay()s thrown all over the code in there as well.

src/audio/windx5/SDL_dx5audio.c(156)

static void
DSOUND_ThreadInit(_THIS)
{
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);
}

src/audio/windib/SDL_dibaudio.c(80)
/* Set high priority for the audio thread */
static void
WINWAVEOUT_ThreadInit(_THIS)
{
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);
}

In other words, I’d be more concerned without how SDL’s audio code
synchronizes with the underlying output driver. I also don’t know why
setting a high thread priority would change anything, since it seems quite
clear it is already running at a high priority.

SDL_audio.c line 969-971 creates a thread that starts at the function
SDL_RunAudio(). First thing does it the
SDL_SetThreadPriority(SDL_THREAD_PRIORITY_HIGH), then calls ThreadInit() for
the current audio device. On Windows, those are seen above – and they
simply (redundantly) set the thread priority to the highest possible. So it
seems setting the priority of the actual audio code may not be the problem.
SDL 1.2.14 does nearly the same thing. I’d say if anything, the problem is
in SDL_mixer. Any way you get the the thread ID of the mixer and maybe
display a list of all threads in the process + their priorities?

PatrickOn Wed, Apr 20, 2011 at 1:54 PM, Nathaniel J Fries wrote:

Forest Hale wrote:

In performance testing it is useful to disable such sleeping, to see if
you can reach 500fps on your (typically higher end) development computer and
thus have a good bet that your lowend targets will
get 50fps, but this is purely a hypothetical performance measure.

I try to develop on low-end hardware so that rather than being
hypothetical, I can be certain. I recommend this for anyone intending to
target low-end systems.

Forest Hale wrote:

There are some 120hz LCDs out there designed for stereo shutter glasses,
which are quite competent for gaming at 120hz without stereo glasses, and
the visual effect of 120hz gaming is hard to beat
(whether it’s a combination of “real” motion blur in the brain or not, it
looks completely unlike 60hz).

Maybe I should invest in one of these some time, as I’ve never heard of
that. Regardless, if you’re rendering to a 60hz display there’s no point in
notably exceeding 60 fps (same with 75 fps on a 75hz display, although the
user likely wouldn’t notice a difference of 15fps as long as its consistent
anyway).

Forest Hale wrote:

P.S. another curiosity to do with thread synchronization is that some
users have input processing apps running on their computer and this can
cause extreme “mouse lag” if your app never sleeps because
it is causing issues with the input application.

To quote a friend, "nobody truly understands concurrent programming."
The case happening here is essentially an infrequent deadlock on the
processor itself.

@OP: Another alternative to sleeping on the main thread, if you’re
completely against it, is to simply ensure that the two threads are not
running on the same processor [core]. This is easy enough on Windows, but
I’m not sure whether or not thread affinities exist in the POSIX standard.
Because basically what this bug is caused by is that the main thread is
starving the audiospec thread out of the common, shared resource of the
processor itself. However, this issue will still exist on single-core
machines.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

Matthew Orlando wrote:> On Wed, Apr 20, 2011 at 7:42 AM, Kenneth Bull wrote:

On 20 April 2011 10:02, Alex Barry <alex.barry at gmail.com> wrote:

Honestly, if you’re above 24fps, there shouldn’t be any visual stutter
at all, at least from the human eye perspective. ??From the software
perspective, I don’t think it’s a big deal, either.

Last I heard, the human eye works at around 60 Hz. ??The reason 24 or
30 Hz works on CRTs and television is because every second scanline is
drawn in a separate pass, which yields an effective framerate of 48 or
60 Hz. ??Persistence of vision and phosphor persistence also tend to
blend frames together to let you get away with effective framerates
lower than 60Hz.

There are a lot of misconceptions about frame rates and human vision.
The first confusion is between smoothness of motion and lack of
flicker. When you see the 60 Hz figure it’s talking about flicker
(assuming the source you’re reading isn’t suffering from the same
misconceptions).

Generally, humans perceive pulses as continuous light when those
pulses are coming at 60 Hz. The center of our visual field is less
sensitive to flicker which is why you might notice fluorescent lights
flickering out of the corner of your eye.

Movies are usually filmed at 24 fps, but projectors will send two
flashes of light through each frame to reduce apparent flicker. You
still see some flicker on the big screen because you’re only reaching
48 Hz.

Flicker is an entirely separate issue from the apparent smoothness of
motion, and is pretty much irrelevant to game developers. Only display
manufacturers have to worry about flicker.

We DO have to worry about the smoothness of motion, though. This is
affected by several factors:

  • Overall frame rate - All else being equal, higher frame rate
    translates to smoother motion. However, the negative effects of the
    other factors mean you really can’t make any meaningful statement in
    isolation about what the right frame rate should be.

  • Frame rate consistency - Even at high overall rates, if it’s
    constantly varying things will look noticeably choppy. 24 fps with
    vsync will look smoother than 75fps without vsync simply because there
    is much less variation in time between frames.

For example, if a ball is moving across the screen in 1 second, it
will look fairly smooth if the distance it travels each frame is
1/24th of the screen width. However, if it moves 1/75th the distance
in one frame, 1/40th the distance in another, 1/60th the distance in
another, and so on, you will see noticeable stutter.

  • The speed at which objects move across the visual field - (NOTE:
    this depends on the size of the display and the distance to the
    viewer.) You could get away with 1 FPS if nothing on your screen moves
    faster than a couple pixels per second. By contrast, even 120 FPS
    might not be sufficient to reduce strobing effects if you have objects
    moving around the screen extremely fast a lot of the time.

  • Motion blur - As a computer graphics technique, it’s a way to
    compensate for both of the latter smoothness factors. If a ball moves
    from one side of the screen to the other in one frame, motion blur
    fools our brains into thinking it traversed the distance. As long as
    the degree of blur depends on the time between frames, it can also
    compensate somewhat for an inconsistent frame rate.

So yeah… it’s a bit more complicated than even reputable sources
might suggest.

Do with this information as you please :slight_smile:

–
Matthew Orlando
http://cogwheel.info

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Am I perhaps mistaken when thinking that the monitor’s refresh rate is the total number of FPS that will actually make it to the user (IE, if you have 100fps on a 60Hz monitor, the end-user will see 60 of those 100 frames)?

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

7

No, that’s absolutely correct. If you want to improve visual quality beyond
what the monitor is capable of, and have the hardware resources to do so, your
best bet is to use your cycles to create appropriate motion blur effects to
improve the illusion of smooth motion.________________________________
From: nfries88@yahoo.com (Nathaniel J Fries)
Subject: Re: [SDL] SDL audiospec thread priority should be higher than the main

Am I perhaps mistaken when thinking that the monitor’s refresh rate is the total
number of FPS that will actually make it to the user (IE, if you have 100fps on
a 60Hz monitor, the end-user will see 60 of those 100 frames)?

8

Indeed. That and/or vsync.On Wed, Apr 20, 2011 at 4:31 PM, Mason Wheeler wrote:

No, that’s absolutely correct.? If you want to improve visual quality beyond
what the monitor is capable of, and have the hardware resources to do so,
your best bet is to use your cycles to create appropriate motion blur
effects to improve the illusion of smooth motion.

From: Nathaniel J Fries
Subject: Re: [SDL] SDL audiospec thread priority should be higher than the
main

Am I perhaps mistaken when thinking that the monitor’s refresh rate is the
total number of FPS that will actually make it to the user (IE, if you have
100fps on a 60Hz monitor, the end-user will see 60 of those 100 frames)?

9

Am I perhaps mistaken when thinking that the monitor’s refresh rate is the
total number of FPS that will actually make it to the user (IE, if you have
100fps on a 60Hz monitor, the end-user will see 60 of those 100 frames)?

You’ll get tearing, which is when you update a buffer while it is being
scanned out to the monitor. In effect, you see half of one frame, half of
another. You can get tearing when operating at less than the monitors
refresh rate, but it is a certainty when operating higher than it. If you
can consistently render > 100 FPS, there is no reason not to increase the
graphical detail or use vsync.

10

Am I perhaps mistaken when thinking that the monitor’s refresh rate is the
total number of FPS that will actually make it to the user (IE, if you have
100fps on a 60Hz monitor, the end-user will see 60 of those 100 frames)?

You’ll get tearing, which is when you update a buffer while it is being
scanned out to the monitor. In effect, you see half of one frame, half of
another. You can get tearing when operating at less than the monitors
refresh rate, but it is a certainty when operating higher than it. If you
can consistently render > 100 FPS, there is no reason not to increase the
graphical detail or use vsync.

And, of course it is more complicated than that… Isn’t is always?
You will see tearing if the video card only actually allocates 2
buffers and if it will actually let you switch buffers at any time
other than vsync. Even if you do not ask for vsync the video card
might just queue the change to happen at the next vsync and tell you
that it did it. Then it will start rendering in a different buffer and
if you finish that buffer and ask to display it then that buffer can
get queued but not displayed and the first one that was queued but not
displayed becomes the current back buffer and so on until vsync and
then the current pending buffer gets displayed. The extra frames just
do not get displayed at all. You see, the graphics hardware/driver
just might decided to do triple buffering even if you just ask for
double buffering.

To make it more confusing if you are actually rendering at 100+ FPS
then the changes you make between frames can be so small that we poor
humans can’t detect the effects of tearing even if it is happening.
The tear (or tears, at very high fps you could get 3, 4 or more tears
per frame) will tend to be at a different location every frame and if
it doesn’t happen in the part of the screen you are focused on you
most likely will not notice it.

Several years ago I wrote a test that could detect whether you were
getting double or triple buffering. Turns out that many video cards
were doing triple buffering when I asked for double buffering. That
was back when a video buffer (4 whole megs :slight_smile: was significant
fraction of the total video memory on a card. Now days a video buffer
is a fraction of 1% of that gigabyte of video on your video card.

Bob PendletonOn Wed, Apr 20, 2011 at 7:37 PM, Patrick Baggett <baggett.patrick at gmail.com> wrote:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

11

@OP: Another alternative to sleeping on the main thread, if you’re
completely against it, is to simply ensure that the two threads are not
running on the same processor [core].
This is easy enough on Windows,
but I’m not sure whether or not thread affinities exist in the POSIX
standard. Because basically what this bug is caused by is that the main

thread is starving the audiospec thread out of the common, shared
resource of the processor itself. However, this issue will still exist
on single-core machines.

Can’t be done. Due to that serious bug in either SDL_mixer or the SDL audio core itself which was apparently never fixed, Eternity (my project), PrBoom-Plus, Chocolate Doom, and many other SDL-based DOOM source ports are all forced to set a processor affinity mask to prevent concurrent execution of the threads spawned by SDL with the main application thread.

Once the SDL audio threads start to run on a separate physical processor from the rest of the application, random crashes begin to occur. Personally I still believe this problem is in the native MIDI backend for Win32, because the code there is extremely lax with the way it handles the winmm callback - it is executed from a system-owned thread which calls it every time it wants more MIDI events. But the code as is doesn’t necessarily wait for the callback to stop executing before trashing or changing the MIDI data. I identified at least three possible race conditions that were unhandled, and even produced a patch that contained a possible workaround. To the best of my knowledge that patch was never merged into the repository.

I had mentioned this problem on the mailing list in the past, and even added it to the SDL bug tracker, but as of 1.2.14, users still report random crashing if they disable the affinity mask setting in our configuration file. You’d probably be tempted to blame this on my own code somehow but seeing how it affects all the SDL-based DOOM ports, some of which (especially Chocolate Doom) share none of our sound or music code, it can’t possibly be. The segmentation violation always occurs on a thread running through winmm and kernel32 calls which can’t be effectively debugged due to there being no symbols or debug info for anything on the stack.

Speed is an issue for us because the other leading DOOM port (ZDoom) is somehow much faster than we are despite having significantly more complicated code. Our main rendering loops are completely cache-bound. I cannot optimize them in any manner except to improve the way they utilize cache, and this is exceptionally difficult. For example removing unused fields that had accumulated in some of the core rendering structures over the tortured 12 years of development this codebase has been through only bought me 2 FPS on average. I believe we also have some serious problems with conversion between floats and integers.

In short, I only worry about speed because my users seem to be concerned with it. If they thought my software was running the way it ought to, I wouldn’t care about losing 15 FPS when the game’s running at 195. But then we have ZDoom getting 900 FPS rendering the same scene. It’s just mind-boggling.

Also just so it is clear, Eternity is software-only; it does not have a GL or DirectX renderer. Some of the other messages mentioned something about this so I thought I’d clear that up.

-James

12

@OP: Another alternative to sleeping on the main thread, if you’re
completely against it, is to simply ensure that the two threads are not
running on the same processor [core].
This is easy enough on Windows, but I’m not sure whether or not thread
affinities exist in the POSIX standard. Because basically what this bug is
caused by is that the main
thread is starving the audiospec thread out of the common, shared resource
of the processor itself. However, this issue will still exist on single-core
machines.

Can’t be done. Due to that serious bug in either SDL_mixer or the SDL audio
core itself which was apparently never fixed, Eternity (my project),
PrBoom-Plus, Chocolate Doom, and many other SDL-based DOOM source ports are
all forced to set a processor affinity mask to prevent concurrent execution
of the threads spawned by SDL with the main application thread.

Once the SDL audio threads start to run on a separate physical processor

from the rest of the application, random crashes begin to occur. Personally
I still believe this problem is in the native MIDI backend for Win32,
because the code there is extremely lax with the way it handles the winmm
callback - it is executed from a system-owned thread which calls it every
time it wants more MIDI events. But the code as is doesn’t necessarily wait
for the callback to stop executing before trashing or changing the MIDI
data. I identified at least three possible race conditions that were
unhandled, and even produced a patch that contained a possible workaround.
To the best of my knowledge that patch was never merged into the repository.

I’d like to see what you’ve written. I guess the obvious question is “did
your patch fix the problem”? If so, that seems like a pretty strong case for
inclusion, or at least review.

I had mentioned this problem on the mailing list in the past, and even
added it to the SDL bug tracker, but as of 1.2.14, users still report random
crashing if they disable the affinity mask setting in our configuration
file. You’d probably be tempted to blame this on my own code somehow but
seeing how it affects all the SDL-based DOOM ports, some of which
(especially Chocolate Doom) share none of our sound or music code, it
can’t possibly be. The segmentation violation always occurs on a thread
running through winmm and kernel32 calls which can’t be effectively debugged
due to there being no symbols or debug info for anything on the stack.

Speed is an issue for us because the other leading DOOM port (ZDoom) is
somehow much faster than we are despite having significantly more
complicated code. Our main rendering loops are completely cache-bound. I
cannot optimize them in any manner except to improve the way they utilize
cache, and this is exceptionally difficult. For example removing unused
fields that had accumulated in some of the core rendering structures over
the tortured 12 years of development this codebase has been through only
bought me 2 FPS on average. I believe we also have some serious problems
with conversion between floats and integers.

In short, I only worry about speed because my users seem to be concerned
with it. If they thought my software was running the way it ought to, I
wouldn’t care about losing 15 FPS when the game’s running at 195. But then
we have ZDoom getting 900 FPS rendering the same scene. It’s just
mind-boggling.

195 vs 900 fps? Sounds like a penis showing contest at those speeds, but
sure 900 FPS seems … inaccurate. 1.1msec to render a frame? I’m not sure I
can even clear the color buffer that fast though now I’m tempted to try it.On Fri, Apr 22, 2011 at 12:03 AM, James Haley wrote:

Also just so it is clear, Eternity is software-only; it does not have a GL
or DirectX renderer. Some of the other messages mentioned something about
this so I thought I’d clear that up.

-James

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

13

Anything an order of magnitude higher than the refresh rate is obviously a meaningless waste of power.

But of course I have seen similar, and I frequently get 2000-3000fps on my current OpenGL card in Linux in some scenes in Quake, one must remember that a glClear operation is a very “soft” operation
these days, it generally flags the tiles as cleared without performing any heavy lifting, little bandwidth is involved - on the next actual draw to the tile it simply performs the deferred clear
before committing pixels.

On an earlier topic, you seem to have misinterpreted my statement about vsync off for “hardcore gamers” - I was stating that higher framerates alter player physics in the Quake series (basically one
can turn the view continuously while airborn and gain extreme acceleration, the optimal turn rate and potential speed depends on the time step) so competitive gamers will never choose the lower
framerate of vsync because it impacts their ability to play effectively in these specific games. I did not mean to imply that vsync off could ever look good.On 04/22/2011 12:37 AM, Patrick Baggett wrote:

195 vs 900 fps? Sounds like a penis showing contest at those speeds, but sure 900 FPS seems … inaccurate. 1.1msec to render a frame? I’m not sure I can even clear the color buffer that fast though
now I’m tempted to try it.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

14

On an earlier topic, you seem to have misinterpreted my statement
about vsync off for “hardcore gamers” - I was stating that higher
framerates alter player physics in the Quake series (basically one can
turn the view continuously while airborn and gain extreme
acceleration, the optimal turn rate and potential speed depends on the
time step) so competitive gamers will never choose the lower framerate
of vsync because it impacts their ability to play effectively in these
specific games. I did not mean to imply that vsync off could ever
look good.

I get what you meant, like I said, I read the IOQuake3 mailing list
complaint about FPS capping making some jumps unable to be made. Guy
posted YouTube videos and everything to make his case.

15

James Haley wrote:

@OP: Another alternative to sleeping on the main thread, if you’re completely against it, is to simply ensure that the two threads are not running on the same processor [core].
This is easy enough on Windows, but I’m not sure whether or not thread affinities exist in the POSIX standard. Because basically what this bug is caused by is that the main
thread is starving the audiospec thread out of the common, shared resource of the processor itself. However, this issue will still exist on single-core machines.

Can’t be done. Due to that serious bug in either SDL_mixer or the SDL audio core itself which was apparently never fixed, Eternity (my project), PrBoom-Plus, Chocolate Doom, and many other SDL-based DOOM source ports are all forced to set a processor affinity mask to prevent concurrent execution of the threads spawned by SDL with the main application thread.

Once the SDL audio threads start to run on a separate physical processor from the rest of the application, random crashes begin to occur. Personally I still believe this problem is in the native MIDI backend for Win32, because the code there is extremely lax with the way it handles the winmm callback - it is executed from a system-owned thread which calls it every time it wants more MIDI events. But the code as is doesn’t necessarily wait for the callback to stop executing before trashing or changing the MIDI data. I identified at least three possible race conditions that were unhandled, and even produced a patch that contained a possible workaround. To the best of my knowledge that patch was never merged into the repository.

I had mentioned this problem on the mailing list in the past, and even added it to the SDL bug tracker, but as of 1.2.14, users still report random crashing if they disable the affinity mask setting in our configuration file. You’d probably be tempted to blame this on my own code somehow but seeing how it affects all the SDL-based DOOM ports, some of which (especially Chocolate Doom) share none of our sound or music code, it can’t possibly be. The segmentation violation always occurs on a thread running through winmm and kernel32 calls which can’t be effectively debugged due to there being no symbols or debug info for anything on the stack.

Speed is an issue for us because the other leading DOOM port (ZDoom) is somehow much faster than we are despite having significantly more complicated code. Our main rendering loops are completely cache-bound. I cannot optimize them in any manner except to improve the way they utilize cache, and this is exceptionally difficult. For example removing unused fields that had accumulated in some of the core rendering structures over the tortured 12 years of development this codebase has been through only bought me 2 FPS on average. I believe we also have some serious problems with conversion between floats and integers.

In short, I only worry about speed because my users seem to be concerned with it. If they thought my software was running the way it ought to, I wouldn’t care about losing 15 FPS when the game’s running at 195. But then we have ZDoom getting 900 FPS rendering the same scene. It’s just mind-boggling.

Also just so it is clear, Eternity is software-only; it does not have a GL or DirectX renderer. Some of the other messages mentioned something about this so I thought I’d clear that up.

-James

I see. Does ZDoom use OpenGL or DirectX? If so, that difference in performance would make sense.
My serious recommendation is to not reinvent the wheel if an acceptable implementation exists. If you don’t have any ethical or licensing issues with ZDoom, I would recommend dropping your current project and offering your assistance to ZDoom to bring whatever advantages your project has (I guess an extremely fast software renderer that’s great for people with outdated/buggy/low-end gpus).

Or, in other words, “if you can’t beat 'em, join 'em”.

My secondary recommendation would, of course, be to just apply this patch over a custom build of SDL that you ship with your project’s release builds. If they want to replace it with a different SDL, they may, and then they get to deal with the bugs. I know that’s not ideal, but that’s how it works. That said, I do recall seeing that bug as I was scrolling through the bug reports and definitely referred Sam to the fact that you have a patch for it. Perhaps he and Ryan have just been too busy with more frequently complained-about bugs right now or something.

@Other posters: You’re getting well outside the topic of this post. I’d recommend forking over into a new topic.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/