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

[Martin F. <mf...@ac...>]

I agree with what's been said about the data cache and memory constraints.
However most programmers I've interviewed without console experience tend to
have a respect for consoles and people with console experience but most of
them appreciate the added difficulty, particularly on PS2 going right down
to the metal in almost every area.

We've expended an enormous ammount of effort on getting memory down,
streaming geometry, textures, animations, sound etc.. And also an enormous
ammount of effort making things data cache friendly, using the DMA to move
data around rather than the processor, using the scratch pad and the
uncached memory access modes. Infact our biggest problems have been with PC
style code that works fine on the PC but ends up requiring an enormous
ammount of effort to get running efficiently on PS2. Just walking a linked
list of any size can be a killer. My recommendation would be for any systems
required to deal with a large ammount of data, particle systems, events
processing, object drawing, collision, lighting, plan your data structures
first to be as cache efficient as possible. Particularly if it's going on a
vector unit. I think it's a mistake to write a PS2 game (or any console)
without planning as you'll end up trying to change some very embedded
systems later on and waste alot of time / give yourself a headache. This
becomes more true the more powerful the console IMHO as chances are your
code is larger and more complex.

We've never had any problems to speak of with the actual processor,
generally memory reads and writes are far more of a concern than the
instructions performed on that memory. You can't treat PS2 like a PC with
reguard to memory accesses and expect to get decent performance but you can
get very decent performance out of it.

There have been a number of articles by people converting PC games to PS2
which have been very interesting. Well respected PC teams talking about how
much they learned about efficient programming practice trying to get their
48MB PC animation cache down to 4MB on the PS2 and managing it. 

My recommendation if you're seriously trying to prototype a game on PC that
you will move to PS2 is allocate yourself about 29MB and try and get your
game to fit in that. Remembering of course you're probably going to have to
lay aside around 2MB for you executable. Have a look also at how much memory
you have elsewhere in the system, VRAM, Sound Ram, IOP etc.. and try and
emulate that through simple managers (texture, sound whatever) with software
limits. If your PC graphics card doesn't support palletized textures but you
want to use them on PS2 calculate the palletized size of the texture and
upload the unpalletized version into your nice 64MB!! of VRAM your PC has. 

I much prefer consoles as they force you to be efficient. I'm sure if I were
doing a PC game there are times when I wouldn't have expended the effort and
simply used a bit more RAM. On a console the specs are up front and totally
static. You can design your systems to suit that spec. You have only
yourself to blame if you end up struggling for RAM or processing speed.

Cheers,
Martin
Lead Programmer
Shadowman2 (PS2)



-----Original Message-----
From: R & D (GameBrains) [mailto:res...@ga...]
Sent: Wednesday, October 24, 2001 12:54 AM
To: gam...@li...
Subject: Re: [GD-Consoles] Comparison PC / PS2 / GameCube ?


I agree completely with the previous posters but I will start a minor rant
too...

One of the things that annoys me is when I hire new programmers who have a
lot of attitude based upon PC work, own a PS2 and think all the games are
crap, and think they will be the ones to show everybody how its really done.
While I appreciate the enthusiasm and confidence, the issue is one of
perspective.  If you approach PS2, GameCube or any console as just that (a
home appliance not a computer system) then that *way of thinking* will solve
most of the other problems.  You start to see that as an appliance: every
machine in the world is the same and can be exploited for that, that the
machine won't do anything you don't tell it to do explicitly since there is
no OS and that every single byte of memory, data and code has got to live
somehwere and if your Excel spreadsheet can't find a place for it in memory
the compiler can't either : )

Ah, I feel much better...

Cheers,
Brett Bibby
GameBrains

----- Original Message ----- 
From: "Stefan Boberg" <Ste...@te...>
To: <gam...@li...>
Sent: Wednesday, October 24, 2001 5:05 AM
Subject: RE: [GD-Consoles] Comparison PC / PS2 / GameCube ?


> > 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...
> 
> 
> 
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> 


_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles