IGDA Japan Report

passerby

Regular
Actually there is only very little info, but non of the other threads seem suitable, and the 'PS3, Xenon, Rev' thread seem to be very occupied currently, so here's a new thread.

By Famitsu.com.
http://www.famitsu.com/game/news/2005/03/26/103,1111843612,37711,0,0.html

The first slide is most interesting, because it mentions the possibility(not confirmed!) of a Xenon add-on, and even names it - 'Avator'.

With regards to Rev, they are wondering if it may be released within the year.

PS3 is interesting too, as they wondered if becuase of capabilities, starting development is TaiHen - which means 'big trouble', although 'big s***' is closer in meaning. Emphasis on the importance of tools and middleware. Start preparing the technology for it as soon as possible, as scale of development may become hugh.

'Economics of Next-Gen Game' slide says that profits from the 1st game may be limited, and sequels are important to leverage on reduced dev costs and marketing costs.

The Cell talk is delivered by a Sega representative. The 'Power PC (Fu An)' slide describes 2 points of discomfort. PPC means a shift from little endian(MIPS, IA32) to big endian. Endian-dependent game engines are going to need some rework. He also wonders a bit about the 64bit nature of the PPE.

The rest of the article talks about stuff we already know.
 
passerby said:
...
The first slide is most interesting, because it mentions the possibility(not confirmed!) of a Xenon add-on, and even names it - 'Avator'.
...

Sounds like the camera add-on for capturing gamers faces so that you know who's ugly mutha faces you've just fragged! :p
 
I've heard it so often that I need a freaking explanation before I pull my hair out. Wtf does little and big endian mean?
 
GwymWeepa said:
I've heard it so often that I need a freaking explanation before I pull my hair out. Wtf does little and big endian mean?

I believe it's the order of the bits. Like in 010001110, is the largest digit the first or the last one? And it refers to the story Gulliver's Travels, which was a satire, in which two political groups argue over which way to eat an egg, small end or big end first, which is something that doesn't really matter.

'Economics of Next-Gen Game' slide says that profits from the 1st game may be limited, and sequels are important to leverage on reduced dev costs and marketing costs.

The Cell talk is delivered by a Sega representative. The 'Power PC (Fu An)' slide describes 2 points of discomfort. PPC means a shift from little endian(MIPS, IA32) to big endian. Endian-dependent game engines are going to need some rework. He also wonders a bit about the 64bit nature of the PPE.

1. I think the economics of a next-gen game will fail, people won't buy the generic sequels. I think a more likely to succeed idea is to either make original games which are very short, or raise the price of games.

2. I thought the PowerPC architecture could operate in either big or little endian mode?

3. Since microcode isn't compatible across different architectures anyhow, what does it matter whether it is big or little endian?
 
I don't see what this fuss is about the extra details required for games. All that will happen, is that instead of starting from scratch each game, developers will pull from a vast library of countless ultra-high polygon models and such. There will be vast, extremely high quality databases of such things that people will get access to, so the amount of time spent on creating all this detail will be minimal. More time will be spent on composing the scene (aka level editing), and less on art creation. With the next generation of games, developers will be forced to be efficent and effective about their work. As a result costs will imho actually go down compared to today. Of course, the greedy bastards like the Evil Alliance will still charge more anyways, I hate them they have no integrity or honor.
 
Pure big-endian: Sun SPARC, Motorola 68000, PowerPC 970, IBM System/360

Bi-endian, running in big-endian mode by default: MIPS running IRIX, PA-RISC, most POWER and PowerPC systems

Bi-Endian, running in little-endian mode by default: MIPS running Ultrix, most DEC Alpha, IA-64 running Linux

Pure little-endian: Intel x86, AMD64, DEC VAX

http://en.wikipedia.org/wiki/Endian
 
Kind of a worthless article if you ask me.

When the hell is someone around here going to spill the beans.

When the hell is Sony going to. Clock is ticking to March 31. ;)
 
CELL's PowerPC Processor Element operates in Big Endian mode only: they specifically dropped little endian compatibility in the design (the MPR article about CELL mentions this too).
 
Panajev2001a said:
CELL's PowerPC Processor Element operates in Big Endian mode only: they specifically dropped little endian compatibility in the design (the MPR article about CELL mentions this too).

But why would this make it more difficult to port games? I mean, aren't games generally written in a higher level language like C++? Shouldn't it be the compiler's job to worry about the endianness?
 
Fox5 said:
But why would this make it more difficult to port games? I mean, aren't games generally written in a higher level language like C++? Shouldn't it be the compiler's job to worry about the endianness?

High level languages mostly hide you from which way your numbers are stored but there are still problems in some places.

The classic example is imagine a data file (say a 3D model) created on a PC and stored in binary for quick loading. On a Big endian system all the numbers (like vertex count etc.) are screwed unless you convert them first.

To be fair though its not that hard, we ported to PowerPC from an Intel build in about 2 days. Had to modify the odd tool and fix up a few relatively dodgy in game function and that was it.
 
Fox5 said:
Panajev2001a said:
CELL's PowerPC Processor Element operates in Big Endian mode only: they specifically dropped little endian compatibility in the design (the MPR article about CELL mentions this too).

But why would this make it more difficult to port games? I mean, aren't games generally written in a higher level language like C++? Shouldn't it be the compiler's job to worry about the endianness?

No: think of a 32 bits variable. We take an 8 bits pointer (you want to edit the fields one by one) pointing to this 32 bits variable.

I want to store the string "ABCD".

uint32 var;

uint8 * ptr = (uiint8 *) &var;

ptr[0] = "A";

ptr[1] = "B";

ptr[2] = "C";

ptr[3] = "D";

In a Big-Endian system I just stored the string as "ABCD" (Most Significant Byte first), while in a Little-Endiand system I just stored the string as "DCBA"(Least Significant Byte first).

http://www.codeproject.com/cpp/endianness.asp

The Xbox 2/Xenon PowerPC CPU should be Big-Endian only as well.
 
Oh I see, but it doesn't seem like that would be too big of a problem to overcome, I guess as the code is more complex it would become more difficult, but certainly not difficult enough to not do a port because of it.
 
Fox5 said:
Oh I see, but it doesn't seem like that would be too big of a problem to overcome, I guess as the code is more complex it would become more difficult, but certainly not difficult enough to not do a port because of it.

It's generally only a tools/data issue.

You end up authoring on X86 (little endian) and you have to byteswap before you can use it on a big endian system. You can either do this when you write the data to the file (the right way) or you can fix the file up when you load it in.

If you've never dealt with it before which a lot of PC devs haven't it can be a real pain in the ass, if you've written a GC game recently, then it's not even news.
 
Back
Top