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

[GD-Consoles] GCC on Dreamcast and PS2

[brian h. <bri...@py...>]

Okay, a little bit of an odd one here, but does anyone know what 
predefined symbols GCC sets when targeting DreamCast or a PS2?

For a Dreamcast I know it sets the processor target to _SH4 (and the 
various permuations), but I don't know if it sets a target for the 
operating system (presumably Linux these days?).  I haven't hunted down 
a cross-compiler just yet.

For the PS2, the GCC for EE targets the MIPS R5900(?) in, I believe, 
little-endian mode, but I can't figure out if it actually has an OS 
target -- I don't think it does.  So I'm not sure how to build a header 
file that targets MIPSLE but that can also identify whether it will be 
on a PS2 vs. some other (?) MIPS little-endia device like the 5900.  
I'm looking at the stuff on ps2dev.sourceforge.net (ee-gcc) and I've 
tried sorting through the huge amount of crap in ee-gcc -dumpspecs.

Thanks,

Hook

[GD-Consoles] Admin: Reply To Change

[Tom H. <to...@3d...>]

Hi again folks!

As of this email, we're changing over the following mailing lists to 
reply-to-list:

gdalgorithms
gd-consoles
gd-design
gd-general
gd-linux
gd-windows

A vote was conducted on the algorithms list since that has the highest 
number of subscribers (~2000) and most of the people on the other lists are 
also on the algorithms list. Of the responses I got, 30 wanted us to change 
and 4 wanted us to stay the way we were. I haven't gotten another vote for 
10 hours, so I figure that's probably all the votes we're going to get.


Thanks for your time!

Tom

Re: [GD-Consoles] PS2 DVD emu?

[<phi...@pl...>]

I think you should buy one for every member of your team. Hell, buy them
two, the more the merrier... oh, no hang on, apparently I don't get a
commission... oh well.

If you're not doing anything clever with the disc then IMHO, it's a 'nice
thing to have'. You might burn a few dozen coasters trying to get the boot
sequence just right, but probably not enough to justify an emulator.
However, if you are trying to do stuff like background loading, while
simultaneously streaming audio (which we do), then it's probably worth it.
I don't think you'd need any more than one kit with it though.

Personally speaking, I did all the CD/DVD work for Kinetica without an
emulator (we have a couple, now, but they didn't arrive in time), and I
have around 100 coasters from that one, of which, about 5% are DVD-R's as
opposed to CDR's. I could probably have saved 95% of them with an emulator,
which adds up to around 40 hours of my time over a year and half.

Cheers,
Phil




                                                                                                                             
                    "Brett Bibby" <br...@ga...>                                                                     
                    Sent by:                                      To:     <gam...@li...>      
                    gam...@li...urc       cc:                                                        
                    eforge.net                                    Fax to:                                                    
                                                                  Subject:     [GD-Consoles] PS2 DVD emu?                    
                                                                                                                             
                    10/08/2002 06:26 PM                                                                                      
                                                                                                                             
                                                                                                                             




Not sure which PS2 developer forum to put this on, so I will ask here.

Can any PS2 developers comment on the usefulness of having (or not) the
CD/DVD emulator fitted into a T10K?  Do I need to have at least one kit
fitted with it to safely get a game through lot check in your opinion?
If it is a nice to have item only, how nice to have is it?

Thanks,
Brett



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553

Re: [GD-Consoles] PS2 DVD emu?

[<chr...@pl...>]

Brett Bibby wrote:
>Not sure which PS2 developer forum to put this on, so I will ask here.

The correct forum would be the Sony newsgroups. Probably the SN
newsgroup.


>Can any PS2 developers comment on the usefulness of having (or not) the
>CD/DVD emulator fitted into a T10K?  Do I need to have at least one kit
>fitted with it to safely get a game through lot check in your opinion?
>If it is a nice to have item only, how nice to have is it?

You don't need to have one, but you'll end up making a lot of
coasters at the end of the project. It's quite nicely integrated
into your windows environment as a device you can upload files to.

I've used it primarily for implementing our background loading
that allows us to move from level to level without the user
noticing there's loading going on, and it really made it much
simpler debugging the whole thing.

I'd say it's very nice to have for doing anything loading
related. Of course, a majority of the stuff we do isn't related
to loading, so I can't really say whether it's worth the money
or not -- that's up to you do decide.


You really should ask the question on the Sony newsgroups, and
you'd get many more answers. As a licensed developer you have
access to them. If you don't have an account send an email to
devsupport and request an account. The Sony newsgroups are an
_invaluable_ resource.



Christer Ericson
Sony Computer Entertainment, Santa Monica

[GD-Consoles] PS2 DVD emu?

[Brett B. <br...@ga...>]

Not sure which PS2 developer forum to put this on, so I will ask here.

Can any PS2 developers comment on the usefulness of having (or not) the
CD/DVD emulator fitted into a T10K?  Do I need to have at least one kit
fitted with it to safely get a game through lot check in your opinion?
If it is a nice to have item only, how nice to have is it?

Thanks,
Brett

RE: [GD-Consoles] Cg, HLSL, ?

[Paul B. <pa...@mi...>]

In Brute Force we have 115 vertex shaders and 85 pixel shaders.
All hand written.  Early on we looked at some sort of high
level shader language (even partially implemented one), but
decided that "we would only have a couple dozen shaders".  We
chose poorly. ;) =20

As others have said, if you are honestly targetting multiple
platforms, then you might not want to look at high level shading
languages.  On the other hand, if you are primarily targeting
one platform, you could tweak and specialize your favorite=20
language for your target - and "make it work" on others. =20

Paul

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]=20
> Sent: Wednesday, August 14, 2002 7:36 AM
> To: gam...@li...
> Subject: Re: [GD-Consoles] Cg, HLSL, ?
>=20
>=20
> Jamie Fowlston <ja...@qu...> wrote:
>=20
> > the only really viable solution i've heard of is to give=20
> the artists=20
> > access to a library of shaders, and reimplement them per=20
> platform. not=20
> > great, but it works.
>=20
> I agree. Could you people guesstimate the number of different=20
> material / shader types used in their games? I would assume=20
> at most a few dozens (with many of them being variations of a=20
> few). Anything under 40 is clearly a job for hand-crafting=20
> them. Even if you have an automated system, you will=20
> definitely leave the option to hand-optimize the most used=20
> (or less optimal when automated) ones.
>=20
>   Javier Arevalo
>   Pyro Studios
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online=20
> job board for high-tech professionals. Search and apply for=20
> tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=3D31
> _______________________________________________
> Gamedevlists-consoles mailing list=20
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D553
>=20

RE: [GD-Consoles] Cg, HLSL, ?

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

In Blade II (XBox version) we used around 150 vertex shader variants
(assembled and compiled from code fragments as and when required), about
five pixel shaders (hand written), and a lot of TSS setups (we don't have a
count of them).

On StarTopia I can't remember exactly how many we used, but from the code a
32-entry hash table was sufficient and efficient for materials that
represented the TSS states. I've also found a bit of code that pre-validated
the 29 most common materials, so there can't have been that many more. Of
course, StarTopia was a fairly simple game in terms of materials - no
bumpmapping, limited multitexture, etc.

It's wierd going back into code you wrote more than a year ago. It's all
half-remembered, but full of suprises.


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: 14 August 2002 13:36
> To: gam...@li...
> Subject: Re: [GD-Consoles] Cg, HLSL, ?
> 
> 
> Jamie Fowlston <ja...@qu...> wrote:
> 
> > the only really viable solution i've heard of is to give the artists
> > access to a library of shaders, and reimplement them per platform.
> > not great, but it works.
> 
> I agree. Could you people guesstimate the number of different 
> material /
> shader types used in their games? I would assume at most a 
> few dozens (with
> many of them being variations of a few). Anything under 40 is 
> clearly a job
> for hand-crafting them. Even if you have an automated system, you will
> definitely leave the option to hand-optimize the most used 
> (or less optimal
> when automated) ones.
> 
>   Javier Arevalo
>   Pyro Studios
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Gamedevlists-consoles mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=553
> 

Re: [GD-Consoles] Cg, HLSL, ?

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

Jamie Fowlston <ja...@qu...> wrote:

> the only really viable solution i've heard of is to give the artists
> access to a library of shaders, and reimplement them per platform.
> not great, but it works.

I agree. Could you people guesstimate the number of different material /
shader types used in their games? I would assume at most a few dozens (with
many of them being variations of a few). Anything under 40 is clearly a job
for hand-crafting them. Even if you have an automated system, you will
definitely leave the option to hand-optimize the most used (or less optimal
when automated) ones.

  Javier Arevalo
  Pyro Studios

RE: [GD-Consoles] Cg, HLSL, ?

[Wayne C. <wc...@re...>]

> the only really viable solution i've heard of is to give the 
> artists access
> to a library of shaders, and reimplement them per platform. 
> not great, but
> it works.

I agree, current consoles are pretty different from each other and limiting
yourself to a shading language will put restrictions on what you can do on
certain platforms (for instance the VU on the PS2 is far more flexible than
any current vertex shader hardware, however it doesn't have the equivalent
of a pixel shader). You could use a general shading language but you'll be
restricted somewhere, unless they're reimplemented for each platform.

Wayne
-Virus scanned and cleared ok

RE: [GD-Consoles] Cg, HLSL, ?

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

the only really viable solution i've heard of is to give the artists access
to a library of shaders, and reimplement them per platform. not great, but
it works.

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brett Bibby (GameBrains)
Sent: 14 August 2002 02:29
To: gam...@li...
Subject: [GD-Consoles] Cg, HLSL, ?


Since there is another thread running in the algo list on shaders, and most
of the people here seem to be there too, I wanted to ask about how people
are handling shaders for multi-platform console work.  We have a nice
development environment now that builds our runtime databases, but
implementing special effects on consoles like the PS2 is a headache.  We
were considering writing a compiler for either HLSL or Cg that could then
have a platform-specific backend to solve the problem.  It seems nVidia will
be releasing a reference implementation of the Cg compiler that has a simple
backend reporting tool and so we are leaning that direction at the moment.
Does this even seem viable to anyone?  It's not that we don't want to take
advantage of each console's capabilities, but rather it is hard to do right
now because artists don't have enough tools to do so, but with a more
generic approach using Cg we could preview the stuff in Max that would
roughly show the final effect.  How are other people getting special effects
implemented on consoles?
Thanks,
Brett Bibby
GameBrains



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code1
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU3

[GD-Consoles] Cg, HLSL, ?

[Brett B. \(GameBrains\) <res...@ga...>]

Since there is another thread running in the algo list on shaders, and =
most of the people here seem to be there too, I wanted to ask about how =
people are handling shaders for multi-platform console work.  We have a =
nice development environment now that builds our runtime databases, but =
implementing special effects on consoles like the PS2 is a headache.  We =
were considering writing a compiler for either HLSL or Cg that could =
then have a platform-specific backend to solve the problem.  It seems =
nVidia will be releasing a reference implementation of the Cg compiler =
that has a simple backend reporting tool and so we are leaning that =
direction at the moment.  Does this even seem viable to anyone?  It's =
not that we don't want to take advantage of each console's capabilities, =
but rather it is hard to do right now because artists don't have enough =
tools to do so, but with a more generic approach using Cg we could =
preview the stuff in Max that would roughly show the final effect.  How =
are other people getting special effects implemented on consoles?
Thanks,
Brett Bibby
GameBrains

RE: [GD-Consoles] render cost

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

GCN and Xbox are similar enough to the PC architecture that you can use a
common language (especially the Xbox, for obvious reasons). PS2 - completely
alien beast. The slow bit abut the PS2 is managing how your data flows
through the system - it's almost never the actual cost of the rendering,
unless you're doing some really complex things per-vertex. So the cost of "a
texture change" isn't something you can easily define :-)

Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: R & D (GameBrains) [mailto:res...@ga...]
> Sent: 19 July 2002 06:34
> To: gam...@li...
> Subject: [GD-Consoles] render cost
> 
> 
> Howdy,
> I was wondering if anybody could help me estimate the various 
> tradeoffs in rendering on PS2, GCN and Xbox.  For example, 
> state changes are considered "bad", but how bad are they?  At 
> some point a skin becomes so large that memory page breaks 
> combined with dma transfer time yield multiple smaller 
> textures a more appropriate solution, and how does number of 
> polys factor into this?  Does anybody have any rules of 
> thumbs for the various consoles regarding this type of 
> performance benchmarking?  Finally, is there a "language" for 
> this type of benchmarking?  Is it common to use Big-O 
> notation?  For anybody who is not sure of the cost as a ratio 
> or algorithm, just hard numbers would be helpful too (e.g. 
> our last game had 32 4,000 poly characters on screen @ 60hz 
> each with a different 512x512 8 bit skin, etc.)
> Cheers,
> Brett Bibby
> GameBrains

[GD-Consoles] render cost

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

Howdy,
I was wondering if anybody could help me estimate the various tradeoffs =
in rendering on PS2, GCN and Xbox.  For example, state changes are =
considered "bad", but how bad are they?  At some point a skin becomes so =
large that memory page breaks combined with dma transfer time yield =
multiple smaller textures a more appropriate solution, and how does =
number of polys factor into this?  Does anybody have any rules of thumbs =
for the various consoles regarding this type of performance =
benchmarking?  Finally, is there a "language" for this type of =
benchmarking?  Is it common to use Big-O notation?  For anybody who is =
not sure of the cost as a ratio or algorithm, just hard numbers would be =
helpful too (e.g. our last game had 32 4,000 poly characters on screen @ =
60hz each with a different 512x512 8 bit skin, etc.)
Cheers,
Brett Bibby
GameBrains

Re: [GD-Consoles] Dev tools & forums

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

1.  Metrowerks CodeWarrior (we use if for GCN, PS2, AGB, PC and Mac and =
it rocks)
2.  This forum :-)

Beyond that, I would say GCN programming pretty simple, especially if =
you know PowerPC assembly language and/or the PowerPC reference platform =
architecture.  Motorola/IBM have lots of info on this...

Brett
GameBrains

----- Original Message -----=20
From: "Johann Fuchs" <jo...@se...>
To: <gam...@li...>
Sent: Thursday, July 11, 2002 8:26 PM
Subject: [GD-Consoles] Dev tools & forums


2 questions:

1. which dev tools do you guys use for
developing for the gamecube?


2. are there anywhere public available
forums, where a programmer without
dev-kit for gamecube can discuss????


wbr
 Johann Fuchs

[GD-Consoles] Dev tools & forums

[Johann F. <jo...@se...>]

2 questions:

1. which dev tools do you guys use for
developing for the gamecube?


2. are there anywhere public available
forums, where a programmer without
dev-kit for gamecube can discuss????


wbr
 Johann Fuchs

RE: [GD-Consoles] Memory...

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

Just some words:
Think about dedicated memories too (PS2 scratchpad). Just use them if
available - there is probably a very a good reason if they exist.
Think about your algos, your data crawling has to be very very cache
friendly on consoles. Compact and Small blocks of data contribute to this.

PCs+Win allow a lot of cool things: just be aware that you were very
comfortable 'before' :) You can't code loosely very long before having some
curious performance troubles with consoles (fe Cache Misses will completely
strangle the beast: not only your main CPU, but probably all mem pipelines
feeding your copros)


-----Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
Tiziano Lena
Envoye : dimanche 7 juillet 2002 16:37
A : gam...@li...
Objet : [GD-Consoles] Memory...


Hi!
I would like to start my new engine using console friendly data structures
and memory handling.
Can someone help me with any tip? What allocation schemes do you use?
A large buffer that is handled like a stack? Or you can use, without
problems, lots of new/delete?
I would like to implement a new/delete handler to track all memory
allocations but in this way all memory should be dynamically allocated...
(not a good idea for consoles I fear).

Thanks, Tiziano Lena



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
We have stuff for geeks like you.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553

Re: [GD-Consoles] Memory...

[<phi...@pl...>]

Memory pools are your friend. Also, avoid allocating / freeing anything
during runtime as fragmentation is a bitch, and you don't have the virtual
memory escape route any more.

Seriously, the hardest thing about console game memory management, is that
you actually have to think about it.

Cheers,
Phil




                                                                                                                                   
                    "Mickael Pointier"                                                                                             
                    <mpo...@ed...>                    To:     <gam...@li...>            
                    Sent by:                                      cc:                                                              
                    gam...@li...urc       Subject:     Re: [GD-Consoles] Memory...                         
                    eforge.net                                                                                                     
                                                                                                                                   
                                                                                                                                   
                    07/08/2002 01:37 AM                                                                                            
                                                                                                                                   
                                                                                                                                   




> Hi!
> I would like to start my new engine using console friendly data
structures
> and memory handling.
> Can someone help me with any tip? What allocation schemes do you use?
> A large buffer that is handled like a stack? Or you can use, without
> problems, lots of new/delete?
> I would like to implement a new/delete handler to track all memory
> allocations but in this way all memory should be dynamically allocated...
> (not a good idea for consoles I fear).

I would say that considering the small amount of memory
we have on console, you cannot really afford to loose
memory for trivial things. So instead of having a lot
of small new/deletes (each one coming with some memory
overhead: block chaining information...), you should
instead allocate large chunks of memory, and use placement
new (if using C++) in those blocs.

The end result will be a gain in speed (during allocation
and deallocation phase), and a gain in memory if you manage
to allocate exactly what you need.

    Mickael Pointier




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-consoles mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=553

Re: [GD-Consoles] Memory...

[<chr...@pl...>]

Mickael Pointier wrote:
>> I would like to start my new engine using console friendly data
structures
>> and memory handling. Can someone help me with any tip?
>
>I would say that considering the small amount of memory
>we have on console, you cannot really afford to loose
>memory for trivial things. So instead of having a lot
>of small new/deletes (each one coming with some memory
>overhead: block chaining information...), you should
>instead allocate large chunks of memory, and use placement
>new (if using C++) in those blocs.
>
>The end result will be a gain in speed (during allocation
>and deallocation phase), and a gain in memory if you manage
>to allocate exactly what you need.

Seconded. We have a custom memory manager that handles multiple
heapzones in which you can do the following types of allocations:

1) Pools. Fast allocation/deallocation of fixed size objects.
2) Arenas. Fast allocation (only) of variable size objects.
3) Generic memory heap. Normal new/delete type allocations/
   deallocations of arbitrary size objects.

We try to use pools throughout for the reasons Mickael listed
above (faster, uses less memory, also more memory coherent).
So virtually all our classes have custom new/delete functions
allocating from a pool.

Our policy is to not do any generic new/delete calls when the
game is running. (There's an exception or two, though.)


Christer Ericson
Sony Computer Entertainment, Santa Monica

Re: [GD-Consoles] Memory...

[Mickael P. <mpo...@ed...>]

> Hi!
> I would like to start my new engine using console friendly data structures
> and memory handling.
> Can someone help me with any tip? What allocation schemes do you use?
> A large buffer that is handled like a stack? Or you can use, without
> problems, lots of new/delete?
> I would like to implement a new/delete handler to track all memory
> allocations but in this way all memory should be dynamically allocated...
> (not a good idea for consoles I fear).

I would say that considering the small amount of memory
we have on console, you cannot really afford to loose
memory for trivial things. So instead of having a lot
of small new/deletes (each one coming with some memory
overhead: block chaining information...), you should
instead allocate large chunks of memory, and use placement
new (if using C++) in those blocs.

The end result will be a gain in speed (during allocation
and deallocation phase), and a gain in memory if you manage
to allocate exactly what you need.

    Mickael Pointier

[GD-Consoles] Memory...

[Tiziano L. <tl...@li...>]

Hi!
I would like to start my new engine using console friendly data structures 
and memory handling.
Can someone help me with any tip? What allocation schemes do you use?
A large buffer that is handled like a stack? Or you can use, without 
problems, lots of new/delete?
I would like to implement a new/delete handler to track all memory 
allocations but in this way all memory should be dynamically allocated... 
(not a good idea for consoles I fear).

Thanks, Tiziano Lena

RE: [GD-Consoles] Nobody on this list?

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

>Issue #1
It depends of your main target. Ours was PS2. We had to be clever with
texturing. XBox it's a bit more comfortable on this topic... So, no
particular problem with resources flow.
At first sight XBox output is a bit 'less bright' (bad impression ?), but we
had to be careful with that on PS2 (because of the general graphic design:
'not too shiny pleaaaase'). Keeping the same resources on XBox will make my
art director an happy man. GC dev. is preliminary, but we have no particular
fear.
With a technician perspective, i believe that it won't be the most
problematic thing (for THAT project: at most an annoying detail) the hardest
work is not 'here' while cross-platforming, is it ?

>Issue #2
Mmmh. See Tom Forsyth's answer. Fits perfectly.


>Issue #3
Consoles are our main targets.
No big parallelism in developments here: so we are queuing platforms from
the biggest sales potential to the lowest. Being hard on this (brrr), it's
more desirable to kick the lowest potentials (the last ones, you can switch
to another project)...
Another point: 'lowest common denominator' ? I prefer 'first version on the
hardest', being very smart at the beginning (you gain some brand new
neurons) -> and toying with the next (you can dedicate them to implement
some new funny features, probing some new Tom F. deliriums...)
Since the beginning we have hardware independant code, using libraries for
the low level stuff guarantees us from being stuck while converting. We have
'other platforms culture' too (experience), useful when designing these libs
:).


>Issue #4
We are not particulary hit by the virus around here... Europe you know. A
bit cautious with internet/broadbands, etc :)
Previously a 1.5 developper for Sega, i had to do some efforts on this
point: it was technically interesting, but a bit... dedicated. Basically a
question of design/market/budget: 'i'm not sure about the sales gain while
considering online... Could that budget be more useful to another part of
your project ?' Well, and more, it depends of what drove your studio:
exciting (online ?) design, or mass market seduction (ok. Binary. But the
melt is not obvious, i believe, for our decision mens)

RE: [GD-Consoles] Nobody on this list?

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

> -----Original Message-----
> From: Steve Rabin [mailto:St...@no...]
> 
> 
> >>> "Jason G Doig" <jas...@py...> 07/03/02 
> 12:23PM >>>
> >Obviously I don't speak for other platforms where you might 
> still be nuked from orbit.
> 
> Roger that. The nukes are positioned and standing by. 
> Awaiting target acquisition...
> 
> (that was a joke)
> Yep, unfortunately many things are covered by NDA and it's 
> hard to talk too candidly in a public forum like this. 
> However, there are some good cross-platform subjects that are 
> worth discussing. I'll throw out some tasty ones:


I'll bite. We're doing PS2 and XBox versions, no GC at the moment. But I can
make wild extrapolations based on friend-of-a-friend rumoured GC specs if
you like... :-)

> Issue #1
> An important issue for cross-platform developers is how the 
> same art/textures will appear on each of the platforms. My 
> sources tell me that Microsoft recently released a paper 
> comparing XBOX to PS2 in terms of color/display output. I'd 
> like to hear from developers what their experiences have been 
> across all three platforms with respect to texture 
> appearance. Have textures needed to be changed in any way 
> when porting from one platform to another?

Fairly simple. PS2 mipmapping is expensive and approximate. So only the
textures that really need it get mipmapped, so the artists need to be
careful with the high-frequency stuff. XBox also has bigger textures because
of the greater memory and better compressed texture support, so for the PS2
we just ditch the top mipmap level of everything.

Also, since the surface effects available on XBox are much fancier than on
PS2, things like specular maps and so on get pre-composited in together to
one or two textures rather than the half-dozen we have on the XB.

> Issue #2
> Consoles have limited memory when compared with PCs. What 
> general compression algorithms (if any) are people using on 
> their titles (custom/zlib/lzo/platform specific). Do you hold 
> any data in memory and then decompress it on-the-fly when it 
> is needed? How concerned are you with patent issues when 
> considering a compression algorithm on your title?

We're using LZSS in places. We generally store compressed stuff on disk
(hard drive for XB, DVD for PS2), stream it in as we need it, and decompress
as we get it. The cost of LZSS decompression is far far less than the speed
boost we get from having to load half the data (typically ~50% compression
from LZSS).

We haven't tried storing stuff in memory compressed - I'm not sure that
would work terribly well. We'd rather use the memory to hold more stuff
cached off disk.

> Issue #3
> For cross-platform games: What platform is your primary 
> platform and at what point do you start porting to the 
> others? During development, what methods do you use to 
> guarantee quality and stability across all platforms? Do you 
> design/code your game for the lowest common denominator or do 
> you build it on the best (perhaps on a top-notch PC) and then 
> gracefully scale down?

Our primary platform is the PC! Our artists aim for PC quality, and we then
scale down in all sorts of ways to the target platform. It's pretty easy to
scale down to a target - bin mipmap levels, merge textures, reduce shader
complexity, reduce vertex count using VIPM, reduce bone counts using
progssive bones, etc. But going upwards in quality is very hard without
actual artwork to base it on.

Some of the artwork was started at PS2 quality before we realised we could
render 2-4x as many polys on XBox, and bumpmaps weren't done early enough.
Inventing that data without redone artwork has been ... tricky. I wouldn't
want to do it again. But if you have bumpmaps, then compositing them down to
"prelit" stuff for the PS2 is pretty easy.

> Issue #4
> Each console maker has a (different) plan for how online 
> games will work. Are you excited by any of these plans and 
> how will it affect the direction of your games? Are you going 
> to jump onboard or sit this one out until the next generation 
> of consoles?

Not done any console games this is applicable to yet, so it's not something
I've thought about much.

> Grab an issue and run with it. Issues #1 and #4 are timely 
> ones and issue #2 holds a certain fascination for me (I was 
> bit by the compression bug about a year ago).
> 
> Steve Rabin
> SDSG - Nintendo of America, Inc.
> Editor of "AI Game Programming Wisdom" (www.aiwisdom.com)


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

Re: [GD-Consoles] Nobody on this list?

[Steve R. <St...@no...>]

>>> "Jason G Doig" <jas...@py...> 07/03/02 12:23PM >>>
>Obviously I don't speak for other platforms where you might still be =
nuked from orbit.

Roger that. The nukes are positioned and standing by. Awaiting target =
acquisition...

(that was a joke)
Yep, unfortunately many things are covered by NDA and it's hard to talk =
too candidly in a public forum like this. However, there are some good =
cross-platform subjects that are worth discussing. I'll throw out some =
tasty ones:

Issue #1
An important issue for cross-platform developers is how the same art/textur=
es will appear on each of the platforms. My sources tell me that Microsoft =
recently released a paper comparing XBOX to PS2 in terms of color/display =
output. I'd like to hear from developers what their experiences have been =
across all three platforms with respect to texture appearance. Have =
textures needed to be changed in any way when porting from one platform to =
another?

Issue #2
Consoles have limited memory when compared with PCs. What general =
compression algorithms (if any) are people using on their titles (custom/zl=
ib/lzo/platform specific). Do you hold any data in memory and then =
decompress it on-the-fly when it is needed? How concerned are you with =
patent issues when considering a compression algorithm on your title?

Issue #3
For cross-platform games: What platform is your primary platform and at =
what point do you start porting to the others? During development, what =
methods do you use to guarantee quality and stability across all platforms?=
 Do you design/code your game for the lowest common denominator or do you =
build it on the best (perhaps on a top-notch PC) and then gracefully scale =
down?

Issue #4
Each console maker has a (different) plan for how online games will work. =
Are you excited by any of these plans and how will it affect the direction =
of your games? Are you going to jump onboard or sit this one out until the =
next generation of consoles?

Grab an issue and run with it. Issues #1 and #4 are timely ones and issue =
#2 holds a certain fascination for me (I was bit by the compression bug =
about a year ago).

Steve Rabin
SDSG - Nintendo of America, Inc.
Editor of "AI Game Programming Wisdom" (www.aiwisdom.com)

Re: [GD-Consoles] Nobody on this list?

[Jason G D. <jas...@py...>]

(Naturally, sent this personally rather than to the list....Sorry Awen)

From: "Awen Limbourg" <ali...@ed...>
> The Big Money Monster is crawling around here. I think most concerned people
> is under NDA (Axe threatened, controled by a Voodoo doll, whatsoever...),
> it's pretty rare to chat smartly around here.
> Brrrr cold place...


FWIW, I don't think there'd be any trouble talking about PS2 issues here, given the rather more open approach taken with the likes
of the PS2 linux project. The forums for that are public (i.e. you don't have to sign anything or buy anything to read them) and PS2
technical details are openly discussed...

In fact, we positively encourage people to learn about/play with our hardware, so long as you don't do anything naughty.

Obviously I don't speak for other platforms where you might still be nuked from orbit.

Jase.


--
Jason G Doig
Senior Engineer - Technology Group (R&D)
Sony Computer Entertainment Europe

RE: [GD-Consoles] Nobody on this list?

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

The Big Money Monster is crawling around here. I think most concerned people
is under NDA (Axe threatened, controled by a Voodoo doll, whatsoever...),
it's pretty rare to chat smartly around here.
Brrrr cold place...

---Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
Johann Fuchs
Envoyé : mardi 2 juillet 2002 15:47
À : gam...@li...
Objet : [GD-Consoles] Nobody on this list?


i subscribed 1 and a half month ago and got no email by now?
is nobody subscribed or are there no questions abaout console development?

wbr
 Yoshi