Sega Saturn al límit (IV)

Great article, you’re ready to write a thesis about Sega Saturn !

I have a few observations :
– VDP1 half transparency is not doing anything weird in term of blending : it is exactly alpha blending two RBG 555 colors with an alpha of 0.5 (which can indeed be computed with a shift, a classic optimization) over an opaque background. The fact that it operates on RGB 555 colors makes it less precise than what VDP2 can do with its RGB 888 colors calculation. And the shift means that the multiplication by 0.5, or division by 2, always rounds down which ends up slightly darkening resulting colors.
– VDP1 shadow is exactly the same result than half transparency using a black texture. VDP1 Shadow is useful because you don’t have to actually provide a black texture, it automatically uses a black texture pixel for of any opaque texture pixel, whatever its actual color. Another key difference of VDP1 shadow is that it doesn’t modify palette framebuffer pixels, contrary to half transparency which would overwrite them with black. This makes it possible to combine a normal shadow written before everything else and a VDP1 shadow to draw a complete shadow over an area composed of RGB sprite pixels and VDP2 background.
– “So when adding a dark value in the source pixel over a light value over a destination pixel, the resulting color will be even lighter.” : this is only the case for additive blending formulas where the ratio of the destination pixel is 1.
– VDP1 mesh can have several layers of mix if combined with half transparency. But doing so cancels the performance advantage of mesh, and displays the potential redraw artifacts of half transparency.
– VDP1 mesh looks much closer to half transparency when the sprites are in horizontal high res.
– “I will try to give some examples with possible default values similar to those of the Gouraud” : I disagree with you on that, VDP1 half transparency calculation has nothing to do with VDP1 Gouraud calculation. As I said, VDP1 half transparency lacks precision due to a full RGB 555 process and tends to darken due to the rounding down of the shift operation.
– “Most likely, in the case of the VDP1 in SS, the Color Calculation is done first and then the Gouraud” : it’s the reverse. When both effects are cumulated, Gouraud is calculated first, then half transparency.
– “In general VDP1 cannot read the CRAM at runtime of its pipeline.” : VDP1 has never access to VDP2 CRAM. When it does color calculation over palette textures, it operates on color indices that refer to CRAM adresses, not on the actual colors contained by CRAM at those adresses.
– “if we also want to take advantage of VDP2 for those written in VDP1, we have the limitation that if we start from a texture with CRAM data, if they are processed in VDP1 in color calculation processes, they remain in the Framebuffer as RGB” : resulting framebuffer pixels drawn by VDP1 color calculation over a palette texture are of palette type. This includes RGB framebuffer pixels modified by VDP1 half transparency, their type switches to palette, as shown by paul_met’s mod of SOTN dialog box.
– “if “Color bank / CRAM VDP2” is used, it will only work with the primitive Polygon even next to the CC VDP1 Gouraud (which theoretically could not be done either). How does the VDP1 read the color or colors at this time from the pipeline?” : like I said, VDP1 never reads colors from VDP2 CRAM, it doesn’t know about it. In the Destruction derby screenshot, the color mode “4BPP(16 color bank)” is meaningless for a polygon command. The hexadecimal color “415A8” is actually an RGB color : due to a bug of Yabause/Yaba Shanshiro, it has to be shifted by 3 to the right to get the actual 16BPP color, whose MSB is set to 1 indicating an RGB color.
– “It is true that the second “blend” of ECC adds extra limitations(…) the number of colors in the palette on the sprite screen is halved, from 2,048 to 1,024 colors if we use the color and priority calculation function. And if we only use it in its MSB mode, this RGB being from 32,768 to 16,384 colors, theoretically.” : the number of VDP2 CRAM colors have to be halved to be mixed by ECC because CRAM must be mirrored (mode 0) to double its throughput. RGB pixels are unaffected by ECC limitations because VDP2 doesn’t need to access CRAM to get their RGB data. So sprites RGB pixels still have 32,768 possible colors.
– “We ended up talking about the “as is” mode.(…) I don’t know if this can also be used in the ECC, in a second layer, but I would say not because of the fixed nature of the ECC mode.” : correct, ECC always uses blending formulas with ratios.
– “In 8BPP mode the maximum will be 6 bits and the minimum 7 bits to define the color.” : it’s actually between 6 and 8 bits for the color, when using 8 bits, one or two color bits are shared with priority or CC.
– “Shadow MSB(…) Main problem, it can only be used in 8BPP mode.” : MSB shadow is limited to 16BPP framebuffer.
– “We would have to add one last limitation to the shadow function in VDP2.(…) if before applying the effect on the pixels marked as shadow, the VDP2 has to apply Color Calculations, it will cancel the possibility of interpreting this data. However if the color calculations are done after the shadow calculation, it will work.” : shadow is always applied after CC (it’s the last step of VDP2 rendering pipeline). The limitation is that it can only be processed if the sprite pixel has the top priority. So if the sprite pixel is visible through a semi-transparent layer which has a higher priority, no shadow is performed.
– “Limitations Offset Color Calculation(…) when the Color Screen per Line is being used inserted in some Screen / Screen. It seems that this is affected less and not in the same way as the rest of the data by the color change of the function.” : this is an old Yabause bug corrected recently in Kronos, see https://github.com/FCare/Kronos/issues/690
– Color offset can be varied for each line by changing VDP2 registers during display, for example the white haze at the title screen of Albert odyssey.
– Nights has a nice window effect on the vortex when Nights loops. The vortex graphics has every other column transparent to make it look semi transparent.

6 comments

Pingback: Sega Saturn to the limit (I) | David Gámiz Jiménez | Portfolio and Personal Site
Pingback: Sega Saturn to the limit (V) | David Gámiz Jiménez | Portfolio and Personal Site
Pingback: Sega Saturn to the limit (III) | David Gámiz Jiménez | Portfolio and Personal Site
Pingback: Sega Saturn to the limit (II) | David Gámiz Jiménez | Portfolio and Personal Site
Fafling says:

02 de juliol 2020 at 01:07 01Thu, 02 Jul 2020 01:07:11 +000011.

Great article, you’re ready to write a thesis about Sega Saturn !

I have a few observations :
– VDP1 half transparency is not doing anything weird in term of blending : it is exactly alpha blending two RBG 555 colors with an alpha of 0.5 (which can indeed be computed with a shift, a classic optimization) over an opaque background. The fact that it operates on RGB 555 colors makes it less precise than what VDP2 can do with its RGB 888 colors calculation. And the shift means that the multiplication by 0.5, or division by 2, always rounds down which ends up slightly darkening resulting colors.
– VDP1 shadow is exactly the same result than half transparency using a black texture. VDP1 Shadow is useful because you don’t have to actually provide a black texture, it automatically uses a black texture pixel for of any opaque texture pixel, whatever its actual color. Another key difference of VDP1 shadow is that it doesn’t modify palette framebuffer pixels, contrary to half transparency which would overwrite them with black. This makes it possible to combine a normal shadow written before everything else and a VDP1 shadow to draw a complete shadow over an area composed of RGB sprite pixels and VDP2 background.
– “So when adding a dark value in the source pixel over a light value over a destination pixel, the resulting color will be even lighter.” : this is only the case for additive blending formulas where the ratio of the destination pixel is 1.
– VDP1 mesh can have several layers of mix if combined with half transparency. But doing so cancels the performance advantage of mesh, and displays the potential redraw artifacts of half transparency.
– VDP1 mesh looks much closer to half transparency when the sprites are in horizontal high res.
– “I will try to give some examples with possible default values similar to those of the Gouraud” : I disagree with you on that, VDP1 half transparency calculation has nothing to do with VDP1 Gouraud calculation. As I said, VDP1 half transparency lacks precision due to a full RGB 555 process and tends to darken due to the rounding down of the shift operation.
– “Most likely, in the case of the VDP1 in SS, the Color Calculation is done first and then the Gouraud” : it’s the reverse. When both effects are cumulated, Gouraud is calculated first, then half transparency.
– “In general VDP1 cannot read the CRAM at runtime of its pipeline.” : VDP1 has never access to VDP2 CRAM. When it does color calculation over palette textures, it operates on color indices that refer to CRAM adresses, not on the actual colors contained by CRAM at those adresses.
– “if we also want to take advantage of VDP2 for those written in VDP1, we have the limitation that if we start from a texture with CRAM data, if they are processed in VDP1 in color calculation processes, they remain in the Framebuffer as RGB” : resulting framebuffer pixels drawn by VDP1 color calculation over a palette texture are of palette type. This includes RGB framebuffer pixels modified by VDP1 half transparency, their type switches to palette, as shown by paul_met’s mod of SOTN dialog box.
– “if “Color bank / CRAM VDP2” is used, it will only work with the primitive Polygon even next to the CC VDP1 Gouraud (which theoretically could not be done either). How does the VDP1 read the color or colors at this time from the pipeline?” : like I said, VDP1 never reads colors from VDP2 CRAM, it doesn’t know about it. In the Destruction derby screenshot, the color mode “4BPP(16 color bank)” is meaningless for a polygon command. The hexadecimal color “415A8” is actually an RGB color : due to a bug of Yabause/Yaba Shanshiro, it has to be shifted by 3 to the right to get the actual 16BPP color, whose MSB is set to 1 indicating an RGB color.
– “It is true that the second “blend” of ECC adds extra limitations(…) the number of colors in the palette on the sprite screen is halved, from 2,048 to 1,024 colors if we use the color and priority calculation function. And if we only use it in its MSB mode, this RGB being from 32,768 to 16,384 colors, theoretically.” : the number of VDP2 CRAM colors have to be halved to be mixed by ECC because CRAM must be mirrored (mode 0) to double its throughput. RGB pixels are unaffected by ECC limitations because VDP2 doesn’t need to access CRAM to get their RGB data. So sprites RGB pixels still have 32,768 possible colors.
– “We ended up talking about the “as is” mode.(…) I don’t know if this can also be used in the ECC, in a second layer, but I would say not because of the fixed nature of the ECC mode.” : correct, ECC always uses blending formulas with ratios.
– “In 8BPP mode the maximum will be 6 bits and the minimum 7 bits to define the color.” : it’s actually between 6 and 8 bits for the color, when using 8 bits, one or two color bits are shared with priority or CC.
– “Shadow MSB(…) Main problem, it can only be used in 8BPP mode.” : MSB shadow is limited to 16BPP framebuffer.
– “We would have to add one last limitation to the shadow function in VDP2.(…) if before applying the effect on the pixels marked as shadow, the VDP2 has to apply Color Calculations, it will cancel the possibility of interpreting this data. However if the color calculations are done after the shadow calculation, it will work.” : shadow is always applied after CC (it’s the last step of VDP2 rendering pipeline). The limitation is that it can only be processed if the sprite pixel has the top priority. So if the sprite pixel is visible through a semi-transparent layer which has a higher priority, no shadow is performed.
– “Limitations Offset Color Calculation(…) when the Color Screen per Line is being used inserted in some Screen / Screen. It seems that this is affected less and not in the same way as the rest of the data by the color change of the function.” : this is an old Yabause bug corrected recently in Kronos, see https://github.com/FCare/Kronos/issues/690
– Color offset can be varied for each line by changing VDP2 registers during display, for example the white haze at the title screen of Albert odyssey.
– Nights has a nice window effect on the vortex when Nights loops. The vortex graphics has every other column transparent to make it look semi transparent.

Fafling says:

02 de juliol 2020 at 13:23 01Thu, 02 Jul 2020 13:23:38 +000038.

Correction about the color offset bug : it was only in Kronos from version 1.7.0, and was corrected in v2.1.1.

6 comments

Leave a Reply Cancel reply