Highlight and Shadow

[kool kitty89]

I've been wondering about this feature for a while, I've learned a little about it from some past discussions but not much, and I couldn't turn up much useful in online searches. (other than claims that it effectivley increases the 512 color palette to 1,536 colors)

So, how does it work, what specifically does it do, what limitations does it impose, and what games take advantage of it?
Was a similar featured used in any of Sega's non-MD based arcade boards?

[Jorge Nuno]

Shadow can be used with some freedom (shadow is applied to the entire palette), however highlight only works for 1 index of it, and when the plane priorities are favorable, which means that highlight is a pain in the ass to use outside techdemos.

And no it's not 1536 colors...

the VDP has a selection of 512 colors, and any color can be shadowed or highlighted, but in some situations (when color intensities are a full multiple of 4) they will result in a less/more brighten color, that's available normally, like this example:

you have this medium-scale gray: 0x0888, now apply shadow to it: it reduces the intensity by half, so 0x444, but this intensity is alreardy selectable without the shadow effect.
Now instead of shadowing it, highlight it: 0x0CCC, umm thats another nortmally available intensity.

[tomaitheous]

what limitations does it impose

Minimum, you need to either use sprites (which increases the chance of sprite drop out, because you're are closer to the sprite pixel scanline limit) or use sacrifice a tilemap (which means you're down to 1 regular BG layer). And then there's the issue of priorities between all layers that Jorge pointed out too.

Ex-ranza/Ranger-x takes advantage of it in the second level. The cave level. Where the beams of light are shining in. Rambo uses it in some parts (I think as a shadow). Toy Story used it for static images, to get more colors per tile and overall onscreen. Batman and Robin uses it quite a bit (the first level with the flash lights). Vectorman uses it. Ecco uses it.

[Jasper061992]

I was always impressed with the Shadow/hightlight effect on the Megadrive. Even moreso that the Master System and Gamegear can pull it off too. I seen it in Sonic 1, Sonic 2 (MS version there isn't any water in Act 2 of Aqua Planet even though it pretends to have water), Sonic Chaos, Triple Trouble and Sonic Blast When the Master System does it, is the maximum master palette increased from the 64?

[kool kitty89]

Do any games use it with streaming video on the Sega CD?

[tomaitheous]

I was always impressed with the Shadow/hightlight effect on the Megadrive. Even moreso that the Master System and Gamegear can pull it off too. I seen it in Sonic 1, Sonic 2 (MS version there isn't any water in Act 2 of Aqua Planet even though it pretends to have water), Sonic Chaos, Triple Trouble and Sonic Blast When the Master System does it, is the maximum master palette increased from the 64?

Uhm.. no. It's only available on the Genesis VDP. Whatever else you're seeing, it's not hardware shadow/highlight.

Do any games use it with streaming video on the Sega CD?

None that I know of. And part of the reason for that, is that even though only 1bit (2bit if you use both) is really needed, the Genesis tile format is packed pixel. So you'd still have to transfer S/H data as if it were 4bit format. That means double buffering the second BG layer and have small FMV window, or get screen tearing. A shame really. It also potentially drops the max frame rate down, but most SegaCD games with FMV didn't have high frame rate to begin with.

I believe Fonzie used it in his own video codec.

[Jasper061992]

Uhm.. no. It's only available on the Genesis VDP. Whatever else you're seeing, it's not hardware shadow/highlight.

You sure? I'm sure the technique refers to the underwater effect. If not, what is the name of it? Sonic 1 Labyrinth Zone, Sonic 2(GG version only), and Sonic Chaos on the Master System and Gamegear definitely has the underwater colour tint effect in them. The Megadrives VDP chip is only an extended version used in the Master system hence compatibity. You tried the 8bit sonic games right?

[tomaitheous]

You sure? I'm sure the technique refers to the underwater effect. If not, what is the name of it? Sonic 1 Labyrinth Zone, Sonic 2(GG version only), and Sonic Chaos on the Master System and Gamegear definitely has the underwater colour tint effect in them. The Megadrives VDP chip is only an extended version used in the Master system hence compatibity. You tried the 8bit sonic games right?

Yes, I'm sure

Shadow/highlight doesn't change colors or tints. It changes the brightness or intensity of a color. That's not the same thing. Two, I've read the SMS docs/info many times in preparation for doing SMS dev (and know/talk with the man who's behind most of the R&D for the console, for emu purposes and demos). If SMS or GG has S/H, I would know about it And he would have made a demo to show it off

The effect you're seeing is a mid screen scanline change. Be it via tilemap or by palette reg updates (I suspect tilemap, because you have enough vertical tilemap room to do it on a 8pixel tall row, and just repalette associated the rest of the timemap. I.e. you only need an two copy of the same 8pix tall row to animate the effect going up and down - the water level). That's not the same the and definitely not as flexible as something like S/H which works on a pixel level basis (and like I said, doesn't effect "tint" or hue or such).

[Jasper061992]

Yes, I'm sure

Shadow/highlight doesn't change colors or tints. It changes the brightness or intensity of a color. That's not the same thing. Two, I've read the SMS docs/info many times in preparation for doing SMS dev (and know/talk with the man who's behind most of the R&D for the console, for emu purposes and demos). If SMS or GG has S/H, I would know about it And he would have made a demo to show it off

The effect you're seeing is a mid screen scanline change. Be it via tilemap or by palette reg updates (I suspect tilemap, because you have enough vertical tilemap room to do it on a 8pixel tall row, and just repalette associated the rest of the timemap. I.e. you only need an two copy of the same 8pix tall row to animate the effect going up and down - the water level). That's not the same the and definitely not as flexible as something like S/H which works on a pixel level basis (and like I said, doesn't effect "tint" or hue or such).

Oh. If it's a mid scanline change how comes whenever i get slowdowns underwater, the colour stays solid (no flicker)?. I can tell a difference between the water in Sonic 1 (labyrinth water which has a real clean colour tint look to it and Sonic 2's aqua planet zone act 1 water that has a dotted look every other pixel. Is that the mid scanline change effect?

[tomaitheous]

Oh. If it's a mid scanline change how comes whenever i get slowdowns underwater, the colour stays solid (no flicker)? I can tell a difference between the water in Sonic 1 (labyrinth water which has a real clean colour tint look to it and Sonic 2's aqua planet zone act 1 water that has a dotted look every other pixel. Is that the mid scanline change effect?

Are these two Sonic's your talking about the SMS or Genesis versions now? The Genesis version of Sonic 1 does mid screen palette updates (it might even do midscreen tilemap swapout too, but I doubt it since it's already doing palette block updates). This leaves some corrupt pixel artifacts onscreen, mostly evenly spaced apart (it's either 16 or 32 pixels apart, I forget off hand). So, they put flickering/alternating sprites at the waters edge to help hide this. And it really does make it unnoticeable. Also, when you change a palette or tilemap position mid screen, the rest of the screen is now drawn with those new updates. So you don't have to do this effect on every single scanline. Just at that one point.

If you see alternating dot pattern in a game, then they most likely using a solid color with every other pixel cut out. On Genesis composite/rf output to the TV, it blends the pixels and you see a kind of transparent layer (RGB users unfortunately didn't get the nice effect. Neither do s-video upgraders). The down side of this, is that it usually requires using one of the BG layers, so you lose a layer for some parallax effects or overlapping multi-direction planes.

Also, Sonic is slower because he's under water. Hahaha. :P

[Jasper061992]

Are these two Sonic's your talking about the SMS or Genesis versions now?

Sorry, i was referring to both Sonics on the Master System.

So, they put flickering/alternating sprites at the waters edge to help hide this.

Actually, when i pause the game on Sonic 1-3 that flickering water waves can disappear at one side. The sprite colour neatly changes colour when one half is outside and the other inside along with any other graphics thats half out.

Also, Sonic is slower because he's under water. Hahaha. :P

lol, i meant if Sonic loses rings underwater, the game framerate slows down to 25-30fps and yet the water colour is still solid, no flicker.

[Jorge Nuno]

The fact that the game lags (It doesn't complete its normal execution cycle within 1 frame) is irrelevant to the water color, due to the fact that the color reloading is done in the horizontal interrupt, where the CPU is... interrupted (heh) from the normal program flow, to load the new colors, and this interrupt is externally triggered periodically (by the VDP).


Also the color artifacts (VDP cram bug) only appear on true hardware.

[tomaitheous]

Actually, when i pause the game on Sonic 1-3 that flickering water waves can disappear at one side. The sprite colour neatly changes colour when one half is outside and the other inside along with any other graphics thats half out.

I'm not sure what you're asking though? Not every transparency trick uses 60hz "flicker", obviously. And what the game does when you pause it, is up to the developers. There's nothing to prevent the sprites from alternating on the waters edge, other than the programmer decided the pause function was also going to pause that routine as well. There are a lot of tricks you can do be it the SMS or the Genesis, and not all of them are necessarily the same. Hell, SMS games are known to do software sprites because it has 4bit tiles. You'll 99.999% never see this on the NES because if its lower color count/restrictions on tiles. If I were going to do such method on the SMS, it would a tilemap method like I mentioned earlier on and interrupt, and manually update the Sonic sprite with different colors depending on which point he entered the water (mainly, because I'm not sure what the effects or possibility of updating palette ram mid screen on the SMS), which is a very simple task given the 4bit color limit of sprites.

lol, i meant if Sonic loses rings underwater, the game framerate slows down to 25-30fps and yet the water colour is still solid, no flicker.

Why would that make any difference though? And interrupt is an interrupt. It's going to happen whether the game codes falls behind or not, on a frame. It's regardless if this is done via palette reg updates or tilemap method, or both. The color shouldn't flicker because the game slowed down. You might be confusing this with some else (or some other broken/borked game engine) or maybe flicker style transparency. Dunno.

[Jasper061992]

Alright, i stand corrected then. I'm still learning. I still find the effect impressive though.

[kool kitty89]

Minimum, you need to either use sprites (which increases the chance of sprite drop out, because you're are closer to the sprite pixel scanline limit) or use sacrifice a tilemap (which means you're down to 1 regular BG layer). And then there's the issue of priorities between all layers that Jorge pointed out too.

More recently Chilly Willy mentioned that shadow could only be used with sprites (wither overlapped sprites or sprite over BG), but the above seems to be saying that the 2 BG planes can be paired (so to speak) to effectively have a single BG layer with full use of shadow on every tile.

So was Chilly Willy wrong or an I misinterpreting the above statement. (if he's right, that's sort of the opposite of Amiga's halfbrite which works on the bitmap planes, but not sprites )


Another thing that got me thinking on this again was in the context of FMV and pseudo-bitmap rendered games (be it CPU, on-cart co-processor, Sega CD CPU+blitter, etc):
Aside from trying to do a full shadowed layer/window (which would use double the VRAM), you could apply it when needed on a tile by tile basis (but that would still use double the VRAM for every tile it was used on), but there could also be the possibility of using a set number of patterns in VRAM used for shading. (various shapes and edges as well as full cells and perhaps dithered patterns in addition to that -the more patterns used, the more VRAM space you'd monopolize, of course -and you could also update the pattern sets periodically)
The same could be done with plain dithered patterns used for overlay (be it sprites or tiles), but that's a bit uglier and in NTSC H40 (320 wide) you risk rainbow color artifacts with most video encoders. (unless you're very careful about not using high luma contrast in dithered pixel pairs)

That use of character patterns is what Zyrinx used for the pseudo-rotation effect in Red Zone and it's also somewhat akin to semigraphics characters in some old computers. (but those were used as the primary graphics rather than overlay)
Rebel Assault on the Genesis also makes limited use of dithered meshes to simulate transparency for sheilds. (such dithered meshes could be also used to brighten rather than shading only darker, but the use would vary)


In the specific context of FMV that could be really useful in general if you had custom compression schemes catering to use of such overlayed patterns (dithering and shadow based) and if conservative enough, wouldn't kill VRAM either. (with only solid dithered/shadow applied 8x8 tiles it would use VERY little VRAM space even if you used several different dithering patterns and shades/colors, but you'd use more space with additional tile patterns -ie diagonal halves, rounded halves, vertically split or horizontally split halves, large checkerboard patterns, different dithered patterns, etc)
In particular: opposed to pre-assembling every frame on the Sega CD side with 2 tile layers and/or shadow and doubling DMA bandwidth/time as well as VRAM space (especially double buffered), but with a single layer/window being updated and then simply modifying the overlaying tilemap, that keeps the transfer rate about the same as a single 16 color layer. (slightly more if you're dynamically updating the overlay pattern set)

One of the first things that got me thinking on this was in the context of how H.261 uses separate chroma and luma encoding: so for FMV, I was thinking in terms of using one primary video window/layer optimized with 16 colors per tile and acting more or less as the chroma layer using 16 distinct color values at similar intensities and then using shadow and/or dithered patterns on a tile by tile basis to provide additional shading...
except that wouldn't necessarily work that well as it would be the opposite of what H.261 does with high resolution luma and low resolution color: and you *could* try to do a B/W layer (using warm and cool shades of gray) and then a lower resolution color overlay, but that would use a lot more distinct tiles to try to get a color layer like that. (maybe not even saving any VRAM space or bandwidth unless you were really careful) The latter would still be an interesting possibility, but likely not really useful unless you really sacrificed a lot of VRAM. (it might make for a decent basis for a compression scheme working within the VDP display limitations, but it would definitely be limited and you'd get to a point where it would be a lot more useful to simply use full paired layers with 31 colors per tile -using 2 overlaid tile and 2 palettes or full shadow --so perhaps used only for cutscenes with nothing but the video window and a black boarder with probably a lotof letterboxing for added DMA time)

In the simplest sense of not using much more VRAM or bandwidth (if any at all), you could simply apply shadow on a tile by tile basis, but rather than using a full shadowed pair with 31 colors per tile, you could make it an all or nothing thing with a solid overlay pattern (so only 1 8x8 tile to store in VRAM) fully shadowed and apply that to enable a "second" palette set: so still only allowing 15/16 unique colors used per tile, but doubling (if you were careful) the effective number of palettes available. (ie the 4 standard palettes and then 4 additional shadowed palettes)

And then there's also use of flicker (taking advantage of both persistence of vision and higher persistence phosphors on TVs) though that works better in 60 Hz than 50 Hz to to sheer speed, but would still have some utility in either case.
If nothing else you could use it as a pseudo shading feature flickering between the video image tile and a solid color/shaded tile on a tile by tile basis. (possibly in addition to shadow)

And you could probably have a combination of several of those techniques, but that eventually gets a bit convoluted and also probably turns into a mess for actual decoding of such a compression scheme. (especially if you're talking just the resource available on the MCD and not an added DSP etc... or the 32x decoding video to display on the genesis VDP )