GBA Doom II Modding Tools! - 0.2 Beta


Get out of my kitchen you flying ass
Well the wait is finally over! I present to you the GBA Doom II Modding Tools!
The tools are programmed in Blitzmax (because it's the programming language I know best).
I have to give credit to Magicteam for handing me their custom tool they used for making the translation patch. Despite that being too unfinished to be usable, it was a massive help to understand the filenames, find out what parts belong to textures/flats/sprites etc.
The source code helped me find offsets but other than that I didn't understand it however the compiled GUI tool was a massive help.

So what about these tools? What can they do?
*Modify, View & Extract in-game Sprites/Textures/Flats
*Modify, View & Extract raw graphics, such as the Hud.
*Modify, View & Extract rom Palettes.
*Convert all above to and from .PNG files
*Modify, View & Extract sounds (partially as of 0.1-0.2 Beta).

What tools are included in here?
Decompile.exe - Rips all the content defined in the bin folder, to extract them from the "DoomII.gba" rom to filetypes in the "\Decompile" folder
Recompile.exe - Gets all the changed files from the \Recompile folder and turns it back into a rom as "DoomII_Recomp.gba"
PaletteViewer.exe - For viewing decompiled/recompiled *.D2P Files
GraphicViewer.exe - For viewing decompiled/recompiled *.D2T and *.D2I Files
D2-TO-PNG.exe - Converts all Textures/Sprites/Flats/Images/Palettes from the Decompile folder into PNG format. They are exported to the "Decompile\PNG" folder.
PNG-TO-D2.exe - Same as above but the other way around. They are exported to the "Recompile\" folder. It loads files from the "Decompile\PNG" folder.
Rom Viewer.exe - Shows the rom with the raw byte data turning into colours from the palette, useful for finding graphics.

Alright so what dosen't the Tools support?
* As of 0.1-0.2 Beta, only a few sounds can be altered as I haven't finished defining them.
*Doesn't support compressed graphics, the intermission screen uses this for example.
*Doesn't support native GBA Sprites, which is used for the players FPS guns, game menus, and text.
*Doesn't support altering skies, but can be easily supported in a future update though.
*In-game mini text, because I simply haven't defined them yet.
*Rearranging YSTART/YSTOP values for sprites. Added to 0.2 Beta

If you want to know about the file formats, how the gba rom stores stuff, or what the command lines are.
I've put a Documentation.txt file in there describing lots of stuff.
For now mostly everything is a command line tool, so I recommend combining this for now with the russian GUI tool. Just so you would know if you recompiled output roughly was.
I plan on replacing the Recompile and Decompile tools with a single GUI tool eventually that can also view stuff on the fly.

Anyhow have some screenshots!

Anyway have fun!
If you appreciate the few months of work put into this, you can always Donate and help me host this website. c:
Check the attachments below for the ZIP Download.


  • GBA D2 MT 0.2
    5.4 MB · Views: 829
Last edited:


Get out of my kitchen you flying ass
There was an update today fellas! Here's the changelog, I may as well update this changelog post whenever a new update is finished.
GBA Doom II Modding Tools! - 0.2 Beta


0.2 Beta:
* X1Downscaler can now read headers (*.H) from the Recompile folder if it exists.
* The Recompiler and Decompiler now don't print a shitload of messages. As this was bottlenecking the speed.
  However there's now a percentage!
* The Recompiler had a big addition to the sprites. YSTART and YSTOP values can be modified on the fly
  to best fit your replacement graphics! Check out "Extras\Recompile Modes.png" and "Documentation.txt"
  for more detail on what you can do with this feature.
* The recompiler code has also been significantly shortend for sprites, not that it would effect real usage anyway.

0.1 Beta:
* Original release.


DeletedUser - For encouraging and the original idea for the entire project.
Id Software - For making such a great game.
And MagicTeam - For making this all possible by handing me their Russian editor, which I was then able to figure out the graphic formats and program the tools.

Thanks dudes appreciate ya! ~ Kippykip
Recompile Modes.png
^Here's an example of what I'm talking about.


Posted once, ONCE
When I try to download the attachment, it says:
Oops! We ran into some problems.

This attachment cannot be shown at this time. Please try back later.


I think I need to repost this:
Unfortunately I haven't worked for Torus Games since 2006, so I don't have access to any of the source code for the Southpaw Engine, which was retired years ago in any case. So, I will have to go on memory. Let me first tell you a bit about the development process. Duke Nukem GBA used bitmap mode 4 for the in-game rendering, and a char-based modes for the cutscenes and menu screens. Torus Games already had a char-based engine that they used for some of their 2D GBA titles and some tools that they used to convert the assets produced by the artists into the palettized GBA char-based formats. They also had a sound engine that was brought across from their 2D games as well. So the Southpaw engine was the only new tech that was unique to DNA.

I was the programmer responsible for the rendering engine, and wrote a conversion tool (called convwad.exe) that converted Doom WAD files to our format. We didn't use WAD files "as is" because of space considerations, we wanted to pack as much onto the cartridge as possible. There is a simple 1:1 correspondence between structures like linedefs and so on from the WAD format and ours. I think the format started off with a count of all the different structure types (linedefs, sidedefs etc) and then the data was just written out. So, it should be possible for you to extract the levels from the ROM, reverse the process and end up with WAD files of all the Duke Nukem Advance Levels. If you look for repeating patterns in the data you should be able to see how large the data structures are and how many of them there are. Once you have reverse engineered the format you can make your own levels and put them in the game.

We stored the wall textures in a compressed format that is different to Doom's. The texture is broken up into vertical 1-pixel wide strips and any duplicates are removed (lots of the textures contain repeating patters so there is a lot of this). A 1D array is stored with the index of the appropriate vertical strip for each horizontal position in the texture. Identical strips will reference the same index. Because the rendering engine draws the walls in vertical strips, the indexing can be calculated at the start of the run rather than per-pixel. Floor textures are all 32x32 pixels (IIRC, might be 64x64) and are not compressed in this fashion because they can be rendered at any angle. All textures are stored with multiple mip-map levels (this improved image quality, but also speed up the rendering, because we could assume that the texture co-ordinate would increase by either 0 or 1 for each screen pixel, which enabled a bunch of optimizations)

Transparent textures are compressed by only storing the pixels between the first and last non-transparent texel of each vertical strip along with the number of transparent texels that have been chopped off at the top so that the rendering code can compensate for this. When there is run of transparent pixels in the middle of the strip there there is a special color index at the start of the run that encodes how many transparent pixels the renderer needs to jump over. This means that it doesn't waste time sitting in a loop iterating over texels that will not be rendered.

Animated and destructible wall textures were implemented using special naming schemes for the textures e.g. wall_0, wall_1, wall_2 would animate in a loop etc

For scripting, we used a combination of the Doom linedef behaviours for opening/closing doors and so on, along with simple text file that contained dialogue text to be displayed and various actions (e.g. show security camera views etc). We changed the meaning of some of the linedef types to look up a string from the text file indexed by the linedef (or sidedef perhaps) and display it instead of producing the Doom behaviour. Various escape characters in the string produced scripting behaviours. It should be straightforward to find this stuff in the ROM by searching for dialogue text. This had the side-effect that it was possible for scripting sequences to work in one language and not another, if someone accidentally removed the scripting commands from the translated text!

Of course in Torus's port of DOOM II to the GBA the default behaviours are used. Duke Nukem was actually produced first, so it was very handy for us that we had used Doom WADs "under the hood" for DNA when it came to doing the Doom II port.

I hope this is all of some help to you, feel free to come back to me with more questions.

Best regards,

Chris Hayton

Palmerston North,

New Zealand

Retro GBA Doom

Active Lad
Dear kippykip I would like to change the music, the maps, all sound effects and the backgrounds of themintermission screen. Can you make a new version?


Get out of my kitchen you flying ass
Dear kippykip I would like to change the music, the maps, all sound effects and the backgrounds of themintermission screen. Can you make a new version?
Ah unfortunately I don't have the time like I did to work on this project anymore, I remember the intermission screen was compressed somewhere but I don't understand the algorithm whatsoever. Same with the title screen as that's compressed too.
As for music and maps, I wish I knew where the music was stored and how it is played back as I'd love to be able to mod that but I don't know any GBA Assembly to be able to find it either. Although I did find the instruments to the music which gets exported to "Decompile\Sound\INSTRUMENTS.RAW"
And for maps, Randy87 made a map converter for GBA Doom 2 -> PC, although unfortunately the BSP format for the southpaw engine is still entirely unknown. So the process can't be reversed as of yet. But at least we know the offsets where the level geometry data is. Here's Randys project anyways:

As for sounds it was a little tedious to get the offset and length for each sound effect so I didn't add that many sounds effects to be replaceable in the release for the GBA Modding Tools. Here's a quick workaround I did for you just now though:

Go to the \Bin directory and remove these files:
Then in the attachments below in this post, add DSALLSND.TXT to that \Bin directory.

When you decompile, you'll get a file in "\Decompile\Sound\DSALLSND.RAW"
Then you can open this file in something like audacity with the "Import Raw" file menu with these settings below:

It has all the sound effects next to each other as they're stored in the ROM.
When you want to re-export you can use these export settings:

Hope this helps in some way, sorry if I wasn't much help. I'd like to be able to change everything else in the game as well and I've always wanted to have a Final Doom TC for GBA Doom II and hopefully we can be able to make big GBA Doom II mods like that in the near future.


    44 bytes · Views: 344


Get out of my kitchen you flying ass
i also wish a programm, that can convert doom PWADS to gba games, not only doom 2 but also doom 1
There actually is one for GBA Doom 1, I believe it was mentioned in that thread. But Doom II GBA does not actually use the Doom engine whatsoever, it uses the southpaw engine which is undocumented, but used in several GBA FPS games.


Get out of my kitchen you flying ass
but the gbadhack doesn't work, or do you mean a other programm, i need an excact tutorial, how to use gbadhack
I think it was command line based if I recall, I'm not 100% how to use it myself. There was a whole thread on Doomworld about it I remember somewhere.