New Killzone screen grabs

[PC-Engine]

One game might sustain a lower rate but include an instance where every condition is so simplified that it can peak extremely high, while another game is actually sustaining a better rate but doesn't have any such ideal condition to peak nearly as high

Bingo.

 

[Lazy8s]

Within the realm of feasibility, and more so than other platforms get, individual game performance is represented by this sampling. True, you could test each game through a full playthrough for an even finer measurement, but that would require dozens of hours of continual sampling for a library of hundreds of titles... per game. And even then, it could be contested that a different playstyle on a particular game would've resulted in bringing about higher polygon rates (putting all the guards to sleep instead in MGS2 to up the detail when you look over the scene, etc.).

marconelly!:

At least when you know what game is being talked about, and what it's peak performance is, you have a clear point of reference. You have a name, and you have performance situation pinpointed - which is much more informative.

Again: unless you know what the conditions which spawned those peaks were (you can't assume the conditions between games were equally facilitating for a peak), comparing games this way is not meaningful. After all, the peak framerates for a first-person shooter are attained when you're facing a wall, and games with certain LOD schemes might peak very high geometry numbers from using simple or non textured polygons out in the distance.

if only that was actually what he was asking about, it would all be fine. However, he was clearly talking about peak numbers, and you tried to provide sustained numbers

Without establishing the kind of conditions that would cause the peak and the conditions that caused the peaks of the games he'd use as a reference to compare to, it would be meaningless to know the peak numbers. And why would anyone want to know meaningless information?

I was just supplying the most applicable guidelines established by the most relevant testing around and most relevant which could be expected to be done.

 

[wazoo]

I can't believe that the average game barely reached 1 million pps, isn't that what the dc could do without tile based rendering? Well, if that's the case, then it looks like Dreamcast would have been better with a 3dfx based card.(assuming it didn't cost more) I think the voodoo2 approached 2 million polygons per second, and voodoo3 did well over 3.

A few poly count we know about DC

SC : around 600k
SA : 500K
NFL2k : 1.2M
MSR : between 1.5 and 2M

and those are not "average" games.

Remenber that those "5M" Le mans game is from the same dev that claim to have a 18M pol/sec game on ps2. Whatever is their weird count method, it is a 4x time increase.

 

[Bohdy]

All that aside, saying that KZ doesn't 'even' look as good as MP, as if MP is not a benchmark looking game on a more powerful hardware, is more than a little ill-meaning, don't you think?

Well, I didn't quite mean it like that.. its just just that KZ is being much touted graphically and the MP engine is getting on a bit now... I was just wondering how they compare.

And Fox5: That's a lot of Turok!

 

[London Geezer]

A few poly count we know about DC

SC : around 600k
SA : 500K
NFL2k : 1.2M
MSR : between 1.5 and 2M

and those are not "average" games.

Remenber that those "5M" Le mans game is from the same dev that claim to have a 18M pol/sec game on ps2. Whatever is their weird count method, it is a 4x time increase.

Oh yes. If bloody Farcry averages at 4-5 million polygons, then i'm sorry to say, no DC game can do that. Granted, that's with some very efficient LOD system (as i said before, turning the LOD off, poly count goes from ~4M to ~25M...)
Or do we have to post pictures of Farcry and ANY GAME on DC?

 

[Guden Oden]

whats your point. I'm only comparing the fog in both games. Both games had very bad fog in them .

Umm dude, Turok has fog in it to hide draw-in. KZ has fog for atmospheric purposes, to set a particular mood. Two TOTALLY different things which you seem to ignore completely.

You KNEW that KZ's fog is just decoration, right? Yet still you choose to bash the game using its fog as the implement. Bad style IMO.

If i can't see 10 feet in front of me because of fog then the game does not impress me.

Neither T nor KZ has less than 10 feet visible distance on average. I'm hard-pressed to remember ANYWHERE in T where visible distance is below 10 feet (the fog barrier varied depending on the area). I don't think there is one, and I seriously doubt there is one in KZ either. Even if there is, you can be assured the fog is that thick purely for atmospheric purposes and not technical.

Under stand what I"m trying to say to you ?

I haven't the faintest clue! You compare two totally different games with different engines, then bring up a completely made-up scenario of less than 10 feet distance... That clearly doesn't work, if you want to make a point you first need to stick to reality man, not make sh!t up.

 

[Guden Oden]

I can't believe that the average game barely reached 1 million pps, isn't that what the dc could do without tile based rendering?

What are you talking about?

TBR has nothing to do with the PPS figures a particular software achieves, you're comparing apples and oranges. TBR just means the chip renders the screen in tiled sections.

I think the voodoo2 approached 2 million polygons per second, and voodoo3 did well over 3.

That's the theoretical polygon setup rate of the hardware, that has no bearing on the actual speed the software renders polygons. In comparison, I believe Simon Fenney stated the PVR-DC chip's poly setup rate is around 7MPPS. You can rest assured no PC game running on either Voodoo2 or 3 comes close to the theoretical performance figures...

 

[jvd]

TBR has nothing to do with the PPS figures a particular software achieves, you're comparing apples and oranges. TBR just means the chip renders the screen in tiled sections

and doesn't render anything not viewed in those tiles.

So if there is a monster standing in front of a wall the wall that is blocked by the monsters body is not drawn .

 

[notAFanB]

TBR has nothing to do with the PPS figures a particular software achieves, you're comparing apples and oranges. TBR just means the chip renders the screen in tiled sections

and doesn't render anything not viewed in those tiles.

So if there is a monster standing in front of a wall the wall that is blocked by the monsters body is not drawn .

no the HSR part is not inclusive of tiling.

 

[London Geezer]

TBR has nothing to do with the PPS figures a particular software achieves, you're comparing apples and oranges. TBR just means the chip renders the screen in tiled sections

and doesn't render anything not viewed in those tiles.

So if there is a monster standing in front of a wall the wall that is blocked by the monsters body is not drawn .

Don't need to be a TBR to be able to do that....

 

[Guden Oden]

TBR has nothing to do with the PPS figures a particular software achieves, you're comparing apples and oranges. TBR just means the chip renders the screen in tiled sections

and doesn't render anything not viewed in those tiles.

Not neccessarily. Intel has a tile-based immediate-mode renderer as a part of its extreme graphics 2 or whatsitscalled integrated junk.

 

[Crazyace]

Just to throw some more wood onto the fire - A lot of the figures shown in ps2 performance presentations tend to be measures of polygons being drawn. As the GS is seperate to the EE and VU's any kind of backface culling can reduce the numbers shown below that expected by the game engine.
On the PVR chipsets - the numbers given may be lower than expected from the pure HW stats, as triangles that span multiple tiles are effectively rasterised and setup multiple times. ( Of course big triangles on all architectures take more time - but I'd have expected the difference in trisetup specs between the PVR and 3Dfx designs to have been affected by this )

 

[jvd]

I am speaking of the hdr in the dreamcast and how it is set up to the best of my knowledge not hdrs or tilers in general

 

[marconelly!]

Again: unless you know what the conditions which spawned those peaks were (you can't assume the conditions between games were equally facilitating for a peak), comparing games this way is not meaningful. After all, the peak framerates for a first-person shooter are attained when you're facing a wall, and games with certain LOD schemes might peak very high geometry numbers from using simple or non textured polygons out in the distance.

It's not like those situations are difficult to see most of the time (when the largest numbers of cars is on the track at the same time, etc), but fair enough. However, I still maintain that using any individual number from that SCEE's 'study' is meaningless, considering the conditions for sampling they used. Unless we can have some numbers done much more accurately for an individual title (sampled for much longer, and at many locations/situations in the game), it's probably the best to not talk about any numbers at all.

Conversely, I assume you will stop using the 'good old' 5M polycount when it comes to discussions of this kind regarding Dreamcast

 

[Lazy8s]

Crazyace:

A lot of the figures shown in ps2 performance presentations tend to be measures of polygons being drawn.

As it should be.

 

[YPO]

The PS2 port of Le Mans pushes 2 million pps according to the press release. So which one is it? Don't tell me they were able to reduce the number by 3 million and having it look the same, minus image quality issue anyway.

The 5 million pps # was for their *engine*, and we all know what *engine* means. Just like GT3 *engine* is able to throw out 10 million pps. The actual game is pretty far from it.

 

[Lazy8s]

The Le Mans DC statistic was given as a peak frame complexity for the game and explained under those conditions... Fellow developer Argonaut actually had an in-production game engine for the system reaching near the 6M polygon limit benchmarked by SEGA's custom libraries.

The performance that the system could sustain for games was what SEGA disclosed when they revealed the system: around 3 million polygons per second.

 

[Fox5]

The Le Mans DC statistic was given as a peak frame complexity for the game and explained under those conditions... Fellow developer Argonaut actually had an in-production game engine for the system reaching near the 6M polygon limit benchmarked by SEGA's custom libraries.

The performance that the system could sustain for games was what SEGA disclosed when they revealed the system: around 3 million polygons per second.

Yet the games that reached those levels are a select few...maybe sonic adventure 2, shenmue 1 and 2, DOA2, and maybe a dozen more.

 

[cthellis42]

That seems to be bringing up the "engine vs. game" point YPO mentioned again, though. Do you know yourself, or know where it's mentioned what Le Mans definitely delivers?

 

[Fox5]

While there are a lot of sites on the Internet that say 5 million, during a quick search I found...
http://www.gamespot.com/dreamcast/driving/testdrivelemans/printable_2596147.html

Infogrames claims that the graphics engine is capable of pushing in excess of three million polygons at a time.

If the engine is only pushing 3 million, then the game's average is probably around 1.5-2 million.