The color/dithering used in ZT looks very similar to that of Duke 3D except they seem to try to keep to a more limited range of colors and avoid the extreme degree of dithering (vertical bars) that Duke uses (much of it is really obvious and often ugly when unfiltered). The most obvious case of that in ZT is the shading used (seems to be close to 8 pseudo light-levels used though a combination of solid black bar patterns and remapped colors -the latter resulting in posterization just as with doom -though given the resolution and dithering/bars, it's not all that noticeable).Quote:
Originally Posted by Chilly Willy
Duke nukem seems to keep to a single light level, bus still uses tons of that dithering (which either uses vertical bars, or simply paired pixels that often result in such columns) and much of it tends to look rather ugly at times when unblended, but pretty good if blurred horizontally. (just watch the demo in fusion set to normal, and then set to CVBS)
One other thing is that, while there's no light levels, it does seem to use realtime shading of some sort as in the open to space areas a blue dithered overlay appears on the scrolling space background, like a blue translucent layer. (and remember, it's not shaded in the behind boarder where it constantly displays, and also remember that it's on the same BG layer as the game window with the boarder on the top layer -unlike ZT's scrolling space BG- so that's not a simple BG over BG tile overlay, but realtime software rendering those blue bars over the space scape)
The big difference with Duke is the screen size and framerate over ZT. (though the screen tearing is more of an issue, and not as well managed -ZT tears too, but sets it such that it tears vertically in the very middle of the screen and updates in 2 consecutive frames -only 1 frame in 60 hz is actually torn and very evenly -I couldn't see it at all until I did frame by frame, unlike duke which was rather annoying IMO -though not nearly as bad as rebel assault)
But it is that same substantial amount of vertical bars (either by design or artifacts from using a paired pixel renderer) that made me think the technique might be applicable for shading in doom: be it using the vertical bar patterns and/or color remapping (both as solid colors and pixel pairs) for such lighting gradients. (if it were used: probably something like the "full color" max brightness paird pixel dithered texture starts losing some of the brighter colors as it shades darker to fewer and fewer distinct colors to an increasingly posterized state with fewer and fewer colors until you reach solid black -depending how decent the paired pixel selection looks and how much the vertical bars are used -if at all- you might get a decent number of shades too)
But again, you'd have to weigh that with how it would look compared to no light levels or simpler shading effects. (ie just per room/area lighting and some added shadows like Doom 32x, plus simpler shading effects or none should speed things up -perhaps why they were simplified on the 32x)
In the case of wolf3D, you'd only really need to weigh the decision of using plain 15/16 colors, or using paired pseudo-8-bit pixels (short of an actual full res 4bpp renderer like Battle Frenzy -plus there's more rays to cast). If you did want to go full resolution with single wide pixels, maybe you could still cater to an engine built around rendering to an 8bpp buffer (like unpacked 16-color chunky pixels), but then converting that to the 4-bit tilemap format. (the ASIC wouldn't facilitate that, would it, or at least not beyond doing the 4bpp packed bitmap to tilemap conversion?)
But one other thing on the shading: I was looking at SNES doom again, and, beyond the lower-res textures, the shading techniques used seem a bit odd too: unlike PC doom, the shading gradients/banding don't seem uniform in depth/distance in some cases and there's many fewer gradients on the SNES. It also has a low-color appearance on top of everything else. (and in particular, the floor shading is often dithered, which seems odd given 256 colors)
In many cases (especially the first 2 rooms in E1M1) there are only 3 distinct shading levels in the distance vs the rather distinct 7 or 8 bands in the PC version, and likewise those 3 bands are stretched much longer (deeper) than the smaller bands on the PC version. Things seem to posterize very quickly as well, with the green walls in the first 2 rooms turning gray/black in the 2nd shade (looks like less than 8 distinct colors/shades) and then to almost monochrome on the 3rd light level. The only area with more gradients I saw in E1M1 was in the corridor next to the secret door: there's the shadow on the ground in front of the corridor which is a checkerboard dithered area on the untextured floor and beyond that you can make out maybe 5 shading gradients (and a lot of dithering in those on the ground layer), but a similar amount of stark posterization there too, just borken up a little more for the added gradients. (it the color loss/shading is simply stepped more subtly)
It makes me wonder if the SNES port might not even use 256 colors, but maybe cut it to perhaps 6-bit tiles for the output to the VDP rather than 8-bit (saving DMA bandwidth and VRAM space especially with the 216x144 game window size and some added 16-color tiles/sprites for the status overlay and player's hand/weapons). I'd guess 6-bit/64 color given what I see on-screen, but actually taking a pure square pixel (unscaled) screenshot and using a utility to examine the palette could be more definitive. It is a planar display, so they could be catering to 5,6,7, or 8bpp (doing 4bpp wouldn't make sense for using mode 3 graphics over mode rather than mode 2 or 1).
If it does do that, they could still have used an 8bpp chunky pixel renderer (but only 64 actual entires used -or whatever the final color depth was to be) and done the 6bpp as part of the chunky bitmap to planar tile conversion. (it could render to a 108x144 chunky pixel buffer and then convert that to the 216x144 planar tilemap window -and probably not buffer the whole tilemap window into the Super FX RAM, but just the chunk of tilemap data that would fit into the next vblank update)
On the other hand, it does seem rather odd that they didn't opt for using mode 7 with the hardware stretching, chunky pixels, and full 256 color palette (not tranparent every 16 entries like mode 3 or 4), though you'd be doing 104x144 rather than 108x144 as you have to cater to 8x8 mode 7 tiles. I think mode 7 tiles take up 2x as much data as plain 8bpp tiles would (or something to do with a large tile index), but if it was the case that lower depth tiles were actually updated for SNES Doom, that would really explain it. (in any case you'd still have to be stitching between 32 kB tile banks to double buffer the game window -even with 6bpp it wouldn't work)
Huh, tomaitheous had given me a different impression when we discussed it a while back:Quote:
No, just BG+SPRITE. The whole idea behind shadow/hilite is that one sprite provides the image, then another sprite just like it (except for the color) provides the shadow/hilite of the first sprite on top of the background.
http://sega-16.com/forum/showthread.php?t=9179
specifically:
http://sega-16.com/forum/showpost.ph...38&postcount=3
Though I seem to recall hilight was far more limited.
It still seems odd that that would happen on games from high profile, high production value games from big-name companies. (granted, MM Lengends was a late 1997 game, so fairly early still -and it doesn't seem like Tomb Raider -or some others- with no perspective correction at all, but still a lot of noticeable twitching and warping -but not that really bad warping seen close to the screen -it seems like it probably focused on correction for the near-camera stuff)Quote:
There will ALWAYS be game producers who are too cheap to pay for a decent engine. Devs often have to cut corners to save time/money, and as a result, the game goes out with issues that should have been dealt with.
OK, that's what I'd thought: I think I just misinterpreted your previous comment.Quote:
Other way around - the 32X version is based on the Jaguar version with certain things trimmed to make it fit the lesser memory in the 32X.
Ah, OK, and probably not the 3DO's coprocessor either (even if it was more general purpose, 3DO's OS probably didn't cater to such alternate uses), though I wonder a bit about the Saturn's DSP embedded in the SCU. (especially if they possibly used the same Samsung core as the SVP given they already had the license, though you'd think they'd have had better documentation if that were the case)Quote:
No. The GTE just does matrix math. That's it. The math is also targeted directly at just that matrix math needed for 3D. It's not even a generic matrix processor.
