Comparison of 5th generation ("32/64-bit") game console hardware

[sheath]

Yes it is. But that's not what he says, if it was, discussions with him wouldn't go on for 50 pages.

"Discussions" are going on for pages because people are trying to make other people admit they are wrong and lament over their own foolishness. This will not happen.

[Kamahl]

"Discussions" are going on for pages because people are trying to make other people admit they are wrong and lament over their own foolishness. This will not happen.

You misunderstood my post. Had he clarified his position as what you said (and we tried to ask if that's what he meant multiple times on every single subject he "discussed") it would have stopped right there and then. This is not the forum discussing, it's the forum arguing with TA because he's an idiot.

[Barone]

Interesting, I wonder how that improves performance then.

There's no performance improvement IIRC (in Hexen's specific case). It just looks less blurred and fucked up with the filtering off.

[kool kitty89]

I think that's what the Turbo 3D mode/microcode does but don't quote me on that.

I'm pretty sure even the original "fast 3D" code offered that. The API should have the ability to turn on/off any effects that aren't hard-coded by the GPU . . . it's just more limited by the things that are actually handled in software by the RSP (more or less). The big thing about "turbo 3D" was use of lower precision geometry computation. (the texture cache management was also a big issue -which is handled in software by the RSP- but I'm not sure if they changed that for Turbo 3D -a huge issue was being limited to 1 texture per polygon without the ability to tile . . . the higher poly budget of turbo 3D helped work around that in any case though -tiling polygons themselves)

The thing is, many of the features don't gain you much or any speed boost when disabled, and this may very well be a hardware feature. (or at least with the way the API/RSP coding is typically set up) There's several contemporary PC GPUs that did nearly all their effects at full speed, like comparing the Voodoo to the Rage or ViRGE series cards. (Rage and ViRGE had considerable gains when reducing filtering, z-fogging, and some other effects -Rage even had gains for reducing perspective correction detail -I think Nvidia's Riva 128 may be closer to the Voodoo in these respects, but I'm not positive: I do know that the Riva and Voodoo both were limited to 16-bit color depth for 3D while the ViRGE and RAGE all did 32-bit color -in the ViRGE's case it actually avoided some errors/bugs seen in 16-bit mode, like the rectangle mattes around alpha textures)

Most games that offer unfiltered textures as an option or cheat code (or gameshark hack) do it for aesthetic reasons alone, either for the odd case where the game might actually have some specific art that looks wrong filtered (bigger deal for some 2D stuff too) or as a joke or testing mode. (I think one of the Tony Hawk games had a "playstation" graphics cheat code as a joke)

To be fair, he probably meant "3DO can't do Mode 7 exactly like Mode 7 at the same framerate and exact color and appearance." So in the same way the PS1 can't do VDP2 floors and not suffer color loss, add gouraud shading and full screen dithering/filtering and probably suffer framerate loss. We all like to say that the Sega CD could handle Super Scaler games and Sega was weird/stupid/wetalldid for not making all_of_them for the platform. But the reality is the Sega CD couldn't do even System-16 colors and framerate in scaler games. I'm pretty sure that is where TA has been coming from the whole time.

Wrong on the Mode 7 comment. 3DO (and PSX) both render at 15/16-bit color depth, and the SNES uses paletted 15-bit RGB color. So a "mode 7" style rotated/scaled 2D object (software raster effects applied for perspective -as with SNES) using a 256 color paletted texture should be identical in appearance as the SNES. (aside from the higher screen resolution)

Handling it at similar framerates as the SNES should also be very doable . . . definitely if you're talking about the same limited usage as the SNES allows (no other BGs on the same scanlines as "mode 7" only sprites on those lines). The Jaguar would have a harder time with it, but that's another story. (texture mapping limitations of the blitter)

But that's not what he says now is it? And when people say "is this what you mean (insert that quote)?" he just parrots what he said before, usually with some partially incorrect quote from some developer in a magazine. Afterwards he uses terrible unrelated examples to prove his non-existing point. People don't say the Sega-CD could make perfect ports of Super Scaler games, just that it could do much better versions of them then the genesis, since the genesis can't do them in any way shape or form at an acceptable framerate (just shitty animation based approximations like, ironically, TA's stupid examples in his previous post).

Actually it is. The original argument was TA's claim that the 3DO couldn't handle some effects common to MD and SNES (first parallax/scroll layers and then the Mode 7 thing) style graphics, and it really should be able to comprehensively outperform both of those in every category. And, hell, Mode 7 should be less GPU taxing than managing 2 or 3 scroll layers given how limited its use is on the SNES. (plus the comment about doing things "in hardware" totally nixes mode 7 in this context anyway, since "hardware" can only treat it as a single rotated/scaled object, and it takes added software assist to manage the raster effects for perspective -granted, all this is software controlling over graphics hardware to some degree, which is part of the point of the counter-argument in the first place )

Bringing the Saturn into the picture totally changed things though, since that has massively more rendering bandwidth (VDP1+VDP2) than the 3DO (and without contention), and the PSX has a great deal more resources for 2D as well. (again, without CPU contention)

I know, he gets hung up on his own particular interpretation of a particular quote and doesn't let go. But, I think it is relatively true that making other systems approximate warped 2D backgrounds without hardware support usually results in trade offs. I think that is all he is being obstinate about.

SNES doesn't have "hardware" support for warped rotated BGs either . . . that's a software assisted effect applied to the more limited scaling/rotation of a single tiled plane/object that Mode 7 handles.

You misunderstood my post. Had he clarified his position as what you said (and we tried to ask if that's what he meant multiple times on every single subject he "discussed") it would have stopped right there and then. This is not the forum discussing, it's the forum arguing with TA because he's an idiot.

I'm still discussing too.
I'm actually addressing other aspects of these arguments and pointing out some interesting specifics or possible contention in the actual arguments. (and clarification -like the whole point of the original "argument" on the 3DO that cropped up in the 4th gen thread being from SSFII's scrolling and TA's claim that the 3DO couldn't handle MD/SNES quality effects properly) --which is also why I refrain from commenting on many of TA's further responses in general. (nothing new/different to comment on )

For that matter, I'm still wondering about the SCSP's DSP again, now that Tiido brought it up. (I'm pretty sure we established several times that it wasn't useful for compressed sample decoding . . . in fact I recall him actually explaining that himself before)

[sheath]

Wrong on the Mode 7 comment. 3DO (and PSX) both render at 15/16-bit color depth, and the SNES uses paletted 15-bit RGB color. So a "mode 7" style rotated/scaled 2D object (software raster effects applied for perspective -as with SNES) using a 256 color paletted texture should be identical in appearance as the SNES. (aside from the higher screen resolution)

Yes of course, Mode 7 proper is only scaling and rotated square objects, the tilt is just, what, line scroll effects using rasters. Still, it is hardware supported and not all software as it would be on other fully or more capable platforms.

Handling it at similar framerates as the SNES should also be very doable . . . definitely if you're talking about the same limited usage as the SNES allows (no other BGs on the same scanlines as "mode 7" only sprites on those lines). The Jaguar would have a harder time with it, but that's another story. (texture mapping limitations of the blitter)

The biggest problem is they wouldn't bother making a flat scrolling/rotating floor with "256" colors just to look exactly like a SNES game, though I guess they did in Chrono Trigger and Final Fantasy IV and whatever else. On the 3DO the closest I've seen is BC Racers minus the scaling sprites and low-low framerate. Otherwise clearly the system can do better than Mode 7. Atari Karts is also a nice 60FPS higher color higher resolution example than Mode 7.

Actually it is. The original argument was TA's claim that the 3DO couldn't handle some effects common to MD and SNES (first parallax/scroll layers and then the Mode 7 thing) style graphics, and it really should be able to comprehensively outperform both of those in every category. And, hell, Mode 7 should be less GPU taxing than managing 2 or 3 scroll layers given how limited its use is on the SNES. (plus the comment about doing things "in hardware" totally nixes mode 7 in this context anyway, since "hardware" can only treat it as a single rotated/scaled object, and it takes added software assist to manage the raster effects for perspective -granted, all this is software controlling over graphics hardware to some degree, which is part of the point of the counter-argument in the first place )

The SNES should technically be able to do 8+ cell scroll layers like some Genesis games do as well, but it just didn't happen because it wasn't as easy to implement. My point wasn't that it was technically impossible, but rather technically unlikely to be implemented in exactly the same way.

[kool kitty89]

Yes of course, Mode 7 proper is only scaling and rotated square objects, the tilt is just, what, line scroll effects using rasters. Still, it is hardware supported and not all software as it would be on other fully or more capable platforms.

3DO, PSX, or Jaguar wouldn't be doing them "purely" in software either . . . 3DO doesn't have near the CPU resource to do that competently, but all 3 of those have hardware texture mapping capabilities (including drawing scaled/rotated rectangular objects or "sprites").
And in the Jag's case, it wouldn't be able to do 60 FPS in some cases. (like mode 7 used as full-screen running at 60 FPS on the SNES . . . well, technically you could if you used fast ROM -or on the Cojag- due to having multiple interleaved RAM/ROM banks for higher bandwidth -blitter is unbuffered and only renders one textel at a time for rotated objects, at only ~2.4 Mpix/s peak, so less than 1/10th that of the 3DO, CoJag should do ~6.65 Mpix/s)

The 3DO and PCFX would be the only consoles of that time without hardware support and with enough CPU grunt to at least moderately handle those sorts of effects in software. (computer platforms with faster CPUs are another story, of course)

The biggest problem is they wouldn't bother making a flat scrolling/rotating floor with "256" colors just to look exactly like a SNES game, though I guess they did in Chrono Trigger and Final Fantasy IV and whatever else. On the 3DO the closest I've seen is BC Racers minus the scaling sprites and low-low framerate. Otherwise clearly the system can do better than Mode 7. Atari Karts is also a nice 60FPS higher color higher resolution example than Mode 7.

True, but I was just addressing TA's original comments (both the Mode 7 and SNES/MD parallax thing). As to "256 colors" . . . that's actually not unusual for 3DO textures . . . I'd expect a ton of 3DO stuff to stick with 16 color textures to save space.
("Texturemap source bitmaps can be 1,2,4,6,8, or 16 bits per pixel and are
RLE compressed for a maximum combination of both high resolution and small
storage space.")
So that's 2, 4, 16, 64, 256, or 65k colors. (or subtract 1 if transparency is present -ie for non-rectangular or non-solid tiles/sprites)

And, again, texture mapped effects on the Jaguar will only be able to hit 60 FPS in some situations due to the blitter bandwidth limitations. (Mode 7 will beat the Jaguar in speed for full-screen rotation effects) I'm also not sure Atari Karts is using highcolor textures . . . it would have made more sense to use 8bpp (256 color) textures for the terrain and perhaps a mix of color depths for the sprites (probably 256 colors or less). The Jag's CLUT only has 256 entries, so you won't get more than 256 unique colors on sprites unless using 16bpp (uses lots of space), though you could certainly have more than 256 colors on-screen due to shading/blending effects. (selective use of 16bpp textures wouldn't be totally unrealistic either, but it's definitely going to cost you on animation and/or texture detail/resolution/size)

In any case, SNES mode 7 stuff should be similarly colorful as 3DO/Jaguar/PS1 stuff consuming similar amounts of memory. Granted, the VRAM (and DMA) limits on the SNES would greatly reduce the maximum practical resolution of textures and/or number of unique tiles used. (it's also limited to a tileset of 256 unique 8x8 cells, and 128 colors if you want per-pixel priority)
In general though, mode 7's raw color capabilities are great, the best of any video mode on any console of that generation. (256 colors from 15-bit RGB with any pixel on any tile able to use any of those colors -and separate from the normal sprite/tile palette entries; of course, that also means each pixel takes up 2x as much as 15 color tiles) The higher resolution/detail allowed by the open-ended texture sizes/resolutions would be a much bigger advantage for jag/3DO examples (scaled sprites and polygons aside).

The SNES should technically be able to do 8+ cell scroll layers like some Genesis games do as well, but it just didn't happen because it wasn't as easy to implement.

What do you mean by 8+ cell scroll layers?

My point wasn't that it was technically impossible, but rather technically unlikely to be implemented in exactly the same way.

Almost no platform would be implemented in exactly the same way, be it differing tile/sprite formats, or totally different rendering mechanisms altogether. (be it doing sprites like the 2600/A8, or sprites/objects like the 7800/Panther/Jaguar, framebuffer/blitter type rendering, multiple hardware framebuffers, mixed tile/sprite/framebuffers, etc, etc)

Having to implement something differently is a very different matter than being genuinely difficult to program, and the 3DO isn't even a "weird" architecture (like the 7800 for its time) since framebuffer/blitter style rendering was a very common technique to use.

Lack of parallax on SSFII on 3DO is just about as stupid as the almost absent parallax on the FM Towns SSFII release.

[sheath]

What do you mean by 8+ cell scroll layers?

Eight or more independently scrolling rows or columns of 8x8 pixel tiles. As seen in "parallax" backgrounds in Genesis games like Sonic 2, Musha, Ranger X, or whatever else. That is as opposed to line scroll effects on background segments. It is what TA is referring to when he says that no other system can do parallax like the Genesis. Other system's can, they just don't have any (or many) games that manage it because it wasn't a hardware supported effect. On the Genesis the VDP handles it in a different way than other systems, even though H-DMA should supposedly make the SNES just as capable.

Almost no platform would be implemented in exactly the same way, be it differing tile/sprite formats, or totally different rendering mechanisms altogether. (be it doing sprites like the 2600/A8, or sprites/objects like the 7800/Panther/Jaguar, framebuffer/blitter type rendering, multiple hardware framebuffers, mixed tile/sprite/framebuffers, etc, etc)

Having to implement something differently is a very different matter than being genuinely difficult to program, and the 3DO isn't even a "weird" architecture (like the 7800 for its time) since framebuffer/blitter style rendering was a very common technique to use.

Lack of parallax on SSFII on 3DO is just about as stupid as the almost absent parallax on the FM Towns SSFII release.

Pretty much the whole point in a large nutshell.

[kool kitty89]

Eight or more independently scrolling rows or columns of 8x8 pixel tiles. As seen in "parallax" backgrounds in Genesis games like Sonic 2, Musha, Ranger X, or whatever else. That is as opposed to line scroll effects on background segments. It is what TA is referring to when he says that no other system can do parallax like the Genesis. Other system's can, they just don't have any (or many) games that manage it because it wasn't a hardware supported effect. On the Genesis the VDP handles it in a different way than other systems, even though H-DMA should supposedly make the SNES just as capable.

Rows are easily done on the SNES . . . AFIK the only reason for a game to feature or lack that would be sheer artistic choice. Linescroll could take a little more CPU overhead since you're managing a lot more specific PPU interrupts (at least for a large area of linescroll -like floors in fighting games or the BG in EWJ2's "Puppy Love"), but it's not a big issue.
Doing "parallax" that way on the NES or SMS (and obviously PC Engine) was quite doable too. (or C64, or Atari 800, Amiga, etc -anything with hardware scrolling and some sort of raster/scanline interrupt support, be it tile or framebuffer based graphics -software scrollers could obviously do it too, but that's a different context in general)

Column scroll OTOH is a different animal entirely and is one of the MD's more interesting features. It's not on an 8x8 tile basis either; it's in 16 pixel wide columns, but still useful and something that was not a common standard feature of other hardware scrolling game graphics hardware. I don't think the SNES can actually do that at all, I know the PC Engine doesn't do it, and I know the Amiga physically can't (it's a linear framebuffer type system so it can't segment vertical scrolling, that is, but it could use brute force blitter drawing to "scroll" columns -on the ST it wouldn't matter since scrolling columns would about as resource intensive as screen scrolling in general)

I've seen mention of the SNES's mode 2 graphics allowing tiles to be "individually scrolled" (including the wiki entry), but I'm not sure whether that refers to column scroll or not. (if it does, that would imply better column scroll than the MD in that it's got 8-pixel granularity rather than 16 pixel)

[sheath]

Rows are easily done on the SNES . . . AFIK the only reason for a game to feature or lack that would be sheer artistic choice. Linescroll could take a little more CPU overhead since you're managing a lot more specific PPU interrupts (at least for a large area of linescroll -like floors in fighting games or the BG in EWJ2's "Puppy Love"), but it's not a big issue.
Doing "parallax" that way on the NES or SMS (and obviously PC Engine) was quite doable too. (or C64, or Atari 800, Amiga, etc -anything with hardware scrolling and some sort of raster/scanline interrupt support, be it tile or framebuffer based graphics -software scrollers could obviously do it too, but that's a different context in general)

Right, in the discussion I had over at spritesmind what I was stipulating was relegated to "excessive" scrolling. The most "rows" I have seen in a SNES game is five in Super Valis IV, I'm pretty sure I saw another game do the same recently though. Still, something to the extent of Ranger X, Sonic 2 (Especially Aquatic Ruin), Thunder Force IV or even Gynoug/Wings of Wor seems out of the SNES' reach. I think the TG16 could do it if not for the single background. It does seem like it takes up too much CPU on the SNES to pull it off, or it could be a simple artistic choice. I just can't imagine why more depth of field would be a bad thing artistically.

Column scroll OTOH is a different animal entirely and is one of the MD's more interesting features. It's not on an 8x8 tile basis either; it's in 16 pixel wide columns, but still useful and something that was not a common standard feature of other hardware scrolling game graphics hardware. I don't think the SNES can actually do that at all, I know the PC Engine doesn't do it, and I know the Amiga physically can't (it's a linear framebuffer type system so it can't segment vertical scrolling, that is, but it could use brute force blitter drawing to "scroll" columns -on the ST it wouldn't matter since scrolling columns would about as resource intensive as screen scrolling in general)

I wonder what the deal is with column scrolling, is it too hard because DMA and registers are on a per line basis? I know the VDP has actual Vertical Scroll RAM to facilitate the effect.

I've seen mention of the SNES's mode 2 graphics allowing tiles to be "individually scrolled" (including the wiki entry), but I'm not sure whether that refers to column scroll or not. (if it does, that would imply better column scroll than the MD in that it's got 8-pixel granularity rather than 16 pixel)

Supposedly H-DMA fixes everything on the SNES, it just didn't in a production game.

[Kamahl]

"Individually scrolled" is exactly what it says, you can scroll each tile individually. See Super Bonk 2.

[Black_Tiger]

Right, in the discussion I had over at spritesmind what I was stipulating was relegated to "excessive" scrolling. The most "rows" I have seen in a SNES game is five in Super Valis IV, I'm pretty sure I saw another game do the same recently though. Still, something to the extent of Ranger X, Sonic 2 (Especially Aquatic Ruin), Thunder Force IV or even Gynoug/Wings of Wor seems out of the SNES' reach. I think the TG16 could do it if not for the single background. It does seem like it takes up too much CPU on the SNES to pull it off, or it could be a simple artistic choice. I just can't imagine why more depth of field would be a bad thing artistically.



I wonder what the deal is with column scrolling, is it too hard because DMA and registers are on a per line basis? I know the VDP has actual Vertical Scroll RAM to facilitate the effect.

Supposedly H-DMA fixes everything on the SNES, it just didn't in a production game.

It's just an "artistic" choice, in that its use isn't restricted by hardware power in 16-bit games. It's more the opposite, in that it was more used as filler to save space by making tiled spamming look less repetetive. Which is why you didn't see it in arcade games, but did see it in 8-bit console games. In games like Mickey Mania(?), the Genesis verson uses it a bit at the bottom of one layer while the SNES version has an entire extra overlapping scrolling layer. PCE games have 20+ strips at a time. The floors in 3DO SSFIIX are basically 50+ strips of the same thing, only one(?) pixel thick. The fact that it's a relic if the 8-bit generation is a good sign that it's not a cpu intensive eftect.

Sonic unfortunately popularized a mixture that gives an unrealistic depth of field. Instead of creating the kind of depth that the mutli-plain camera was designed for, Sonic games give the impression of holding an ant farm in front of your face and walking in front of a wallpapered wall. The layer that Sonic interacts with is so tall that the strips behind shouldn't be so thin for many elements and the back layer in general shouldn't scroll much vertically. Instead it's just a "video game" effect for the novelty of having a cool looking effect, instead of a depth of field effect. But since Sonic was so big on Genesis, too many Genesis games tried to ape the overall effect, often moving further away from real depth of field. SNES games went for more of an arcade aesthetic right from launch.

PCE games (such as Browning and the Downloads) seem to more often scroll those horizontal strips vertically and overlap them, creating an even greater depth of field impression (when done right). I believe that it is again, done to get more out of limited storage space than super powers of the hardware and I'm sure it's no problem for SNES and Genesis.

[Kamahl]

Sonic games give the impression of holding an ant farm in front of your face

Can't unsee...

[kool kitty89]

"Individually scrolled" is exactly what it says, you can scroll each tile individually. See Super Bonk 2.

Where in Super Bonk 2? I didn't notice anything obvious? Plus that game runs in mode 1 for the main game parts, not mode 2 (4 color tile layer used for status overlay) and it seemed like that scrolling feature was specific to mode 2.

I wonder what the deal is with column scrolling, is it too hard because DMA and registers are on a per line basis? I know the VDP has actual Vertical Scroll RAM to facilitate the effect.

Video is scanned out to the screen a line at the time . . . sprite data is buffered into line RAM in h-blank and tile data is scanned out during active display. (a pretty common arrangement, and even the Amiga does something like that, sprite in hblank and framebuffer(s) in active display)

Since it's a line at a time, you can use interrupts (CPU interrupts and/or VDC/VDP/PPU/etc interrupts depending on the system) and modify certain parameters before the next line gets scanned out. (or set it up to do it on a row basis rather than line, depending on the system in question)

Vertical strips are another matter entirely, and need specific hardware support to make possible . . . or have interrupts between every single pixel/tile segment fetch, but there's almost never support for that and it would take a lot of overhead if it was supported. (you'd need a bunch of interrupts each line rather than 1)

With a specific table to control column scrolling, this can be handled by the VDP(etc) and adjust the scroll position of the individual tile columns (or pairs of tiles in the MD's case -16 pixel wide strips). This is more practical on a tilemap based system since it's already using a nonlinear display system (using a table to select which tiles to scan out when/where rather than linear data scanning as in a framebuffer . . . or even a specifically arranged nonlinear framebuffer like the ZX Spectrum -reading pixel and color attribute data separately).
You could technically allow for similar support on a framebuffer based system, but it would take a much larger table to support, since it would be controlling vertical scroll of a ton of single pixel tall line segments rather than tiles. (you'd also need the bandwidth available to have the VDP reading the added data from that table mid-screen . . . or more hblank bandwidth and more registers or buffers to account for the more complex display lists/commands) -So, again blitting (software or hardware) is the main option for vertical column scroll with framebuffers.

On an "all sprite" system, you'd avoid that issue, but be limited to scrolling columns by the width of the sprites used. (narrower sprite strips gives finer columns)

Sonic unfortunately popularized a mixture that gives an unrealistic depth of field. Instead of creating the kind of depth that the mutli-plain camera was designed for, Sonic games give the impression of holding an ant farm in front of your face and walking in front of a wallpapered wall. The layer that Sonic interacts with is so tall that the strips behind shouldn't be so thin for many elements and the back layer in general shouldn't scroll much vertically. Instead it's just a "video game" effect for the novelty of having a cool looking effect, instead of a depth of field effect. But since Sonic was so big on Genesis, too many Genesis games tried to ape the overall effect, often moving further away from real depth of field. SNES games went for more of an arcade aesthetic right from launch.

Wow . . . yeah, Sonic 1 MD looks really weird in that respect, and the fast autoscrolling clouds in the JP version make it even weirder.

Sonic 2 and 3 don't seem to do this. Emerald Hill zone in particular makes a very obvious contrast with very slowly scrolling far BG in a similar scene as Green Hill Zone. Some other stages have faster BG scrolling, but it makes more sense since that's things like walls, ruins, or a forest (Angel Island) where the "far" BG is much closer than in Green or Emerald Hill.
Emerald Hill actually looks WAY better now that I think about it. (I'm not really a fan of the blocky art style used for some of Sonic 1's BGs either . . . I realize it's a reasonably well adapted design that allowed for much better compression in ROM, and it looks OK for what it is, but when you can actually spare the space for proper detail the difference is definitely noticeable)

[Kamahl]

Where in Super Bonk 2? I didn't notice anything obvious? Plus that game runs in mode 1 for the main game parts, not mode 2 (4 color tile layer used for status overlay) and it seemed like that scrolling feature was specific to mode 2.

The big pixelated bonk face animation is using mode 2.

[Moirai]

Funny how y'all are taking about 16 bit consoles in the 32bit console thread.