5 ms·

Why did you have to simulate pixel level output to sort your polygons, out of curiosity? I've also written rendering engines for hardware lacking Z-buffers, an

Why did you have to simulate pixel level output to sort your polygons, out of curiosity? I've also written rendering engines for hardware lacking Z-buffers, and our approach was to build a BSP tree of the level, which gets you part of the way to working around no Z buffer, since there's no Z overlap in static polygons after being partitioned, but the downside is you split triangles and increase the triangle count, so it reduces model complexity if the splitting blows your poly budget. Once you have your BSP cells, you can precompute all the visible cells from any given cell - heh, we too did this on SGI's, but by rendering each cell is a unique color and seeing which colors were visible in an output frame. Then, within each cell, we'd have six draw orders for triangles, picking whichever was closest to the eye vector. Not pretty, and sometimes this produces quite a bit of overdraw, but it works. I'm guessing your approach minimized overdraw as compared to a heavily pre-computed BSP approach. Anyhow, thanks for the post, it's fun to read about the the hacks form the early days of graphics hardware.

dmbaggett 10y ago
>Why did you have to simulate pixel level output to sort your polygons ... ? We essentially rendered every frame with a Z-buffer; it's just that the Z-buffer was running in software on the SGI ahead of time, as the level was processed. We needed pixel accuracy so that the occlusion was perfect. The BSP tree technique was well understood by then, thanks to Carmack's work on Quake, but we didn't want to split polygons so we used this brute force method instead. However, as a little bit of disinformation to other developers, we put a big file of random data on the Crash CD called BSPTREE.DAT. You still have to download this huge, pointless data file when you buy the game on PSN. I feel slightly guilty about that. :)
- STRML 10y ago
  That's hilarious. It was just a matter of empty space on the disk = let's misdirect competitors for a while?
  - dmbaggett 10y ago
    Yup.
- digi_owl 10y ago
  Oddly i could have sworn that there was a problem with fitting the game on a CD until some clever compression was applied.
  - dmbaggett 10y ago
    You're thinking of fitting the levels into the maximum number of pages that could fit into memory. That was hard, but had nothing to do with the CD capacity.

dmbaggett 10y ago

>Why did you have to simulate pixel level output to sort your polygons ... ? We essentially rendered every frame with a Z-buffer; it's just that the Z-buffer was running in software on the SGI ahead of time, as the level was processed. We needed pixel accuracy so that the occlusion was perfect. The BSP tree technique was well understood by then, thanks to Carmack's work on Quake, but we didn't want to split polygons so we used this brute force method instead. However, as a little bit of disinformation to other developers, we put a big file of random data on the Crash CD called BSPTREE.DAT. You still have to download this huge, pointless data file when you buy the game on PSN. I feel slightly guilty about that. :)

STRML 10y ago
That's hilarious. It was just a matter of empty space on the disk = let's misdirect competitors for a while?
- dmbaggett 10y ago
  Yup.
digi_owl 10y ago
Oddly i could have sworn that there was a problem with fitting the game on a CD until some clever compression was applied.
- dmbaggett 10y ago
  You're thinking of fitting the levels into the maximum number of pages that could fit into memory. That was hard, but had nothing to do with the CD capacity.