Austin, on Fri Mar 4, 2011 9:51 PM, said:
kool kitty89, on Fri Mar 4, 2011 9:36 PM, said:
The later Amok is a good example of a combined voxel/polygon renderer. (though it's much more primitive than what Phase Zero pushed -but that avoids polygons too)They probably should have pushed for a Commache port as well.
When you mentioned voxels I immediately thought Amok, but you beat me to it, haha. That's certainly a good example, as it runs at a blazing framerate for a 32-bit game (and as you noted, it has a mixture of textured polygons, too). More games would have run in a much more fluid manner during this generation had they used this method (including Jag titles!).
Yeah, and interestingly there's a demo of Amok's renderer on the 32x from the Scanvenger teams' demo. (Zyrinx and Lemon were the 2 32x developers working on Scavenger projects and you see Lemon's Amok demo in the Scavenger 32x demo tape posted online in several places)
I haven't played Amok myself though, and I'm not sure it did any Doom/Duke3D (etc) type height map portions. (again, a really nice engine pushed on a CPU/DSP -ie Jag RISC- resource heavy platform -PC/Jag/32x/Pippin- would really have been best to push faster "3D" methods that other platforms couldn't accelerate in hardware -though the Saturn has more bandwidth/CPU/DSP power than the 32x -N64 might have done very well at such too with an RSP microcode implementation aimed at such sheer flexibility)
I think Outcast uses doom-like height mapped spans for some buildings/objects as well as the voxel terrain, water effects engine, and polygon renderer. (that's a really neat example and one of the last purely software rendered PC games -aside from some Java/Flash stuff- )
Of course, if hardware acceleration on PCs had focused on flexibility (powerful DSP/GPU along with moderate blitter based acceleration for 2D/3D textures/objects/shading), you could have seen all that done without excessive CPU resource on PCs. (granted, later gen GPUs actually did push for such flexibility -more like the Jag in some respects- but by then "real 3D" had become the norm -though to this day there are many cases -like most ground/on-foot/vehicle based 1st/3rd person games- where you could use voxel terrain instead of polygons without any added limitations; other games would be a bit constrained by height map rendering though)
Zerosquare, on Sat Mar 5, 2011 11:06 AM, said:
kool kitty89, on Fri Mar 4, 2011 9:36 PM, said:
The jag has hardware texture mapping
Not really. It's just a 2D zoom/rotation feature, and to do 3D you have to break each triangle into segments, then draw then one by one. It can't draw a complete texture-mapped (or even flat-shaded, for that matter) triangle by itself.
Yes, exactly, that's hardware texture mapping, or more accurately: affine line texture rendering.

(as much as the gouraud shading is hardware as well -or plain line filling for solid shaded polys)
Texture mapping isn't a 3D thing, it's 2D, you need more than that for 3D.
The Jag has no hardware for warped primitive (triangle or quad) rasterization, true, but that's a separate issue from texture mapping. (ie it can't do flat shaded polys in hardware either -needs the GPU to set every single line for the blitter to fill, just like you'd need to for textures)
The problem is that texture mapping is unbuffered and thus slow due both to having to work with single words at a time (8 or 16 bits -no support for 4 bit sources iirc) and dealing with page breaks all the time since there's no line buffering or separate source and destination.
With buffering like you've got for gouraud shading, texture mapped polygonal 3D would be almost as fast as solid shaded 3D.
That lack of buffering is also a great hindrance to rendering rotating sprites or a warped BG plane. Hell, if the blitter's texture mapping feature was fully buffered, the need to have the OPL at all would be much less.
You could then render everything with the blitter at pretty high speed and have high speed rotation/warping effects for textures as well -OPL can only stretch/zoom, maybe more so if there was a special high-speed mode for the blitter that disallowed rotation like the Saturn's single point VDP1 "sprites" or the PSX's 2D mode (rendering rectangular object "sprite" cells of any size that could be stretched/scaled but not rotated, thus approaching 100% of the 133 MB/s bandwidth for 2D drawing -sort of like the restriction of the OPL to only doing scaled rectangular objects except you'd be sharing the same logic of the blitter and it wouldn't be as flexible as the OPL for 2D -the PSX's "sprite mode" itself is superficially similar to what the OPL displays or sort of what the Neo Geo does in the sense that it's all sprites -but a big difference compared to the NG's hardware sprite logic).
That's what gave the PSX an advantage in 2D over the Saturn in some cases too: the Saturn has a powerful tilemap based BG engine (4 planes with lots of flexibility), but the PSX smokes the Saturn's VDP1 in pure 2D drawing (and texture mapping in general), so a sprite heavy game (or a game not highly optimized to use the tilemap BGs of the Saturn) would thus favor the PSX. (the fact that PC GPUs and many other blitter type systems worked in such a fashion -and tilemap based consoles/arcade machines were becoming proportionally less common- that also favored the PSX for many multiplatform 2D games for PC and such -and many such games directly ported to the Saturn using VDP1 would likely suffer from slowdown due to bandwidth limitations)
Of course, all of that is worthless for a game like doom or duke nukem 3D.

(those are all column based renderers and thus only the scaled 2D objects would be any good for affine texture rendering -which the Jag's OPL can handle fine) You'd either need a fast CPU/DSP to handle the raycasting and vertical column (constant Z) texture rendering, or you'd need to rebuild the engines to support polygons as well as use software perspective correction to avoid distortion. (PSX Doom did that, 3DO Doom probably would have been much better if it used quads rather than CPU rendering -didn't help that you could only code to 3DO's C libraries/OS and that 3DO Doom didn't allow a low-detail option for 1/2 horizontal res a la PC/Jag/32x/SNES -Saturn Doom was a sloppy PSX port and coupld have been better with a properly optimized Quad renderer like Duke Nukem 3D on the Saturn or a CPU/DSP based raycasting renderer)
Edited by kool kitty89, Mon Mar 7, 2011 1:23 AM.