[gameprogrammer] Re: What do the new processors mean forgameprogramming?
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 4 Mar 2005 21:50:52 +0100
On Friday 04 March 2005 20.47, Bob Pendleton wrote:
> On Fri, 2005-03-04 at 11:45 +0000, Trollfiddler wrote:
> > True, but is a one-man-band capable of producing a game for dual
> > core processors and dual video cards in time to sell it before the
> > next great thing? I don't think so. The threading is easy enough
> > per se, but it's all the technical stuff you have to do IN those
> > threads that's the bummer!
>
> LOL! How right you are! Of course, the reasons for raising questions
> like this is so we can all think about it and share our thoughts so
> we don't have to be completely alone. We are not all one man bands
> and we don't need to be one man bands.
And either way, I can certainly think of ways to put quite a few P4
class CPUs to work; no worries there...! ;-)
Just as an example, rendering soundscapes, music and sound effects
with mostly real time analog and physic modelled sounds with upcoming
versions of Audiality (with the new EEL scripting engine, that will
be able to run in the real time audio thread) can fry just about as
many cycles as the "sound guy" wants it to. There is no such thing as
too much processing power when it comes to audio.
...or graphics rendering, for that matter. How about some *serious*
procedural texturing? :-)
...which is basically what one of my latest hacks, ZeeSpace, is about;
rendering "2.5D" graphics with real time light and shadows into SDL
surfaces or (preferably) OpenGL textures that are rendered to screen
- sort of like emulating hardware scrolling to avoid rerendering the
whole screen every frame. The results so far actually suggest that
one could do full real time rendering in 640x480 or so on a decent
machine (ie not the 933 MHz relic I'm working on; 320x240 is more
like it ;-) with "acceptable" frame rates - but since the only
acceptable frame rate in my book is the display refresh rate :-D,
dirty rect style rendering + h/w scrolling emulation will probably be
required even on relatively hot machines. It would also be nice if
one could make things asynchronous enough that the scrolling remains
smooth even when the rendering/lighting system is overloaded.
That is, stuff that *can*, to some extent, be implemented with various
dirty hacks in a single threaded engine;
while(running)
{
do_some_work();
if(time_to_update_screen)
update_screen();
}
but would be both easier to do reliably, and more SMP/multicore
friendly if done using some form of multithreading.
However, there's one major problem with all this: The AGP bottleneck.
Unless you're lucky enough to have a really nice driver that makes
full use of busmaster DMA transfers, texture uploading has about the
same bandwidth restriction as s/w rendering directly into VRAM -
which means it sucks real bad. :-(
What it means to ZeeSpace (and any other procedural texture heavy
engine) is that one can't update more than about half an 800x600
screenful's worth of graphics data every frame without dropping below
the display refresh rate. That might still be ok, though; I don't
think anyone will notice if the dynamic lighting runs at a lower
frame rate sometimes, as long as the scrolling is smooth and steady.
One might even give fast moving objects higher priority, to avoid
still or slow moving objects spending the bandwidth budget for no
visible gain. (Yeah; moving an object means recalculating the
lighting in the affected area, so OpenGL isn't helping much here...
Though one *could* cheat some and do normal sprites; only updating
them and the background as fast as possible, while moving the sprite
at the full frame rate.)
Anyway, time for caffeine and more hacking... (Mostly work related,
unfortunately - though I still have some stuff almost ready for
release. Where did all that code come from, really!? Someone isn't
getting enough sleep here...)
//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 ---
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
