RE: [GD-Consoles] Comparison PC / PS2 / GameCube ?

[Stefan B. <Ste...@te...>]

> Is it possible, to help the game design of a game before having the
kits
> and engine ready on PS2 and GameCube, to compare the PS2 and the
GameCube
> with a PC ?

  On the projects I have worked on, the most significant difference
between the consoles and the PC is the penalty for missing the D-cache.
Most PC's have large primary and secondary caches, and don't compete for
access to memory bandwidth with any other devices (apart from AGP memory
of course). So if the programmers on your team have not been careful
when laying out and accessing their data structures, you might see
considerable performance degradation simply due to cache misses (the
penalty is *significant*). The NGC is less sensitive than the PS2, which
is very sensitive.

  On the graphics side, most of the new consoles and PC cards have gobs
of fillrate, but getting geometry efficiently to the rasterizer is quite
involved on some of the consoles (*cough*). IMHO, more involved than it
really ought to be. So depending on your time constraints, some form of
middleware might be sensible on some platforms, whereas on others I
don't really think it buys you a lot because they already provide
reasonably rich and flexible APIs.

  The other big consideration which others have already mentioned is
memory usage. The constraints are HARD on consoles, not soft like on the
PC. If you ask most PC programmers how much memory they are using, they
most likely give you a blank stare... ask a console programmer the same
question, and you are likely to get a very different answer. You need to
make sure you manage memory very carefully. Static buffers are actually
your friend... dynamic allocation is nice but in the end your heap is
going to get fragmented if you keep allocating bits all over the place.
But unlike the PC, the OS won't be nice to you and move pages around in
virtual memory space or page it out for you... your game will simply
crash. There are many different memory allocation strategies, but the
simple ones tend to work best, so if you can, design your game engine
with this in mind.

  Also... keep your data as "monolithic" as you can... CD/DVD access is
SLOW and you really don't want to be loading small files here and
there... just preprocess your data so that is as close to the in-core
representation as possible - perhaps even a straight memory dump of the
static data structures!!! Pre-build as much as you can... display lists,
render state blocks, etc etc. Because building stuff in real-time is
very costly.

  Just my 2 pence... there's lots more to be said about it but now I
have to go back to sort out some of the abovementioned issues on a PS2
game initially developed on the PC... it's fun, fun, fun! :)

Cheers,
Stef
--
Stefan Boberg - R&D Manager, Team17 Software Ltd.
bo...@te...