Pssst... PSP... psst... Pixel Shading... psst

Read the part about Nintendo's magic wand above
Well I would sooner guess they probably had one of those daily horoscope writers 'predict' it, but it's along the same lines yeah.

Anyway, I guess in your world writting a game consists of plugging the hardware and loading up the graphics. The rest will run itself somehow within those realworld specs the hardware makers know so well.

Incidentially why are you dodging the fact that audio/visual presentations/demos are a far better indication of realworld performance for an average person then any numbers could ever be?
 
The point is that SONY knows the realworld performance figures for their own designs as Nintendo does yet SONY chooses to hype raw non ingame figures instead.

Nintendo knows its raw figures too, and it doesn't stood a chance with the real raw figures of Xbox. That's why they're made humble.
 
V3 said:
The point is that SONY knows the realworld performance figures for their own designs as Nintendo does yet SONY chooses to hype raw non ingame figures instead.

Nintendo knows its raw figures too, and it doesn't stood a chance with the real raw figures of Xbox. That's why they're made humble.

There's really no proof that was their reasoning. It was mere speculation from people on message boards. Not to mention that releasing raw numbers is meaningless to the average gamer ;)

Incidentially why are you dodging the fact that audio/visual presentations/demos are a far better indication of realworld performance for an average person then any numbers could ever be?

Nobody said audio/visual presentations aren't better than numbers, but the average person doesn't attend tech demo presentations or even aware they exist ;)

Heh why not just not release numbers or tech demos at all and tell the consumers to wait for the games to make their own conclusions as to typical performance :oops: :LOL:

Ex. "We have this very powerful game console to be released soon, but we don't know what it's capable of so you the consumer will have to decide when it's released onto the market in a few months" :p
 
You think they have no clue? You think they don't have some kind of benchmarking software that includes textures, lights, physics? Do you think they can't release specs that gave a range like 6-12 Mpolys/sec?

with a range like that sure.

Are you telling me that Nintendo has a magic wand that SONY doesn't that allows them to gauge realworld performance???

yes it's called being conservative. your point about hyping number stands but lets face it along as the SPECS aren't flat out lies then it's great for techies. the average joe will not give a crap whether u gove them conservative numbers or not.


WTF is 66 Mpolys/sec??? I thought this was a GAME console. Are there any GAMES on PS2 (let alone most) that pushes 66 Mpolys/sec??? Didn't think so.

exactly what it says on the tin.



The point is that SONY knows the realworld performance figures for their own designs as Nintendo does yet SONY chooses to hype raw non ingame figures instead.

nope Sony knows the Probable performence of their System in the real world. that they choiose to hype RAW figues is their perogative and is not outright misleading.
 
There's really no proof that was their reasoning. It was mere speculation from people on message boards.

Some marketing pointers, if you can't compete head on, put a spin on it. This is a standard marketing practice. You would be stupid to do otherwise.
 
V3 said:
There's really no proof that was their reasoning. It was mere speculation from people on message boards.

Some marketing pointers, if you can't compete head on, put a spin on it. This is a standard marketing practice. You would be stupid to do otherwise.

Thing is I don't recall Nintendo ever hyping peak numbers for their other consoles either.
 
Thing is I don't recall Nintendo ever hyping peak numbers for their other consoles either.

That's only because for its time, when spec become trendy, Nintendo hardware, never had raw specs worth mentioning.

Just wait, when they do have one, marketing will no doubt use it, and watched Sony or MS goes around it.

Next gen, will be spec war.
 
PC-Engine:

Why act as if Sony only published the raw perspective transformation number (66 million polygons/sec) of the Emotion Engine?

Here's the spec sheet Sony released in March 1999:
PR: Emotion Engine Spec-Sheet
PR: Graphics Synthesizer

Not only did they give raw spec numbers, they also gave good indications of what the hardware is cabable of during certain circumstances:

for example, out of the Graphics Synthesizer PR:

"With Z-buffering, textures, lighting and alpha blending (transparency), a sustained rate of 20 Million polygons per second can be drawn continuously."

Ironically, most media and gaming sites chose to go after the big number.
 
heh, it turns out even 20 MPPS was an exaggeration. too bad there is no "3dmark" style program you can run on different consoles, to accurately compare them. as it is, we'll just have to take Micro$ofts word for it that XBox does 300mpps ;)
 
Josiah said:
heh, it turns out even 20 MPPS was an exaggeration. too bad there is no "3dmark" style program you can run on different consoles, to accurately compare them. as it is, we'll just have to take Micro$ofts word for it that XBox does 300mpps ;)

actually there are games that are pretty much up with that number. I'm sure if you use the search function, you'll find a thread about GPC (Grand Prix Challenge) which does 18 MPPS. Though, isn't it a bit pointless to compare polygons when a game is made up of so much more than just polygons? :?
 
Josiah said:
heh, it turns out even 20 MPPS was an exaggeration. too bad there is no "3dmark" style program you can run on different consoles, to accurately compare them. as it is, we'll just have to take Micro$ofts word for it that XBox does 300mpps ;)

no game pushes 20MMPS. however I beleive there demos that Push the above in the appropriate circumstances

With Z-buffering, textures, lighting and alpha blending (transparency), a sustained rate of 20 Million polygons per second can be drawn continuously

notice how the number of lights is not mentioned here.
 
Josiah said:
heh, it turns out even 20 MPPS was an exaggeration. too bad there is no "3dmark" style program you can run on different consoles, to accurately compare them. as it is, we'll just have to take Micro$ofts word for it that XBox does 300mpps ;)

20MPPS was not an exaggeration, first gen titles like DropShip and the J&D engine peaked arround 18-20 MPPS. Those numbers were proven by the PA.

"3dmark style program" is not necessary , the GS outputs loads of signals to listen to, such as polygons drawn, etc. The GS was designed this way from the start, since the new SDK every dev could analyse that data too ...
 
20MPPS was not an exaggeration, first gen titles like DropShip and the J&D engine peaked arround 18-20 MPPS. Those numbers were proven by the PA.
This may sound a bit strange but I would take PA poly numbers with certain... reservations. They're probably the least usefull part of data about game performance that PA gives you (IMO at least).
Anyway on that note I think it was R&C that reportedly got 10-20M on PA.

notice how the number of lights is not mentioned here.
Using 4 lights on single VU you get pretty close to that number. Notably Sony was referring to dual VU use in those docs, which is the part that could be considered a bit deceiving - or at least, unlikely to happen since it's unlikely you'll be running VU0 100% of its time to do graphics.
But practical tests have shown you can get quite high utilization of running the two together for rendering and those numbers aren't far off at all in the right scenarios.
 
Fafalada said:
This may sound a bit strange but I would take PA poly numbers with certain... reservations. They're probably the least usefull part of data about game performance that PA gives you (IMO at least).
Anyway on that note I think it was R&C that reportedly got 10-20M on PA.

Hehe sure, the PA actually underestimates the polys drawn, because it doesn't take into consideration, what was rejected by the GS or VU micro-code for drawing, so are stuff like offscreen things or stuff less of the size of a pixel (narrow or small polys).

Do you got your T15K finally? How is it working out for you?
 
Hehe sure, the PA actually underestimates the polys drawn, because it doesn't take into consideration, what was rejected by the GS or VU micro-code for drawing, so are stuff like offscreen things or stuff less of the size of a pixel (narrow or small polys).
Yep, and in effect you can quickly inflate your polycount by culling less too :p which is the most bizarre sideeffect I think. And I'm still undecided on whether counting FB operation primitives into polycount is ok or not ;) (I used to think of those only in fillrate cost terms even though they can amount to quite a number of vertices when you go effect happy).

Do you got your T15K finally? How is it working out for you?
Not yet, only had a session or two at Sony - project being almost over there wouldn't have been much use anyhow.
Though I might work with it on International version a bit if we get one soon :)
 
Fafalada said:
Yep, and in effect you can quickly inflate your polycount by culling less too :p which is the most bizarre sideeffect I think. And I'm still undecided on whether counting FB operation primitives into polycount is ok or not ;) (I used to think of those only in fillrate cost terms even though they can amount to quite a number of vertices when you go effect happy).

By "inflate" I take it you mean they’re non-visible polygons?
There has been some talk that the GS would actually work faster if you didn’t backface cull. Is this right or is it a misunderstanding or distorted truth? Sony themselves seem to dismiss this, for example here in this presentation, on page twentynine.

What are those "FB operation primitives" you talk about?
 
Squeak said:
There has been some talk that the GS would actually work faster if you didn’t backface cull. Is this right or is it a misunderstanding or distorted truth? Sony themselves seem to dismiss this, for example here in this presentation, on page twentynine.
The GS doesn't do any back face culling, it renders exactly the same whether the triangle is forward or backwards. Now that means it burns fill-rate on triangles you can't see (after all back face culling is a method of rejecting triangles you can't see). To remove back faces you have cull then in the VU code, the fuzzy area is that the GS is so damn fast that for many situations it can render the invisible triangle faster than the VU can cull it.
The heavier the processing on the VU or complex the texture state, the more likely backface culling in the VU is a win. But in the simplist cases of non-lit small textured triangles, its best to let the GS just render the thing.
 
Back
Top