Most modern games vary the frame rate according to the rendering
demands. Especially for 3D, a bit of jitter in the timing doesn't
matter. (You need very low jitter for say, a sideways scroller, but 3D
is much more forgiving).
That said, >> 60Hz refresh would be nice :-)
> - - up to 200Hz music update (depending of the way the music is
> generated and of the temporal precision of sound effects generation)
Not necessary. You can get really fine temporal precision without such
a high update rate. 30Hz update will do in my experience.
(To those interested: temporal precision is handy for the speed-of-sound
delay between visual and aural effect, and also for stereo location).
> - - <0.1s reactivity to player actions
Latency again :-)
> - - adaptativity to CPU busyness (frame dropping, etc...) to avoid a
> general slowdown
All the modern games of the type you're describing keep the game running
at the same speed whatever happens to the framerate and the CPU.
> - - hability to have long-running processes to precompute things
This is a balancing act that the game should probably manage internally.
> For such things, RT is the best existing tool for now. The
> high-latency (and low bandwhich) of X is what makes it so
> unnacceptable for games, btw. Having quake only showing 5-10fps on a
> quadriprocessor reality engine II kind of sucks.
If it's that slow, your reality engine sucks. X had no problem updating
a 320x200 window at > 60Hz on a 486 running Linux 5 years ago!
In my experience (and I have developed video games with Linux), RT is
needed to avoid the occasional glitch in sound mixing, though the gaps
turns out to be quite rare anyway if the mixer's coded right.
And the RT mixer thread should probably stick to just the mixing.
Prefetching sample pages, calculating channel priorities,
doppler/stereo/area/3d calculations don't need to be in the RT thread.
Video and game code generally does *not* need RT. Really, the only
thing RT would buy is avoiding the very rare delay for a moment, and
they're not noticable with video. RT would cost you a stable
environment (bug in game -> computer locks up), it's not worth it.
> I agree that games are very different from standard unixy applications
> because they require a high level of interactivity, something at which
> unix systems are generally bad at (they're slow or fast, but not
> snappy).
You're wrong, about games on Linux anyway. I've written some very
snappy stuff that does a lot of work, at very high frame rates when the
machine can handle it, complete with stereo audio mixing in the
background and the temporal precision you mentioned. It runs reasonably
on a 486, snappy on anything faster.
> But then they only show what is going to be needed for
> tomorrow applications, for instance on-the-fly compression and
> decompression of video and audio data, voice recognition,
> virtual/enhanced reality...
IMO, all of that would work best _without_ RT, except some low-level
audio mixing because that's where you notice the glitches. Perhaps also
network latency needs to be kept down, but I'm not sure RT is
appropriate there either. I'd try it in a SIGIO handler polling to get
the effect of priority over the main program, + main loop polling to
cope with kernel bugs.
> Buffering don't help when you need low-latency interactivity.
That's true. Aim to not have more than a frame or so of buffering!
Though it depends on what kind of buffering. Buffering needn't mean
adding a delay all the time. Multi-buffering video, for example, gives
smoother degredation in frame rate as rendering load increases, so it's
actually faster than say, jumping from 60Hz all the way down to 30Hz.
It's what everyone does these days.
> To sum up, add user-level, easy to use RT capabitilies to Linux and
> they will be used much more than one RT-thread per system.
All I can say is, my experience writing games suggests RT is handy for
one specific thing (audio mixing), but nothing else.
Maybe it will become an issue with VR, as the image timing there is much
more critical. Or with force feedback, where rapid feedback may be
needed to keep the control system stable.
But a related issue...
It would be nice would be the ability to _limit_ the system load due to
processes other than the one running in the foreground, so you can
receive mail, updatedb runs, your local news spool expires etc. without
significantly impacting the game you're playing or the film you're
watching.
What happens now is typically, you're playing away and unexpectedly,
some routine system maintenance process runs ruining the interaction for
a while. "Don't run anything else" isn't practical if you take it to
mean "kill crond while playing games".
I've seen in with people playing Win95 games -- they're playing and all
of a sudden everything goes choppy while the daily virus check kicks
in... No-one tries to fix such problems. It's just taken as something
you have to live with from time to time.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/