This is the second part of The History of Sonic Adventure DX Modding article. If you haven’t read already the introduction of this article/topic, you can do so by clicking right here. You can find the first part as well after that or by checking the end of this page.

In this Part 2, we will take a look at several of the tools that went from being part of the crucial evolution and development in SADX modding, to the current editing tools that are used nowadays for creating modern SADX mods (as well as covering the important SADX Mod Loader).

A big step from the early days of hex-editing and rudimentary tools, MainMemory would join the Sonic Retro forums in August 14, 2009, and would then showcase all the things she made for SADX. These ranged from a Cheat Engine table and a Trainer, to specialized modding tools like the aforementioned SADXMDL, SADXLVL, SETEDIT; and several others. Later on there would also be a toolkit that included the latest improved versions of these tools named SA Tools, previously known as SADXPCTools. Another later tool, ModLoader, would eventually allow for many more things than before. But first we will take a course through the original tools, including some deprecated ones.

All of these tools were important for both helping further research the game and bringing more players or modders to the SADX community. As the community grew more attention was brought to the PC SADX port, and the state it was left in, further justifying the work that needed to be done.

I think it [SADX modding] really took off when MainMemory joined the scene (now she, btw. I’m so happy for you, MainMemory!). She brought a lot to the table in terms of tools and impressive mods right off the bat, and that really kicked the hacking scene back into gear. It certainly revitalized my interest.


Split Tools and files

Knowing that main game data can be stored in either sonic.exe (the game executable) or in a DLL file, splitting tools are provided with SA Tools in order to extract the game data files into a folder. These can then be accessed through external editing tools and rebuilt in sonic.exe/DLLs again (pre-Mod Loader) or compiled in organized folders and then redirected to the game when the mod is loaded (Mod Loader).

The earliest level modifying tools (like SADXLVL) loaded from the executable file itself, and saved changes to it as well (which is why mods like Sonic RDX came with their own EXE). However, with the introduction of SADXPCTools, splitting the game data in external files was introduced, and was necessary for making level edits with SADXLVL2, as it asks for .ini files generated by the split process.

Almost all other mods ended up benefitting from splitting once Mod Loader was introduced. Saanim, sa1mdl, sa1lvl, and other similarly named files, were generated from it and could be loaded with the new editing tools. Of course, these would be integrated into a .DLL file when the mod gets compiled.

About the audio, music files and most audio voice clips originally were in .WMA files. Changing these was as straightforward as replacing the files. But with the creation of ModLoader, it was possible through a update in 2016 to use .ADX files (which were the original format used in SA1; and also fixed an issue with audio clips lagging sometimes). There would be other specific sound effects stored in a different way though, which were .DAT soundbank files. These would require the use of a specific tool for replacing the sounds inside (more on that later).

Another interesting tidbit from the PC port of SADX is the texture format. As mentioned before, the PVM/PVR files were compatible with a tool from the Dreamcast SDK for editing textures, as it essentially was a Dreamcast texture format. The Gamecube version of DX used .GVM instead (which could be seen as a variation of the format but for Gamecube). In other words, SADX PC used textures converted from a GC format into the original DC format. But, as documented in PkR’s Dreamcastify site, many of the textures (either based on the Dreamcast version or modified in SADX GC) were botched in quality.

SADX Trainer

One of the earliest things done by MainMemory for SADX was a trainer for the game. If you are unaware with the concept, a trainer is an external program that can be used to modify variables like lives or health in game. This is done either through keyboard commands or through an external window. They’re essentially cheat programs made for the game. SADX Trainer was no different, and allowed you to change things like rings, characters, and time. It also had a few hacks allowing the player to get Super Sonic in an Action Stage.

This trainer also allowed you to use Super Speed (have your character zip forward with incredible speeds) and Moon Jump (basically an infinite jump) with adjustable values. You could also change the object/spawn point for characters (for example, using Tails on Sonic’s Emerald Coast), and even change to Metal Sonic. While it wasn’t a tool for modding, it was one of the earliest things related to messing with the default game.


SETEdit is a rather early tool made specifically to modify SET files through a Graphical User Interface (GUI), that made it convenient to change the coordinates for specific objects in levels. It was a more practical method than painstakingly hex-editing the file while having to check the right values.

SETEdit with a file open. Note that it shows an drop-down list of objects in SADX on the Object-labeled box, as well as values for object rotation and position. The first box that has the “Add/Remove/Copy/Clear” buttons at the right of it shows a list of all the Objects present in the SET file.

While it would be useful during the period of time there wasn’t a level editor, its functionality would be outright superseded by SADXLVL which allowed moving objects from SET layout files. The main difference with SADXLVL was you could see where the objects would actually be located through the preview instead of having to assume and then open SADX to check.

SADXTweaker (and SADXTweaker2)

One of the earliest tools by MainMemory, in October 2009, SADXTweaker allowed you to mess with several values and variables inside the executable file. Among those were the text strings for all of the game’s cutscenes.

Screenshot of SADXTweaker with several options enabled/windows open.

It allowed you to change the music track used for certain music IDs (which meant that you could change the music file used for a certain event or stage, edit physics values, swap character spots, and a slew of other things. Any changes had to be saved directly to the .exe file in order to be applied.

Of course, it would receive an updated version known as SADXTweaker2, which would be bundled with SA Tools. One of the more useful upgrades was allowing you to save changes to a mod file instead of the .exe itself (which can be compiled as a .DLL. More on that later). There was more visible info and notes added too, like the name for music tracks in the music list editor.

SADXLVL (SADX Level Editor) and SADXLVL2

With the initial versions being released somewhere around 2009, SADXLVL is one of the earliest editing tools for the game. It would later evolve into a fully-featured level editor and would be the only one out there. And, of course, it would become vital to many future SADX mods and projects.

Demostration video of SADXLVL back from 2010.

SADXLVL allowed you to explore the scene of specific levels through a freecam-like method, where you could fly around a recreated display of the map constructed from the game’s executable data. You could then modify the model materials (which could be seen as the textures, but also could have properties like specular mapping), as well as display the level/death boundaries, change the player starting location, and use SETedit to allow for modifying object layouts. But the main difference was that any changes made through SETedit would also display in the level viewer, making everything easier to manage.

Having a visual, real-time, WYSIWYG (what you see is what you get) editor was a game-changer. It let modders have a really fast iteration loop for their work, as well as let them deploy the full power of their visual cortex towards the problem, instead of having everything just be a bunch of hexadecimal numbers. Granted, you could use 3DSMax as a 3D visualizer before that, but the process of actually getting your data in game was extraordinarily tedious.


Demostration video of results from using SADXLVL by JCorvinus back from 2010. Made to showcase the results of an tutorial he made for using SADXLVL on that time.

The final version of SADXLVL would be released in 2012, before being discontinued in favor of its successor, SADXLVL2. One of the biggest advantages this new version had was that it supported split data files; meaning you could modify a copy of the level data instead of messing around with the game’s executable file itself.

Screenshot of SADXLVL2 (as it is in 2020) in Windy Valley 1 (with Sonic SET object layout). One of the aerial propeller objects is selected. Other objects like capsules, an enemy, and normally invisible objects like collision spheres and walls are visible in the visual preview.

The interface would slowly be entirely overhauled for this new iteration as new features were added. Changes included having the features available on side bars, instead of pop-up windows opened from the menu bar, and selecting the character’s object layout to load with the right-upper corner icons. Starting around 2014, JCorvinus would add the implementation of moving level objects (be it geometry or SET objects) through the visual editor itself. This allowed you to move and rotate the selected object on its three axises. Interestingly, most of these were developed as a way to restore the Beta Windy Valley (more on this later):

I wrote several new features into SADXLVL2 for this project [Windy Valley Restoration] – the camera editor, the gizmo, and the view frustum culling were all built to satisfy the needs of this project. I wanted to implement a triangle strip generator but I was only able to get it partially working.

JCorvinus, July 11, 2014 (on Windy Valley Restoration’s video description)

On the topic of easy usage, if it is used through Project Manager (more on this later), SADXLVL2 asks you to select what stage to load, and after that, it loads all the landtables and objects in the selected level.


In addition to this level editing tool, SADXMDL would appear around that same time as SADXLVL and would allow the user to inspect the game models by loading SADX files. Unlike SADXLVL, which required you to have pre-extracted data through the split tool for loading levels, SADXMDL would request you to open a .DLL or EXE file. This would be for picking either the .DLL files inside the game’s system folder (something like CHRMODELS.DLL), or opening the sonic.exe file as models for several objects would be contained in said files. After selecting a file it would ask you for the purpose the file was loaded (from a drop-down list), as well as the model you wanted to load.

Once the above was done, the program would ask you to load a texture file to apply to the displayed model. After selecting one you could move around the camera with keys and, if it was pieced in chunks, the model’s separate pieces could be highlighted. These could also be seen in the Treeview window, which showed “root/child/siblings” in the model, the root being the whole model, and child/siblings being sub-pieces of the model (like the arms, legs, details on the shoes, eyeballs, etc). On top of that, there was a window for Advanced Info display, a window for editing the position and scale of the chunks, and a Material Editor which allowed you to alter the textures and the properties it had.

Screenshot of SADXMDL with Knuckles model loaded from CHRMODELS.DLL, and the 4 additional windows open. Note that Knuckles body model is highlighted, and all 4 windows show information related to it.

When you attempted closing the program it would prompt you to choose a place to save the file. This was to help save any changes done to the model you altered in the program. The last SADXMDL release would be in 2011, before turning into SAMDL and getting integrated into SA Tools.

SAMDL with E-102 Gamma model and textures loaded. Note that the interface is different.

The interface would be revamped to have information from the selected sub-model and treeview on the side of the window instead of separate windows (similar to what happened with SADXLVL and SADXLVL2). On top of that, it also allowed showing nodes and node connections. You could now load .saanim files and have the model posed from a animation, remap textures through a new window, and enable or disable fullbright (note that E-102 model has a sort of lightning applied to it. Unlike the SADXMDL screenshots enabling fullbright would disable the lightning and make it look similar to those cases).

The texture mapping window would allow you to select textures loaded in a model from one side, and then add a remap property to have te texture replaced in the model with another avaliable texture from the loaded PVM file.

SADXsnd and SADXsndSharp

Remember when I mentioned that .DAT files containing soundbanks needed special tools for editing? Well, this tool actually would have originated as early as June 23, 2004 (from the file creation date), with SADXsnd, created by SANiK (which could be considered one of the most important pioneers in this story, specially when he taught some of the most skilled members today). The fact that it is an early tool does show when you open it:

As you can see, it prompts you to use command line (no graphical user interface present); and if you input it as asked (for example, using SADXsnd with a .DAT file like “WINDY_VALLEY_BANK01.dat”; both files would have to be in the same place), the result is SADXsnd extracting all the files from it as .WAV files. Now, while it would have been useful to be able to extract sound files, it didn’t actually allow you to reinstert sounds on it (from what I could find; it doesn’t seem to accept any parameters other than the filename). This was solved with an accompanying tool: SADXsndpack, dated only 5 days later after SADXsnd.

Using SADXsndpack would be simpler to use than the extracting tool, since it would require you to run on a folder where SADXsnd has extracted a soundbank from a .DAT file already, and it will insert the .WAV files into an file called “out.dat”.

But of course, MainMemory would also make a variation of this tool for ease of use, named SADXsndSharp, as it was based on these two previous tools, but with the difference of working through a GUI instead of command line. The very first version would be released in January 26, 2011.

It would allow for extracting WAV files, replacing existing sounds with another WAV file, and adding or deleting sounds from the soundbank. In February 2012, the third release would allow for loading .DAT files from the 2011 port. Something to note about SADXsndSharp is that it is one of the only tools to not be superseded or deprecated by a revamped version of the tool, even when SA Tools was released (and is included with it).


With the initial version of this tool dated April 2012, SASave was actually quite simple but useful, allowing you to modify many of the things saved in your .snc save file, from lives and emblems, to miscelaneous flags. In other words, it was a straightforward save editor for SADX, and a functional one for that matter. It also allowed saving to specific slots (or all slots) when saving a file.

The name is actually a reference of how it is actually compatible with saves from other versions of the game (and not just SADX): It is compatible with .vmi (Dreamcast Sonic Adventure), .gci (Gamecube SADX), .snc and .bin. It also has a separate tab dedicated to SADX-only flags, like the rings for Black Market, Metal Sonic stats, and Mission mode stats. Its also one of the few tools that did not get revamped for SA Tools.

SADX Mod Loader

As mentioned several times, MainMemory’s SADX Mod Loader would be an absolute game changer for the SADX modding scene: Released in August 9, 2013 alongside with SA2 Mod Loader (since at that point the PC version of Sonic Adventure 2 was also out, and there was an modloader in the works for it too), it allowed for mods to work with files on the folder and have them used instead (for example, files in a “system” folder inside the mod would be used instead of the ones in the game data folder, meaning that there’s no need for replacing files like before).

Of course, there would also be another slew of features that ModLoader would bring to the table: The biggest ones were the fact that data that originally needed to be injected into the .exe file (Character and stage models, text, etc) could be inserted in the game through the modloader instead (as mods could be compiled in .DLL files), removing the need of replacing CHRMODELS.DLL and sonic.exe (with the exception that the ModLoader patches both in order to do its thing). Anohter overlooked but VERY important thing it did was making windows much more flexible, including borderless windows, V-Sync, aspect ratio, the aforementioned ADX sounds feature, and even upscaling and widescreen resolutions; whatever you needed! It was a welcome change compared to the way it was handled in stock 2004 (and 2011; which forced a 16:9 window but 4:3 aspect ratio, borders, and no proper upscaling).

[…] I’ve worked on the mod loader extensively and added tons of features (like dynamic resolution changes without crashing, the texture pack system, enforced texture filtering and mipmap generation, etc etc).


About the “Scale HUD” option, this one was quite important if you know exactly what it does. You may have noticed that the menu elements in a previous screenshot with a old Silver mod were shrunk instead of being sicaled with the window; that’s because SADX 2004 normally doesn’t scale HUD and menu elements at all when using resolutions higher than 640×480, and this shows when you are playing on a fullscreen view, with the menus being super-tiny. Of course, it would down to these dedicated people to add proper HUD scaling with Mod Loader, making it look much more natural (and properly done like other games).

SA Tools and ProjectManager

As you may have noticed, most of the tools seen here had second upgraded versions of themselves. Most if not all of these upgraded tools formed part of a whole new idea: SADXPCTools. It included most of the previously mentioned tools under a single package, and included some split and build tools as well. Released in June 2012, the name would be changed in December to “SA Tools”, after how some of the tools would receive support for the other games (DC Adventure 1 and Sonic Adventure 2), as well as introducing SALVL (which was designed to be a general purpose level viewer for the other games, but had some features unavaliable from SADXLVL2).

They’re a constant work in progress, and they get better every week. I’m actually working on some projects for it currently. Specifically getting more objects loaded into our level editing program for users to play around with.


SA Tools progress would easily be another key milestone in allowing for much more accessible usage of tools for SADX modding, both because of the improved tools on functionality and user interface, and because of Project Manager.

SA Tools has come a long way from when I first started using them and they’re needed for anyone who wants to make a mod of these games. The ProjectManager is easy to use, splits everything (including unidentified models) and even builds the mod for you, so it’s a great resource to have.


To explain Project Manager’s usefulness in simple terms, imagine having a whole assembly of tools for building your own game, but it would be a chore to figure out how to use everything to do a single package; Project Manager would be the terminal or interface behind accesing the right tools for the right purposes, as well as allowing you to quickly build your package.

That’s essentially how Project Manager acts in SA Tools, as it allows you to create a new “project”, splitting the game data in a folder and then allowing you to pick between SADXLVL2, SAMDL and SADXTweaker2 to use with your project, and save the data on said project folder. It could be said that it allows for the modifications that previously were done to DLL or the EXE file, but without the complications or risks of that approach.

Project Manager opens up with some options for creating a new project (or opening a previous one if there’s one present), configuring the game paths, or ausing the splitting tools manually. It will only let you create or open projects if there are valid paths for either SADX PC or SA2 PC (or both).

When creating a new project, a window will ask you for the Project Name, Author, Description (these are used when Mod Loader displays information of your project/mod), and the game it is intended for. Note that the Project Name and GameType boxes are disabled in the screenshot because of how the project creation process was started. A freshly made project folder is around 70MB of size.

Once the process is finished, you will be greeted by the Project Manager window for opening your tools. It lets you pick between SADXLVL2, SAMDL, SADXTweaker2, and some extra options, like building the mod (Auto Build, Manual Build, Build and Run) and changing the mod description as well as allowing other mods to be loaded (Configure Build).

The process on getting to use those three tools for modding is simplified in this process, as for both SADXLVL2 and SADXTweaker2, the tool asks you to select what you want to do (in SADXLVL2 case, load a stage; in SADXTweaker2 case, you can start using the options directly as the needed file was already loaded). While SAMDL doesn’t do this (which means you have to select “Open”, then go to the project folder if it isn’t there already), it is quite an improvement over the previous revisions of the tool (like all the other ones).

All three tools also show a pop-up that points you to SA Tools Documentation (which is pretty packed with resources and pretty useful for that matter), the Documenation for the tool you picked, and X-Hax’s Discord server.

After you have finished doing your modifications, if these don’t involve custom code or complete character mods (face morphers, joint welds), you can use the “Auto Build” option to have your mod built inside the mods folder in its own folder, ready for usage (Build and Run does the same but uns the game as well). With more complex, code-involving mods though, it will need you to use the Manual Build option.

The Manual Split Tools option is provided for data extraction purposes, and lets you choose from a DLL/EXE or a MDL file, add extra jobs/sections to split another file, and then extract the selected files in the specified folder paths.

Thanks for reading the History of Sonic Adventure DX Modding (Part 2)! The original concept was to have all the sections in a single article; but as a way to allow some gradual ease in reading the whole thing, these sections that cover the entire topic will be spread out in separate posts. You can find the next one and all the others in the index below.

If you liked my content, sharing this with others helps me out; and you can lend me a hand through my Ko-fi page as well! While I took long because I had an internet shortage a month ago, not only I came back to finish this one, but also managed to upgrade my setup. This should help me get back into working in stuff here much faster!

I hope that you have enjoyed this, see you in next part!