PSone...what was the avg polygon count for the avg game?

I read on the box on my old Playstation and it say that the Playstation is able to do 360,000 polygons a sec.

This must be Maximum possible polygon count. What was the avg polygon count in games like Metal Gear Solid, Gran Turismo, or even Tomb Raider?
 
kenneth9265_3 said:
I read on the box on my old Playstation and it say that the Playstation is able to do 360,000 polygons a sec.

This must be Maximum possible polygon count. What was the avg polygon count in games like Metal Gear Solid, Gran Turismo, or even Tomb Raider?

My guess is 48. It's always 48. Or the value of Pi.
 
Yeah its a how long is a peice of string kind of thing. The average football game won't need masses of poly's because it's drawing a flat pitch, and at the time most crowds were flat polys with a few sprites here and there. If you look at games like tomb raider etc they all make great use of HUGE poly's. I guess the most impressive stuff is outdoor or large charchters, but those situations are rare and controlable (on rails ish).

I think the average scene you'd be looking at ~20k polys textured.
 
sytaylor said:
Yeah its a how long is a peice of string kind of thing. The average football game won't need masses of poly's because it's drawing a flat pitch, and at the time most crowds were flat polys with a few sprites here and there. If you look at games like tomb raider etc they all make great use of HUGE poly's. I guess the most impressive stuff is outdoor or large charchters, but those situations are rare and controlable (on rails ish).

I think the average scene you'd be looking at ~20k polys textured.

20,000 poly per sec? Wow! :oops: to me thats kind of low for a orginal Playstation game, but you would probally know more than me...
 
london-boy said:
Why does it matter? It never mattered then, it doens't really matter now...
What are you talking about?! Polygoncounts doesn't matter?!
I think you need to explain yourself.
 
Squeak said:
london-boy said:
Why does it matter? It never mattered then, it doens't really matter now...
What are you talking about?! Polygoncounts doesn't matter?!
I think you need to explain yourself.

Explanation: Who cares about how many polygons PS1 was pushing!?

Better explanation: If Kenneth himself is saying that he doesn't really know much about all this, why does it matter to him how many polys a PS1 game is pushing? Is it gonna change anything?

Sorry i'm in a very clinical mood today.
 
london-boy said:
Squeak said:
london-boy said:
Why does it matter? It never mattered then, it doens't really matter now...
What are you talking about?! Polygoncounts doesn't matter?!
I think you need to explain yourself.

Explanation: Who cares about how many polygons PS1 was pushing!?
I do, Kenneth do. Don't you think its interesting to find out the real capabilities of a given piece of hardware, outside of paper specs? If not, then why?
Better explanation: If Kenneth himself is saying that he doesn't really know much about all this, why does it matter to him how many polys a PS1 game is pushing? Is it gonna change anything?
There are many interesting questions you could answer with that.
Sorry i'm in a very clinical mood today.
Yes I can see that :p
london-boy said:
My guess is 48. It's always 48. Or the value of Pi.
 
kenneth9265_3 said:
20,000 poly per sec? Wow! :oops: to me thats kind of low for a orginal Playstation game, but you would probally know more than me...

Nah, not per sec; per scene; or in other words, what is currently displayed on the screen. This number would be multiplied by the game's framerate to get the polygons-per-second figure. Thus, a very well-optimised PS1 game running at 60fps would get 120,000 polys/sec.

It might be noted that the first Crash Bandicoot game had some seriously high poly numbers in the "tunnel-like" levels where the player runs "into" the screen because it streamed precalculated data straight off the CDROM and passed it straight to the graphics hardware. No numbers were mentioned by the devs except that often distant polys were as small as one pixel in size - which means the game can fit in a lot of them at any one instance.

Of course this meant that the gameplay was very limited too - as I recall the screen didn't scroll from side to side at all in those tunnel levels. It was a pure "on-rails" experience.
 
Guden Oden said:
Of course this meant that the gameplay was very limited too - as I recall the screen didn't scroll from side to side at all in those tunnel levels. It was a pure "on-rails" experience.
Ha ha, if that's true, they might as well just have done a video stream instead, and saved the optimisations.
 
Streaming video takes up much more data, and the quality is a lot different from the PS's realtime-rendered GFX, so the characters and items would have looked extremely out-of-place when stuck on top of the video background. Framerate synching might have been an issue as well I can imagine.
 
Guden Oden said:
kenneth9265_3 said:
20,000 poly per sec? Wow! :oops: to me thats kind of low for a orginal Playstation game, but you would probally know more than me...

Nah, not per sec; per scene; or in other words, what is currently displayed on the screen. This number would be multiplied by the game's framerate to get the polygons-per-second figure. Thus, a very well-optimised PS1 game running at 60fps would get 120,000 polys/sec.

It might be noted that the first Crash Bandicoot game had some seriously high poly numbers in the "tunnel-like" levels where the player runs "into" the screen because it streamed precalculated data straight off the CDROM and passed it straight to the graphics hardware. No numbers were mentioned by the devs except that often distant polys were as small as one pixel in size - which means the game can fit in a lot of them at any one instance.

Of course this meant that the gameplay was very limited too - as I recall the screen didn't scroll from side to side at all in those tunnel levels. It was a pure "on-rails" experience.

20,000 polys per scene/frame x 60 FPS = 1,200,000 polys per second, not 120,000 polys per second.

BTW, someone at GA told me recently that a PSX emulator he use to use had a polygons per frame counter that hovered between 1000 to 2000 triangles in Tekken 3!
 
Shogmaster said:
BTW, someone at GA told me recently that a PSX emulator he use to use had a polygons per frame counter that hovered between 1000 to 2000 triangles in Tekken 3!

That sounds about right. IIRC a couple of thousand was about the limit a PS1 could cope with in a single frame - any more than that and you're down to 30fps. I might be getting my numbers wrong but I think for textured the theoretical frame limit was 3k.

20k in a scene would be huge for a PS1 (and v. slow).
 
You can get exact counts with some of the emulators around if you know the original framerate at least.

IIRC most games floated arounnd somewhere between 20K/sec and 60K/sec, with the latter being the exception rather than the rule.
 
I know that the raptor (or wsa it t rex ) tech demo was running at 200k a second .

As for games I thought one of the racing games was doing 32k a scene .
 
PS-X / PlayStation / PSone

Geometry Transform Engine: (calculated/transformed polygons/sec)
*1.5 million verts/sec
*500,000 polygons/sec

GPU: (rendered, displayed on-screen)
*360,000 flat shaded polygons/sec displayed
*180,000 textured, gouraud shaded, lit polygons/sec displayed


I don't think any PS1 game pushed more than the theoretical max of 180,000 texture mapped, gouraud shaded, lit polygons/sec

sure you could do more than 180,000 polygons without texture mapping, or without gouraud shading and lighting.


I think the first PS1 Ridge Racer (1994) used about 90,000 textured polygons/sec
 
I think the first PS1 Ridge Racer (1994) used about 90,000 textured polygons/sec

Nope, run it through an emulator with a polygon count.
Even R4 which was technically far superior pushes a LOT less than that.

To be fair the counts that emulators will show do not include back faced polygons since most PS1 games would have rejected them before rendering.
 
Back
Top