Hardware pushed to the limits according to Sega-16 members

[Sik]

That looks a lot like how Crash Bandicoot handles levels: it has a list indicating which polygons are visible in each possible position of the camera... don't ask me how they made it fit in memory other than it's compressed to hell it seems. Crash'n'burn seems to just keep track of when to load graphics in a more coarse way... actually watching it again I can't notice any obvious pop-up, I wonder if that's what this was trying to take care of.

[Black_Tiger]

When the N64 launched, magazines said that it has hardware support to only draw visible polygons and how something like Mario 64 would require much more polygons to do on PSX/Saturn.

Was this ever proven to be true?

[Sik]

They were probably referring to the depth buffer (which neither the PS1 nor Saturn have), no idea where the whole "would need more polygons" thing comes from though.

[Soulis]

When the N64 launched, magazines said that it has hardware support to only draw visible polygons and how something like Mario 64 would require much more polygons to do on PSX/Saturn.

Was this ever proven to be true?

This reminds me of a very old post around here.

There was a picture comparing the geometry in N64 and PS1 versions of Mission Impossible.

The image showed a flat wall in wireframe mode. The PS1 version wireframe was much more complex than the N64 one, despite both rendering the same flat wall without features (IIRC). The N64 wireframe was as simple as a flat surface should be.

Correct me if i'm wrong but maybe the N64 can render large surfaces using less polygons, thanks to perspective correction, while the PS1/Saturn has to waste more polygons for a similar effect? Maybe because of the way geometry warps on the PS1/Saturn they need to break large surfaces into smaller ones so the warping doesn't effect the whole surface but only parts of it?

[Barone]

I think you have a reasonable argument there, Soulis.

Compared to the N64, both the PS1 and Saturn lack sub-pixel precision so it leads to a couple of problems. Seaming issues are pronounced in many PS1 games and that's a problem you can only fix/mitigate applying tricks to the way you handle the camera positioning and/or wasting polygons to try to cover it up AFAIK.

It's not a coincidence that most of the PS1 games which look more solid in terms of geometry have some sort of limitation or trick applied to their camera/view angle.

Cross-platform games tend to expose the limitations of the hardware, unless you go with something especially reworked for the system like PS1's Quake II.

[Tower of Power]

This reminds me of a very old post around here.

There was a picture comparing the geometry in N64 and PS1 versions of Mission Impossible.

The image showed a flat wall in wireframe mode. The PS1 version wireframe was much more complex than the N64 one, despite both rendering the same flat wall without features (IIRC). The N64 wireframe was as simple as a flat surface should be.

Correct me if i'm wrong but maybe the N64 can render large surfaces using less polygons, thanks to perspective correction, while the PS1/Saturn has to waste more polygons for a similar effect? Maybe because of the way geometry warps on the PS1/Saturn they need to break large surfaces into smaller ones so the warping doesn't effect the whole surface but only parts of it?

Ya, that's pretty much what I've heard too, that the N64 was able to use much larger polygons because if you did the same thing on PSOne/Saturn, you'd have mucho texture warping.

[tomaitheous]

Maybe they're referring to z-buffering? IIRC, it acts as a sort of z-culling - but the polygons still get parsed, just no wasted pixels if it appears behind something. And, from what I've read, z-buffering (along with anti-aliasing) take a performance hit on the N64; its polygon pixel bandwidth is cut down - thus polygon throughput is cut down.

I do know that PS1 games tended to use smaller polygons to help reduce the texture warping artifacts, but it was able to push more polygons than the n64 when the n64 was using z-buffering and anti-aliasing. So the fact that it's using more, probably doesn't really mean much. Though ideally, someone with direct experience with these console should chime in.

[Folco]

Cross-platform games tend to expose the limitations of the hardware, unless you go with something especially reworked for the system like PS1's Quake II.

About Quake 2 for PS1:

Octant sort-lists.

Every object was stored as 8 seperate painter-order draw lists, with the correct list to draw for correct appearance being applied according to camera orientation.

The editor we built for it did an initial pass to try and figure it out programatticaly, but it still required a team of around a dozen "mappers" who's job was to laboriously hand tweak everything so it looked ok.

Do that for the scene objects and every key-frame of every enemy, and you have a very fast brute-force rendering method.

Obviously the sheer size of ID's original maps (which we stupidly tried to replicate) were far too large to fit into memory, and so after conversion and simplification had to be broken down in PSX-sized chunks. Each chunk was further sectored using a portal-based occlusion system to further reduce the draw overhead in real-time.

Other than that, just the usual PSX bits of business; surface subdivision where possible to get around the lack of perspective correction on textures, UV decals and lighting, the works. We already had a pretty solid tech-base from Shadowmaster the year before, but a huge amount of effort was poured into a bespoke unified editor program unimaginatively titled GLMFC (for OpenGL in a MFC wrapper) which basically did everything from world geometry construction from prefab chunks, lighting and texturing, level population, pathing and event triggering.

Bane of my existence for about 3 years lol.

http://www.neogaf.com/forum/showthre...#post205104123

Remember there's no z-buffer on PSX, so in order to make an object look solid you need to apply the painter's algorithm to each face and draw it back-to-front relative to the camera. Rather than compute this every time for each face, we basically pre-generated 8 lists per object -be that a chunk of world geometry or an entity within it- then simply selected which one of the lists to use.

As a system it really had no major drawbacks other than the inherent limitation of the painter's algorithm which struggles with complex shapes. 8 angles pretty much covers all cases but its very manpower intensive to prepare it as what it entails is someone sitting there and manually selecting faces and pushing/pulling them around in the order until you have something that looks right as much of the time as possible.

Where stuff was problematic we either removed or rebuilt to work around the problem.

It was a pure code/data solution that required no hardware assistance, very old school in its reliance on pre-calcing as much as possible to reduce cpu overhead.

To clarify a bit on why 8 lists, its really simple if you imagine you are rendering a cube. A cube is made up of 6 faces, each made up of 2 triangles. Now if you look diagonally down on the cube's corner from above and build your face-draw order list, you are 1/8 of the way there.

Do all 4 corners looking diagonally down, you are half way. Then repeating the process looking up from below covers all bases because looking directly parallel can always be covered by the corresponding diagonal orders.

http://www.neogaf.com/forum/showpost...&postcount=231

Maybe they're referring to z-buffering? IIRC, it acts as a sort of z-culling - but the polygons still get parsed, just no wasted pixels if it appears behind something. And, from what I've read, z-buffering (along with anti-aliasing) take a performance hit on the N64; its polygon pixel bandwidth is cut down - thus polygon throughput is cut down.

I do know that PS1 games tended to use smaller polygons to help reduce the texture warping artifacts, but it was able to push more polygons than the n64 when the n64 was using z-buffering and anti-aliasing. So the fact that it's using more, probably doesn't really mean much. Though ideally, someone with direct experience with these console should chime in.

The algorithm for z-buffering in the SGI microcode was inefficient for use in gaming that's why some of the better looking N64 games had the developers rewriting the microcode (most notably World Driver Championship).

[Barone]

There is also one on IGN btw where Yu Suzuki says much the same thing
http://uk.ign.com/articles/2000/05/3...iews-yu-suzuki

Awesome, thanks a lot!

About Quake 2 for PS1:
http://www.neogaf.com/forum/showthre...#post205104123
http://www.neogaf.com/forum/showpost...&postcount=231

That was insanely cool and informative! Thank you very much for sharing it.

Quake II is without a doubt one of the few PS1 games which look really solid in terms of geometry and texturing, good to know how they achieved it and how much effort was put into it.
HammerHead was awesome, too bad it was so short-lived.

[Blades]

^Yup. Great info. The PSX was surprisingly versatile.

[Team Andromeda]

Awesome, thanks a lot!




That was insanely cool and informative! Thank you very much for sharing it.

Quake II is without a doubt one of the few PS1 games which look really solid in terms of geometry and texturing, good to know how they achieved it and how much effort was put into it.
HammerHead was awesome, too bad it was so short-lived.

No worries, Yeah Quake II was amazing onthe PS . I also think Vagrant Story, Alien Resurrection pushed the PS to its limits . Also O.TO.GI II was pushing the XBox to its limits too

[EPSYLON EAGLE]

R-TYPE for Master System comes close to bringing the 8 bit SEGA machine to limit.

https://www.youtube.com/watch?v=Y7BgS78b4t0

[tomaitheous]

R-TYPE for Master System comes close to bringing the 8 bit SEGA machine to limit.

https://www.youtube.com/watch?v=Y7BgS78b4t0

One of my pet peeves, is that a lot of master system youtube videos are played on emulation with sprite scanline limited turned off. That video is a prime example. If you play on the real system, it flickers (the first bosses tail is less impressive when it flickers a lot, second boss a lot, etc). It's gives the wrong impression of the master system's sprite capabilities (which was actually the same as the NES; 8 per line scanline). And the game does slowdown.

I think it's difficult to find games that actually push the system to its limits (to answer segarule's question). Rtype isn't doing anything special to push the system. It's easily within the realm of the system's capabilities and graphics. Rtype is the type of game I expect from the master system's specs.

Where the master system is weak, is certain types of special effects (small tilemap, no Y re-positioning mid screen via interrupts).. and large amounts of animation (no DMA to upload fast amounts of data, not much vram to double buffer things). The master system is not weak in color and detail via color.



Toki on the Amiga is pretty impressive. More impressive than any of those "copper" effect games. Here's a game on the Amiga, with dual scrolling layers, that has none of the typical tell tale signs of Amiga limitations. No 7 colors shared between enemies and background look, no copper to cover it up with "splash" color distractions, etc. It really looks something straight off the Genesis. The game has music and sound fx too.

[gamevet]

I think that Blood Money pushes the Amiga pretty hard, with not a hint of slowdown, plenty of colors on screen and music with sound effects.

https://www.youtube.com/watch?v=qxciUa4YmeY

Toki on the Amiga is pretty impressive. More impressive than any of those "copper" effect games. Here's a game on the Amiga, with dual scrolling layers, that has none of the typical tell tale signs of Amiga limitations. No 7 colors shared between enemies and background look, no copper to cover it up with "splash" color distractions, etc. It really looks something straight off the Genesis. The game has music and sound fx too.

I really think that you are doing the Amiga a disservice by saying it doesn't have a lot of games that would look like they were something straight off of the Genesis. Gods may run a bit smoother on the Genesis and have 3 sound channels for music, but it sacrificed sound quality to achieve those 3 sound channels. Shadow of the Beast II has very abrupt color bars for the Genesis game, while the Amiga game has a more gradient appearance.

Gods on the Genesis
https://www.youtube.com/watch?v=J-RPTtdoTK0

Gods on the Amiga
https://www.youtube.com/watch?v=DaKY87e6j04


Shadow of the Beast II on the Amiga
https://www.youtube.com/watch?v=PrmHYib5_bQ

Shadow of the Beast II on the Genesis
https://www.youtube.com/watch?v=_bxqyS94N_s


I've heard Genesis fans on this site state that the port of the original Shadow of the Beast was a bad port of the game, but the game was also brought over to the PC-Engine CD and SNES, with changes to the graphics and sound to fit those systems. The Amiga is a pretty clear winner, compared to the other versions, and I feel that it is the definitive showcase of the abilities of the Amiga, when compared to other games on the hardware.

https://www.youtube.com/watch?v=QUT91K4mPlw

[Thief]

Ya, that's pretty much what I've heard too, that the N64 was able to use much larger polygons because if you did the same thing on PSOne/Saturn, you'd have mucho texture warping.

Yes, the more ploygons a PS1/Saturn wall is made of, the less texture warping. The N64 had that perspective correction thingy so it could do a wall out of one rectangle and no warping textures. ie.



If you check that Wipeout wireframe video, the closer the track gets to your vehicle, each rectangle gets sub divided further into more so the road doesn't warp as much. If you want to see a really bad warping road, look at Sega Touring Car for Saturn (especially in replay mode).