Transparency issues

All versions of SADX suffer from problems with rendering transparent models, which play a major role in visual downgrades. The original game took advantage of SEGA Dreamcast’s hardware features that were impossible to replicate on the Gamecube and other platforms. When the game was being ported to other platforms, the developers ran into numerous transparency-related problems with ingame assets. Some of such problems were fixed, but in the majority of cases the problematic assets were redesigned, usually without much care for quality or style of the original game. Let’s discuss the transparency issues in general, have a look at some specific problems and see how they could’ve been fixed.

In many ways, the Dreamcast was a console ahead of its time. One of the Dreamcast’s unique features was its PowerVR GPU. It was equipped with a hardware feature called order-independent transparency (OIT). No console before or after the Dreamcast ever had that feature built in on the hardware level, and it took many years until mainstream GPUs became capable of dealing with order-independent transparency.

Why is this significant? Traditionally, in 3D graphics rendering transparent objects is a pretty complex problem. To properly display transparent models together with non-transparent models, the polygons in a 3D scene have to be rendered in a specific order. Transparent polygons have to be rendered after opaque polygons in back to front (furthest to nearest) order to ensure the transparent blending operations are performed correctly. The framebuffer is the “canvas” on which the polygons are “painted”. The order is important because once something’s been “painted” onto the framebuffer, you cannot simply put something behind a transparent object that’s already there.

In complex scenes with many transparent objects and moving camera this can become a problem because the engine needs to tell what is visible from the current camera angle, whether the visible polygons have transparency or not, and how close they are to the camera, all of which would influence their draw order. On top of that, the composition of each model should ensure that the transparent polygons are processed after the opaque polygons, not before. Even modern games struggle with transparent things sometimes.

With order-independent transparency the above issues are irrelevant. The polygons can be processed in any order, and transparent and non-transparent polygons are sorted automatically by the Dreamcast’s GPU. In the case of SA1, up to 32 layers are sorted per pixel using 32×32 tiles, while other games, such as Omikron: The Nomad Soul, require 64 layers to look correct (according to MetalliC, the developer of Demul, the Dreamcast can sort up to 256 layers). This allowed the developers of Dreamcast games to create complex scenes involving transparent things without worrying about draw order. It was also unnecessary to have a strict model hierarchy of transparent and non-transparent polygons. Sonic Adventure is one of such games where the ingame assets are mixing transparent and opaque polygons without any consistency.

When the game was being ported to the Gamecube, the benefits of order-independent transparency were no longer there, and the developers ran into numerous problems involving transparent models. They tried to address them in two ways:

1. A draw queue system was set up to tell the game which models should be rendered in what order. While technically not bad for a game of that generation, the draw queue system doesn’t always work right in this game because of code bugs, and, judging by the disassembled code, the developers themselves didn’t know very well how to use it. The most common issue with the draw queue system is transparent objects disappearing when you move the camera. This happens pretty often throughout the game, check out Twinkle Park or Hot Shelter for examples.

Sometimes the draw queue can’t handle transparent things because of engine limitations. For example, look at the aquariums in Hot Shelter Act 1:


The water behind the green glass is invisible in SADX, but it’s still there – here’s a part of it that manages to clip through the glass. This scene requires the water to be rendered first so that the green glass can be rendered on top of it. The reason it doesn’t render in SADX is that the water here is an interactive object (SET object), whereas the green glass is a level piece, and the game always renders objects after level pieces. This confuses the draw queue system and makes all transparent things behind the green glass disappear.

2. Alpha rejection was an additional measure to hide transparency problems or make them look less terrible. For textures with an alpha channel, the game only displays the pixels whose transparency (alpha) value is within a certain range. This allows some models with a grid-like transparent pattern (fences in Speed Highway and Hot Shelter, paths in Windy Valley) to look acceptable even though the game is still struggling with rendering them. Here are some examples of alpha rejection:

This doesn’t look too pretty, but at least it helps a bit. However, the problem with alpha rejection in SADX is that it also breaks a lot of completely unrelated special effects. In Perfect Chaos, alpha rejection causes special effects such as waterfall splashes and mist to flicker or disappear. Check out the Bosses section for a comparison. Also, all particle effects now have ugly outlines that makes them look low-res. Water splashes, dust, fire, explosions – all of these look lower quality than they are because of this feature. Here’s an example from Lost World:


Even with the above workarounds in place, the game still has a huge amount of transparency issues. There is no solid proof for this, but I’m inclined to believe that the majority of “stylistic” changes in SADX were made because the port had problems displaying the original assets correctly. I think so because I’ve imported Dreamcast levels into SADX myself and found out that almost all levels that look different in SADX had transparency issues with their original Dreamcast designs.

Here’s a typical SADX redesign. This roof had a triangle-shaped pattern in the Dreamcast version. In SADX the pattern was removed and the roof was made solid:


This was likely done because the triangle pattern is a square texture with an alpha channel, which had rendering problems in SADX. Here’s a screenshot from the “Preview” prototype where this area is still using Dreamcast graphics:

In fact, you can still see issues with textures like that in the final version at some camera angles if you try hard enough:

There appears to be a strong correlation between the areas that were redesigned and the areas that had rendering issues in the port with their original designs, which is why I believe the majority of those redesigns were done to get rid of transparency problems. As you can see, even the replacement assets don’t always work well.
NOTE! The above point is speculation on my part. My opinion is based on my experience with both games. However, the only way to know why the assets were redesigned is to ask the people involved with the ports, which is unlikely to happen anytime soon. There are other possible reasons for SADX redesigns, which will be discussed in a separate section on this blog in the future.

Even within the engine limitations, most transparency issues in SADX are fixable by rearranging the models involved, which is usually just moving around a couple of lines in code. Let me illustrate a typical transparency problem in SADX and how it can be fixed within the limits of SADX engine:

Here you can see a shop roof that has to be rendered together with its surroundings. Let’s describe all the meshes involved in this scene:

  • 1 – roof top (opaque)
  • 2 – roof side (opaque)
  • 3 – roof top decoration (transparent)
  • 4 – wall
  • 5 – window reflection (transparent)

To render this properly on platforms other than the Dreamcast, we have to arrange these meshes in the correct order, which would be 4, 1, 2, 5, 3. We render the non-transparent pieces first, starting with the wall, and then we render the transparent parts, finishing with the one that should be layered on top of the previous one. In order to render these assets like that, we have to make sure the level pieces are arranged in this particular order. However, in the Dreamcast level the order could be anything, which is why there are issues when the original level is imported as-is. There are cases when this gets complicated, but for the most part rearranging the models is quite easy. However, instead of rearranging the problematic models (which probably would’ve taken less time and effort), the developers decided to redesign those areas with new textures and models. The redesigned assets sometimes fail at conveying the atmosphere of the original game. Quite often they lack the variety or special effects of the original, or have lower quality textures. There are also cases where the developers didn’t redesign or fix the models that still have transparency issues. Almost every level in SADX has problems related to transparency. You can read more on level-specific problems by using the top menu.

I resolved the majority of transparency issues with Dreamcast assets in my mods by sorting the models manually. Sometimes I also hooked the game’s queued model system to set an arbitrary depth value to make models render in a specific order. Although not everything is fixable this way, I think my mods demonstrate that making a faithful conversion of SA1 assets was possible in the PC port at the very least.