| Home | Forums | What's new | Resources | |
| Fading and variable translucency |
| Omni - Jun 15, 2007 |
| Omni | Jun 15, 2007 | ||
| I'll go ahead and answer one question: I found the parts about the blending ratio for VDP2 layers near page 187-188 of the SDL tutorial document. | |||
| Omni | Jun 17, 2007 | |||
| I'll glance at chap. 9, thanks. Didn't Traveller's Tales use some hacky VDP1-2 voodoo for the transparent textures in Sonic R? I was under the impression that when it came time to render a transparent poly in the Z-order, everything was copied to the VDP2 framebuffer, the polygon was drawn with VDP1, then combined back with the rest of the data using VDP2, and then normal drawing continued (thus allowing all of the VDP1's translucency options to go toward a single poly without affecting the others). That's a really layman description though -- I personally don't know the technical details of how that was done. 32 levels of translucency? That's an odd set. Can the "transparency ratio register" be set individually for any sprite object, or just on VDP1 drawing as a whole? [even though of course the mixing is between that sprite and the VDP2 framebuffer ONLY] | ||||
| antime | Jun 17, 2007 | ||||||
My understanding is that you can use them to control sprite color calculation based on the priority bits (because there's obviously too few ways otherwise). You put the level in SPCCN0-2 and then the condition (less than, equals, greater than or MSB) in SPCCCS0-1.
Sprite transparency is calculated per pixel based on a number of conditions, so the only thing needed is to set up the track sprite pixels to blend with a background layer that is below another background layer. IIRC they used the transparency effect to fade in scenery in some other tracks. | |||||||
| rorirub | Jun 20, 2007 | ||
| Are you guys absolutely sure that its impossible to do sprite-on-sprite transparency? I recall many software which used some degree of transparency without background interaction - heck, even the BIOS does this (the two circling specs which highlight the cd player icons, their trails are transparent). | |||
| antime | Jun 20, 2007 | ||
| VDP1 can blend sprites using half-transparency as mentioned in the original post, but there are no other blend modes or ways to control blend rates. | |||
| Omni | Jun 21, 2007 | ||
| So, summary. Correct me if wrong on any point. 1. VDP1 can draw sprites with sprite-aware translucency only in half-transparent mode. This mode is glitched due to unusual rasterization methods in the Saturn. (There's also mesh mode, of course, which isn't real lucency and a little rough, but it has uses). 2. VDP2 can combine VDP1 drawing with its own framebuffer at 32 degrees of variable translucency, but only with VDP1 drawing as a whole -- not on a per-primitive basis, and all blending is done directly between the entire VDP1 layer and any underlying VDP2 backgrounds, so it can't be used for primitive-primitive transparency. 3. VDP2 can combine 2 (or optionally 3) VDP2 background layers with 32 degrees of transparency. 4. Color offset allows you to blend the final screen toward a particular color, thus enabling fading. And I suppose that's it then. | |||
| antime | Jun 21, 2007 | |||
VDP2 has eight sprite blend setting registers, which are chosen from the CC bits in the VDP1 frame buffer data. The data format setting in the VDP2 sprite control register determines how many CC bits there are, and you can set them and the priority bits via the color bank setting in the VDP1 sprite draw command. Unfortunately all RGB-mode sprites (which are the only ones really usable with half-transparency) always share the same blend setting register. You should be able to select blend register for each sprite pixel by including the colorbank and priority bits into the sprite data and drawing it into the framebuffer as an RGB mode sprite and then setting the VDP2 sprite control register to treat all pixels as palettized. | ||||