gamedevlists-consoles — List for discussing game development on consoles like the PS2 and XBox

Re: [GD-Consoles] TOOL

[Alistair M. <vw...@nt...>]

> From: "R & D (GameBrains)" <res...@ga...>

> Specifically, when I boot my TOOL I get the network info
> screen.  Once I start coding it goes away.  Is there an
> easy way to get it redisplayed?  Is there a better place
> to ask questions like this?

Connect to the Devkit using a web browser, you can get all the info that way.  The info screen gets obscured when you flash the bios with a recent update anyway.  

> I have searched the SCEE and SCEA web sites and cannot
> find any docs telling you all the things and ways to use
> the TOOL, but if anybody knows where such a doc lives,
> let me know.

There's some info at www.ps2-pro.com in the Documents/Technical Notes area.  Not much, but some.

Alistair

[GD-Consoles] TOOL

[R & D \(GameBrains\) <res...@ga...>]

I was wondering if anybody knows any tips and tricks they would like to =
share on using PS2 dev kits.  I don't think it violates any NDA to =
discuss shortcuts, etc.

Specifically, when I boot my TOOL I get the network info screen.  Once I =
start coding it goes away.  Is there an easy way to get it redisplayed?  =
Is there a better place to ask questions like this?

I have searched the SCEE and SCEA web sites and cannot find any docs =
telling you all the things and ways to use the TOOL, but if anybody =
knows where such a doc lives, let me know.

Cheers,
Brett

RE: [GD-Consoles] new to console programming...

[Seungrog, O. <emp...@75...>]

Hi all, I'm new to PS2 programming, too.
Actually I got my PS2 development machine today,
but can't find developer's website and newsgroups.
I guess there exists some other resources other than https://sce-
net.scei.co.jp,
which is in Japanese. :-(
Anyone please can give me some access points?
Thanks in advance.

Seungrog, Oh

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Jeff Lander
> Sent: Wednesday, October 03, 2001 3:34 AM
> To: gam...@li...
> Subject: Re: [GD-Consoles] new to console programming...
> 
> 
> If your company is NDA'd with Sony already, you should have 
> access to the developer's website and newsgroups.  There is 
> quite a bit of material there covering all aspects of PS2 
> development.  The newsgroups are pretty active and the 
> website has a lot of sample code and docs.  Definitely get 
> the code off the developer website.  The demo code that comes 
> with the system is horrible but I wouldn't let that 
> discourage you too much.  
> 
> I doubt you will find too much on any public forums or 
> websites.  All the material is under NDA.
> 
> -Jeff
> 
> At 11:02 AM 10/2/2001 -0700, Marcin Wieczorek wrote:
> >Hi,
> >
> >         I'm new to console programming, namely PS2, and I 
> was wondering if anyone
> >could point me to some resources on the net where I can read 
> up on maybe
> >general programming techniques and such.
> >
> >         We recently had the Gamasutras PS2 article float 
> around the office
> >(http://www.gamasutra.com/gdce/green/green_01.htm )and I was 
> wondering if
> >maybe there are some other articles like this one that will 
> give me a better
> >understanding of the console before I actually sit down and 
> start typing.
> >
> >Does anyone have any opinions about the above mentioned 
> article?  Is it a
> >good thing for a beginner to engrave in his head?  Pitfalls 
> that I should be
> >aware?
> >
> >I don't want this to turn into a why xbox programming is 
> easier and I should
> >do that' topic.  My company is looking into making a title 
> for PS2 and I
> >need as much basic knowledge of the machine as possible.
> >
> >Any help would be appreciated.
> >
> >Thanks,
> >Marcin
> >
> >
> >_______________________________________________
> >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
> 

RE: [GD-Consoles] Textures vs. Polygons

[Alistair M. <kr...@kr...>]

That's huge!  We're normally using a single 512x256 texture for our main
characters, which can sometimes take up to 50% of screen space when you get
in close, and they still look magnificent.  Lighting has a lot to do with
it, adding subtlety and tint where none exists, and the fact that we're on
PS2 displaying through a TV helps a lot too!  On some of the more
"background" filler textures, we were surprised that 4-bit palettised
textures with dithering still looked really nice with a good quantisation
algorithm and judicious use of lighting.

The image-splitting trick you mentioned in a previous email also looks
great, but we haven't used it in-game yet.  If you reduce the colour map to
25% (1/16 area, that is), then use 2 bits per pixel for the detail map, you
can get it down to 4 bits per pixel, which is nice.  You could even reduce
that further by palettising the colour map, but that can start looking
messy.  The really neat thing about this method is that you can get
continuous level of detail by controlling the alpha value when
multiplying-in the detail map.  Fade out the alpha for further-away objects,
and you have a visually seamless cut-off point where you don't need the
detail any more.

Alistair Milne
Dogfish Entertainment Ltd



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Tom Forsyth
> Sent: 21 November 2001 12:08
> To: R & D (GameBrains); gam...@li...
> Subject: RE: [GD-Consoles] Textures vs. Polygons
>
>
> There is no typical size! We've tended to use 512x512 for a whole
> person in
> the past, but that was for StarTopia, which is very RTS-like in its
> viewpoint - you're high up, and there's lots of small people
> running around
> on the screen. For Blade2 we have something like eight 256x256 textures to
> cover the main character - Blade, but that's for a console title,
> where you
> just don't have enough pixels on the screen to see any higher
> detail. For a
> PC version, we'd probably upsample a few of those, because people
> will want
> to run at 10x7.
>
> Tom Forsyth - Muckyfoot bloke.
>

RE: [GD-Consoles] Textures vs. Polygons

[Jamie F. <ja...@qu...>]

Sounds like what I was getting at :) Nice to discover (occasionally) areas
where the PC guys have more difficulty than the PS2 guys :)

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Awen Limbourg
Sent: 21 November 2001 08:58
To: gam...@li...
Subject: RE: [GD-Consoles] Textures vs. Polygons


>2.  Jamie/Awen:  Sorry, I am not clear on what you mean by splitting the
geometry matrices, could you explain this in more detail?

Hope i'm going to describe what Jamie had in mind...
Ok: objects verts/polys/etc are sorted and stripped using some criterions
(polys batched on a per-material basis is a common practice). Strip best
size, and neihgbouring choice, is generally choosen using many params
considerations (GPU cache size ?). More specifically on a PS2, if you choose
to use VU to do your mesh mathematics, the VU mem size may be one of these
params. For an object, you need to compute the storage required by the VU to
process one of your vertex (3d coords+normal+uvs+rgbs... etc.), and usually
a matrix or two, to rotate and light your stuff. You have to be smart with
you VU and make some decisions on what could stay for a while, and what must
be quickly discarded to minimize DMA traffic. Matrices may be considered
more 'static' than verts flow.
For an animated object your need to add some skinning consideration to that
point, and configure your mesh to require the least possible matrices
swapping. And it shows naturally the way you choose to strip/sort your mesh
polys.

Ant it's a bit related to your texture details problem, since if you NEED to
split your mesh into chunks because of matrices, why not having many
materials per object, if you're a king of parallelization and swapping
texture buffer, text upload cost stuff may be masked.
Sorry to stay a bit vague, it begins to touch some dungeon secrets, around
here ;)





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

RE: [GD-Consoles] Textures vs. Polygons

[Tom F. <to...@mu...>]

There is no typical size! We've tended to use 512x512 for a whole person in
the past, but that was for StarTopia, which is very RTS-like in its
viewpoint - you're high up, and there's lots of small people running around
on the screen. For Blade2 we have something like eight 256x256 textures to
cover the main character - Blade, but that's for a console title, where you
just don't have enough pixels on the screen to see any higher detail. For a
PC version, we'd probably upsample a few of those, because people will want
to run at 10x7.

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: R & D (GameBrains) [mailto:res...@ga...]
> Sent: 21 November 2001 00:09
> To: gam...@li...
> Subject: Re: [GD-Consoles] Textures vs. Polygons
> 
> 
> Thanks to everyone for posting some help.  Some follow-up....
> 
> 1.  Tom:  What is a typical size for a head texture and body skin?
> 2.  Jamie/Awen:  Sorry, I am not clear on what you mean by 
> splitting the geomtry matrices, could you explain this in more detail?
> 
> Thanks!
> Brett
> 
> 
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> 

Re: [GD-Consoles] Textures vs. Polygons

[R & D \(GameBrains\) <res...@ga...>]

Awen,
Thanks for explaining.  We are doing as you said and stripping based =
upon material already, and sorting everything else to minimize state =
changes, etc.  What I am not doing yet is looking at how skinning will =
effect what changes I need to make to our morphing and kinematic data, =
structure and the matrices.  Your note has helped me forsee some stuff I =
need to look at, thanks much!
Brett

----- Original Message -----=20
From: "Awen Limbourg" <ali...@ed...>
To: <gam...@li...>
Sent: Wednesday, November 21, 2001 4:58 PM
Subject: RE: [GD-Consoles] Textures vs. Polygons


> >2.  Jamie/Awen:  Sorry, I am not clear on what you mean by splitting =
the
> geometry matrices, could you explain this in more detail?
>=20
> Hope i'm going to describe what Jamie had in mind...
> Ok: objects verts/polys/etc are sorted and stripped using some =
criterions
> (polys batched on a per-material basis is a common practice). Strip =
best
> size, and neihgbouring choice, is generally choosen using many params
> considerations (GPU cache size ?). More specifically on a PS2, if you =
choose
> to use VU to do your mesh mathematics, the VU mem size may be one of =
these
> params. For an object, you need to compute the storage required by the =
VU to
> process one of your vertex (3d coords+normal+uvs+rgbs... etc.), and =
usually
> a matrix or two, to rotate and light your stuff. You have to be smart =
with
> you VU and make some decisions on what could stay for a while, and =
what must
> be quickly discarded to minimize DMA traffic. Matrices may be =
considered
> more 'static' than verts flow.
> For an animated object your need to add some skinning consideration to =
that
> point, and configure your mesh to require the least possible matrices
> swapping. And it shows naturally the way you choose to strip/sort your =
mesh
> polys.
>=20
> Ant it's a bit related to your texture details problem, since if you =
NEED to
> split your mesh into chunks because of matrices, why not having many
> materials per object, if you're a king of parallelization and swapping
> texture buffer, text upload cost stuff may be masked.
> Sorry to stay a bit vague, it begins to touch some dungeon secrets, =
around
> here ;)
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
>=20

RE: [GD-Consoles] Textures vs. Polygons

[Awen L. <ali...@ed...>]

>2.  Jamie/Awen:  Sorry, I am not clear on what you mean by splitting the
geometry matrices, could you explain this in more detail?

Hope i'm going to describe what Jamie had in mind...
Ok: objects verts/polys/etc are sorted and stripped using some criterions
(polys batched on a per-material basis is a common practice). Strip best
size, and neihgbouring choice, is generally choosen using many params
considerations (GPU cache size ?). More specifically on a PS2, if you choose
to use VU to do your mesh mathematics, the VU mem size may be one of these
params. For an object, you need to compute the storage required by the VU to
process one of your vertex (3d coords+normal+uvs+rgbs... etc.), and usually
a matrix or two, to rotate and light your stuff. You have to be smart with
you VU and make some decisions on what could stay for a while, and what must
be quickly discarded to minimize DMA traffic. Matrices may be considered
more 'static' than verts flow.
For an animated object your need to add some skinning consideration to that
point, and configure your mesh to require the least possible matrices
swapping. And it shows naturally the way you choose to strip/sort your mesh
polys.

Ant it's a bit related to your texture details problem, since if you NEED to
split your mesh into chunks because of matrices, why not having many
materials per object, if you're a king of parallelization and swapping
texture buffer, text upload cost stuff may be masked.
Sorry to stay a bit vague, it begins to touch some dungeon secrets, around
here ;)

RE: [GD-Consoles] Textures vs. Polygons

[Jacob T. (C. D. Ltd) <Ja...@Co...>]

I looked into luminance splitting compression method for textures and it is
a massive saving for 24-bit textures, but not that big a gain if you using
256 colour paletted textures.

Just for the record we texture each face individually on a character (well
actually the artists do the texturing ;-) ) and let the artists use as big a
texture as they want and then we split it up into 256x256 chunks when we
build the game data.  This allows the freedom to put more texture detail
into those parts that need it e.g. faces, hands, feet.

Jake

> From: Tom Forsyth <to...@mu...>
> To: Jamie Fowlston <ja...@qu...>, 
> 	gam...@li...
> Subject: RE: [GD-Consoles] Textures vs. Polygons
> Date: Tue, 20 Nov 2001 15:07:53 -0000
> 
> DX/OGL vertex shaders have limits as well, and in some cases they're
> possibly lower than the VU ones. So yeah, splitting meshes up 
> like this is
> something people have to do.
> 
> I don't know of any magic stuff that wil help. There's detail 
> textures - but
> that just adds some "noise" to things - it's good for gravel 
> and grass and
> other landscape stuff, but probably not very useful for 
> people until you get
> horrendously close (cloth weave, fingerprints, pores, etc). 
> If you're aiming
> for ultimate realism, they will be useful, but my impression 
> is that you're
> having trouble well before then.
> 
> Having different bits of the body at different sizes on 
> thetexture can work
> well. We always have faces take up about four times the 
> texture area (i.e.
> twice as big in each direction) as equivalently-sized body 
> parts, because
> people look at faces much more closely, so you notice 
> pixellisation much
> quicker there than elsewhere. They're still on the same 
> texture as the rest
> of the body though.
> 
> For really high detail there's not much that cn beat just using a big
> texture. Obviously you can compress them with the S3TC/DXtn 
> stuff for space
> advantages. Another compression trick I've been thinking 
> about is to take a
> huge texture made by the artist, then extract the luminance 
> as a separate
> texture. Then quantise it to 4 bits. Then remove that 
> influence from the
> original texture, downsample the texture quite a bit down to 
> more sensible
> sizes, and compress using S3TC/DXTn.
> 
> Then we can render the combo using multitexture hardware. The 
> colour and
> subtle gradient info is encoded in the (relatively) low-res 
> RGB texture, and
> the high-frequency luminance info is in the high-res 
> monochrome texture
> (some hardware may not understand A4 texture, so it might 
> need expanding to
> A8 unfortunatelky).
> 
> It's the same trick as used by television of course, and I 
> believe there's a
> Sony sample using this method too.
> 
> Tom Forsyth - Muckyfoot bloke.
> 
> What's he up to now (and can I have a go)?
> http://www.eidosinteractive.com/downloads/search.html?gmid=86
> 

Re: [GD-Consoles] Textures vs. Polygons

[R & D \(GameBrains\) <res...@ga...>]

Thanks to everyone for posting some help.  Some follow-up....

1.  Tom:  What is a typical size for a head texture and body skin?
2.  Jamie/Awen:  Sorry, I am not clear on what you mean by splitting the =
geomtry matrices, could you explain this in more detail?

Thanks!
Brett

RE: [GD-Consoles] Textures vs. Polygons

[Tom F. <to...@mu...>]

DX/OGL vertex shaders have limits as well, and in some cases they're
possibly lower than the VU ones. So yeah, splitting meshes up like this is
something people have to do.

I don't know of any magic stuff that wil help. There's detail textures - but
that just adds some "noise" to things - it's good for gravel and grass and
other landscape stuff, but probably not very useful for people until you get
horrendously close (cloth weave, fingerprints, pores, etc). If you're aiming
for ultimate realism, they will be useful, but my impression is that you're
having trouble well before then.

Having different bits of the body at different sizes on thetexture can work
well. We always have faces take up about four times the texture area (i.e.
twice as big in each direction) as equivalently-sized body parts, because
people look at faces much more closely, so you notice pixellisation much
quicker there than elsewhere. They're still on the same texture as the rest
of the body though.

For really high detail there's not much that cn beat just using a big
texture. Obviously you can compress them with the S3TC/DXtn stuff for space
advantages. Another compression trick I've been thinking about is to take a
huge texture made by the artist, then extract the luminance as a separate
texture. Then quantise it to 4 bits. Then remove that influence from the
original texture, downsample the texture quite a bit down to more sensible
sizes, and compress using S3TC/DXTn.

Then we can render the combo using multitexture hardware. The colour and
subtle gradient info is encoded in the (relatively) low-res RGB texture, and
the high-frequency luminance info is in the high-res monochrome texture
(some hardware may not understand A4 texture, so it might need expanding to
A8 unfortunatelky).

It's the same trick as used by television of course, and I believe there's a
Sony sample using this method too.

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 20 November 2001 11:26
> To: gam...@li...
> Subject: RE: [GD-Consoles] Textures vs. Polygons
> 
> 
> I had a half insane idea for character rendering on PS2. I'm 
> probably not
> the only one who's had it, but I'll share it anyway :)
> 
> One of the limitations on PS2 is the number of matrices you 
> can fit on VU
> for skinning (don't worry, this will get relevant to your 
> problem). So to
> counteract this, you could split the character geometry 
> according to which
> matrices it uses. This way you'd never _need_ more than 3 * M 
> matrices on VU
> at any one time (where M is the maximum number of matrices applied per
> vertex). You may, of course, choose to lump in a few more matrices.
> 
> From a texturing point of view, this should fairly naturally split the
> geometry into chunks which are skinned, so you can then use 
> textures more
> efficiently, and use several per character effectively.
> 
> Disclaimer: I haven't actually done this :)
> 
> Jamie
> 
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On 
> Behalf Of R
> & D (GameBrains)
> Sent: 20 November 2001 06:19
> To: gam...@li...
> Subject: [GD-Consoles] Textures vs. Polygons
> 
> 
> List has been quiet of late and I have a semi-OT question....
> 
> Technology has come far enough in close-up character 
> rendering that the
> skins for characters seem to take up too much precious space 
> for the quality
> they show on screen and I was wondering if there are 
> solutions around this.
> For example, when you see a character up close that has been 
> skinned, even
> with a hi-res texture you can see pixelation around the 
> places like the neck
> etc. and the pixel filtering makes it look really not natural 
> when compared
> to the individually textured environments in the background.  
> The "easy"
> solution is to not use skins, but to individually texture 
> each part of the
> character, but then the subtle detail of clothing seams and 
> shadows is gone.
> To get around this we could use shadow maps, decaled textures, vertex
> coloring, etc.
> 
> 1.  How have others solved this problem, especially on 
> consoles such as the
> PS2 where texture cache is limited?
> 2.  For those using skins, what has been a good resolution 
> for the skin for
> consoles?  For PC?
> 3.  Can multi-texturing and other solutions actually solve 
> this problem?
> 
> Any advice that those have to offer would be welcome:)  Most 
> of our previous
> games have used rigid body objects rather than organic 
> characters, so we are
> new to the problems that are likely old-hat to everyone else...
> 
> Thanks!
> Brett
> 
> 
> _______________________________________________
> 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
> 

RE: [GD-Consoles] Textures vs. Polygons

[Awen L. <ali...@ed...>]

>One of the limitations on PS2 is the number of matrices you can fit on VU
>for skinning (don't worry, this will get relevant to your problem). So to
>counteract this, you could split the character geometry according to which
>matrices it uses. This way you'd never _need_ more than 3 * M matrices on
VU
>at any one time (where M is the maximum number of matrices applied per
>vertex). You may, of course, choose to lump in a few more matrices.

It's something we had to do: and finally it's only a matter of stripper
criterion (like materials) during the exportation phase of our object. We
even added some subtle params changes depending - effectively- of the size
remaining in the VU, depending of the rendering mode of the animated object,
etc.
Beware of the misunderstanding between texture 'skin' and animation 'skin'
(the data which links a vertex to their bone). By the way, why such a
limitation to only one material per skinned object (for a heavy polygon
mesh, the overload of 'more than one' texture to upload on a PS2 is not so
heavy) ?


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of R
& D (GameBrains)
Sent: 20 November 2001 06:19
To: gam...@li...
Subject: [GD-Consoles] Textures vs. Polygons


List has been quiet of late and I have a semi-OT question....

Technology has come far enough in close-up character rendering that the
skins for characters seem to take up too much precious space for the quality
they show on screen and I was wondering if there are solutions around this.
For example, when you see a character up close that has been skinned, even
with a hi-res texture you can see pixelation around the places like the neck
etc. and the pixel filtering makes it look really not natural when compared
to the individually textured environments in the background.  The "easy"
solution is to not use skins, but to individually texture each part of the
character, but then the subtle detail of clothing seams and shadows is gone.
To get around this we could use shadow maps, decaled textures, vertex
coloring, etc.

1.  How have others solved this problem, especially on consoles such as the
PS2 where texture cache is limited?
2.  For those using skins, what has been a good resolution for the skin for
consoles?  For PC?
3.  Can multi-texturing and other solutions actually solve this problem?

Any advice that those have to offer would be welcome:)  Most of our previous
games have used rigid body objects rather than organic characters, so we are
new to the problems that are likely old-hat to everyone else...

Thanks!
Brett


_______________________________________________
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

RE: [GD-Consoles] Textures vs. Polygons

[Jamie F. <ja...@qu...>]

I had a half insane idea for character rendering on PS2. I'm probably not
the only one who's had it, but I'll share it anyway :)

One of the limitations on PS2 is the number of matrices you can fit on VU
for skinning (don't worry, this will get relevant to your problem). So to
counteract this, you could split the character geometry according to which
matrices it uses. This way you'd never _need_ more than 3 * M matrices on VU
at any one time (where M is the maximum number of matrices applied per
vertex). You may, of course, choose to lump in a few more matrices.

From a texturing point of view, this should fairly naturally split the
geometry into chunks which are skinned, so you can then use textures more
efficiently, and use several per character effectively.

Disclaimer: I haven't actually done this :)

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of R
& D (GameBrains)
Sent: 20 November 2001 06:19
To: gam...@li...
Subject: [GD-Consoles] Textures vs. Polygons


List has been quiet of late and I have a semi-OT question....

Technology has come far enough in close-up character rendering that the
skins for characters seem to take up too much precious space for the quality
they show on screen and I was wondering if there are solutions around this.
For example, when you see a character up close that has been skinned, even
with a hi-res texture you can see pixelation around the places like the neck
etc. and the pixel filtering makes it look really not natural when compared
to the individually textured environments in the background.  The "easy"
solution is to not use skins, but to individually texture each part of the
character, but then the subtle detail of clothing seams and shadows is gone.
To get around this we could use shadow maps, decaled textures, vertex
coloring, etc.

1.  How have others solved this problem, especially on consoles such as the
PS2 where texture cache is limited?
2.  For those using skins, what has been a good resolution for the skin for
consoles?  For PC?
3.  Can multi-texturing and other solutions actually solve this problem?

Any advice that those have to offer would be welcome:)  Most of our previous
games have used rigid body objects rather than organic characters, so we are
new to the problems that are likely old-hat to everyone else...

Thanks!
Brett


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

[GD-Consoles] Textures vs. Polygons

[R & D \(GameBrains\) <res...@ga...>]

List has been quiet of late and I have a semi-OT question....

Technology has come far enough in close-up character rendering that the =
skins for characters seem to take up too much precious space for the =
quality they show on screen and I was wondering if there are solutions =
around this.  For example, when you see a character up close that has =
been skinned, even with a hi-res texture you can see pixelation around =
the places like the neck etc. and the pixel filtering makes it look =
really not natural when compared to the individually textured =
environments in the background.  The "easy" solution is to not use =
skins, but to individually texture each part of the character, but then =
the subtle detail of clothing seams and shadows is gone.  To get around =
this we could use shadow maps, decaled textures, vertex coloring, etc.

1.  How have others solved this problem, especially on consoles such as =
the PS2 where texture cache is limited?
2.  For those using skins, what has been a good resolution for the skin =
for consoles?  For PC?
3.  Can multi-texturing and other solutions actually solve this problem?

Any advice that those have to offer would be welcome:)  Most of our =
previous games have used rigid body objects rather than organic =
characters, so we are new to the problems that are likely old-hat to =
everyone else...

Thanks!
Brett

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

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

[R & D \(GameBrains\) <res...@ga...>]

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 -----=20
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 ?
>=20
>   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.
>=20
>   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.
>=20
>   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.
>=20
>   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.
>=20
>   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! :)
>=20
> Cheers,
> Stef
> --
> Stefan Boberg - R&D Manager, Team17 Software Ltd.
> bo...@te...
>=20
>=20
>=20
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
>=20

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...

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

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

I don't think it's really possible.

The architecture of the PS2 particularly is so completely different to that
of a PC.

What works fine on a PC is more than likely going to give you any number of
performance problems on the PS2.
And this applies the other way round there is alot of stuff you can do on
the PS2 you wouldn't normally attempt on a PC.

Suppose you were able to draw the same number of polys on a very high spec
PC at the same frame rate with the same textures / FX as the PS2. The means
to do that at the same framerate would be very different.

GameCube I don't know about. For now ;) I would expect it to be easier for
GameCube (than PS2) to say if I have PC X with Graphics card Y then that's
what my GameCube could do. Again though I think it'll still be a very
difficult match and even then there would be things that GameCube would
likely do alot better. I don't want to start a flame war with NVIDIA or
anything but there will be things that the best PC graphics cards cannot
match on both GameCube and PS2 though they'll be much better in other areas.

I think the best advice is to become a registered developer for Sony or
Nintendo (or both ;) and get hold of the docs before the devkit arrives. Try
and work out what it's going to be good at and what it's really bad at. Sony
I think run tutorial days where you can learn about the system from the
technical support group. There's all sorts of powerpoint presentations and
the such like on their developer website containing performance do's and
dont's.

Cheers,
Martin
Lead Programmer
Shadowman2 PS2



-----Original Message-----
From: Lionel Fumery [mailto:li...@hy...]
Sent: Tuesday, October 23, 2001 8:17 PM
To: gam...@li...
Subject: [GD-Consoles] Comparison PC / PS2 / GameCube ?


Hello,

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 ?

In other word, can I say "If your game runs fine on a Pentium XXX at XXX MHz
with the XXX graphic card, so it will probably run fine on a PS2 ?" ? Idem
for the GameCube.

And which value can I put behind the XXX ?

For example, I think that if my game runs fine on a Pentium 750 with a
GeForceIII, it will fit the Xbox. Same reflexion for PS2 & Gamecube.

Thank you in advance for any advice,

Lionel.


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

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

[Lionel F. <li...@hy...>]

Hello,

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 ?

In other word, can I say "If your game runs fine on a Pentium XXX at XXX MHz
with the XXX graphic card, so it will probably run fine on a PS2 ?" ? Idem
for the GameCube.

And which value can I put behind the XXX ?

For example, I think that if my game runs fine on a Pentium 750 with a
GeForceIII, it will fit the Xbox. Same reflexion for PS2 & Gamecube.

Thank you in advance for any advice,

Lionel.

RE: [GD-Consoles] Generic MP3 Player for Playstation 2

[Rachid El G. <ra...@mi...>]

Thanks a lot!

I heard also that 'arctan2' behaves differently in extreme cases.

I'll try what u suggested and see what it gives.

-rachid
Midway

-----Original Message-----
From: Arn [mailto:ar...@bl...]
Sent: Tuesday, October 09, 2001 10:49 AM
Cc: GDConsoles
Subject: Re: [GD-Consoles] Generic MP3 Player for Playstation 2


Alistair Milne wrote:
> [..]
> > Rachid El Guerrab
> > [..]
> > It's mostly some jittering.. and my guess is that it mostly happens in
my
> > collision processing (lots of floating point computations). And I
> > have that
> > behavior too when I'm far away from the center of my sector (Big
floating
> > numbers).
>
> When you do a floating point multiply on the PS2, the lowest order bit of
> the mantissa effectively becomes random.  You cannot get around this.
This
> is why you get the jitter.  You need to scale things so that the lowest
> order bit makes the smallest possible difference to the outcome.

I also had jitter problems and tracked them down to my camera
matricies.  The sin/cos functions I was using for one of the camera
modes wasn't giving accurate enough results.  I replaced with the
sin/cos with the algorithm described in the VU manuals and all of my
jitter problems went away.


Arn

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

Re: [GD-Consoles] Generic MP3 Player for Playstation 2

[Arn <ar...@bl...>]

Alistair Milne wrote:
> [..]
> > Rachid El Guerrab
> > [..]
> > It's mostly some jittering.. and my guess is that it mostly happens in my
> > collision processing (lots of floating point computations). And I
> > have that
> > behavior too when I'm far away from the center of my sector (Big floating
> > numbers).
> 
> When you do a floating point multiply on the PS2, the lowest order bit of
> the mantissa effectively becomes random.  You cannot get around this.  This
> is why you get the jitter.  You need to scale things so that the lowest
> order bit makes the smallest possible difference to the outcome.

I also had jitter problems and tracked them down to my camera
matricies.  The sin/cos functions I was using for one of the camera
modes wasn't giving accurate enough results.  I replaced with the
sin/cos with the algorithm described in the VU manuals and all of my
jitter problems went away.


Arn

RE: [GD-Consoles] Generic MP3 Player for Playstation 2

[Alistair M. <kr...@kr...>]

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Rachid El Guerrab
>
> I have some difference of behavior between the PC and PS2 versions of the
> game.
>
> It's mostly some jittering.. and my guess is that it mostly happens in my
> collision processing (lots of floating point computations). And I
> have that
> behavior too when I'm far away from the center of my sector (Big floating
> numbers).
>

When you do a floating point multiply on the PS2, the lowest order bit of
the mantissa effectively becomes random.  You cannot get around this.  This
is why you get the jitter.  You need to scale things so that the lowest
order bit makes the smallest possible difference to the outcome.

Hope this helps,

alistair

RE: [GD-Consoles] Generic MP3 Player for Playstation 2

[Rachid El G. <ra...@mi...>]

I have some difference of behavior between the PC and PS2 versions of the
game.

It's mostly some jittering.. and my guess is that it mostly happens in my
collision processing (lots of floating point computations). And I have that
behavior too when I'm far away from the center of my sector (Big floating
numbers).

I tried reducing the floating unit precision on the PC to have the same
behavior, but no it's still works perfectly for PC.

Can somebody help me lay down a list of other things to verify/try? anything
(even if it seems strange or stupid) that may be the cause of the
differences?
(Could be a console specific thing, but could also be general CPUs
problem..)

Thank you.

Rachid
Midway


-----Original Message-----
From: Javier Arevalo [mailto:ja...@py...]
Sent: Monday, October 08, 2001 6:12 AM
To: GDConsoles
Subject: Re: [GD-Consoles] Generic MP3 Player for Playstation 2


From: "Leath Muller" <Lea...@en...>


> It surprises me Sony haven't looked at this yet as they seem to be really
> pushing the PS2 as a generic home entertainment component to play games &
> DVD's & CD's -- but not MP3's?

Sony has a large stake in the music record market. Nuff said. :) I'd be
surprised if they ever give the go ahead to any MP3 playback program for
PS2. Now this has finally drifted quite off-topic so I shut up.

Javier Arevalo
Pyro Studios



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

Re: [GD-Consoles] Generic MP3 Player for Playstation 2

[Javier A. <ja...@py...>]

From: "Leath Muller" <Lea...@en...>


> It surprises me Sony haven't looked at this yet as they seem to be really
> pushing the PS2 as a generic home entertainment component to play games &
> DVD's & CD's -- but not MP3's?

Sony has a large stake in the music record market. Nuff said. :) I'd be
surprised if they ever give the go ahead to any MP3 playback program for
PS2. Now this has finally drifted quite off-topic so I shut up.

Javier Arevalo
Pyro Studios

[GD-Consoles] Memory use ?

[Lionel F. <li...@mi...>]

Hello,

Some basic questions again !

Does anybody have real cases of memory use on GameCube and PS2 ? (% Code, %
3D Data, % Textures, % sound) ?
Which kind of compression ratio can I expect for the hardware texture
compression on those targets ?
Which kind of compression ratio can I expect with the vector compression on
PS2 ? Does the GameCube use a float/vector compression too ?

Thank you in advance,
Lionel