DOOM 32X WAD Converter

I have created this utility to convert 32X WAD data over to the standard PC WAD file format, and vise-versa. This makes it possible to see the contents of the WAD file from the 32X port of DOOM for anyone curious, as well as allowing people to modify it and create new (or port existing) levels and such.

TO USE:
Run the utility from the command prompt. To export a WAD from a DOOM ROM, type "wad32x in.32x out.wad". To import, type "wad32x in.wad out.32x"

Obviously, you replace the file names I gave there with the correct file names.

Also, here's a modification from Shana at Sonic Retro. I'll quote his post:

I've made a small (crappy) 2 map test to see how much can the 32x take (in MAP02). Download
The tools are working very well.

If you trigger a lot of sounds, sounds won't play anymore, but awkwardly the pause menu SFX still works. Maybe because they are uncompressed as mentioned in the post above? If you awaken too many monsters the game hangs. I've reduced some of the stuff in MAP02 so that it doesn't hang, but there's always a chance.

If you do anything with this tool, post about it, and perhaps even show some screen grabs =)

SCREEN SHOTS:
Here are some various screen shots I've taken to show off the program:

Share this post

Link to post

Good post, but not a newsy post. If you're going to take another crack at a news post, you should look at the other news posts that are on the front page for reference, and just post a summary of this and link to this thread from it.

Share this post

Link to post

I've been messing around with this today, and so far I've removed the palette and weirdo HUD weapons, grabbed the TITLEPIC via an emulator and thrown in a MAPINFO lump to handle the secret level and end screen. I also fixed the missing texture/HOM issues in MAP15.

This could possibly be the fastest completion time for a TC in history :P

@Chris: Those textures are from Jaguar Doom, the only console port handled by id themselves and the base for all other console ports (except SNES Doom and Doom64).

Share this post

Link to post

- The 32X version uses a collision detection method that is simplified in comparison to the PC version, making it harder to fit through some doorways (and possible to get trapped -- e.g. Entryway from DOOM II), thus one reason some maps may have been modified slightly (other than to slim down on memory usage.)

- DOOM 32X is also optimized so that it will not draw a ceiling texture if it's impossible for a ceiling to be seen (e.g. if a floor is at the same height as the ceiling under it or next to it.) This causes problems with certain maps such as Entryway from DOOM II, because the sky doesn't get drawn in the outside areas as a result.

- The engine doesn't worry with complex texture mapping. It uses the actual patch names to reference textures for walls. In fact, the ONLY thing the TEXTURE1 file is used for is for the engine to figure out the size of a patch (the size is stripped from the patch header.)

- The game doesn't crash if a texture isn't found, unlike the PC version. In the case of a missing texture, it simply uses the first texture listed in the TEXTURE1 file. This also helps MAP15 look correct, because they forgot to change a few "missing" textures, but the level just happens to use ASH01 throughout, so it's not noticeable.

- Masked walls don't function in the 32X port. That's why several levels, such as MAP01 and MAP03, have been modified to not use fencing (or whatever you want to call it). Any use of a masked texture will simply not be drawn.

- Floors and sprites are the same, with the exception of gun sprites. These sprites are cut down to half the X size. They get stretched in the game, and part of this is due to DOOM 32X using interlacing. The screen size itself is half the normal X size (see the Jaguar DOOM source code for evidence of this.)

- While most unused things in the 32X version were deleted out of the code, all co-op and deathmatch starts can remain in maps without yielding an error from the engine. Part of this is due to the Jaguar version having multiplayer, and although the 32X version doesn't, they never stripped those thing numbers out of the engine.

Also, in case you haven't been following the topic I linked to located on Sega-16 forums, I modified my program slightly to be able to dump maps from the Jaguar version of DOOM. I did this because the 32X version is based directly on the Jaguar version (e.g. maps are identical.) Since the Jaguar version has 24 maps instead of 17 like the 32X version has, I ported the missing maps over. So, if you have a Genesis/32X emulator, you can try the 24 level version of DOOM 32X:

I also modified the main menu so that you can select from all 24 levels. The only problem arises with level 20 -- the 32X runs out of memory when trying to load it (the 32X combined with the Genesis gives you 320KB you play with, not very much for a game like DOOM!) Other than that, they all work just fine. And levels 16 and 17 are Jaguar-exclusive maps that aren't from any other version of DOOM, so enjoy those if you've never played them before =)

Share this post

Link to post

Heh, pretty cool. I had once tried ripping the PSX version's data (and dumping what appeared to be the 32X's IWAD data from the ROM to disk), but there were some (deliberately?) oddball things like differently named lumps, different number endianness (makes sense, if any performance was to be expected on big-endian non-Intel platforms) etc. which prevented normal editors from opening lumps or levels (renaming only solved the identifiability issue, but values/sizes were still very screwed up. I got as far as opening a level in DB, but it looked like t3h bug).

Exactly what corrections does the utility apply when converting from and to 32X, other than the ones mentioned above?

Share this post

Link to post

The MSB in the first character of a lump names tells the game if compression is used or not. If the bit is on, then compression is applied. The size of the data defined in the WAD is it's size after being decompressed. Someone else asked me about this too, so I'm going to copy/paste what I wrote on how to read the compression:

You have a byte I like to call the "key." Each bit in the key represents the data that follows it. If a bit is 0, a direct copy is used (no compression.) If the bit is a 1, then at the location the bit represents, a word will be read which tells the decompressor how far to look back to find data, and how many bytes to copy. The upper 12 bits tells the decompressor how far to look backward that number of bytes, plus 1. The lower 4 tells the decompressor how many bytes to copy, plus 1.

The bits in the key are read in order from LSB to MSB. When the key has been completely read, a new key will start. To end a file, you use a 1 in the key and use 0x0000 for the word.

Also, lumps should be aligned in 32-bit intervals. So, if a file ends at say 0x12345, then you place dummy bytes at 0x12345, 0x12346, and 0x12347. The next lump will start at 0x12348.

And that's all there really is to it. That's not to say the lump data hasn't been changed in formatting though. I had to read the sprites differently in the 32X WAD than I would have to in a PC WAD, but that's getting ahead of things. I'll be releasing the source code to my utility which will show everything that is done in the conversion process.

Share this post

Link to post

Heh, pretty cool. I had once tried ripping the PSX version's data (and dumping what appeared to be the 32X's IWAD data from the ROM to disk), but there were some (deliberately?) oddball things like differently named lumps, different number endianness (makes sense, if any performance was to be expected on big-endian non-Intel platforms) etc. which prevented normal editors from opening lumps or levels (renaming only solved the identifiability issue, but values/sizes were still very screwed up. I got as far as opening a level in DB, but it looked like t3h bug).

Exactly what corrections does the utility apply when converting from and to 32X, other than the ones mentioned above?

I accidentally bumped a 2 year old thread but anyways I have already covered JaguarDoom and PSXDoom hacking a while back:

PSX and Jaguar Doom compresses the lumps and to indicate if its compressed or not, it 'bit-ANDS' the first character of the lump name by 0x80. PSXDoom also has a different sector format and uses a new LEAFS lump for converting subsectors into polygons since PSX Doom uses 'true' 3D rendering.

Share this post

Link to post

I posted this on Sega-16, but it would be nice to remaster the 32X Doom music so it doesn't sound like the 32X has a gas problem. It would be awesome to make the upbeat songs sound more heavy (i.e. Comix Zone or The Ooze), and make the atmospheric tunes sound more eerie (I can't really think of any Genesis games with eerie ambient music, but XTDoom could be recreated to some extent).

Share this post

Link to post

I wonder if the 32x can handle something like SiD, I assume it has the same limits (or less) than PC Vanilla.

Unfortunately, it doesn't.

What I've discovered so far:

Visplane Limit: 128, same as PC
Seg Limit: 128, half that of the PC (moan)
Sprite Limit: 128, double that of the PC (heh)
Active Monsters: I gave up at 512. The game was a slideshow, but still didn't crash.
Memory Allocated to map data: @96KB (LAAAAAME)

I'll work on figuring out more limits later.

Something to keep in mind on the map size, you can have a map file that is larger than 96KB, however you need to make sure that each individual difficulty level doesn't contain information that goes over that amount. So for example, whatever sprites that are only in UV mode won't count for ITYTD mode, and vice versa. So it's possible to have a game that crashes with a Z_MALLOC (out of memory) error on UV, but not on HMP or ITYTD.

Right now, I've almost got MAP20 (Jag Doom) running in 32X Doom. I just need to get UV mode working (going to have to delete some more sidedefs) and I'll upload it here when I'm done.

Share this post

Link to post

Program crashes when I replace what's in the converted WAD over with correct values (sprites). I even resized everything correctly - it seems WAD32x crashes in Windows with no error message. Then Fusion chugs due to weird graphics that were never patched correctly - and crashes with I_Error: R_DrawSpriteRange: bad texturecolumn. I'm assuming that's either lack of memory, or more importantly, wad32x crashing.

I've converted a MAP over but in the end repkaced it with the regular MAP01. I'm working on the limits that was just posted but so far I don't think I'm violating anything. Wad32x just crashes mid-conversion.

Share this post

Link to post

Right, got the Jag TC up and running. Made another couple of DECORATE tweaks - invul haze is now blue and all translucency has been removed. Monsters now infight again also.
If there are any issues please let me know.

EDIT: Just found a little mistake in the MAPINFO lump. This has been corrected. Also fixed the Spectres (Jag and 32x Doom don't have any).