GBA Doom II Modding Tools! - 0.2 Beta

Kippykip

Get out of my kitchen you flying ass
God King
#1
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?
Code:
*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?
Code:
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?
Code:
* 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!
Capture.PNG
Capture2.png
Capture3.PNG


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.
 

Attachments

Last edited:

Kippykip

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

Changelog:

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.

Credits:

Dinomite - 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
http://kippykip.com/index.php?threads/gba-doom-ii-modding-tools-0-2-beta.433/
Recompile Modes.png
^Here's an example of what I'm talking about.
 

Dexiaz

Posted once, ONCE
Member
#7
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