Sega Saturn to the limit (IV)

First draft translation. Apologies for the mistakes. I will improve the text in future revisions.

Very, very, long entry warning. In this post I have used a lot of information, complex and in some ways imprecise. It is possible that I have made errors of interpretation or understanding. I will try to correct everything that arises.

In this spreadsheet you have the data that I have collected from 323 games. Of the approx. 1200 titles in total. Which are 20% approx. of the total.

Index:

5. The most complicated thing: Transparencies and / or Half-Transparencies

The myth par excellence in SS, can or cannot it make transparencies by hardware like the PS1? The answer as in everything, in the official documentation.

And speaking of the official documentation. Without underestimating the immense work behind it. Watch out! Both the VDP1 and VDP2 documents are full of grammatical mistakes and errors. If the VDPs are already complex, some more complex features are more difficult to understand due to these problems in the official documentation

Let’s continue, but first let’s take a look at the competition in this feature.

Transparencies in the competition

Before starting the analysis of the state of the art and the competition, I have prepared this comparative table between technologies of different contemporary machines in development, launch and life time.

Legend: A = Foreground / Origin; B = Background / Destination

Atari Jaguar

The GPU of the Atari Jaguar was fully programmable. It could do anything, theoretically even real alpha. If you can handle alpha-channel colour spaces, which I don’t know, in theory if you handle 32bit words and their processors are, you should be able to process ARGB5555 or ARGB8888 for example.

I have seen several games that do this. In 3D only Club Drive in the windows. 2D in various games. Light and shadow effects. But the result, on my understanding, is even slower than 3DO, SS or PSX. Perhaps this is why little or nothing was used in 3D.

Jaguar will not have problems for the effect or the way of rasterizing or the frame buffer, which is also unique.

3DO

The 3DO has the Mode-P that it is a fully programmable mode or feature, which requires either a 16bit uncoded or 6bit coded mode. ARGB1555 and the second a combination of MSB + unused + 9 + unused + 5.

The Mode-P is also configured analogously to PS1 and SS with the MSB, bit 15.

The Mode-P is very powerful in its modulation or pre-mix stage (it is similar to VDP2), being able to choose up to 7 ratio values of transparency in the upper and/or lower layer. But in some aspects superior being able to select the origin (primitive / framebuffer), destination (zero / constant value (0 … 32) / framebuffer / primitive) or pre-mix modes and combine them. Also even superior to the PSX GPU for all the possibilities that it offers. But on the contrary it is very slow. The Brightness/Intensity multiplicative premix can be used to obtain the ratios per pixel, theoretically up to 32 levels since it is ARGB1555. Or the division for shadow effects.

In the mixing stage and simplifying there are 3 great modes A + B, AB and A [XOR] B plus these optionally dividing by 2. What they would do 6. Not counting that the values A and B can be inverted, as in the VDP2. Actually many more for the possible combinations.

In addition 3DO shares with SS that its primitives are “quads” or distorted sprites. But 3DO does it in a completely different way. More complex and slow on the one hand. But more precise on the other. I explain. The GPU of the 3DO rasterizes in 3 steps. The first one draws the element in space ordered by depth and in the same way as the VDP1 of the SS and PSX GPU. Then he projects it and finally applies the effects. So when you draw a distorted sprite finally in the projection that is drawn line by line in horizontal (like the PS1) the pixel redrawing problem that does appear in SS disappears. Or that should be in theory because in the course of this investigation I stumbled upon this:

As you can see, they are redrawing errors in the shade. It is the Samurai Shodown of 3DO, when the zoom is far away this problem arises. I find it curious, perhaps in some scenarios the 3DO solution also generated problems similar to SS.

Returning to the comparison, SS does everything in 2 steps, like the PS1. It is faster, but less accurate as we say in part, despite the problem I have seen in Samurai Shodown. Not to mention that the 3DO has a final and unique buffer. Which allows you to mix everything like the PS1 or the Jaguar.

Finally, although I know a little off topic, I think that 3DO despite not having Gouraud for hardware, could be simulated with a small part by software and the rest with a colour maths engine. It would be expensive, like transparency. But it would be possible because of how powerful it is.

PS1

It can make four kinds of mix 1 * A + 1 * B, 0.5 * A + 0.5 * B, 0.25 * A + 1 * B and 1 * A-1 * B. And these values added to the Brightness / Intensity can obtain a blend such as “as is” or the calculation function Normal or first blend of the Extended of the VDP2. It is valid for any type of ARGB1555 colour configuration. In PS1 the values A and B cannot be inverted, they are fixed, as in the case of the VDP1 of the SS.

In some aspects the PS1 GPU partially works similarly to the VDP1 / VDP2 playing around with the MSB value to activate advanced color calculation modes. In the case of PS1 the MSB is its STP and it is the equivalent in the VDP1 SDP, but it is a separate record, which in both serves to say whether or not the primitive has a color mask (pure black on both consoles) . With the combination of STP plus a function / register called SetSemiTrans (), half-Transparency modes are obtained on PS1.PS1 in its modulation or pre-mix stage processes transparency only multiplicatively at 16BPP (ARGB1555) and with an additive final mix with 32 effective brightness ratios to be used. PS1 rasterizes by horizontal line in 2 steps so when you apply its transparency algorithm it doesn’t have any redraw problem, in principle. If the elements are not well aligned at the vertices, for example GTE precision error. There may be redrawn at the ends. But little compared to SS.Finally, as I have already mentioned PS1 has a single buffer, so you will have no problem mixing it all up. With a use penalty between 2 and 3 times more than an opaque pixel.

Alpha Blending REAL? NO

But before continuing I want to expand on clarifying first of all. What is “Alpha blending”? Because not even I had been really clear during all this time.

This effect that is so striking and so spectacular has always been for me and everyone.

The mathematical principle was established in 1984 by engineers Thomas Porter and Tom Duff from Lucasfilm at SIGGRAPH’84.

Legend: src = Origin; dst = Destination; out = Result; A = alpha 0≤alpha≤1; RGB = Color value per pixel and channel

General formula for Alpha blending Real:

Formula for Alpha blending Real when the background is opaque:

Formula for Alpha Blending Real premultiplied:

Formula for Alpha Blending Real premultiplied when the background is opaque:

Arrived at this point to make clear that no machine with hardware transparency implementation at that time towards real alpha transparency. Well, they did not handle color formats with alpha RGBα channel. They handle ARGB1555 color spaces for 3D with a kind of “premultiplied alpha” or “chroma key”.

Alpha Blending on these machines.

The Alpha Blending in these machines is processed in two stages: alpha modulation ratios and the final color or mixed Math.

Modulation by alpha ratios

We can say that both 3DO, PS1 and VDP1 / VDP2 did Alpha blending with fixed alpha ratios. Which allowed them to do half-Transparencies directly without additional information on the colors of the textures or on the flat polygons.

With additional information we mean interpreting the maximum brightness values in each pixel, in order to preassign an alpha value in each of these pixels. These “premultiplied” pixels with darker intensities that act as degrees of transparency. Giving that smooth finish at the ends of the gradients where the color fades.

These will be “interpreted” after the first stage, which is modulation. This will add or remove% transparency on the entire primitive. Perhaps the 3DO or the Jaguar can do it even at the pixel level. But both the PS1 and the VDP2 of the SS do it over the entire layer or primitive.

The modulation stage normally and according to the known alpha blending formula is multiplicative. We are going to multiply values between 0.0 and 1.0.

In the case of 3DO multiplication and division are available. In the case of the PS1 alone the multiplication.

And in the case of the SS in its VDP1 it is a kind of “division” and in the VDP2 of multiplication on the one hand and also a kind of “division” on the other. I put “division” because in these cases what the hardware does is make a “shift” or “offsets” of the values in the negative direction, used in the shadow functions.

It is still curious how SEGA implements a technology for the Shadow effect that seems to have been used since 1986. And even on Mega Drive. But do not implement the effect highlight that was also used at this time in 1989 in the VDP1 to achieve a blend with more luminosity.

As regards the alpha values, we could say, in conclusion, that the alpha values for “the origin” and “the destination” in the cases of 3DO, PS1 and SS VDP1 are fixed values. And in the case of 3DO, PS1 and VDP2 added to the “interpreted” of the brightness / value of the pixels / pattern / pattern origin.

Up to 7+ ”2” are available for fixed alphas in the 3DO, up to 4+ “2” values for the PS1 and only 1+ ”2” for the SS in the VDP1. Taking into account as fixed alphas the possible 1bit “mask” values available on all systems: off or on.

On the other hand, in the case of the SS, up to 32+ ”2” fixed values can be assigned in your VDP2. We could say that VDP2 Screens will always have a kind of “5bit alpha channel”. And in addition to applying the full formula for two elements, the VDP2 can blend up to two layers with “alpha” values against an opaque third. What three elements do. It can even mix 4, but it’s somewhat special and limited, not comparable to a general case.

In the case of the values interpreted in the 3DO it should be able to reach 32, in the case of the PS1 also 32 values. While in the case of the SS up to 2 in the VDP1. In the VDP2 up to 32 if it processes it internally and with up to 8 simultaneous ones out of a total of 32 available if it is done in conjunction with the VDP1.

As we can see, no machine does real Alpha blending. The one that most approximates it is the VDP2 with its 32 configurable fixed ratios plus the ability to interpret the brightness in the pixels.

The final mix or Color Math

Normally and most used is the additive / addition. Which leads us to the doubt of the previous point, how did they manage to interpret or mix these darker or “pre-multiplied” parts smoothly? Perhaps the 3DO can interpret the extra data per pixel with one of its modes. But both the PS1 and the VDP2 of the SS do it in a simple way. In the final mixing stage, after modulation, with its additive mixing modes. 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. Black remains hidden and gives fruit to a new mixed color.

On the other hand, both 3DO and PS1 had some other way.

In the case of PS1, it also had the “subtractive”. Which used to precisely be able to make mixtures with dark values of origin: shadows, smoke … etc.

And in the case of the 3DO it also had subtractive and a mode with a logical condition (a kind of mask or window mode). Plus all of these above divided by 2.

The case of VDP1 is special. It is not a pure additive mixture. It makes “shift” or “offsets”, adding or subtracting values, with certain exceptions. This is not fully documented. But seeing how Gouraud works in VDP1, explained more in detail in the documentation. Or how other modes of color calculations work in the VDP1. And after giving it many laps, I have come to this conclusion. The key is that the VDP1 when mixing dark or black colors does not blend these source values with the destination as assumed in an additive sum. Black prevails and shouldn’t. Even with a pattern with a black shape, the result is almost the same as Shadow mode. The result is that the source and destination colors are mixed preserving part of their base color and if they have black this also remains. Another genius of the domestic SEGA R&D team in Japan? Or another mistake. What is clear is that the operation is not intuitive as an Artist can expect. I say this in the first person. XD

On the other hand, the VDP2 only has additive mix in the final mix.

We could also say that the VDP1 and VDP2 have a mix with logical condition like 3DO but not at the same level of detail.

Types of blend or mixed

In the world of “blend” or mixed. Or also called color mathematics. There are various formulas to obtain varied mixing results between the “origin” and “destination” operands. Being some commutative or non-commutative operations. Although the best known and most common, which serves as the basis for everything is Alpha blending.

I am going to give as an example those used in programs like Photoshop / Gimp / PaintShopPro or similar, with modes that are most similar to the results that we obtain in these machines in their mixing effects. These mixing formulas the group together by mixing result depending on how white or black as “alpha” to transparency or opacity is interpreted:

White is “alpha” or disappears:

Multiplicative [commutative]→ Destination x OriginBlack is ” alpha ”or disappears:

Screen / Inverse Multiplicative [Commutative]→ 1 – (1 – Destination) x (1 – Origin)

Linear Clearance (Additive) [Commutative]→ Destination + Origin

NOTE: In these formulas we usually use scale values of 1. Using the hue value of the base color.

In this case all the formulas are Commutative. But there are others that do not. For example the formula actual alpha blending is not commutative.

As we can see there is quite a bit of confusion with terms and results. Since there are many patents, and ways to do it.

Final results of “Alpha Blending” of these machines

Depending on the capabilities of the machine, different effects could be achieved:

A) The additive Mixing together with a multiplicative modulation allowed for effects Rinse or Light: flashes, sparks, rays, blood, water, crystals , lighting, fire, clouds, fog, rain … etc. This can be similar to an Alpha Blending Additive from the 1996 GPUs.

B) And the Additive Blend together with a divisive modulation of Shadow or Darkening: shadows, smoke … etc. This may be similar to a Multiplicative Alpha Blending of the 1996 GPUs.

C) The subtractive Blend: Special effects such as shadow or

D) The Mix logical condition: Masks, “Chroma key” or limitation of application of effects.

Jaguar in theory could make any type of blend imaginable: lights, shadows, inversions, lightens, burns …

3DO could achieve perfect light and shadow effects. And other extras even better than PS1 but without the possibility for gradients due to the lack of Gouraud and nor the quality of the same as they also have no dithering. Thanks to the multitude of options available in your color pipeline.

SS could get correct light and shadow effects. The shadow ones with both VDPs. Of lights mainly and with better results with the VDP2. You can add the Gouraud in both VDP2 to get gradients or color changes, but without reaching the quality of PS1.

PS1 could achieve perfect light effects, and correct shadows. And some extra effect. With excellent animated gradients thanks to its Gouraud plus dithering.

Conclusion Alpha Blending of the time

The hardware implementation with options, quality and performance of “Alpha blending” on consoles at the time was not bad.

First the Jaguar in 1993, which went to its roll with full support via software on programmable hardware, with infinite possibilities, but ultimately very poor performance.

That of 3DO, especially and in 1993, for its earliness in a hardware implementation, with high quality and many options, but with poor performance.

Support in SS as early as 1994 was erratic, like the general trend in the system. In VDP1 showing good intentions but poorly executed. And in the VDP2, along with the shared mode with VDP1, it was a remarkable implementation of “its alpha mode” with many options, fair quality and extremely fast.

While PS1 also in 1994 has just enough options but with very optimal performance for the time.

Disregarding the option of Alpha blending by software on PC, until 1995 Alpha Blending modes were not seen in any 3D graphics accelerator. And these were just basic enough, with poor quality and very slow. It was not until the arrival in 1996 of the 3Dfx Voodoo, when we could see a real and complete full support of Alpha blending:

*Legend similarity implementation* hardware on consoles 1993-4 against 3dfx Voodoo 1 1996, I do not include the Jaguar because “literally ”not have the features implemented in hardware with registers like these: Does 1 SS VDP1 * Not exactly additive looks like in part* * 2 SS VDP2 * The one that most closely resembles the Alpha Blending REAL * 3 Can do by combining the VDP1 + VDP2 * 4 Needs Gouraud shading or the like for color change on palettes * 5 No machine does Multiplication Blend. But through “a division” something similar can be achieved.
PC 3DFX 1996 Features	% of similarity 1993-4 Consoles
	3DO	*SS VDP1 1**	*SS VDP2 2**	PS1
Alpha Blending	50%	20%	90%	50%
Addivitive Alpha Blending	90%	20%	90%	90%
Multiplicative Alpha Blending *5	20%	20%	20%	20%
Vertex Alpha Blending *4	0%	0%	50% 3*	50%
Texture Alpha Blending	50%	20%	50% 3*	50%
Vertex And Texture Alpha Blending *4	0%	0%	50% 3*	50%
Decal-Alpha Texture Blending	60%	30%	50% 3*	50%
Factor Alpha Blending	60%	20%	90% 3*	50%
Modulate Texture Blending	70%	20%	90% 3*	50%
Modulate-Alpha Texture Blending	70%	20%	90% 3*	50%

The transparencies of the SS

Before starting with the SS in detail, I have prepared this small table with the data collected from%

Mesh

To clarify before continuing. We could interpret the use of the mesh mode as possible “transparency” in the SS or “pseudo half-Transparency”.

To achieve this “transparency”, the refreshment or interlacing of composite video systems for CRT tubes was used. Which made it invalid for RGB / SCART outputs / TV.

In these companion catches panzeroust in the elotrolado.net forum we can see what it looks like on a real CRT TV. On the left with RCA cable and on the right with RGB cable.

The mesh effect can be done by hardware on the VDP1. Or in a pre-drawn plot or by drawn software in both VDPs.

In the case of VDP1, it is a quick process-level way to perform a “half-Transparency” by hardware. A great advantage is that it will “work” between VDP1 and VDP2 without problem.

Given the latter, we find in most conversions from other systems. That developers used mesh mode to replace half-Transparencies. Well, with a function the same as in the other systems, they had “something transparent and that worked as expected” and also without any performance penalty.

% Games with Mesh

We are talking that 53% of the total number of games analyzed use this effect.

We will now see the use by Exclusives on the total number of games analyzed.

games Exclusive 1st party are approximately 22% of the total number of games analyzed. Of these, 63% of 1st party games use mesh.

The games exclusive 2nd party represent approximately 8% of the total analyzed, of which used the mesh 11%.

games Exclusive 3rd party are approximately 42% of the total analyzed. And we see that was mesh used in 14% of them.

Something that draws a lot of attention of the% of use in the exclusives, are the games 1st parties. Since they have the highest value by far. I have a theory after watching SEGA games and their progression even in Arcade. My theory is that in the AMx departments there was no interest in this type of effects. They did not use them or attempt to implement them in their Arcade technology that was contemporary to SS. And surely, this was added in SS because the competition had something similar: SNES, 3DO … and what they came to know about the PS1. Even with the SS released, they didn’t try to use it in any of their games.

To give an example that caught my attention, it took almost 2 years to use the Gouraud in their games. When other 2nd parties or 3st parties used it even earlier. But it is that in their Arcade: Virtua Racing, Virtua Fighter, Daytona USA or Virtua Fighter 2, they did not use it either because they did not even implement it in hardware. Which was normal, because his competition in Arcade was super far and even more on the subject of transparencies. As I say at the SEGA technology level, he took several paths, and he was a bit lost between his recent present and the imminent and fast future in which they were in 3D.

Now let’s analyze cases of PSX ports. These represent 24% of the total, of which 63% are using mesh.

The PSX Ports of Psygnosis are 2% of the total analyzed, where 50% used mesh.

While PSX Ports EA’smean 5%. Of which 73% used mesh instead of SS transparencies.

Here in the PSX ports we have more important data, just like in the 1st party games here the percentages are that more than half of the total of the games used mesh. Further demonstrating the causes of the effect or belief that the SS “could not” make transparency.

Mesh limitations

The effect mesh of the VDP1 is practically free for the system. But it has a catch. If there is another item with Mesh of the VDP1 below it will not be seen. It only allows one layer of “mix”.

If it is pre-drawn or by software, it is possible to get “something more” to overlap. But it wouldn’t be perfect either, because depending on how they would either cancel or there would be a lot of flickering. In addition there is the fact that pre-drawn implies wasting space in VRAM or by software process consumption and RAM, minimum but consumption.

Mesh Conclusions

As we can see and conclude the vast majority of titles and almost all of the best known used Mesh. Numerically, now, it is completely understandable to understand why the false idea that “SS could not make transparencies” was so strong. Because in fact in his games it was evident. Nothing is further from reality as we will see, unfortunately.

VDP1

In this case and starting with the VDP1 drive which was the equivalent of the PS1 GPU. And we find these two modes of the function for color calculation in the VDP1:

Shadow: The pixels of the framebuffer that are covered by the primitive will be rewritten with 1/2 of the brightness, the information of the primitive [pattern or texture] is not will draw or take into account.

half-Transparency: The pixels above and below the framebuffer will be averaged together.

half-Transparency + Gouraud The half-Transparency process is done and sooner or later (I am not 100% clear although the result will be the same) the Gouraud calculation is made.

Why do I include Shadow?

It is simple, a typical effect from 2D games is the shadow of the characters. The first transparencies that I remember, in arcade games or on the SNES or the MegaDrive itself, I saw in those kinds of things. They were usually done with some “transparency” effect. Either with palette changes or with effects shadow / highlight from MegaDrive / MasterSystem / GameGear or the layer of transparency that had the SNES or the effect of transparent Shadows that had the plates Arcade System 16/32 of SEGA. The latter is the one most similar to what SS has implemented in both VDP1 and VDP2 for the effect of Transparent Shadow.

As a curiosity to add, that Arcades of the competition in 1991 also had solutions for “transparencies”. Konami at Xerxes and Data East at Desert Assault. Also very close in 1992 the Taito-F3 board with a solution similar to the VDP2.

As we can see, the “Transparencies” of the VDP1 are described as half-Transparencies, since the ones supported by hardware were 50% fixed transparencies that could not be graduated with greater or lesser intensity by hardware. Although they have the possibility of unlimited mixing as on the PS1. The exact type of blend is the additive, a sum of the pixel value of the background with the pixel above it, this sum divided by 2, that is, a FIXED half-Transparency of 50%. Being this way, in some colors there will come a time when the addition and division result after x layers mixed in the original “opaque” color, and there does not seem to be transparency. A major disadvantage is the fact that you will only “see” the information in the VDP1 layer, never what is in the VDP2.

In the official SDK manuals we can see more in detail:

Shadow (Color calculation mode = 1)

The processing differs according to the MSB from the pixel data already written in the frame buffer. When the frame buffer’s MSB is “0”, the color calculation processing, including substitution, is not performed and the frame buffer is left as is. When the frame buffer’s MSB is “1”, shadow is performed.

In the shadow, the pixel data already written to the frame buffer is subjected to a color calculation. The area in the frame buffer in which the color calculation will be performed is searched from the character pattern and its drawing coordinates in the case of sprites, and from the drawing coordinates in the case of non-textures. The brightness of the pixel data already written to the frame buffer in the area where the part is to be drawn becomes half for each of R, G and B.

Shadow does not change the MSB of the background. Transparent areas remain transparent.

Shadow halves the brightness of the pixels in the frame buffer. To make the luminance a quarter, set the same command table in VRAM twice. To make it an eighth, set the same command table to VRAM three times.

In the shadow, the calculation is performed on the pixel data read from the coordinates at which the pixel data from the original graph is written. The drawing in this case slows down, so be careful: it takes six times as long as when the color calculation is not done.

half-Transparency (Color calculation mode = 3)

The processing differs according to the frame buffer’s MSB. When the MSB is “0”, the replacement is made. When the frame buffer’s MSB is “1”, half-Transparency results are obtained. half-Transparency is half (average) of the sum of the data from the original graph and the background (frame buffer). The result is written in the frame buffer.

The half-Transparency color calculation is performed on the pixel data from the original graph and the pixel data read from the write coordinates in the framebuffer. In this case, the drawing slows down, so be careful: it takes six times longer than when the color calculation is not performed.

Gouraud Shading + half-Transparency (Color calculation mode = 7)

Processing differs depending on the frame buffer’s MSB. When the frame buffer’s MSB is “0”, Gouraud shading is performed. When the frame buffer’s MSB is “1”, Gouraud + half-Transparency shading is performed.

In the case of the Shadow of the VDP1, as we have already said, it is a kind of “division” only in the target or target pixel. This function works by pixel (pattern and screen) in “RGB” or CLUT mode and even “Color Bank / CRAM” for the source data. And only on RGB target data, if used on “Color Bank / CRAM” data it produces a “mask” or non-write effect:

A = Origin / Foreground; B = Destination / Background / Objective; R = New Destination / Result

P = position (x, y); L = base luminance; Fs = Shadow factor = 2, 4 or 8

P (A) = P (B) then R = L (B) / Fs

In the case of the half-Transparency of the VDP1 it has a special method. And it is processed by pixel (pattern and screen) in “RGB” or CLUT mode:

A = Origin / Foreground; B = Destination / Background / Objective; R = New Destination / Result

The first formula that can come to us is this: R = (A + B) / 2

But as we have said it is no longer a pure additive mixture. I would also like to emphasize that the result of the final effect on the source and destination colors tends to darken them. And when they overlap several times it is difficult to perceive transparency.

As I mentioned before, it is curious that SEGA engineers did not implement something similar to the Highlight mode of the Megadrive in order to have a brighter mix.

If it were an additive formula, the final blending would be like that of PS1 or VDP2. But it’s not like that. The VDP1 CC respects blacks, for better and for worse. For good, because it can make shadow or darken effects. To bad, because it will not mix the dark parts in a smooth way and will not increase the brightness in the white ones, which gives that luminous finish of the additive mixture. After another incredible conversation on the SegaXtreme Discord and thanks to XL2 and faflinggotten a I havelittle closer to the possible formula for color calculation. Concluding that SEGA engineers ultimately leverage the Gouraud shading algorithm or pipeline in different combinations in the VDP1 color calculations. Therefore for half-transparency it will work similarly but with different source and destination data. In the Gouraud the assigned RGB vertex table plus the texture. And in this case the upper texture against the background in the framebuffer:

R = (“A” + B)

“A” = It will take a value with a negative sign if it is a value very close to black. If it is an intermediate value, the value will be maintained. And if it is brighter it will take a value with a positive sign. The exact values, I do not know.

I will try to give some examples with possible default values similar to those of the Gouraud:

If the primitive origin is a “shadow”: All with RGB 1,1,1 values and the background is 25,25,25. With the VDP1 system it will subtract the default complement from “A” to B: -15. Giving a result of 10,10,10 a color quite dull or dark and that is almost half the target. In additive the result before dividing in half would be 26,26,26 a color a little more bright or luminous. In the middle we would have 13,13,13 where there would not be much difference either.

If the primitive origin is “smoke”: All with RGB values 30,30,30 and the background is 25,25,25. With the VDP1 system it would add a default supplemental value of “A” to B: +14. Giving a result of 39.39.39, exceeding the limit of 31.31.31 which is a pure white. In this case it is normal, since both the origin and the destination were very light colors. In additive the result before dividing in half would be 55,55,55 a color that exceeds the limit. In the middle we would have 28,28,28 there is not much difference either.In the case of Gouraud + half-Transparency Shading, it is still a “special” mix on both sides. first half-processedand thenTransparency the Gouraud Shading. Someone may ask: What is this mode useful for? Well, it is useful in several scenarios:

1) Through the coloring of patterns / patterns, to save VRAM that allows Gouraud Shading to make color change effects or palettes for light effects in flares, explosions or fumes.

2) Dynamic masks for explosions or progressive disappearance / appearance effects.

3) Add gradients rich in shades on spot colors plus half-transparency:

The sequence order of both calculations is important, but given how VDP1 was mixed it didn’t matter. Being a “special” mixture and not additive, the result was going to be the same. Most likely, in the case of the VDP1 in SS, the Color Calculation is done first and then the Gouraud, as I have read and understood in the official documentation. While in the case of the PS1, I am almost sure, first towards the Gouraud and then make the mixture half-transparent. So I could make the dynamic masks that the SS could only do by adding the VDP1 + VDP2.

Clipping / Skins / Priority / ”Z-Buffer” It

was something that in principle I had not thought to deal with. But by going deep into the transparencies, by logic I have reached the point of how the opaque elements overlap with the “transparent” ones.

He also took the opportunity to talk about the essential difference of saying 15BPP or 16BPP. That bit of difference, usually on the MSB. It is the transparency bit, which we can often read from alpha. We should not confuse that the system has alpha blending capacity, this is something totally different. It is true that this bit is part of the fourth information channel of a pixel. And that if it is expanded in bits, it will be operative for alpha blending. So in the SS itself in the VDP2 we will see how similarly it has a 5-bit alpha channel. In short, this 1bit is used to indicate if the pixel is 100% transparent or 0% opacity, which is the same. Normally it is used to make simple masks in bitmap, but in this generation as we have seen it was used in combination with other systems for different purposes, including transparency issues.

With this we come to the masks or clipping. Because I call it clipping, because after all it is an initial way of clipping as it is known today or as it was done in more advanced systems at the time. The VDP1 has a mode called local user clipping (not to be confused with system clipping also very useful), which allows you to discard pixels inside or outside of an area so as not to be drawn, within the same graphic information package. PS1 has something very similar for its GPU, and if I remember correctly the 3DO too. Analogously it can also be defined as Window, which is what the VDP2 has or even systems of these generations or past as SNES or Genesis.

In other modern GPU systems this would be done with advanced multilayer mixing and depending on how this clipping will be used, it would be somewhat analogous to a kind of very basic “Z-buffering” in VDP1, somewhat more complex in VDP2. But that thanks to the “connection” between VDP1 and VDP2, elements of VDP1 can take advantage. We will see something later.

To finish, the key to this “Z-Buffering” will be the priority values that each pixel, sprite / character or data set have. In the case of VDP1 this value is given by the drawing order in the command list. In the case of VDP2 it can take up to 8 values.

% Games with half-Transparency / Shadow

We finish again with the percentages of use over the total number of games analyzed. In this case they use half-Transparency / Shadow 30%. Of this percentage, half-Transparency uses 73% and Shadow 20%. Developers clearly opt for the first, allowing them to do the same as the second, practically, and more things with equal toll.

Let’s now see the use in the Exclusives.

games Exclusive 1st party are approximately 22% of the total number of games analyzed. Of these, 27% use half-Transparency / Shadow.

While the exclusive 2nd parties account for approximately 8% of the total analyzed, where 48% use half-Transparency / Shadow.

Finally, the exclusive 3rd parties are approximately 42% of the total analyzed. And we see up to 57% use of half-Transparency / Shadow.

We can see how the use in the exclusive 2nd and 3rd party are above the average usage of their total. This shows that it was a feature that was really needed in the industry and that developers were looking for because they could have it on other machines.

Now let’s take a look at even more “significant” gaming cases within the total. They are PSX ports, which are 24% of the total. And we see up to 50% half-Transparency / Shadow usage on them.

In the PSX ports of Psygnosis that are 2% of the total analyzed. We see 63% use of half-Transparency / Shadow.

While PSX ports represent EA’s5% of the total. Of which 60% used half-Transparency / Shadow.

With these percentages it is even clearer that the push to use it in SS came from PSX. Well the numbers are clearly high with respect to the total and even the exclusive ones.

Limitations of Transparencies in VDP1

The “background” of the FrameBuffer of VDP1

The first and clearest limitation is that while VDP1 draws on the empty framebuffer, what remains unpainted or indicated as mask, chroma key or 100% transparent. Then it will be a place where the VDP2 information is seen. From the rear Screen to the other Screens in order of priority.

The real problem comes when the VDP1 does a color calculation and does not even know what will be here, therefore it will leave a flat color without any extra information of type “alpha” or similar.

All this problem comes from the separation in units of the graphic pipeline. And the 16-bit limitation for pixel information. Only one “free” pixel is available to them and SEGA engineers used it as they knew at the time. That is the MSB or bit15.

Perhaps using an extra pixel for this problem could have solved the problem. A kind of MSB2, at bit 14.

Color Spaces and Color Types

The main limitation that VDP1 has when it comes to processing Color Calculation effects is the problem of mixing unit RGB direct color spaces with Indirect color spaces towards the CRAM of the VDP2.

In general VDP1 cannot read the CRAM at runtime of its pipeline. And I say in general because we have the undocumented case of using Gouraud or even other modes like Shadow or half-transparency on origin primitives for color calculations. We know exactly what happens, but we know that something can be done. And that some color of the CRAM is capable of reading the VDP1 at this time.

Where it is clear that VDP1 cannot do anything is with the data written to its Framebuffer. If these are formatted for CRAM and MSB = 0, you will not be able to do the color calculations if you cannot have the color data available.

This does not generally give the limitation that if we want color calculations as transparencies in VDP1 we need the data in the Framebuffer to be MSB = 1 and direct RGB.

On the other hand, 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 and the VDP2 will not be able to use them. In theory. Because I have seen cases where they do, in FIFA 98 in the shadows of the players. Like, exactly I don’t know.

Connection between color modes and VDPs:

Mode 0: 4BPP CRAM-VDP2 <> Mode 1: 4BPP CLUT-VDP1

Mode 0 is the 16-color mode that points to the CRAM of the VDP2 and will be indicated in Bit15 of the data of the pixel as MSB = 0. On the other hand, there is Mode 1, which is also the 16-color mode but which points to the VRAM of VDP1 and will be indicated in Bit15 of the pixel data as MSB = 1.

Both are connected in the way that the 16bit pixel color data is configured. The difference is in how the color data is configured plus the MSB in each case.

In the case of CLUT in the primitive it is indicated that it is mode 1 and it will go to the VRAM of the VDP1 to look for the list of 16 16-bit colors. There you will find 2 types of colors:

1) Normally and mainly a direct RGB color of all those available in the VDP1 of 15BPP, that is to say 32,768 colors with “1 bit of alpha”. Or 16 total bits per color.

2) The other may be a “CRAM” color that indirectly points to the VDP2 colors that are configured in its internal 4KB CRAM. This would interpret it when it reaches the VDP2, it will process it with some of its functions and it will put the RGB color as a result of the total available configured in its Color Mode :, 1024 or 2048 total available colors of a total of 16bits or 24bits respectively.

What is the use of this mode? In my view it was the attempt of the connection between VDP1 and VDP2 unfinished. This would have given the SS versatility to make transparencies and priorities of VDP2 together with VDP1. But it does not allow this. In the end it allows to have direct colors or RGB from VDP1 or from the CRAM indirect from VDP2 mixed in the same pattern / texture.

Note, that in this way the Sega Saturn could have real 24-bit colors on the data processed in VDP1, if VDP2 had its CRAM configured in mode 3 or 24-bit color mode.

The really striking thing here is that somehow, as I say, there is an early way to connect the units. Questions are even raised as to whether it would be possible to go further via software or some other unknown trick via hardware. For example, being able to use the VDP1 color calculations first, leaving the colors in CRAM format in the FrameBuffer of VDP1 so that later VDP2 can do something with them.

Just finishing this post, after a help exchange with @paul_met for the Castlevania hack. We have come to this problem with RGB CLUTS and priorities on the VDP2 Sprite Screen. But first @paul_met himself has highlighted that CLUT was used in Castlevania itself with different priorities in the VDP2 Sprite Screen. And then @fafling and @XL2 have confirmed it. But they are also both sure it cannot be used first on VDP1 and then on VDP2. The type of color that is configured in the pixel of the CLUT primitive will determine one way or the other. Not both. Let’s continue with my dissertation anyway.

The greatest difficulty is that the colors between the origin and the final result will change giving different results. The good thing is that despite this complexity. There is a known limitation within the colors that will be available as they are configured and how they are subsequently processed and the result that will be obtained is somehow “known” within a conversion range. It is difficult, but not impossible, to get to use Gouraud mode on VDP1 and then leave it in CRAM in Framebuffer with a software thread. Or even where VDP1 leaves a half-Transparency that indicates that it is “transparent” for VDP2. This idea is not entirely mine. Again on the Discord channel talking to @fafling and @XL2, we were able to come to these kinds of conclusions. This could open up new possibilities for extra usage between units.

Finally, analogously to this connection of Mode 0 and 1. It occurs to me that it could have been possible and useful to also connect modes 2, 3 and 4. That is, extra CLUTs for 6BPP, 7BPP and 8BPP. The latter exists as such on the VDP2 side. Could we have CLUT 8BPP on VDP1 somehow?

MSB On

We return to the MSB. Well, as we have seen before in the color calculations depending on how the MSB is configured, we may or may not use these effects. MON, or MSB On, is its own record in the VDP1 command list. This register is used when writing the final pixel of the primitive in process in the framebuffer, the VDP1 marks it as MSB = 1, if this register is active. The VDP2 will be able to use it for its special transparency functions: Color Calculations + Priority and Mask / Window on the screen / Sprites layer / VDP1 and on the other hand the Shadow option MSB of the Shadow function of the VDP2.

Obviously this register makes sense to use it in a primitive with MSB = 0, or what is the same Color bank or CRAM of the VDP2. This would theoretically nullify the use of the VDP1 color calculations and at the same time would limit us in theory to the use of the special functions of the Sprite Screen in the VDP2.

But above all I wanted to talk about the MSB On, as another primitive sample by SEGA engineers to connect the two VDPs. Another sign of an incomplete connection in my judgment. And that as I have stated before. And now with this MSB On, if it had been arranged the same as this record, let’s call it MSB1 another for a hypothetical MSB2. We could have seen a full connection between the VDPs.

Now I will expose some other drawback and also review others with some extra data and images to illustrate:

Limitations of the nature of the VDP1 raster Artifacts

were seen in the case of distorted or perspective primitives (distorted sprites or flat-colored polygons) opaque stripes in the middle of the transparency. What was the repainting of the effect, causing the poor quality and the extra expense of cycles.

It could not mix the data of the background generated by the VDP2, leaving in these areas the transparencies as annulled.

We may also have a case. Where already painting an element of the VDP1 in the framebuffer in RGB (the shadows in FIFA 98 are CLUT / RGB VDP1), another superior one in process in the VDP1 with half-Transparency does not see the first one at all. In this case it is perhaps because, the element has been marked to be used in the VDP2 for some color or function calculation. Or its MSB value is 0.

Color Space limitations within VDP1 due to incomplete data sharing with VDP2.

It is only capable of mixing elements that are within the RGB color space of the VDP1. If the texture / pattern / spot color / distorted sprite is already painted in the background (Frame buffer 0 of the VDP1) to be mixed, it is checked to use color data from the VDP2 (CRAM palette color) the mixing will not be done, looking opaque and with a flat color.

This color type restriction does not totally affect the upper primitive. In other words, the top “texture / pattern / spot color / sprite” can be in “Color bank / CRAM VDP2” or “CLUT / RGB VDP1” regardless.
That if, as far as I have seen and understood, 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? I really don’t know today.

If the primitive has a “pattern” in “Color bank / CRAM VDP2” it may “iron” the pattern and it will be flat color making the mix. But I am not 100% sure. I saw an example on NBA Jam Extreme. And during the writing of this part @Paul_met confirm my doubts. On the CRAM color gradient pattern, he has activated HT mode. This one tries to blend in with the characters in CLUT RGA below him. Troubled, but it works. Upgradeable via a little software help?

What I have been able to see use is a “texture / pattern / spot color / sprite” with “Color bank / CRAM VDP2” and CC VDP1 Shadow mode. But this CC irons the pattern to make it “gray” by mode definition. What is expected of this CC function.

To finish I will add a summary table like in SEGA’s SAT for the shadow function:

VDP1 over VDP1
Penalty for use?	Between 3 and 6 times more than an opaque pixel.
Can sprites be mixed on top of other sprites?	Yes
Type of modulation?	“Division”
Type of mix?	“Additive” Black intensity is not interpreted as transparency. Muted or darker results.
Can sprites have different priorities / depths?	Yes, usually 65,536 values. Integer16. = 16bits
Valid color types on source data Valid color	RGB or “Palette”
types on destination data	RGB or MSB= 1
Number of factors / alpha levels available	3 fixed. 100%, 50% and 0%
Can multiple layers of transparency be mixed?	Yes, 65,536
Can more than one color calculation function or mode be combined?	Yes, they increase the penalty.

Conclusions Transparencies VDP1

You can see the use of this effect in many games throughout the catalogue, from the beginning and throughout the life of the system. What happens is that the use is very small or in details that often go unnoticed. And this increased the feeling that there were no transparencies or that by not using them anymore, it was even “believed” that the SS could not do them.

As we can see SS could make transparencies with his VDP1. It wasn’t alpha blending, but it did something similar. The one that will not be used (in general, because it was used in many titles) as we have seen was due to multiple disadvantages or drawbacks. But perhaps one of the most important was this “warning”:

That if it was NOT used well, it could be a very high cost for the system, taking SIX times more to calculate the same pixel than without this effect.

And I add: In the worst case. My theory is that if there is no redraw, and it is used within the rest of the limitations, I think that the penalty is less. Between 3x and 2x.

It is clear that the combination of drawbacks, such as the default penalty, added to the ignorance of how to use it well, in this perhaps an SDK helped a lot at first that did not help what it should. Or because of the ease it presented when converting from PSX, just by plotting in SS what was transparency, and forgetting about headaches. It is clear that using one effect or another in SS was not the same as PSX … because the dependence between its chips had to be controlled, and that had a cost. In addition, that despite this, the exact same result was never obtained in complex 3D cases, if very close or equal in simple 3D or 2D cases.

As a reflection to say that in the 3DO or the Jaguar the use of their half-Transparency modes also penalize (much more) but they did not have the problems that the SS had. Quite a mistake by SEGA in the design, when it had almost two years to do at least the same as these. Sony solved it much better, here too. PSX matches how you use these effects in 3DO or Jaguar. And improve speed when using this effect.

VDP2

VDP2 is an ultra complex chip. In a way it reminds me of the SNES VDP, which was already complicated and powerful. But the VDP2 multiplies by 10x its complexity and power. In the scene we know him as the wild beast.

In other graphics systems the graphics pipeline usually ends in a final frame-buffer. In SEGA’s Domestic R&D department they got creative, or had a fantastic idea, depending on how you look at it. And they decided that the frame-buffer was going to be in the middle of the pipeline. Between VDP1 and VDP2. The reasons may be various. I think the main one is, that the VDP1 is somewhat “slower” since it depends on the CPUs to get their starting information to draw. While the VDP2 can do “almost everything” by itself. Thus the VDP2 is in reception mode, takes what comes from VDP1 when it “has it ready” and does its magic.

This way of working between graphic processors, coupled with the fact that if the VDP1 towards the “3D” of the console, in a “2D” way. While the VDP2 was “almost totally” 2D plus its 3D plane processing capabilities (like SNES mode 7) it was the only thing that took it away from its 100% 2D nature. And as I was saying, all this united towards the developers having to enter a very concrete and special world. Sega Saturn with its VDP1 + VDP2 tandem was powerful, but extremely novel and exotic.

Thus the VDP2 can apply different processes of color, clipping or priority on pixels, patterns or layers. Both in its own unit and on the information received from VDP1. All this, under a complexity to configure and combine that includes: VDP2 resolution, VDP1 resolution, Color type in use in VDP2, VDP1 reception color type and data shared between VDPs through the MSBs.

But let’s focus on its abilities to make transparencies. The VDP2 has 3 types of mix (A + B) or (B + A) and “As in” that takes the Brightness / Value values of the “Origin / superior” component. In each mode the VDP2 can apply 32 ratios for A and / or B and in “as is = CCMD (1,1)” in the component that is selected as “Origin / superior”. VDP2 can mix RGB or Indexed colors within its own unit.

In the case of the transparency of the VDP2 this is of multiplicative modulation plus additive mixing (like the GPU of the PS1), per pixel (pattern and screen) in “indexed color and RGB” mode and with the possibility of using ratios or steps of mixed like the PSX, in the case of the VDP2 up to “32” steps. But in the case of the VDP2 fully configurable and not fixed, added to the brightness / value, even more possibilities of combination. The 3DO’s VDP is almost on par with the VDP2 in this regard, superior in others. The VDP2 has special shadow modes and can also combine up to 3 layers for mixing in one pass and one cycle. PS1 and 3DO as much as they can are 2 elements to mix in one pass and also in several cycles, from 2 to 3 in the case of PS1 and in the case of 3DO more than 6, I estimate almost certainly for its slowness seen in real games .

Being more precise:

F = “brightness / value” factor or “configured ratio”

A = Origin / Close-up; B = Destination / background / Objective; R = New Destination / Result

Ratio configured → R = A * F (A) + B * F (B); F (A) = F (B) = 0 … 31

“As is” → R = A * F (A) + B * F (B); F (A) = F (B) = 1

Where F can be configured or configure the “as is” mode that will use the “brightness / value” factor in the base color of each pixel, pattern or screen.

And where A and B can be any Screen / Layer of VDP2, including the one coming from VDP1. And then you can apply this formula in a concrete and configurable way on: pixels, pixel areas (mask or window), patterns or the entire screen / layer. This capacity is superior to the GPU of the PS1 but very similar to that of the 3DO.

Now we are going to go into something more detail in each of the parts of the VDP2 that can perform a “transparency” effect.

Normal / Extended Color Calculation (ECC) Functions / “as is” Mode

The VDP2 has a main Color Calculation function, which is responsible for making transparencies. This function can make transparency on all Screens including that of VDP1. Including the special Line Color Screen but except the Back Screen. In turn, it has two modes of operation: Normal and Extended.

The Normal color calculation mode is only capable of mixing “one level” or, to put it another way, between two layers / screens, one upper and one lower. Although it is possible to “activate” it in all the layers without problem. Making the transparency correctly, while the target pixel is opaque. If it is transparent it will not work. To give a clear example:

If we have 4x active layers / screens, all four with transparency. We will only see the 1st layer / screen mixed with the 2nd. The rest, the 3rd and 4th, will be hidden or opaque after the 2nd layer / screen. This is an extreme example, but totally possible.

Like everything in the VDP2, and in a the SS comes at a price. Using CC lowers the total color bits. Depending on how the VRAM of the VDP2 and the color types are configured on the sprite screen. We will have more or less color quality. The VDP2 can process color to 24BPP and up to 32-bit words. At the communication level with the VDP1 it is limited to 16BPP. And then if you use the exclusive color and priority calculation function of this screen, we go down to 11bits of effective color. Going from 32,768 colors to 2,048 colors, being able to mix so palette or RGB color information. When we go to Hi-Res you can only mix on Palette color.

The Extended Color Calculation (ECC) mode allows mixing of “up to 4 layers / screens”. Where it will actually be:

If we have 4 active layers / screens. 2x layers with transparency, the in-line color layer / screen inserted in some of the layers / screens and finally all this against 1x opaque layer / screen. It gives us 4 “mixed” layers.

In short, the main difference between the two is in the limit of layers that can be mixed with effective half-transparency. In normal you can mix up to 1 layer transparency and extended mode up to 2 effectively.

It is true that the second “blend” of ECC adds extra limitations: The ratios are now 3 possible combinations for the 3 screens at once. And the “additive blend is partially lost”. Not processing the areas with brightness / intensity gradients or black mask, in the second alpha blending. In addition, 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.

Which is still impressive for 1994. Making two alpha blending half-transparencies in a system cycle, on three layers of up to 352×512 (interlaced) is brutal.

We ended up talking about the “as is” mode, which is still the normal mode but with unconfigured alpha values. Leaving only the additive mixing step to the system. It is not complicated to use, rather like everything in SS difficult to fit inside a 3D pipeline. 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.

% Games use Normal / Extended Color Calculation Functions (ECC) / “as is” Mode

We finish again with the percentages of use over the total number of games analyzed. In this case 44% use Normal / Extended Color Calculation (ECC) functions. Of this percentage they use the normal mode 38% and the Extended (ECC) 6%

The “as is” mode is present in 0.93%.

The developers opt for the normal mode, since it is more versatile and relatively easy to implement However, the Extended / ECC being more interesting and spectacular, complicates its use even more. Not excessively the truth.

Finally, despite the fact that it is currently difficult to know due to the state of the emulation, and being aware that there are many more games using the “as is” mode

Conclusions of Normal / Extended Color Calculation (ECC) Functions / “as is” Mode

Both functions are extremely powerful for the time. And with them the VDP2 had the closest alpha blending to the reality that existed at that time by hardware. The problem we already know, that the focus was mainly 2D. Although, as we also already know, and I will explain a little later, it is also possible to take advantage of it for the 3D part of the system. Not without complications, of course

VDP2 Screens

Screens in VDP2 are like layers or backgrounds in other similar or analogous systems. They can be of three natures: NBG or XY scroll plus scale on each axis, RBG or XYZ rotation plus scale on each axis. Then the special Screens. The Sprite Screen or FB1 of the VDP1. The Back Screen or Back Screen and the Line Color Screen or Color Line Screen.

As we have said the Screens to which functions with color effects and priority can be applied except the Back Screen. Furthermore, the VDP2 could discriminate how to process said effects with spatial or concrete modes, so it could apply the effects to all Screens, at the level of characters or patterns, or the level of pixels or points. It should be noted that this last process level will only be available under the Palette color space.

The VDP2 will be able to process transparency effects in almost all its modes. Except for some special way that will restrict the use of VRAM and the available cycles of the system. But we can say that in general both in normal resolution mode and high resolution. As the interlaced modes the VDP2 will be able to perform color effects.

As a curiosity to highlight that the VDP2 will be able to represent a Screens in 24-bit color and perform color effects without problems against the Sprite Screen. Which for example the PS1 could not do.

On the other hand, the VDP2 can process RGB color data as palettes on its Screens. Although internally it works with RGB. This RGB is configured in three modes. 3 mode being 24-bit mode, which partially limits the two special or extended color calculations, but does not cancel them.

% Games with transparencies VDP2 Screens

We again with the percentages of use over the total number of games analyzed. In this case use 38%VDP2 Screens.

Let’s now see the use in the Exclusives.

games Exclusive 1st party are approximately 22% of the total number of games analyzed. Of these, 52% use VDP2 Screens.

While the exclusive 2nd parties account for approximately 8% of the total analyzed, where 59% use transparencies VDP2 Screens.

Finally, the exclusive 3rd parties are approximately 42% of the total analyzed. And we see up to 45% use of transparencies VDP2 Screens.

We can see how the use in the exclusives in general lines is normal. About half. We highlight again how in the case of SEGA games this unit was no longer used. Transparencies was not something that worried them much it seems to be.

Now let’s take a look at even more “significant” game cases within the total, PSX ports, which are 24% of the total. And we see up to 33% use of VDP2 Screens transparencies on them.

In the PSX ports of Psygnosis that are 2% of the total analyzed. We see 25% use of transparencies VDP2 Screens.

While EA PSX ports mean 5% of the total.Of which 53% used VDP2 Screens.

We can see in these percentages, the difficulty of transferring the transparency effects from the nature of PS1 to the nature of VDP2. Curious to see that in the case of EA the effort is significant. Being in the same percentages as the exclusive ones.

Conclusions transparencies VDP2 Screens

We can see that the use of transparency on Screens existed. In a percentage within the mean of the effect itself within the system. In my way of seeing low or very low, especially in the case of the exclusive ones and which was also relatively easy to use, within what is the VDP2. Although it is also fair to say that those who used it used it very well. On the part of the ports from PSX, we already know that it was complicated. Yet again pleasantly surprised how EA games make use of the high in this case at least.

VDP1 (FB1) Sprite Screen / VPD2 Screens

VDPs have a bridging mode between the two. VDP1 and VDP2 are linked using FB1, or “drawn” or “final” framebuffer. This one at the end will contain values of only 16bit or only 8bit, depending on the color mode configured in the VDP1. And then VDP2 will have different ways of interpreting this information and processing it. From leaving it like this to being able to do extra processes within the Screens / Sprite Screens or against the rest of Screens of the VDP2.

This translates into an amazing amount of possibilities and complexity. But it is also the evidence of power that the VDP2 has. The amount of pixels it is capable of processing in a system cycle is monstrous. And everything you can do with them even more.

The main problem is the fitting of a graphics chip of a 2D nature within a moment of 3D graphics. And since it also works in conjunction with VDP1, another graphics chip with 2D DNA but even closer to 3D.

Mainly SEGA engineers partially solved the communication between VDP2 partially by means of a VDP2 function that reads and uses the values in each pixel that arrives from the VDP1 layer. This is called the color and priority calculation function which I also like to summarize as CC + priorities. And this will look first at the newcomer FB1 of the VDP1 in the MSB bits of each pixel for the value that exists.

If the MSB = 1 will be an RGB pixel and represent it as is, and if the color and priority calculation mode is 3, the process will be applied. Actually when RGB is the process that is done is the color process and that the priority will be canceled to the priority value that all the Screens / Sprite Screen have. However the color process may have a given transparency value as configured. It will be a single single value for all RGB pixels or with MSB = 1.

If the MSB = 0 it will be a Color Bank or CRAM pixel. And now comes the really complex part. Depending on how the Color Bank pixel type has been configured for the Screens / Sprite Screens. Among 8 types available. The final pixel configuration will vary and with it the process that will make the VDP2 color and priority calculation function on it. These pixels are in the CRAM, and they are still RGB pixels. Depending on how it is configured, the CRAM will be either 1024 or 2048 total colors. In any case for the Screens / Sprite Screens there will be 2048 maximum colors available for the palette colors. Since these have a maximum of 11 bits available to define them:

The MSB (Most Significant bit): Value 15, of the 16 possible as it is 16-bit color. Which will be the value that according to the configured color mode will leave in the FrameBuffer this mark that acts to use the information of that pixel as transparent between VDPs. And for special VDP2 modes like MSB shadow mode or CC in MSB mode. Or even as a usable value for special priority or color calculation functions.

The LSB (Less Significant Bit) values will vary according to the chosen mode, having a maximum of 11 bits and a minimum of 9 bits to define the color in 16BPP mode. In 8BPP mode the maximum will be 6 bits and the minimum 7 bits to define the color.

The remaining values between the MSB and the LSBs are the values for the special functions color and priority calculation. They will vary between 3bits maximum for each and 1bit.

You can use its mixing capabilities or priority discrimination or layer probability as in NGBx or RGBx layers. With a limitation, it can only take 8 values for both transparency blending and priorities. This means that for transparencies you can interpret up to 8 levels of opacity, not the 32 total possible. And for priorities the same as possible for layers.

It is an extremely complex feature to use, but at the same time very powerful. Since in a system cycle VDP2 is capable of alpha blending and a kind of “Z-buffer” on the information drawn by VDP1.

The color and priority calculation function in this screen does not work separately as in the rest of Screens. If not, they work together by CONDITION color calculation linked to priority by logic functions (≥ = ≤).

Finally, this function although it works mainly with the colors associated with CRAM. It also has a way to work with RGB colors. Using the identifying MSB to associate in this case only an alpha blending value and a priority value or “Z-buffer”.

Transparency limitations VDP1 Sprite Screen + VPD2 Screens

Most of the limitations or the main ones are perfectly explained in a response from the SEGA Technical Service on August 16, 1995. In this case, they do not attach a summary table. As if they did to explain the shadow function, which we will see later. I have tried to reproduce one to summarize these limitations by adding a summary of VDP1’s own, since these will eventually reach the VDP2 side.

VDP1 over VDP2
Penalty for use?	None.
Can sprites (VDP1) be mixed on top of other sprites (VDP1)?	In general NO. But SI can in a very limited way. Only with the MSB Shadow function.
Modulation type?	Multiplicative
Type of mix?	Additive (black intensity as transparency) if it is 1st layer. Additive with error on dark parts (Black intensity is not interpreted as transparency) if it is 2nd layer with ECC Brighter or whiter results
Can sprites have different priorities / probabilities?	Yes, 1, 4 or 8 priorities. 1 to 3bits.
Color types valid on data source	RGB or palette
Valid color types of data destination	RGB or palette
number of factors / alpha levels available	2 to 32 possible colors according origin and / or destination.
Can multiple layers of transparency be mixed?	Yes, 1 to 2 (with ECC).
Can more than one function or color calculation mode be combined?	Yes, with limitations or with modes such as ECC.

Link to full table (To be finished)

% Games with transparencies VDP1 Sprite Screen + VPD2 Screensfinish

We again with the percentages of use over the total number of games analyzed. In this case,use 49%VDP1 Sprite Screen + VPD2 Screens. Of this percentage they use transparencies VDP1 Sprite Screen + VPD2 Screens of CRAM 41.26% and RGB or MSB mode 7.74%. Clearly, developers opt for the first, since it is the one that gives the most spectacular results and the most versatile. The second is used more to use as a mask or “Sprite Window”.

Let’s now see the use in the Exclusives.

Exclusive 1st party games are approximately 22% of all games analyzed. Of these 39% use transparencies VDP1 Sprite Screen + VPD2 Screens.

While the exclusive 2nd parties represent approximately 8% of the total analyzed, where 33% use transparencies VDP1 Sprite Screen + VPD2 Screens.

Finally, the exclusive 3rd parties are approximately 42% of the total analyzed. And we see up to 38% use of transparencies VDP1 Sprite Screen + VPD2 Screens.

We can see how the use in exclusives is even lower than in the case of Screens. This feature is complex, and also fitting it into the 3D pipeline is not easy. We can say that the exclusives are within the average of use.

Let’s analyze what are PSX ports, which mean 24% of the total. And we see up to 33% use of VDP1 Sprite Screen + VPD2 Screens transparencies on them.

In the PSX ports of Psygnosis that are 2% of the total analyzed. We see 0% transparency usage VDP1 Sprite Screen + VPD2 Screens.

While EA PSX ports mean 5% of the total.Of which 37% used VDP1 Sprite Screen + VPD2 Screens transparencies.

We see that the percentages drop even more in the case of exclusive ones. But again EA saves the house, even increasing its use. Very significant for me the 0% in the ports of games of Psygnosis, possibly the ports that more were compared and more damage did.

Conclusions transparencies VDP1 Sprite Screen + VPD2 Screens

We have already seen that just enough was used in the case of Screens, being quite affordable to use. And with VDP1 Sprite Screen + VPD2 Screens being even more complex to use. The most logical thing happens. Usage rates drop even further. A pity, because the result of transparency in this is spectacular. And it was the best way to get the best transparency and the hardware equivalent of PS1 in the SS on 3D elements. To highlight again the great use that some exclusives made of this, such as not talking here about all the Treasure games that use it in an outstanding way or the excellent Shining Force 3.

Shadow Functions: Normal Shadow and MSB Shadow

We continue with the Shadow functions . I include them within the VDP1 Sprite Screen + VPD2 Screens part because they work with VDP1 source data to be processed by VDP2. In the same way as the CC + Priorities function that we have seen before. But with other results / objectives and limitations as we will see:

Normal Shadow

This shadow is essentially identical to that of VDP1. Take the sprite / pattern / texture, without the color data, and everything that is under this data darkens or reduces its brightness values or the three RGB channels in half.

This mode has similar limitations to the CC + Priorities function. If two overlapping patterns / textures where one is with this effect on top of others, the shadow one will not see the other. We can say that it is only capable of processing “one layer” with this effect.

These shadows are typical on RGBx rotated floor. Or 2D character shadows in Treasure games or most Story of Thor 2 games.

Operation is simple. The sprites that are going to use this function must be marked on their LSB with values 0. Depending on the type of sprite configured in the VDP2, they will be more or less 0.

Shadow MSB

It essentially works the same way as the previous ones. But when the sprites / patterns / textures that are marked to be used this effect with others overlap each other, the shadow one will mix with the rest below it. This means that it is capable of processing the effect “in multiple layers” in principle without limit of overlaps.

Main problem, it can only be used in 8BPP mode. Priority or depths cannot be configured and must be CRAM colors, it will not be possible to use RGB values.

The operation is the same as normal, but also as its name says, the value 15 or MSB should be 1.

Games like Sexy Paradious and Astal use it exquisitely. Again The Story of Thor 2 also uses them but when they are on other sprites / patterns.

Transparency limitations Shadow Functions

The limitations of the shadow functions are perfectly summarized in this table, which is attached in part to the clarifications of SEGA Technical Service on May 23, 1995:

The following table summarizes the differences between MSB shadow and shadow normal:

	MSB	Shadow Normal Shadow
Do you have a use penalty?	None.	None.
Can they cast shadows on other sprites?	Yes	No
Can it be mixed with RGB sprites?	No	Yes
Can different shades have different priorities?	No	Yes
Valid types	sprite 2-7	All

We would have to add one last limitation to the shadow function in VDP2. At the hardware level, your pipeline is right at the end as the color offset function. This means that 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.

It must also be made clear that when mixing between them, the shadows do not matter which variant. These will not mix with each other. By having the same darkening value for all of them, even in the case of the MSB. Where these are all processed together as a single “Screens” separate from the Sprite Screens.

Finally note, that according to the documentation both functions can be used at the same time.

% Games with transparencies Shadow Functions

We finish again with the percentages of use over the total number of games analyzed. In this case they use transparencies with Shadow Function 9%. Of this percentage they use transparencies with Shadow Function Normal 7% and MSB 2%.

Developers clearly opt for the first one, since it is the most versatile and easiest to use. The second is difficult to find, although again, the developers who used it were fair, they did it very well.

Conclusions transparencies Shadow

functions The shadow function, as we have been saying, is a technique that SEGA and its employees knew very well. And integration into VDP2 is natural. Perhaps it is repetitive and very limited in certain aspects.

What I find interesting about this is the MSB mode. As in this function it somehow works as I was looking for. In other words, a way where the VDP2 could mix several layers of “transparency” on the opaque parts of the VDP1. It is the only function that does this in the entire VDP2, with serious limitations, it is true. But for me it is indicative of the incomplete connection between VDPs and the great potential that it would have had to be able to do these processes so quickly in VDP2 and in a more functional way with VDP1. I am sure that the developers would have used the VDP2 more and would have been able to better transfer the differences with other systems in this spectacular area.

Window / Clipping / Masks and Priority / ”Z-Buffer”

As I have already done in VDP1, I think it is very necessary to talk about how VDP2 can put elements above or below, in order to compose based on the priority or probability of graphic data.

The way to interact with special bits remains. So the MSB will be used to mark the total transparency or mask. Or the value 000 or 0000, will be interpreted as full transparent. And 3bits of LSB for the Special Priority Function.

In the case of VDP2 this applies to 16BPP and 24BPP pixels in the same way. Bit 15 in one and bit 23 the other. These bits of transparency, which we can often read as alpha. We must not confirm that the system has alpha blending capacity as we have already said. It is normally used to make masks and to use the window function of the VDP2.

But in addition to the MSB in VDP2 we have up to 3 bits for probability or priority. This data is used by the specific priority functions. In the case of Screens with fixed 3-bits and can be applied at different levels: The entire screen, character or point.

Again and now with more bits, in VDP2 we would also come to a concept similar to clipping. What is really interesting in VDP2. Because with the CC + Priorities function you could have up to 8 values of a kind of “Z-buffer” in color bank mode with the data from VDP1. Not so possible for RGB data which would leave it at 1 single value.

Precisely the interesting thing here for me, would be to find a way via software, in a minimal and optimal way, to be able to obtain these probability values also with RGB data from VDP1.

Conclusions transparencies of the VDP2

Now we are going to close the block of transparencies possible by the VDP2 and we are going to see the set.

General limitations on transparencies of the VDP2

We can determine some general and common limitations throughout the VDP2:

Limit of layers according to CC mode
Limit of mixing capacity according to CRAM mode
Limit of mixing capacity according to color type: RGB or Palette.
Functionality limits according to special modes: Hi-res or external signal.
Use of the MSB. Definition of its value and possibility of using it or not.
Order of the internal pipe in the process of calculations in VDP2.

% Games with transparencies VDP2finish

We now globally with the percentages of use over the total number of games analyzed for the general use of transparencies with the VDP2 44%.

Let’s now see the use in the Exclusives.

games Exclusive 1st party are approximately 22% of the total number of games analyzed. Of these, 46% use transparencies with the VDP2.

While the exclusive 2nd parties account for approximately 8% of the total analyzed, where 46% use transparencies with the VDP2.

Finally, the exclusive 3rd parties are approximately 42% of the total analyzed. And we see up to 42% use of transparencies with the VDP2.

We can see how the use in the exclusives does not even reach 50%, for me disappointing. That even in games unique to the machine there is no high use seems inconceivable to me. But it was so.

Let’s analyze what are PSX ports, which mean 24% of the total. And we see up to 33% transparency usage with the VDP2 on them.

In the PSX ports of Psygnosis that are 2% of the total analyzed. We see 13% transparency usage with the VDP2.

While EA PSX ports mean 5% of the total. Of which 60% used transparencies with the VDP2.

We see that the percentages drop even more also in the case of the exclusive ones except in those of EA, which even surpasses SEGA in use. It is true that% are less games, but in my point of view it has a lot of merit. And part of the bad image EA had for me has been rectified with this analysis. Even clearer after all this, the feeling that SS “had no transparencies” when even SEGA did not use it as it should. A pity definitely.

Conclusions VDP2 transparencies

Well I have not finished the transparency point yet. But at this point we can clearly see two questions:

1) The SS could make transparencies. And also with remarkable quality and performance.

2) The perception that the SS did not have or was very bad is completely clear. Even SEGA itself did not gamble everything it should have done to solve this problem for its consumers and its developer clients. It is true that in SEGA there are expectations, and as we will see superb. That they arrived, sadly late and if the necessary documentation and expansion.

Regarding the transparencies of the VDP2, as we have seen the options are varied. High complexity. But I think the results are worth it. The VDP2 is capable of doing a lot, fast and with quality. It is true that the price to pay is high. But from there to say that there could not be a universe, in my view, unaffordable.

Other functions of the VDP2

Now we are going to see other interesting functions that “are not transparencies” but can do something similar.

Offset Color Calculation

This function is also at the end of the VDP2 pipe as the shadow function. Its main utility is that it is capable of making changes in RGB values between two points: A and B. This function is configured by Screen / Screen. Being able to apply to all Screen / Screens available throughout the VDP2.

Being able to make transitions in RGB values to 24BPP. Achieving really smooth transitions, and superior to PS1 since this can only be done in 16 bits and with dithering, which is not the same. PS1’s 24bit mode is only usable in spot color, could be used in this and get gradients of this level but only in one layer and without GPU acceleration.

The usefulness of this function can be varied. From making transitions between logos, menus or beginning or end of levels or game events. Or paint the screen for damage, death, lighting or environment changes.

Limitations Offset Color Calculation

The only limitation I have seen is 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.

% Games with Color Calculation by Offset

It is used practically in the entire catalogue.

Conclusions Offset Color Calculation

It is really useful and simple. Also with exceptional color quality.

Inserting the Color Screen per Line

This function is somehow also the end of a part of the VDP2 pipeline, in this case in the Screens part. Furthermore, it can be used by the Normal Color Calculation Function or ECC.

To really work it must be inserted in some Screen / Screen. If not, it will not be seen.

This function is capable of painting, by additive mixing, colored lines (different or always the same) from the CRAM on the Screens. Being able to paint only in those that are assigned or in all taking into account the priority of layer one of them. Also in the same sense it will adapt to the rotation or deformation of RGBx Screens.

The typical use case would be the fog or horizon effect on the infinite soils of many SS games. Or simple “transparency” effects on a screen / screen like in the water of Castlevania: Symphony of the Night.

Limitations Insertion of the Color Screen per Line

As we have commented, this will not be affected by the Offset Color Calculation function.

% Games with Color Screen Insertion per Line

The truth is that it is a function that is difficult to detect by the state of the emulators. Thanks to a latest release of Kronos, we can now see when it is being used.

That said, I have been able to see it in 11% of the catalog. Wherever I am using the infinite rotated plane with fog effect, it will always be this.

Conclusions Inserting the Color Screen by Line

It is an exotic function. Like so many in VDP2 and SS. It is really useful for infinite rotated planes without a doubt. And if you want to achieve a horizontal linear darkening or fog effect on the Screens.

Software + Hardware: VDP1> transfer> VDP2entering

We are now the world beyond VDP2. How to get tricks and using the SS hardware, that it make better transparencies or as close to the competition. And they are also more usable or easier to integrate within the 3D pipeline.

Burning Rangers

Since you don’t have to start with Burning Rangers. This effect or trick is totally undocumented by SEGA. At least in the known documentation and SDK.

It is said that Chris Coffin at the Sega Technical Institute in the USA, was the one who developed and advised the Sonic Team. Or maybe it was born from the Sonic Team programmers. We really don’t know.

What we know is that it arrived in 1998, almost 4 years after the machine was launched.

Its limits were unknown. From what I analyzed, by myself and by other people that I have seen on forums or spoken on Discord, we now have an almost exact idea of how it works.

For me the best method to improve the quality, the performance (in part) but especially the usability of the transparencies in SS. Since it is a hybrid between software and hardware.

How it works

In Burning Rangers, an extra “layer” is created for the 176×112 point transparencies in VDP2, exactly in NBG2. Possibly uses Direct DMA SCU plus HRAM as intermediate well with VDP2 VRAM. As XL2 has, since BR almost certainly uses SGL as its base. And XL2 encountered problems using other DMAs when occupied by SGL.

This layer is created asynchronously next to the opaque data. It is true that there is some “transparent” data that continues to be drawn on the “opaque” layer, but only for the UI.

BR gets to painting between these two “layers” about 1300 polygons. In its “transparent” layer about 300, half for the transparent parts and the other half for the trim or mask parts. Generally and approximately.

Limitations

The main one is in the number of primitives and types to use. More in the case of BR in my view, less in the case of XL2 as we will see later. Since BR first paints the elements transparent and sends them to VDP2. After sending this without deleting, FB0 paints the opaque data and already sends these to FB1. Therefore timing on transparent data is crucial for the next step. The advantage is that the synchronization of the “layers” can be ensured in the same “instant” or frame. The biggest drawback is that it is taking time to draw the transparent first, then send to draw the opaque. You could play desynchronize the frames between these layers, if it goes over a value of ms. To compensate. What actually happens when you move the camera fast in loaded scenes.

The other limitation is the maximum resolution to send. This is also related to timing. Since given the possible paths, the system will be able to send x bits per sec, which will determine a maximum limit so that it does not subtract the rest of the processes from the set of this algorithm and the rest of the game, of course. In the case of BR as we have said, it is just half the width and height.

This whole combination of limitations may or may not explain BR’s 20FPS. It could be other factors.

Finally, the most important limitation, in my opinion, is how to solve the overlap or the probability between transparent and opaque pixels. For this I will dedicate a specific point below.

Clipping

BR has a simple solution for this but with certain limitations. This uses primitives from the VDP1 in the same trick area for transparencies but painted in absolute black as a mask where an opaque part would be. In this way, when all this data passes to the VDP2, it will not paint there and will mix it with the opaque part on the VDP2 Sprite Screen.

Limitations

Various. The “clipping” or clipping will be performed in less resolution, the staggering being much more evident. Second, you paint much more primitive, or you even get to duplicate them to be able to match the opaque ones and thus have an optimal cut or overlap.

Alternatives to BR clipping?

As mentioned before, find a way to use the VDP2 pixel or character priority functions with the VDP1 information from the Sprite Screen. Maybe in some way.

Limitations of this alternative solution?

In principle no face to transparencies per se. Since even for intermediate opaque elements it will be possible to paint a black primitive between two transparencies for greater accuracy accuracy. Much less than if we only use this route through VDP1. Even in cases where they are Billboards the HT VDP1 could be used so that there is a correct mix between these intermediate mask elements. Then the VDP2 with its additive mix will mix everything correctly.

This is not the case with BR, in fact this limits the mask elements a lot. Causing the clipping failure on many occasions and evident.

Implementation of XL2

XL2 uses part of the Framebuffer that is outside the visible part, to paint with the VDP1 the elements that are transparent.

Similar to BR, after / or during the drawing on VDP1 it sends all / part of the VDP1 area to NBG1 of VDP2 via SCU DMA (Direct or Indirect or SCU-DSP DMA).

And then scale with the VDP2 function the information of the Screen to match the final area with the original.

How it works

XL2 makes an implementation based on BR but with significant changes. XL2 uses part of the Framebuffer that is outside the visible part, to paint with the VDP1 the elements that are transparent. Instead of waiting to finish painting the opaque or transparent part to paint in a “new FB”. Take advantage of the same FB to paint in all the available area. Paint everything transparent first. Next he paints the opaque and at the same time in parallel he sends the painted lines of the “transparent” pixels. Similar to the BR, it sends to the NBG0 of the VDP2 via SCU DMA Direct, using the HRAM as an intermediate well. Since it is not possible to use other DMAs that are occupied by SGL. And in principle it is not possible to send via DMA from the B-Bus to the B-Bus directly.

And then scale with the VDP2 function the information of the Screen to match the final area with the original.

XL2 draws the primitives that will be transparent in the free space in FB0 outside the visible area. At the same time it is sending line by line in the free gaps between painting and painting of the opaque part of the VDP1. Through the SCU Direct DMA and using the HRAM as an intermediate well. To finally store it in the VRAM of the VDP2.

In his case 160×112, that is 160 lines of 112 pixels of 16 bits. 224Bytes or 112 16bit transfers. In the case of B there are 176 lines, 16 more lines. 1792 fewer transfers in the case of XL2. 17,920 total transfers.

In both cases this pixel area is sent to a Screen / Screen of the VDP2 and scaled to the total resolution in “X” and “Y”. The “as-is” mode of the VDP2 color calculation function is activated and it is given a higher priority than the Sprite Screen or opaque pixels.

In the case of XL2, activate and configure the ECC to be able to use it together with other Screens with CC. In his case he has the sky in transparent RGB1. And he manages to mix the sky, with the transparencies of the BR layer and elements of the Sprite Screen behind the sky.

Clipping

XL2 uses the same solution as Burning Rangers. Duplicate the opaque elements, using an equal but total black in the “transparent” area in the proper order of probability. In your case in specific areas of the map and in all the elements of the hand / weapon in the foreground. I am aware that you have an idea to improve them, using the priorities of the VDP2 as we have spoken at least in the hand / weapon, because also you want to use the metallic effect of the Gouraud trick in the VDP2 as the demo of Akira’s SGL.

Limitations

Practically the same as BR. With the great improvement of using the same FB for opaque and transparent data.

Alternatives the same as for BR.

Conclusion

XL2 not only implemented the BR solution. He also had to deal with the reality of implementing it. And I surpass it, in addition to improving the original taking even better advantage of the SS. Also added elements with half-Transparency VDP1 in the area to transfer. Having spectacular Lens effects and NEVER seen on the system. In addition to mixing these with water effects. Spectacular is little.

Grandia: Battles

How it works

Grandia uses a totally original method. As far as I can see from my analysis of the SS catalog.

This sends the sprites only when they are updated to the NBG1 layer, character by character. Presumably as in the case of XL2, or BR, through the SCU DMA (Direct or Indirect or SCU-DSP DMA).

On the other hand, it draws several elements in the VDP1 that is above this layer, such as: Part of the UI and particle effects. It’s funny that some elements of the UI draw them as mesh, possibly as the “second transparency layer”, so that it doesn’t cover the elements that are transparent underneath.

Clipping Clipping

problem, it does not exist because it only puts everything on top or below. Being “2D” it is easier to solve.

Limitations

Actually the normal ones of VDP1 and VDP2. Grandia’s Battle Scheduler simplifies the transfer to the maximum to send only what is necessary to VDP2 from VDP1. It also leaves most of the data in VDP1, which will be for transparency purposes. Just the opposite of the Burning Rangers effect. It is also true that the problem is simpler since it is “2D” graphics.

Conclusion

The Game Arts team at Grandia, and like the rest of the Game Arts titles, demonstrate their good work in SS and their extensive and proven knowledge. And so they put it in this trick to be able to have the greatest amount of transparency at the minimum cost of process and with the highest quality of the system, those of the VDP2.

Arcana Strikes

This game does something similar to Grandia. In battles when you cast a magic, transfer the sprites to a VDP2 Screen, it has a slight delay that shows. And paint the transparencies with a superior Screen. Also from the end of 1997 as Grandia. It does not reach the level of elaboration of the previous ones. But the developers’ intent is significant.

Transparency limitations VDP1> transfer> VDP2finish

We with a summary of the limitations of these tricks. As we can see basically it would be 2:

1) The amount of data to transfer. Which implies more or less resolution or elements to send.

2) How to solve the overlap or clipping problems. More complicated in 3D, and easier in 2D to solve.

% Games with transparencies VDP1> transfer> VDP2

As we see few, few crazy or brave dared to go so far in this matter in SS. 2 games throughout the system. It barely reaches 0.7% of the total number of games analyzed.

Conclusions transparency VDP1> transfer> VDP2

Well the conclusion is clear. It was the best way to have the best transparencies in the system. In quantity, quality and performance. The problem was the price to pay. SEGA did not help provide this pathway quickly and easily. And of course, why complicate life like that. I suppose that the Sonic Team being a fisrt party and Game Arts having such a large base in Japan saw it feasible to go that far. Better late than never, as the saying goes.

For the homebrew community it is a very attractive way to explore. Because all SS users yearned for this feature and many of us were convinced that more was possible. XL2 has demonstrated this, now we hope that more will come and we will finish this route to make it perfect.

By software:

VDP1

It would be possible to render transparent and / or opaque elements by software via CPU and it is sent to a pattern / pattern in VDP1 or Framebuffer.

Soul Hackers Devil Summoner does a little trick on the map. @mrkiso I commented on it during my writing of this point in Discord, and I saw it as another case of effect for software “transparency”. When the player’s cursor is covered by a higher element. By code it cuts the texture, making a hole, and in the following command it uses the same texture (without trimming) along with the half-Transparency of the VDP1. Creating a very interesting effect.

What Sonic R does is render opaque textured elements by software via CPU sends it to a pattern in VDP1. In this case, to recreate the environmental mapping at the UV coordinate level, to finally use the half-Transparency of the VDP1 to mix with the opaque base. This can be seen in R 3D in the startup titles.

Scorcher and Die Hard Trilogy(in the car game only) what they do is render textured elements and multiply further modulate a final additive mix on the frame-buffer to create half-transparencies. Right now they are the only ones known, opening up the possibility that even more would be done.

Die Hard Trilogy rasterizes the primitive with VDP1 itself in the free zone of the framebuffer just at the end of the list of commands, and then it will be read and mixed in the final coordinates on the framebuffer. This does not leave black areas, because the entire 3D game is being drawn on VDP1.

While Scorcher rasterizes everything via software. This leaves areas with black levels against the empty Framebuffer, where the VDP2 will draw. If these blacks could be marked with the register bits for the VDP2’s CC ratio and priority, it would be possible to mix with the VDP2 as Guardian Heroes or FIFA 98 does.

Die Hard Trilogy does not feature these black halos however. Possibly, and lack of being able to investigate further, because all the 3D is drawn with the VDP1, including the backgrounds. And the software mix is complete. The result as in Scorcher is that when there is a lot of area with the effect on the screen, a very large drop in FPS occurs, even degrading the gameplay. This is the case when an enemy car is on fire in front of you, below 10FPS in this case.

VDP2

It would be possible to render transparent and / or opaque elements by software via CPU and a VDP2 Screen is sent. And the closest thing I have seen is in Amok but it uses a mesh type like that of the VDP1 but by software.

VDP1 Sprite Screen + VPD2 Screens

In principle, it would not be possible to mix transparencies between VDP1 and VDP2 by software as they are systems that work by closed and different algorithms. Or within the VDP2 alone, since it draws it all in real time, “without frame buffer”.

One could try to mark the pixels that are drawn on the “frame-buffer background”. Or even look for color matches for results in the VDP1 CCs and pass them to the VDP2 CRAM while leaving the data in the framebuffer as Color Banks for the VDP2.

Clipping or Priority / ”Z-Buffer”

As I have already mentioned before, on several occasions, it would be possible through software to make RGB values processed in VDP1 pass to VDP2 as CRAM colors to be processed by their priority function and Thus, the opaque and transparent parts can be superimposed to achieve a better quality and precision effect, with a low processing cost for the VDP2.

% Games with software transparencies

The known% of games using the software path is very low. We only know for sure 4 titles that make use of a pipeline as pure as possible via software. That means 1.24% of the total number of games analyzed.

Software transparency limitations

The main one is to obtain an optimal enough code which has to read data from different wells and by different buses. In addition to different processors and memories at different speeds and data / word size. And finally integrate into the entire graphics pipeline, especially in the timing and direction of the processes, Read:

SH2 + RAM <-> SCU <-> VRAM + VDP1 + FB0-> FB1-> Sprite Screen VDP2 + VDP2- > TV output

If all this is not within a final timing between 8 and 16ms, or even less, the penalty will be high and the game will hardly move to 25FPS or more.

Of course if the algorithm needs RAM or VRAM, or both. In addition to needing a% of processes from the processors involved. This will take a% of bandwidth of the buses and of course the space of the VRAM or RAM that you need to use.

Finally you can also use some DMA of the system in% of time which will be another factor to take into account in all this complex equation.

Conclusions software transparencies

As we can see it is not a simple task. And the chances of it not being optimal are very high.

In fact, in the examples found, few, real works very fair. And when the amount of information to process on average increases, performance falls. In other words, the final stages of the processes go up a lot.

As a challenge and goal it is encouraging. The SS had this great “advantage”. It gave a lot of window to find ways to do “more” things.

To finish. A unique software path, in my honest opinion, seems too much. For small 2D elements it can be very useful and possibly optimal. But for large areas or quantities I see it unnecessary, being able to use other hybrid paths adding to the hardware itself at some point in the pipeline where it is best.

Summary of the possibilities of “transparencies” in SS:

1.Mesh

1.1 VDP1

1.1.1 Hardware

1.1.2 Software or pattern / texture

1.2 VDP2

1.2.1 Mesh: Software or pattern / texture

2. VDP1

2.1 Calculation Functions Color

2.1.1 Shade

2.1.2 half-Transparency

2.1.3 half-Transparency + Gouraud

2.2 Clipping / Masking

3. VDP2

3.1 Functions Normal / Extended Color Calculation (ECC)

3.1.1 VDP2 Screens

3.1.1.1 Defined Ratios

3.1.1.2 “as is = CCMD (1,1)”

3.1.2 VDP1 Sprite Screen + VPD2 Screens

3.1.2.1 Color Calculation Condition

3.1.2.1.1 Priority ≥ = ≤ Condition Number for CC (Color Calculation)

3.1.2.1.2 Color Data MSB

3.1.2.2 Shadow Function:

3.1.2.2.1 MSB Shadow

3.1.2.2.2 Normal Shadow

3.1.2.3 Window / Clipping / Masks and Priority / ”Z-Buffer”

3.2 Color Calculation by Offset

3.3 Insertion of Color Screen by Line

4. Software + Hardware: VDP1> transfer> VDP2

4.1 Burning Rangers

4.1.1 XL2 Engine

4.2 Grandia: Battles

4.3 Clipping or Priority / ”Z-Buffer”

5. By software

5.1 VDP1

5.2 VDP2

5.3 Clipping or Priority / ”Z-Buffer”

But how many transparencies can we have active by hardware and that they mix correctly?

This will mainly depend on the order in which the data is processed. From its origin to the end of the entire pipeline of the VDPs and between them.

Secondly, of the existing restrictions mentioned: color, data type, type of process… But first we see the number of layers that each possibility allows in VDP1 and VDP2 separately:

OK = It works; KO = Not Work

VDP1

Mesh Hardware = 1 layer does not work + OK with VDP2
Mesh Software-Pattern / Texture = “Infinite layers” + OK with VDP2
CC (HT / Shadow) = Infinite layers + KO with VDP2
Software = “Infinite” + KO with VDP2
- Variant not seen: That marks the pixels against VDP2 as CRAM CC + Priority.

VDP2

Mesh Software-Pattern / Texture = “Infinite layers”
Normal CC = 1 layer or Extended CC = “4 Layers”
- VDP1 + VDP2
  - CC + Priorities = 1 layer
  - Normal Shadow = “+ 1 Layer”
  - Shadow MSB = “Infinite”
Color Offset = “Up to 8 Layers +”
Line Color Screen Insertion / LCS = “up to 8 Layers +”

As we can see there are several possible combinations within the normal pipeline, but the most versatile would be:

VDP1 [Mesh Hardware + Mesh Software-Pattern / Texture + CC (HT / Shadow)] >> VDP2 Extended CC [Mesh Software-Pattern / Texture + Normal Shadow + Color Offset + LCS] = “Infinite” + Mesh

Which would be limited by the color types used in the VDP1 for the CC + Priority function of the VDP2 and the modes of said function.
And the normal Shadow should be processed before the CC.
Avoid black gradient in second layer of ECC.

Now if we add the BR trick to the pipeline:

VDP1 + [VDP1 + VDP2] + [VDP1> Transfer> VDP2] + VDP2 = “Infinity – Mesh” You

inherit: VDP1’s
- own casuistry but now OK with VDP2.
- Previous case series:
  - Which would be limited by the color types used in the VDP1 for the CC + Priority function of the VDP2 and the modes of said function.
  - And the normal Shadow should be processed before the CC.
  - Avoid black gradient in second layer of ECC.
We simplify color issues in transparency data for VDP2.
- We can have separate transparent opaque data in two Screens of the VDP2.
- At least with two different priorities.
We increase the quality (final real additive) and transparency calculation speed for large areas.
- We avoid the redraw problem in 3D elements and we can make transparency with them.
We finally remove the mesh in the middle. At least for close-ups or big things.
Less potential effective resolution. If you don’t use a path like Grandia: Transfer only specific tiles / characters.
You have the clipping problem which:
- In 3D you almost have it. In 2D games less or nothing, depending on the design.
- You draw more elements for mask. Which penalizes you in the VDP1 a little more.
- Or you are looking for the VDP2 to do it as we have talked about. Easier in 2D and 3D with CRAM colors. More complicated and limited with RGB colors.

The “prohibitions or limitations” that “are not”

Color spaces on source elements in CC VDP1: In theory the CC of VDP1 are restricted in origin to RGB data. But we can see in many games using Color Bank, both for half-Transparency as Gouraud or both combined. It is true that it is mostly about polygons with a flat color. Which can have its advantages in the quality of the gradients that the VDP2 gives up to 24 bits. But I have even seen a case of using on a source element with pattern / texture, it is true that it is difficult to see if it works or not. But it raises ways to investigate.

Using CC and priority with elements that are not color bank from VDP1: I have seen an example where Color LUT is used to later apply effects of the VDP2 unit of CC and priority on this data.

These situations are not documented, or used very little. They may be the subject of research for their advantages in making better use of the connection between VDPs and simplifying the use of them, with limitations, of course, but unknown today.

Possible solutions for limitations:

Solutions via software:

Bypass limitation not transparency between VDP1 and “VDP2” with HT of VDP1.

The real problem is that VDP1 does not know when it is drawing against the background of the framebuffer or on an already painted pixel. In this way and similarly the VDP2 also. If it could be marked using a real-time algorithm that reads pixels or groups of pixels (8×8 for example) from the framebuffer marked with a mask or characteristic color. And that this process, when detected by the mark, change the pixel data to a color bank (color bank + character data) with values of CC and priority determined in the CRAM of the CRAM.
Similarly to be able to use aspects of the Sprites VDP2 display unit and its CC function and priority for other needs. As from RGB source pixels but that we want to use for CC or priority, a similar solution would be possible.

Save VDP1 redraw problem.

Rasterize via software and dump the result in the form of a pattern + result colors in a primitive.
Rasterize via VDP1 in the free zone of the framebuffer and dump the result in the form of a pattern + result colors in a primitive.

Save problem of lack of mask and multiplicative modulation plus additive mixing of VDP1.

Rasterize via software and mix against the framebuffer directly. Very slow, valid for patterned areas and small areas. If larger is needed use the “advanced BR layer” mode using VDP2
Rasterize via VDP1 in the free zone of the framebuffer and mix against the framebuffer directly. Very slow, valid for patterned areas and small areas. If larger is needed use the “advanced BR layer” mode using VDP2

More CLUT modes.

I see it complicated. VDP1 stores via 4BPP ready hardware. I don’t know if they could be linked in any way, or alter the boundary to have 16x 4bit CLUT = 8bit CLUT. And thus have 256 colors on a 16bit palette or even be able to link it with its simile in the VDP2 as the 4bit CLUT.

Hardware changes:

Bypass limitation not transparency between VDP1 and “VDP2” with HT of VDP1.

With two MSBs instead of one. MSB1 and MSB2. To identify “destination transparency” of each unit. MSB1 for VDP1 and MSB2 for VDP2. The unwritten part of the framebuffer of VDP1 would be equal to VDP2, ie MSB2 = 1.
And a register like the MSBon to go to 1, the same but to go to 0 (Color Bank) from 1 (RGB).

Save VDP1 redraw problem.

Add to the general painting algorithm of the VDP1 that marks in 1 bit of the pixel / texel when it has already painted in the process. When you go through a marked pixel / texel again it will jump to the next pixel / texel.

Save problem of lack of mask and multiplicative modulation plus additive mixing of VDP1.

Copy CC technology from VDP2 to VDP1. Why did not it happen?

More CLUT modes.

Add 8BPP and 11BPP CLUT as in VDP2 on VDP1.

Was this disadvantage finally resolved?

Despite all the major drawbacks, in this case more than in others, YES, but only in part. Being very improvable in general. Let’s make a brief summary according to parties:

By the first parties of SEGA clearly. Sonic Team, Team Aquila and Team Andromeda. They pushed the machine to the limit with different results. For me the most notable and that set the bar at the PSX level or in some cases more: Sonic Team with Burning Rangers, Team Andromeda with Panzer Dragoon Saga and Team Aquila with SEGA World Wide Soccer saga.

half-Transparencies of multiple forms, the best without a doubt that of Burning Rangers.

For the second parties we find Treasure with Guardian Heroes, Silhouette Mirage and Radian Silvergun. Sonic! Planning Software with Shining Force III and Shining the Holy Ark. Traveller’s Tales with Sonic R. Realtime Associates with the Bug! Saga. Jumpin ‘Jack Software with Ghen War, Congo and Pandemonium!

Finally the Third parties Gremlin with Loaded. Attention To Detail with Blast Chamber. Microcabin with Blazing Heroes / Mystaria: The Realms. Nextech with Battle Arena Toshinden Saga, D-Xhird, Resident Evil … and many more. Like Altron with Tadaima Wakusei Kaitakuchuu !, Robo-pit, Mighty Hits, and more.

There are many more examples of each party. I only try to expose the best ones in my opinion and in a summarized way.

Now a more detailed list in chronological order according to the types of transparencies used in a selection of titles where I have been able to detect them, I have omitted those that used mesh because they are really of no interest in this analysis:

VDP1

Color Calculation Functions

VDP1 CC Shadow

1995

Blazing Heroes (U) / Mystaria: The Realms (E)
Ghen War
Gex
Devil Summoner: Shin Megami Tensei

1996

Congo: The Movie – The Lost City of Zinj
Return Fire
Dark Savior
Exhumed (E) / Powerslave (U)
The Incredible Hulk – The Pantheon Saga
Blast Chamber
Grid runner
Bug too!
Black Dawn

1997

J League – Go Go Goal!
Duke Nukem 3D
Nascar 98
Quake
Ninpen Manmaru

1998

Sokko Seitokai Sonic Council

VDP1 CC half-Transparency

1994

BIOS

1995

Panzer dragoon → Weapon trails
Robotica: Cybernation Revolt (1995) → explosions and UI mainly, noplots seen
Blazing Heroes (U) / Mystaria: The Realms (E)
Nekketsu Oyako
Bug!
From TV Animation Slam Dunk: I Love Basketball
Victory Boxing
Ghen War
Tadaima Wakusei Kaitakuchuu!
Battle Arena Toshinden Remix
Highway 2000 (U) (E) / Wangan Dead Heat (J)
Gex
Titan Wars (E) / Solar Eclipse (U)
Black Fire
Devil Summoner: Shin Megami Tensei

1996

Robo-Pit
Wipeout
Congo: The Movie – The Lost City of Zinj
Criticom
Magic Carpet
Return Fire
Virtual Golf
Keio Flying Squadron 2 (1996) (2D) → In all the flashes, explosions, and particle effects, not a mesh is seen.
Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 1
Lifescape – Seimei 40 Okunen Haruka na Tabi Disc 2

1996

Loaded
Impact Racing
NiGHTS into Dreams
Shockwave Assault
Road Rash
Destruction Derby
Terry Pratchett’s Discworld
Tokusou Kidoutai J SWAT
Dark Savior
Olympic Soccer
Wangan Dead Heat + Real Arrange
Actua Golf
Casper
Policenauts
Exhumed (E) / Powerslave (U)
Space Hulk: Vengeance of the Blood Angels
Tunnel-B1
Bottom of the 9th
Mighty Hits
Tomb Raider
The Incredible Hulk – The Pantheon Saga
Blast Chamber
Grid runner
PGA TOUR 97
Fighting Force (Judgment Force)
NBA Jam Extreme
Bug too!
NHL 97
Black Dawn
Andretti Racing
Shining the Holy Ark

1997

Amok
Soviet Strike
Pandemonium → Shadow, glitter or particle special effects, no raster, if opaque)
Scorcher → Green smoke or dust. It is almost certainly VDP1 HT when you are in first person on the real machine there are very strong slowdowns.
HEXEN
Battle Stations
D-Xhird
Welcome House
Swagman
Sonic Jam
Ferox
Terra Cresta 3D
Discworld II – Missing, presumed…
Assault Rigs
G-Vector
Layer Section II
Nascar 98
Sonic R
Vandal Hearts
Quake
Shining Force III Scenario 1/2/3 / Premium
FIFA 98 → Indoor field, crystals.
Grandia → Shadows, Water, Smoke Chimney, Cinematic Flash

1998

Jung Rhythm
Solo Crisis
Panzer dragoon Saga
Burning Rangers
Choro Q Park
Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night)
Lupine the 3rd Pyramid no Kenja
Wachenröder
Genso Suikoden

VDP2

Calculation Function NormalColor

VDP2 Screens

***defined*Ratios:**

1994

SEGA GAME SAMPLE 1 For SBL 1.1
- Magic carpet; CC priority and ratio / Normal / MSB Shadow demo; Color Line Screen Demo; Windows VDP2 and screens demo

1995

Panzer Dragoon
Cyber Speedway
From TV Animation Slam Dunk: I Love Basketball
Rayman
Wing Arms
Ghen War
Double Switch
Dragon Ball Z: Shin Butōden
Battle Arena Toshinden Remix

1996

Guardian Heroes
Sea Bass Fishing
Congo: The Movie – The Lost City of Zinj
Linkle Liver Story
Panzer Dragoon II Zwei
Dragon Force
Magic Carpet
True Pinball
Skeleton Warriors
The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
Keio Flying Squadron 2
Dragon Ball Z: Idainaru Dragon Ball Densetsu
Alien Trilogy
NiGHTS into Dreams
Decathlete / Athlete King
Road Rash
Albert Odyssey
Tokusou Kidoutai J SWAT
Blam Machinehead
Dark Savior
NBA Action 96
Exhumed (E) / Powerslave (U)
Lunar – Silver Star Story CPK / Lunar – Silver Star Story MPEG-ban or Complete
Sexy Parodius
3D Baseball
PriCla (Princess Clara) Daisakusen
Street Racer (Extra)
Fighting Force (Judgment Force)
Cyber Troopers Virtual-On
Sega WorldWide Soccer 97 / Victory Goal ’96
NBA Jam Extreme
Bug too!
Vatlva
Black Dawn
Shining the Holy Ark

1997

Amok
Fighting Illusion K1 Grand Prix
Sonic 3D Flickies’ Island
Soviet Strike
Assault Suit Leynos 2
Gundam Side Story 3 / Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
Scud The Disposable Assassin
Manx TT
Tempest 2000
Doom
MechWarrior 2: 31st Century Combat
NBA Live 97
Touge King the Spirits 2
D-Xhird
Swagman
Sonic Jam
Samurai Shodown RPG
Trash It
Bulk Slash
Thunder Force V
Darklight Conflict
Resident Evil
Last Bronx
Rockman X4 (Mega Man X4)
Terra Cresta 3D
Madden NFL 98
Desire
Silhouette Mirage
Croc : Legend of the Gobbos
WipEout 2097
Söldnerschild / Soldnerschild
The Lost World Jurassic Park
Asuka 120 Burning Fest
Sega Worldwide Soccer 98 / J. League Victory Goal ’97
Steep Slope Sliders
Nascar 98
J.League Pro Soccer Club or Tsukurou! 2
Mass destruction
Sonic R
Quake
Princess Crown
Shining Force III Scenario/ Premium
FIFA 98
NBA Live 98
Grandia
1/2/3Ninpen Manmaru

1998

Chill
Sokko Seitokai Sonic Council
Winter Heat
Burning Rangers
Sega Ages – Power Drift
Stellar Assault SS
My Fair Lady Virtual Maajan
Dragon Force II
Savaki
Gungriffon II
Baroque
MeltyLancer Re-inforce
World League Soccer 98
Lunar 2 – Eternal Blue
Pro Yakyuu Greatest Nine ’98 Summer Action
Genso Suikoden
Sorvice
Cotton boomerang

2000

Final Fight Revenge

Mode “as is” (difficult to spot incomplete or inaccurate list )

Grandia
Burning Rangers

Window / Clipping / Masks and Priority / ”Z-Buffer”

Window W0 / 1 Activated:

1995

- Virtua Fighter 2
- Titan Wars (E) / Solar Eclipse (U)
- Sega Rally Championship

1996

- Sea Bass Fishing
- Panzer Dragoon II Zwei
- Pro -Pinball: The Web
- Wangan Dead Heat + Real Arrange
- Casper
- Fighting Force (Judgment Force)
- Shining the Holy Ark

1997

- Assault Suit Leynos 2
- Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
- Indepen dence Day
- Doom
- FIFA 97
- Formula Karts
- Moon Cradle
- Terra Cresta 3D
- Croc: Legend of the Gobbos
- DoDonPachi

1998

- BATTLE GAREGGA
- My Fair Lady Virtual Maajan
- MeltyLancer Re-inforce
- Initial D: Koudou Saisoku Densetsu
- Deep Fear
- Wachenröder
- Capcom Generations 1
- Cotton boomerang
- Capcom Generations 4

1999

- Street Fighter Zero 3

2000

- Final Fight Revenge

Special Priority Mode 1 per pixel Activated:
- Sega Rally Championship (1995-12-29)
- Guardian Heroes (1996-01-26)
- Wipeout (1996-02-29)
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden (1996-04-26)
- Keio Flying Squadron 2 (1996-05-17)
- Rockman 8 (1997-01-17)
- Tempest 2000 (1997-03-20)
- Metal Slug (1997-04-04) )
- Rockman X4 (Mega Man X4)
- Silhouette Mirage (1997-08-01)
- DoDonPachi (1997-09-18)
- Princess Crown (1997-12-11)
- Real Bout Fatal Fury Special ()
- 1997-12-23Sokko Seitokai Sonic Council (1998-01-29)
- BATTLE GAREGGA (1998-02-26)
- Akumajo Dracula X: Gekka no Yasokyoku (aka: Castlevania: Symphony of the Night) (1998-06-25)
- Street Fighter Zero 3 (1999- 06-08)
- Albert Odyssey (1996-08-09)

Special Priority Mode 2 by tile Activated:
- Lunar – Silver Star Story CPK / Lunar – Silver Star Story MPEG-ban or Complete (1996-10-25)
- Assault Suit Leynos 2 (1997-02-21)
- Grandia (1997-12-18)

VDP1 Sprite Screen + VPD2 Screens

Conditional and / or Priority + Ratio:

Color Calculation = Priority> <== CC Condition Number.

1994

- SEGA GAME SAMPLE 1 For SBL 1.1
  - Magic carpet; CC priority and ratio / Normal / MSB Shadow demo; Color Line Screen Demo; Windows VDP2 and screens demo

1995

- Cyber Speedway
- From TV Animation Slam Dunk: I Love Basketball
- Rayman

1996

- Guardian Heroes
- Sea Bass Fishing
- Dragon Force
- True Pinball
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden
- Keio Flying Squadron 2
- Dragon Ball Z: Idainaru Dragon Ball Densetsu
- Albert Odyssey
- Blam Machinehead
- Lunar – Silver Star Story CPK Lunar – Silver Star Story MPEG-ban or Complete
- Sexy Parodius
- PriCla (Princess Clara) Daisakusen
- Fighting Force (Judgment Force)
- Sega WorldWide Soccer 97 / Victory Goal ’96
- NBA Jam Extreme
- Vatlva
- Shining the Holy Ark

1997

- Fighting Illusion K1 Grand Prix
- Assault Suit Leynos 2
- Scud The Disposable Assassin
- Tempest 2000
- Doom
- Touge King the Spirits 2
- D-Xhird
- Swagman
- Samurai Shodown RPG
- Trash It
- Bulk Slash
- Thunder Force V
- Darklight Conflict
- Resident Evil
- Last Bronx
- Terra Cresta 3D
- Madden NFL 98
- Söldnerschild / Soldnerschild
- The Lost World Jurassic Park
- Asuka 120 Burning Fest
- Sega Worldwide Soccer 98 / J. League Victory Goal ’97
- Steep Slo pe Sliders
- Nascar 98
- Mass destruction
- Sonic R
- Princess Crown
- Shining Force III Scenario 1 / 2 / 3 / Premium
- FIFA 98
- Grandia

1998

- Chill
- Sokko Seitokai Sonic Council
- Sega Ages – Power Drift
- Stellar Assault SS
- Savaki
- Gungriffon II
- MeltyLancer Re-inforce
- Lunar 2 – Eternal Blue
- Pro Yakyuu Greatest Nine ’98 Summer Action
- Genso Suikoden
- Sorvice
- Cotton boomerang

2000

- Final Fight Revenge

Conditional Color Calculation = MSB Color Data

1995

- Ghen War
- Double Switch
- Dragon Ball Z: Shin Butōden
- Congo: The Movie – The Lost City of Zinj

1996

- Linkle Liver Story
- Magic Carpet
- NiGHTS into Dreams
- Decathlete / Athlete King
- Road Rash
- Tokusou Kidoutai J SWAT
- NBA Action 96
- 3D Baseball
- Street Racer (Extra)

1997

- Soviet Strike
- MechWarrior 2: 31st Century Combat
- Touge King the Spirits 2
- Sonic Jam
- Silhouette Mirage
- J.League Pro Soccer Club o Tsukurou! 2
- NBA Live 98

1998

- Winter Heat
- My Fair Lady Virtual Maajan
- Dragon Force II
- Baroque
- World League Soccer 98
“as is” mode (difficult to detect incomplete or inaccurate list)
- Guardian Heroes

Window / Clipping / Masks and Priority / “Z-Buffer”

- Sprite window: Activated in the vast majority of titles.

Extended Color Calculation (ECC) Function Color

1995

Battle Arena Toshinden Remix

1996

Linkle Liver Story
Alien Trilogy
NiGHTS into Dreams
Dark Savior
PriCla (Princess Clara) Daisakusen
Sega WorldWide Soccer 97 / Victory Goal ’96
Bug too!

1997

J.League Pro Soccer Club o Tsukurou! 2
Sonic R
Shining Force III Scenario 1 / 2 / 3 / Premium
NBA Live 98
Grandia

1998

Savaki
Cotton boomerang 2
D-Xhird
Wachenröder

Offset Calculation Sprite

For Screen, Layer Screens, Color Line and Back Screen

In the vast majority of games I have analyzed. The list would be too long.

Line Color Screen Insertion

1994

SEGA AMx – GAME SAMPLE – SGL 1 (1994)
- Magic carpet ; CC priority and ratio / Normal / MSB Shadow demo; Color Line Screen Demo ; Windows VDP2 and screens demo

1995

Panzer Dragoon 1 → Gradient infinite plane horizon.
Wing Arms

1996

Guardian Heroes
GunGriffon
Panzer Dragoon Zwei → Gradient infinite plane horizon.
Dragon Ball Z: Idainaru Dragon Ball Densetsu
NiGHTS into Dreams
Decathlete / Athlete King
Battle Arena Toshinden URA
Sega WorldWide Soccer 97 / Victory Goal ’96 → Gradient field horizon.
Street Racer (Extra)
Shining the Holy Ark

1997

Shinrei Jusatsushi Taroumaru
Gundam Side Story 3 Kidou Senshi Gundam Gaiden III: Sabakareshi Mono
Independence Day
D-Xhird
J League – Go Go Goal!
Sonic Jam
Bulk Slash
Thunder Force V
G-Vector
Sega Worldwide Soccer 98 / J. League Victory Goal ’97
J.League Pro Soccer Club o Tsukurou! 2
Sonic R ← Water Waves with Animated Color Line Display + ECC
Ninpen Manmaru

1998

Dragon Force II
Savaki
Gungriffon II
World League Soccer 98
Radiant Silvergun
Grandia → Full-Color Glow Magics ← Could be Color Offset
Pro Yakyuu Greatest Nine ’98 Summer Action
J.League Pro Soccer Club or Tsukurou! 2
Panzer Dragoon Saga → Gradient infinite plane horizon.
Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998) ← Water Level first castle rooms against various screens, or on top of all

Function Shadow:

Shadow MSB
- SEGA GAME SAMPLE 1 For SBL 1.1
  - CC+priorities + MSB / Normal Shadow demo
- Astal
- Sexy Parodius
- The Story of Thor 2
- Shinrei Jusatsushi Taroumaru
- J League – Go Go Goal!
- Asuka 120 Burning Fest
- Mass destruction
Normal Shadow
- SEGA GAME SAMPLE 1 For SBL 1.1
  - CC+priorities + MSB / Normal Shadow demo
- Astal
- From TV Animation Slam Dunk: I Love Basketball (1995-08-11)
- Guardian Heroes (1996-01-26)
- Skeleton Warriors (1996-04-16)
- The Story of Thor 2 / The Legend of Oasis / Thor: Seireioukiden (1996-04-26)
- Three Dirty Dwarves (1996-09-27)
- Lunar – Silver Star Story CPK / Lunar – Silver Star Story MPEG-ban o Complete (1996-10-25)
- Sexy Parodius (1996-11-01)
- Fighting Illusion K1 Grand Prix (1997-01-31)
- Shinrei Jusatsushi Taroumaru (1997-01-17)
- Soukyugurentai (1997-02-07)
- Drift King Syutokoh Battle 97 / Shutokou Battle ’97: Tsuchiya Keiichi & Bandou Masaaki (1997-02-28)
- FIFA 97 (1997-04-04) → Without CC and without Transparent Shadow Enabled? How will do?
- J League – Go Go Goal! (1997-05-30)
- Moon Cradle (1997-06-27)
- Silhouette Mirage (1997-09-11)
- Asuka 120 Burning Fest (1997-10-09)
- Layer Section II (1997-10-30)
- Mass destruction (1997-11-20)
- FIFA 98 (1997-12-17)
- Courier Crisis (1997-12-20)

Transparency Software + Hardware: VDP1> transfer> VDP22

Arcana Strikes (1997-12-11)
Grandia (1997)
Burning Ranger (1998)
XL engine (2019)

Transparency Software render

Scorcher (1997) → Halos. When you are in first person on the real machine there are very strong slowdowns with a far camera and medium good speed.
Die Hard Trilogy (1997) → Halos / flashes and fire / explosions. When you are in the first person and you have large occupied areas with transparencies in the real machine, there are very strong slowdowns.
Soul Hackers Devil Summoner (1997) → Hiding effect with transparency VDP1.
Sonic R (1997) → CPU rendered environmental mirror plus transparency with VDP1.

Use of various SS Transparency options (VDP1, VDP2 or others) A selection:

1995

From TV Animation Slam Dunk: I Love Basketball

1996

Congo: The Movie – The Lost City of Zinj
Magic Carpet
Keio Flying Squadron 2
NiGHTS into Dreams
Road Rash
Tokusou Kidoutai J SWAT
Dark Savior
Policenauts
Street Racer (1996) → Round shadows and UI VDP1> VDP2 / Shadows + clouds VDP2 RBG color ratio over VDP2 RBG / VDP1 + VDP2 3D Near Clipping 3 Level Fade to VDP2
Bottom of the 9th
Mighty Hits
Fighting Force (Judgement Force)
NBA Jam Extreme
Shining the Holy Ark

1997

Shinrei Jusatsushi Taroumaru
Soviet Strike
D-Xhird (1997) → VDP1> VDP2 CC + Ratio, Extended and Normal CC VDP2, Line Color Screen and / or Gradient Function. Adapted to each setting and effect sought. And in menus.
J League – Go Go Goal!
Darklight Conflict
Mass Destruction (1997) → CC+Ratio, MSB ON, Transparent Shadow Enabled, Normal CC VDP2
Nascar 98
Sonic R (1997) → CC+Ratio, Color Line Insertion Animado, VDP1 CC Half-transparent, Sprite Window Enabled, Extended, Normal CC VDP2 and Mesh.
Shining Force III (1997)→ VDP1>VDP2 CC+Ratio, Color Line Insertion?, VDP1 CC Half-transparent, Normal CC VDP2.
FIFA 98
Grandia (1997)→ VDP1>VDP2 CC+Ratio, Color Line Insertion?, VDP1 CC Half-transparent, VDP1 transfer to VDP2 trick.

1998

Jung Rhythm
Panzer Dragoon Saga (1998)→ VDP1>VDP2 CC+Ratio, Color Line Insertion?, VDP1 CC Half-transparent
Sokko Seitokai Sonic Council
Burning Rangers (1998)→ Burning Rangers Transparency Trick, VDP1 CC Half-transparent and Mesh.
Akumajo Dracula X: Gekka no Yasokyoku (aka. Castlevania: Symphony of the Night) (1998)→ VDP1>VDP2 CC+Ratio, Color Line Insertion, VDP1 CC Half-transparent and Mesh.

Before finishing this point, I would like to make a final reflection on this topic. The issue of transparencies on SEGA home machines has been an almost constant problem. From the Megadrive / Genesis against the SNES and then with the Sega Saturn. It is curious how even, on Arcade machines, at least until Model 3. There did not seem to be a clear interest in SEGA either. It is true that in one way or another they can be done both in SMD / Genesis or SS, even more so in the latter as we have seen. But that would work well and easily as in the competition, no. Even SEGA’s own internal teams also did not show much interest in them. Seeing how in most games the easy solution of “mesh” or “dithering” was chosen.

As a climax after all the drama that involved. SEGA finally got rid of the “issue of transparencies” at the domestic level and even in the Arcades with the PowerVR2 for DC/Naomi1-2. This gave SEGA the the hardware algorithm for transparencies most accuratethat has been around for a long time. Speaking on home consoles or PC chips, of course.

To finish the section, as usual. Let’s take a closer look at three games that stand out to me in this particular way:

Loaded

1996-06-01. Launched in the middle of the 3rd wave. You could already see how the European developers were already beginning to master SS more easily. Also thanks to the arrival of the new SEGA SDK, SGL in part, which helped developers make better use of the machine, as we can read in a quote from Wikipedia.

All in all, we can see how in this game the usual trend was, not dedicating enough resources to the SS version and even delaying releases a lot, in this case one year in the USA and almost half a year in Europe. This as we can understand does a lot of damage to a platform in the face of strong competition. But it is what it was.

We can only see a programmer assigned to this port. The rest of the accredited appear as from the original version of PS1, to what extent they helped in this port, we do not know. Gremlin generally has no bad ports or games for SS. In fact at the time, they made games that are very high in 3D technology. Very soon using Gouraud effects, fog, dynamic color lighting, 3D great worlds and with many elements. Loaded is one of them.

We are facing a really spectacular game. So much today, imagine at the time. I clearly remember seeing this game on PS1 in “Legends,” the video game store in my town, and literally exploding my head. The dynamic lights in color, the amount of objects and things that happened on the screen. And of course: The number of transparencies! I remember, before the SS version came out, talk to my friends at the store, my cousin Nono about everything and Carlos. About the most important features of the game that in SS would be difficult to see or not be. Color lighting and transparencies was one of them.

Doing justice to the time, we have to say that the port is very close to the original. Very close. The differences are minimal. Different resolutions for the menu. Strangely in SS the final resolution is 352×224 while that of the VDP1 is 320×240. On the other hand the rest of the game runs at 352×240, at a little more full resolution than on PS1. While on PS1 the menus are at 512×256 and the rest at 320×256. And of course, the transparencies. But in this case the differences are minimal, the only element that does not have transparency with respect to the original, are the explosions. It is true that it is a very attractive and important element. And maybe the reasons for this were that they are Distorted Sprites with rotation and it is also an element that is using color bank. They are not a billboard like in other cases, where the transparency of the VDP1 can be guaranteed to work correctly. The rest as I say this, in this game where everything is being drawn with the VDP1, it was quite direct to make use of the transparencies, also in a lot of quantity and size. This was one of the games that have most impressed me in this research that I have done, I was shocked to see so many “prohibited” features in the same XD game.

Everything else is intact. The resolution and probability of color in the textures was identical. As everything is identical but with the understandable hardware differences. Dynamic lighting with color Gouraud is identical on both machines. The only difference is that in SS they tend to be more black than in PS1 which tends to have brighter dark areas. It is because of the difference in Gouraud between machines. You could say that the SS version is darker. But it was something that could be corrected, with a little more work. The only problem is that some very dark areas on PS1 on SS really are too dark.

On performance, we would be almost on par. In SS the 30 / 25FPS are maintained almost all the time. But where there were already drops on PS1 in SS they are somewhat more pronounced, about 20FPS. This game may have an optimization problem on the CPU, because with what you see on screen, over 400 quads the VDP1 could handle it without problem. The amount of on-screen geometry is the same, or very similar, to the PS1. And the fruit of the poor performance may be that the PS1 code has been partly transferred to SS. Well, we can see the typical flickering in the PS1 textures in this version. The use of VDP2 is null, absolutely nothing.

Although it is curious, we can find some very advanced interesting details, in addition to those of dynamic color lighting and the use of transparencies, two great features for the machine and the time. One of these details is the presence of the use of “Render-to-Texture”. Something complicated for SS, easy on PS1. But in Loaded we can see it in up to three different scenarios:

- In the game pause menu. When we pause it is used to make the background texture. I really see it as something excessive, but that’s the way it is. That little lag there is when you pause is to pass the information from the framebuffer to a few textures in the VRAM of the VDP1. In this case it is 352×128. Not the entire screen, about ⅓ of the top total.

- On the UI and map in the upper left corner. The graphics you see there are textures that are painted, presumably by the CPU, and sent to the UI every time they refresh. I also see it as excessive. Because you could see echo with the VDP1 perfectly, or even with the VDP2, a part at least.

- Finally, and I am not 100% clear. They are the loading screens. When we ask the Yabause debugger to tell us there is nothing on any VDPs. But if we disable the VDP1 / Sprites layer, it goes away. We can deduce that it is being painted directly in the FrameBuffer in the VDP1 part. We could be facing a Render from the CPU to the Framebuffer directly. Another overcomplication, in principle.

We can find FMVs with a very good quality. Full screen and high compression, at a quality close to PS1.

Finally the use of the machine is remarkable. They use 2xSH2 throughout the FMV game and the 3D game. We can see a use of SCSP-DSP, possibly for CD-DA sound. The main RAM usage is 95% HRAM and 75% LRAM. The VRAM usage of VDP1 is 90%. Finally, the VRAM of the VDP2 is being used at the memory level, 50% in the pattern / patterns part and 60% in the CRAM. The only signs of use are in some elements with a bank color such as: Flat polygons with transparency, some textures such as explosions … The rest of this use is unknown.

Pandemonium!

1997-02-28. Being a development of the 4th wave of developments, in this case from the USA. By Jumpin ‘Jack Software team second party SEGAat the time. It never ceases to amaze me as in my research, but I always seemed to see that it had transparencies. And so it was, but if I have to define this port in any way, it is like aport bold and irregular.

Jumpin ‘Jack Software closes your life with this port. That it was not even officially accredited. They were daring, because they started programming on a completely different type of engine and game than what they had been doing so far. They went from FPS to a 3rd person platform with a fixed camera. In addition to making a port, not an original game from them. So they left behind their Engine 3D and ported the famous and successful PS1 game for SS, the machine they knew very well. It is true that none of his previous games were excellent, but regarding FMV they were. Strangely in this game, knowing Duck well, more than Cristal Dynamics also knew him and used him with mastery. It has bad FMVs. Small 256×160 and poorly compressed. It is totally, incomprehensible more when the Crystal Dynamics logo looks great at 320×200. First two signs of daring on the one hand and manifest irregularity on the other.

Now let’s move on to the game itself. Menus, maps, models, animations, levels, secrets … everything is pinned to the original. For this game they had to deal with dynamic color lighting by Gouraud who had the original and they got it. But they also had to deal with a large number of transparencies and they did it, halfway. Halfway because some are still missing, it is true that very few, transparencies (as in the UI, the waterfall of the first level or the crystals of the final enemy). And without usingat any time mesh mode. And in this they were bold. But irregular, because they use the transparencies in 3D elements not billboard showing VDP1 errors in the transparency and really important slowdowns because of it. Or using them against VDP2 backgrounds that can occupy large areas of the screen, completely canceling the transparencies used by them, totally those of VDP1. Because there is no trace of using the VDP2 transparencies in any of its forms. If this we add a conversion of models to quads in some cases deficient, with too many triangles, also causing these slowdowns. And in general, a very irregular performance optimization with frame drops at enough points, even affecting gameplay, for example in the final boss. The game runs at just 25FPS in many sections of the game and mostly global. But at very specific times it drops below 15FPS or less. Not seen more than 450 quads on the screen, maybe 500. It is not an amount that for the VDP1 is a problem, only if it is not using as it should or even the part of the CPUs is not sufficiently optimized.

I have several theories. This was practically, I am almost certain, a SEGA “gift”. They sensed that it would be the last. Possibly on a very tight budget. All this together with a number of new challenges that I had to face. All this I do not think it helped to reach the maximum goal. It must be said that we can see a use of SCU-DSP in this game, which I have not seen in their previous titles, and that may mean that they wanted to go further and better with the SS hardware. But sadly they did not succeed, they stayed halfway.

The use of the hardware on the other hand is very good. Using the 2xSH2 + SCU-DSP both in 3D and in the FMV. Reaching a memory usage of the SCU-DSP of 60% and a use of its registers of 39.13%. Although it has MIDI music, we did not see a clear use of the SCSP-DSP, something curious. But if Yabause signals up to 35% in the memory of the sound DSP.

The main RAM usage is at 65% LRAM and 90% HRAM. For the VRAM of the VDP1 in 80%. Finally, the VRAM of the main VDP2 at 35% and the CRAM at 30%.

Burning Rangers

We are talking about possibly one of the best 3 games in the SS. Without a doubt, on a technical level it is outstanding. It is true that it was already one of the last, belonging to the 5th and last wave of Japanese first party developments. Published early 1998-02-26. But turning out to be a 3D platforms with a 3rd person camera that fully lives up to many similar titles on PSX.

In 1998-12 Sonic Adventure for DC is published. They worked on both at the same time. All programmers. Some worked on Nights, others on Sega Rally or 32X Metal Head.

Burning Rangers is presented in HD in all its initial logos and menus at 704×224 in interlaced Dual-density mode, giving us about 704×448 points on screen, second to none at the time. In the rest of the game it goes to an SD resolution of 352×224 (NTSC). Always at 16bit color. Except for 24-bit color FMVs.

The 3D Engine is spectacular for the moment but in the final details it is somewhat irregular.

It is possible that the Sonic Team used some SGL 3.x version. Since two years earlier for Nights it was one of the first SEGA teams to use SGL1.x. Plus the dragged modifications of Nights and new, and unique, features developed internally by the Sonic Team for this Burning Rangers.

But the quintessential feature defined by the game’s title is the transparency layer Burning Rangers has. A genius of trick, which was a real shame that it appeared at the end of his life. Alternately renders the same frame in two batches. The first one is the opaque elements at full 352×244 resolution. Then render at half of the total resolution, ie 160×122, the transparent elements plus the mask elements. Where the latter are still the same geometry as before but in black.

I have come to see 1200 total quads approximately. All with Gouraud, the vast majority of them textured. Where which were between:

200/855 opaque elements + 100/150 transparent elements + 50/150 mask elements

We can see that the mask elements are very low, this may be one of the causes of Z-fighting of the elements Transparent in this Burnign Rangers.

All this must be limited, because sometimes the same transparent particles are drawn on the opaque layer. Perhaps even a limit of quads are allowed in the transparency layer and from there they are not drawn or passed to VDP1.

Even on a few occasions the mesh mode is used in some elements such as: Smoke, shadows, teleportation … A pity, because in my point of view you could see the transparency layer used for them. Perhaps there was some prop problem with shadows when passing over water or glass. But I think that using the VDP1 correctly all these elements could be transparent without problems. For equal smoke, or sandwiching the VDP2 layer with the VDP1 transparency…. In short, only alternatives are possible.

What is CLEAR. And it is HUGE. Is that this team made the fire, and the most beautiful and spectacular particle effects in the system. The water and light beams from the second mission are AMAZING for the SS. Giant glazed windows. I remember literally exploding my head when I saw it. And keep hallucinating a lot every time I see it.

As I point out. This amount of transparencies on screen, especially the area and the number of elements, even evaluating the cost of transferring the data from VDP1 to VDP2. They make this quantity and quality of transparency very seriously rival the PS1.

To finish off the transparencies. Note that those of the VDP1 are also used. In this case only in the UI. With various problems. The first that the transparency layer of VDP2 covers the UI elements that are drawn in VDP1. As it is above the drawing priority. This overlap could have been avoided, transferring the elements of the UI in black in the same way as those of the stage. Or using color back with priorities and ratios for the opaque elements and position them on top of the transparency layer. The second is that the transparency of VDP1 when it is on the background in VDP2 does not work. They could have used their own transparency layer trick to make these elements transparent plus the transparency of the VDP1 so that it would work properly with everything.

It is true that the drawing distance is relatively short, being abrupt on too many occasions. The culling system is very basic or possibly non-existent. Since with the wirerame activated we can see a large amount of geometry behind the walls or doors. The culling that you are implanting safely is the Back culling. Convex quads for steps are seen, something very daring, but possible for the VDP1. They don’t use LODs, nor do they mip-mapping. Neither Depth cueing, curious because they did not use it in Nights either and even more curious because the latter was already implemented in SGL 3.x. You can see how in the polygon transformation calculation there is a clear fliquering (in vertices) like Tomb Raider or Loaded. It may be because a low precision was used in the transformation and projection of vertices. We also observe, more often than we would like, a very pronounced Z-figthing and also a corner junction with overlaps.

There is Gouraud lighting throughout the game. Static (also animated) pre-calculated in color in spectacular settings that affects 3D entities completely without source. This simplification of lighting may have been expensive for optimization. Although it still has dynamic point light details in explosions. Finally there is a fully dynamic color spotlight (like the Silent Hill flashlight) in the dark sections.

With all that said, I have incredibly Burning Rangers stable. Very stable. It is also true that it is running at 20FPS. In fairness, it puts the machine to the limit. Perhaps they lack to optimize something more to be able to see arrived at 25 / 30FPS. With a dynamic subdivision or LOD, both to increase the drawing distance and better culling. Adding a Depth Cueing in some way would also have smoothed the drawing distance. Plus a mip-mapping to lower the requirement to VDP1. Perhaps with all of these they could have lowered the almost doubled requirement that they had when rendering the two layers. Even to see improved the aspect, reducing the Z-figthing.

Although in the end what really makes everything show is also the originality, quantity and quality of the art. It is a game that even today is enjoyed and looks fresh and unique.

Finally, with large FMV, that if with the Codec Cinepak in its final variant .CAK, but very well used in this case for the type of content. The Anime to Cinepak is doing very well the truth. Along with an ADX audio stream, they push the codec and the highest quality for this great SEGA title. Perhaps it lacks in my point of view a bit of resolution, the 296×216 being a tad short for the quality of the animation made.

With magnificent music, using ADX ADPCM multistream sound .acx for it and the dialogues (continuous throughout the game as it is a mechanic of it). Playing up to three (Stereo music and two mono dialogs at the same time) stream at one time at excellent sampling and quality. This was another feature that put sound quality on par with PSX. Also with echo and reverb effects, almost certainly via SCSP-DSP, which are perfectly noticeable. Perhaps one of the games where these effects that I like so much are used more and better. SCSP-DSP usage reaches 95% memory usage. And the M68x at 60% in the registers.

As we have been exposing the use of the machine is absolute. Coming to use 70 LRAM and 80% of HRAM. On the other hand, up to 85% of the VRAM of the VDP1 and 60% of the VRAM VDP2 for patterns / patterns and 100% of CRAM of the VDP2.

The use of processors is very high, as it could not be otherwise. Using 2xSH2 + SCU-DSP throughout the game. A user in Segaextreme quantified the use of the SH2 slave by 60% Slave. In FMV, menus and during 3D game. I have had many doubts about the use of SCU-DSP in this game. Finally, the most possible is that this use is by the ADX codec, and also for the transfer of the transparency layer to the VDP2. It may have been used for lighting as well, but I see it less likely. Reaching 13% of the registers and 70% of the memory in both FMV and 3D parts.

End of the fourth part.

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:

Thursday July 2nd, 2020 at 01:07 AM

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:

Thursday July 2nd, 2020 at 01:23 PM

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