Character models in SADX are the cornerstone of the SA1 vs SADX debate. They’re one of the few aspects of SADX that can be considered an improvement over the original game as they have more polygons resulting in a more detailed look. It’s particularly noticeable if you look at characters’ hands. Dreamcast character models have “mittens” like many other games at the time, while SADX models feature hands with clearly separate fingers.
From a purely technical standpoint there’s no argument about it: more polygons = more detail = better. But the SADX models aren’t just improved SA1 models with a better polygon count. They are also different in proportions, they use different textures and are missing several effects from the original. But first, let’s have a look at the following comparison just to see how they differ on a basic level. This comparison was done using Dreamcast and PC versions with several hacks, where we set up a test environment to ensure the models are placed in the exact same spot and have the same lighting:
SonicTails
Thanks to SonicFreak94, there's been some fixes and clean up some of the stuff going on with the mod, and now the sadx-mod-loader is a submodule! This is just helpful going forward, and means everything stays up to date without me having to manually fix it every time. Dreamcastify is a blog about Sonic Adventure DX downgrades. Sonic Adventure is a game originally released for SEGA Dreamcast back in 1998-1999. In 2003-2004 the game was ported to Nintendo Gamecube and PC, where it’s known as Sonic Adventure DX: Director’s Cut. I never thought Sonic Adventure DX was a garbage port, it just seems like they had the wrong idea. The higher frame rate and better camera controls are hard to part with. I find the Gamecube version to be an alright port for its time, but the PC version (at least the Steam release, I can't speak for the 2004 release) is complete garbage without. SADX Dreamcast Conversion mod by PkR. Dreamcast Conversion is a mod for Sonic Adventure DX PC that brings back Dreamcast levels, textures, object models, special effects and branding.
Knuckles
Better Sadx Mod
Amy
Big
E-102 Gamma*
Super Sonic
*Apart from some material flags, E-102 Gamma’s model is identical to its Dreamcast counterpart, but there’s a transparency issue with his chest, which will be discussed separately.
Some people prefer the higher poly SADX models, while others say they prefer the original models aesthetically. Some people argue that the SA1 models for Sonic, Tails and Knuckles have proportions resembling those characters in the classic Sonic games, while the SADX models look closer to more recent Sonic games, especially Sonic Adventure 2. This makes sense because SADX came out on the Gamecube after SA2B, and perhaps this prompted the developers to redesign the models so that the newer release wouldn’t look so different from the sequel that came out first on the Gamecube.
I’d also like to mention the redesign of Sky Chase models, which replaced the low-poly “Saturn” style models with more detailed models. This is also an improvement over the original game.
Higher polygon counts and separate fingers are objective improvements, and the rest is a matter of personal preference. However, in many aspects the updated character models are poorly implemented in SADX. Here’s a list of problems with the SADX models that didn’t exist or were less noticeable with the Dreamcast models:
- The “fur” textures for all characters were replaced with simple colors or gradients. Some people may not like the “grainy” textures on the Dreamcast models, but replacing the “grain” with a solid color seems like loss of detail. It would’ve probably looked better if the original texture was remade in higher resolution.
Here’s a comparison of the “grain” texture between versions: - The updates are inconsistent as only the main characters were updated:
a) Tikal and Eggman only received the higher-poly hands, and not all their models were updated – e.g. Eggman’s low-poly models in Egg Hornet and Egg Viper were not updated at all.
b) Amy’s model in the cutscene where she is captured by Zero is still using her Dreamcast model with mitten hands. Same problem with Tails in the cutscene where Sonic sees him crash. Gamma’s flashback with Amy also wasn’t updated. Sonic’s Light Speed Dash aura also wasn’t updated.
c) The jumping/rolling models for characters were not updated. They use the SA1 hand models with SADX hand textures, which doesn’t look too great together with broken vertex welding and lower quality textures. To be fair, vertex welding is broken on the Dreamcast too, but at least it has the correct textures. Lack of updates to anything besides the most visible things is jarring and illustrates the lack of effort put into the model upgrades. - The screenshots seen in the endgame credits were updated to feature new models and environments, but character tutorials and final credit screens still feature the old levels and old models with mitten hands.
- The updated models are inconsistent with other models in the game. The higher-poly models of Sonic and other characters look strange when they are standing next to NPCs because the NPCs use much more basic models. This was already noticeable in the Dreamcast version, but SADX made the contrast even more jarring. The best example of this inconsistency is Knuckles standing next to an NPC in the Echidna City. His original model looks a lot more consistent with the echidnas than his SA2-inspired model used in the ports.
- The updated models don’t follow the design guidelines from the Sonic Adventure Stylebook (scroll down a bit or search for “stylebook”). They use wrong shapes and proportions, whereas the original models follow them quite closely. Considering that SADX is supposed to be a better version of Sonic Adventure, the updated characters don’t represent the original game’s artistic vision.
- The Dreamcast models had some gloss on them, but the SADX models have much more gloss, which makes them look like plastic. Many people find the excessive gloss unappealing, especially in the PC version, where you can install a NoGloss mod to fix it, or use the Lantern Engine mod to tone it down. The gloss difference is the side effect of the inferior lighting system in SADX. Check out the section on character gloss in the Lighting post to find out more.
- The new hands are good to have, but Amy has got monster hands with very long fingers and it looks a bit freaky.
- The updated Sonic model has an animation error causing Sonic’s eyes to disappear during his “hanging” animation.
- The more rounded shoes are good, but the textures used on them were squeezed into one texture, and that texture isn’t very detailed. For example, Amy’s shoes look “dirty” because of the noise that comes from upscaling a low-resolution shoe texture.
- There is a visible seam between the upper and lower halves of Big’s body in SADX. Big’s model in particular is a great illustration of how a higher poly count improves almost nothing. Did you know that the SADX model has a higher poly count for Big’s body? I didn’t because it looks exactly the same to me.
- Super Sonic has lost the reflection effect (environment mapping) on his body and is now using a simple yellow texture.
- Super Sonic’s foot sticks out of his aura (lol).
Some people say the SADX models have better textures. Other than the “grain” mentioned in point 1 above (which is still debatable), this isn’t entirely true. Here’s a comparison of SA1 textures with SADX textures for Sonic:
You can see that the textures used for Sonic’s face and body (stx_hoho and stx_hara), Crystal Ring (stx_itemring) and the shoe buckle (stx_kanagu) are higher resolution in SADX*, but the textures for Sonic’s jump ball, eyes, nose, teeth etc. are the same resolution. You can also notice that the SADX model uses less textures. This is because most of the shoe textures have been squeezed into one. Normally this wouldn’t cause any issues, but in some cases the combined texture in SADX is less detailed than the individual textures used in the Dreamcast version (see the Amy’s shoe example above).
*Interestingly the “Autodemo” prototype of the Dreamcast version has higher quality character textures that are mostly on par with SADX resolution wise.
*Interestingly the “Autodemo” prototype of the Dreamcast version has higher quality character textures that are mostly on par with SADX resolution wise.
I’d like to go back to the “grain” issue again here. The texture in question is stx_btest1, which looks like this:
As you can see, the SADX texture is split into four pieces, which are applied to different parts of Sonic’s body. If we color code the parts, it looks like this. This is obviously an improvement over just one texture in the Dreamcast version, but it also means the resulting texture that gets applied to Sonic’s body is half the resolution of the Dreamcast texture in addition to the loss of “grain” discussed earlier.
The textures that weren’t redesigned in SADX suffer from quality degradation. A common misconception is that the texture quality downgrade happened only in the PC version, but the Gamecube version’s loss of texture quality is also quite significant. For example, look at what happened to the texture you see on Sonic’s jumpball:
Note that all textures in the game have suffered from quality reduction, not just the character textures. More on it in the Textures section.
Even Gamma’s model, which wasn’t redesigned, is suffering from some problems in SADX. There’s a part of his body that looks like this:
This is what it looks like in different versions of the game:
As you can see, the only version of the game where it renders correctly is the Dreamcast version. The front shield texture is supposed to be semi-transparent so that you can see the light behind it. The texture is still transparent on the Gamecube, but the light part is invisible and you see other parts of Gamma’s body through it. In the PC version the front texture is simply opaque. The same problem affects other robot characters, which also have body parts like that.
Some time ago we found out what was causing this. Gamma’s chest uses a mesh type that is not supported in SADX. However, that mesh type is exactly the same as another mesh type (trimesh), which is supported in SADX, so making it work would’ve been extremely trivial, and even if they didn’t want to support it they could just change a few bytes in Gamma’s model to make his chest use the trimesh type. In the PC version and later ports transparency is disabled entirely by using a constant material with no transparency on the whole model. This also would’ve been trivial to fix, although it may have been intentional.
Also Gamma’s eyes, parts of his feet and head base are supposed to be lit up at all times. The “ignore lighting” material flags for those body parts were removed in SADX for some reason, so Gamma’s eyes are no longer lit up. Same with Big’s eyes that no longer glow in the dark.
Sadx Dreamcast Models Mod Pc
Now let’s talk about missing effects. When Sonic rolls around, the blue trail he leaves behind has an interesting “rainbow” effect in the Dreamcast version. The trail is always purple in SADX, and the “rainbow” effect is missing: Jar launcher mac download.
This happens because SADX never sets the correct texture for the effect. It’s supposed to cycle between the first and second texture in SON_EFF.PVM, but SADX sets one of the textures meant for the longer dash trail, which is always purple.
Sonic’s Light Speed Dash aura is also different. It looks more jagged in SADX and its glow is a lot brighter. It’s quite likely that the developers couldn’t get additive blending to work properly with the glow model (which uses many transparent layers), so they decreased the transparency to make the problem less noticeable. However, that resulted in more “jagginess” and a worse look of the aura overall:
The original Japanese release of Sonic Adventure had an interesting “motion blur” effect when Sonic was running at high speed. It involved real-time replacement of Sonic’s shoes with stretched models to produce an effect akin to what you see in classic Sonic games. In addition to the stretchy feet, the game rendered Sonic’s model multiple times with various levels of transparency to imitate motion blur. In later releases on the Dreamcast the effect was toned down – the transparency was removed, but you could still see the stretchy feet sometimes. In SADX the effect was removed entirely:
Sonic’s model looks glitchy in the SADX screenshot – the shoe buckle is missing and the bottom of the shoes use a strange looking yellow texture. Those are the leftovers of the stretchy shoe effect. In SADX, the code for the stretchy shoes is still active, and when Sonic is running fast the shoes switch to an old model that wasn’t updated to use the final SADX textures. This is why the bottom of the shoes is using the buckle texture, and the buckle itself is missing. This bug has always been visible in official promotional materials, such as the Steam page.
Sadx Dreamcast Models Mod
A somewhat similar effect was removed on Tails’ tails. If you go back to the model comparisons near the top of this page, you can see that Tails had more than two tails in the Dreamcast version. Those semi-transparent tails showed up when he was running or flying, creating another variation of the “motion blur” effect. Putty client for mac. He still retains those extra tails in SADX, but the transparency on them is deactivated, which looks a bit strange:
Knuckles has also had several effect downgrades. The Shovel Claw has lost the environment mapping effect that gave it a shiny metallic surface:
Knuckles’ Maximum Heat attack aura is also different in SADX. It looks noticeably worse in the PC version, although the Gamecube version also looks somewhat broken:
Even with all the problems mentioned above there’s a lot of subjectivity when it comes to saying which models are better. However, in a supposedly enhanced port we shouldn’t have to choose between higher polygon counts for some character models on one side and worse texture quality, removed effects and broken character lighting on the other side. Most of the downgrades discussed here have been fixed in my Dreamcast Conversion mod, where I restored or recreated the missing effects. SonicFreak94‘s Lantern Engine mod takes care of level and character lighting, and ItsEasyActually‘s Dreamcast Characters mod is for those who prefer the original Dreamcast models in the PC version. Learn more about the mods here!
Fan Works, Hacking
Sonic Retro user Morph and several others have gone through Sonic Adventure DX and created a mod that restores the lighting effects that were previously seen in the original Sonic Adventure into the PC version. The difference gives off more vibrant colors in the environment that also reacts to objects and characters. You can download the mod from the discussion thread in our forums.
Lighting can be used to set a specific tone or mood in an environment. But why is it such a difficult thing to remain consistent when converting this to other game platforms? The game featured an artistic shift that occurred when the game was converted to other platforms. A combination of technical hurdles and creative liberties can dampen the original artistic intent, and Sonic Adventure is no exception. The original Dreamcast version featured a “Lantern” engine which provided impressive looking lighting effects using palettes on SEGA’s then cutting edge game console. However the dozens of ports of the game left out these lighting effects in favor of using drop shadows instead, until now. Check out additional videos, comparison screenshots and an interview with Morph on the mod after the jump!
After the original Dreamcast version, the lighting effect was replaced with drop shadows on the GameCube. The GameCube port ran at 60 frames per second, but with some random bursts of slowdown and frame stuttering. The developers also chose to remodel characters and change the textures that feature muted colors and shinier characters. Later PC ports retained the same graphical changes at the expense of changing the nuance throughout the scenery despite using potentially stronger hardware. Notice the rock alcove in the screenshot above. You can see the lantern lighting effects in the Dreamcast version give more definition to the structure. The palette mod makes it possible to combine both drop shadows and lantern light sources at the same time.
The lantern engine also affects how characters are rendered. Aside from the texture and model changes, characters give off a more rubbery, shiny look to them while other colors appear more flat. With the lantern lighting system, the vaseline effect appears reduced as seen in the character select screen. The lantern engine’s rendering technique shown across Sonic’s eyes gives a better illusion of a light source on both Dreamcast and in the palette mod.
A more obvious example comes in Red Mountain Part 2. Here the lantern light sources give a lighting ambiance with the flames inside the skulls decorated in the caverns. In comparison the DX version doesn’t really bother with any kind of ambient lighting effects hiding the detail of the skull due to the texture used and looks rather primitive as a result. The palette mod comes pretty close to the Dreamcast version with the ability to render at a higher video resolution.
Finally lets take a look at Final Egg Part 2. Aside from the texture changes, the DX version faces a change of tone in the environment and on Sonic (and Tails!) as light seems to not exist on the GameCube version, and just pumps up the shine in the Steam version having light pointed at Sonic coming from seemingly nowhere. In the palette mod, the restored lantern engine matches and in some cases even surpasses the detail seen in the Dreamcast version thanks to Sonic’s higher polygonal count showing light bouncing off of his quills and hands.
If you’re tempted to try the mod out yourself, you can obtain it from the discussion thread on Sonic Retro. This will work on the PC version released in 2004 or by installing the Better SADX mod designed for the Steam release. You can also check out the dedicated Dreamcast hacking and conversion thread for Sonic Adventure DX which allows you to restore the Dreamcast experience even further by restoring the original textures and UI, or you can go hog wild in the general hacking thread and go for the even crazier changes including the addition of Super Sonic to normal gameplay among other features made possible by the talented hacking community. I also fired off some technical questions over at Morph to give a more detailed look on the conversion process of the lighting mod which you can read below.
If you want more help installing the mods or want to look at more comparisons, BlazeHedgehog has also created a handy video that also provides a tutorial on his YouTube channel. If you want to see levels compared in further detail, check out YouTube user ZoядkдяoZ’s channel, who I totally didn’t just copy and paste into this article, in his dedicated playlist.
From the Forums
- Discussion Thread (Download Here)
Screenshots
Videos
Interview
Retro: What were you able to take from the Dreamcast original to work on this mod?
Morph: Literally speaking, the color palettes themselves. If you take a look inside the mod’s system folder, all those .bin files hold the lighting information. Depending on your archive extractor of choice, they should all still have their original last modified dates of 1999-2000.
Retro: Why were later ports of Sonic Adventure on GameCube and PC lacking these lighting effects?
Morph: The SADX Preview prototype for the GameCube still had this system in place, and it appeared to be working (mostly) fine, so I can only imagine it was a design choice. If not, it could have been due to performance, but that’s unlikely given how simple the effect is. I’m no graphics pro though, so I of course could be wrong.
Retro: Who helped contribute to the mod?
Morph: PkR and ItsEasyActually both played big roles in understanding the palette format. PkR in particular frequently checked the accuracy of my implementation against the original Dreamcast version, which was a great help. I did the programming, though. That being said, it’s an open source project, so anyone with the know-how who’s willing to contribute is of course welcome to!
Retro: What were the changes made to the lighting system to reinstate the lighting?
Morph: Does totally disabling it count? I basically had to inject code wherever changes are made to the lighting so I can see what it’s trying to do, and then I forward that information to my shader instead which does all of the actual lighting work. The only typical lighting calculation that occurs in the shader, however, is per-vertex brightness. It uses this brightness to select a color from the specified palettes, and outputs that to the rasterizer as the vertex color. For those unfamiliar with vertex color, a good example is Spyro the Dragon. It uses vertex colors for distant geometry so they could just skip the texturing phase entirely. On the PS1, that’s sure to improve performance. They did a lot of cool stuff with all three of those games!
Retro: Why is the lighting mod resource intensive?
Morph: It’s partially due to my own inexperience with using a shader, and partially because of the way I have to inject code to enable the use of the shader at all. The way I designed it (using the Microsoft Effect system) allows it to basically generate several shaders (called Techniques) based on a few parameters. As it is now, the shader has a technique for your regular run of the mill lighting, one for no lighting, one for no fog, and one for both no fog and no lighting. This plays into why it’s so intensive.
If I had more control over the rendering pipeline, those separate techniques would be welcome optimizations rather than performance hindrances. The idea behind them is to reduce load on the GPU. Ideally, the models in the scene would be grouped by desired shader technique and rendered in bulk. If I were to perform those checks in the shader (Is lighting enabled? Is fog enabled?), those checks would be happening for every single vertex of every single model rendered, and potentially every single pixel rendered to the screen.
But unfortunately, I have to switch between them multiple times (understatement of the year) per rendered frame to accommodate the needs of the models being rendered. The bottleneck here is the CPU–or more accurately, DirectX, which is not designed for such frequent shader technique switching. So of course if you have a fast CPU, it can get that operation over with faster; hence the CPU bottleneck.
The game has a render queue built in (used by default to sort transparent objects so you can actually see through them) that I’m working to understand and perhaps take advantage of. If I manage it, I can queue up all models to be rendered and sort them by required shader technique which would reduce the number of shader switches from potentially hundreds per frame to about 8 tops.
For the time being though, I’m going to experiment with doing this the inefficient GPU way: check flags every vertex and/or pixel. It could be that the GPU performance tradeoff for doing it that way would be enough of a CPU performance boost that it will run silky smooth all the time.
Retro: Did you have to make any major changes to the levels, characters or objects to reinstate the original lighting?
Morph: Nope! I designed this using mostly vanilla DX assets, just because I hadn’t bothered to download PkR’s wonderful Dreamcast level ports for a long while.
Retro: This mod requires a later revision of the Direct X library to reinstate the lighting effects. What does Direct X 9 offer over DirectX 8?
Morph: More advanced (which isn’t saying much, mind you!) shader capabilities. I had originally attempted to implement this in vanilla DirectX 8, but the shader had to be written in assembly. Basic features required special instructions which would break the rest of the instructions after it, it would fail to compile the shader with seemingly useless errors, etc etc. With DirectX 9, I was able to write the shader using HLSL, which uses C/C++ style syntax. It gives much more useful error messages and was much easier to prototype changes since it’s overall easier to understand.
As far as the game knows though, it’s still using DirectX 8. Thanks to Windows’ DLL shenanigans, I was able to use a shim called d3d8to9 which forwards all D3D8 calls to D3D9 render calls and vice versa. This otherwise wouldn’t have been possible without tearing the game apart (even more so than it has been) to replace the renderer manually. I even helped fix bugs to ensure it was SADX-compatible.
Retro: What are the future plans for the mod?
Morph: I’d like to implement an ingame palette editor/visualizer. Maybe integration into SA Tools since it’s vital for lighting on the Dreamcast. As a long-term goal, I might try to make the code more generic so it can be used as a platform to implement arbitrary shaders.
Retro: Any other thoughts on the project?
Morph: Hm… Maybe how it managed to get this far? I thought the reason SADX looked so much worse lighting-wise was because it had poorly configured lights. It wasn’t until PkR started poking at the files that I realized it allowed for arbitrary color gradients. My first thought was that it was some form of texture overlay (as not much testing had been done in the original SA1 at this point), so that’s how I tried to implement it. Getting it to look right was mostly trial and error until one day I had an epiphany. I realized it must be using the brightness of the vertex to determine which color to select from the palette (which by the way, is determined by calculating the dot product of the vertex normal and inverse light direction). I went ahead and wrote some code to do that, and it was comparatively speaking shockingly close to how it should look.
From there, it was a matter of determining which palette was applied where, how, and why. It was confusing, because each palette was oriented in pairs. Eventually after some experimentation, we (PkR, ItsEasyActually and I) determined that the first color in each pair was the diffuse color with baked ambient color, and the second color in each pair was used for specular lighting. Aside from some precision issues and overall polish, we had achieved the winning formula.
Pretty much a tl;dr of the last 6 months or so for me, lol. It was a great learning experience; I’m now much more familiar with a lot of the inner-workings of SADX due to the reverse engineering it required. Plus, now I know HLSL.
Retro: What were you able to take from the Dreamcast original to work on this mod?
Morph: Literally speaking, the color palettes themselves. If you take a look inside the mod’s system folder, all those .bin files hold the lighting information. Depending on your archive extractor of choice, they should all still have their original last modified dates of 1999-2000.
Retro: Why were later ports of Sonic Adventure on GameCube and PC lacking these lighting effects?
Morph: The SADX Preview prototype for the GameCube still had this system in place, and it appeared to be working (mostly) fine, so I can only imagine it was a design choice. If not, it could have been due to performance, but that’s unlikely given how simple the effect is. I’m no graphics pro though, so I of course could be wrong.
Retro: Who helped contribute to the mod?
Morph: PkR and ItsEasyActually both played big roles in understanding the palette format. PkR in particular frequently checked the accuracy of my implementation against the original Dreamcast version, which was a great help. I did the programming, though. That being said, it’s an open source project, so anyone with the know-how who’s willing to contribute is of course welcome to!
Retro: What were the changes made to the lighting system to reinstate the lighting?
Morph: Does totally disabling it count? I basically had to inject code wherever changes are made to the lighting so I can see what it’s trying to do, and then I forward that information to my shader instead which does all of the actual lighting work. The only typical lighting calculation that occurs in the shader, however, is per-vertex brightness. It uses this brightness to select a color from the specified palettes, and outputs that to the rasterizer as the vertex color. For those unfamiliar with vertex color, a good example is Spyro the Dragon. It uses vertex colors for distant geometry so they could just skip the texturing phase entirely. On the PS1, that’s sure to improve performance. They did a lot of cool stuff with all three of those games!
Retro: Why is the lighting mod resource intensive?
Morph: It’s partially due to my own inexperience with using a shader, and partially because of the way I have to inject code to enable the use of the shader at all. The way I designed it (using the Microsoft Effect system) allows it to basically generate several shaders (called Techniques) based on a few parameters. As it is now, the shader has a technique for your regular run of the mill lighting, one for no lighting, one for no fog, and one for both no fog and no lighting. This plays into why it’s so intensive.
If I had more control over the rendering pipeline, those separate techniques would be welcome optimizations rather than performance hindrances. The idea behind them is to reduce load on the GPU. Ideally, the models in the scene would be grouped by desired shader technique and rendered in bulk. If I were to perform those checks in the shader (Is lighting enabled? Is fog enabled?), those checks would be happening for every single vertex of every single model rendered, and potentially every single pixel rendered to the screen.
But unfortunately, I have to switch between them multiple times (understatement of the year) per rendered frame to accommodate the needs of the models being rendered. The bottleneck here is the CPU–or more accurately, DirectX, which is not designed for such frequent shader technique switching. So of course if you have a fast CPU, it can get that operation over with faster; hence the CPU bottleneck.
The game has a render queue built in (used by default to sort transparent objects so you can actually see through them) that I’m working to understand and perhaps take advantage of. If I manage it, I can queue up all models to be rendered and sort them by required shader technique which would reduce the number of shader switches from potentially hundreds per frame to about 8 tops.
For the time being though, I’m going to experiment with doing this the inefficient GPU way: check flags every vertex and/or pixel. It could be that the GPU performance tradeoff for doing it that way would be enough of a CPU performance boost that it will run silky smooth all the time.
Retro: Did you have to make any major changes to the levels, characters or objects to reinstate the original lighting?
Morph: Nope! I designed this using mostly vanilla DX assets, just because I hadn’t bothered to download PkR’s wonderful Dreamcast level ports for a long while.
Retro: This mod requires a later revision of the Direct X library to reinstate the lighting effects. What does Direct X 9 offer over DirectX 8?
Morph: More advanced (which isn’t saying much, mind you!) shader capabilities. I had originally attempted to implement this in vanilla DirectX 8, but the shader had to be written in assembly. Basic features required special instructions which would break the rest of the instructions after it, it would fail to compile the shader with seemingly useless errors, etc etc. With DirectX 9, I was able to write the shader using HLSL, which uses C/C++ style syntax. It gives much more useful error messages and was much easier to prototype changes since it’s overall easier to understand.
As far as the game knows though, it’s still using DirectX 8. Thanks to Windows’ DLL shenanigans, I was able to use a shim called d3d8to9 which forwards all D3D8 calls to D3D9 render calls and vice versa. This otherwise wouldn’t have been possible without tearing the game apart (even more so than it has been) to replace the renderer manually. I even helped fix bugs to ensure it was SADX-compatible.
Retro: What are the future plans for the mod?
Morph: I’d like to implement an ingame palette editor/visualizer. Maybe integration into SA Tools since it’s vital for lighting on the Dreamcast. As a long-term goal, I might try to make the code more generic so it can be used as a platform to implement arbitrary shaders.
Retro: Any other thoughts on the project?
Morph: Hm… Maybe how it managed to get this far? I thought the reason SADX looked so much worse lighting-wise was because it had poorly configured lights. It wasn’t until PkR started poking at the files that I realized it allowed for arbitrary color gradients. My first thought was that it was some form of texture overlay (as not much testing had been done in the original SA1 at this point), so that’s how I tried to implement it. Getting it to look right was mostly trial and error until one day I had an epiphany. I realized it must be using the brightness of the vertex to determine which color to select from the palette (which by the way, is determined by calculating the dot product of the vertex normal and inverse light direction). I went ahead and wrote some code to do that, and it was comparatively speaking shockingly close to how it should look.
From there, it was a matter of determining which palette was applied where, how, and why. It was confusing, because each palette was oriented in pairs. Eventually after some experimentation, we (PkR, ItsEasyActually and I) determined that the first color in each pair was the diffuse color with baked ambient color, and the second color in each pair was used for specular lighting. Aside from some precision issues and overall polish, we had achieved the winning formula.
Pretty much a tl;dr of the last 6 months or so for me, lol. It was a great learning experience; I’m now much more familiar with a lot of the inner-workings of SADX due to the reverse engineering it required. Plus, now I know HLSL.