Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Mattfrie1

Information about Wolf 3D on Atari Jaguar (Jaguar Doom engine info)

Recommended Posts

So I've recently bought an Atari Jaguar, and with it both the ports of Doom and Wolfenstein 3D. The source code of Jag Doom has obviously been available for a long time now, but the Jag port of Wolfenstein 3D has been a little bit harder to get information on.

 

As we know, the Jaguar port of Wolfenstein 3D came before the port of Doom, and was ported by id as a way to test the abilities of the Jaguar to see if it would be able to handle Doom. The Jaguar port of Wolfenstein 3D is noted for having numerous similarities with Doom. The sprites for the pistol, chaingun and rocket launcher are all borrowed from Doom, the lives/treasure system is completely removed and those items now act like the health potions and soul spheres from Doom, and higher difficulties randomly have treasure pieces removed and replaced with enemies.

 

Like I've done with previous games in the past, I figured to open up the ROM of my copy of Jaguar Wolfenstein 3D in a hex editor just to poke around and see if there was anything unusual in there. I'm not sure if any of this has been documented any where else on the web, I've done a quick google search about the Jaguar port of Wolf 3D, and I haven't really found all that much info about the port. Perhaps if someone has some knowledge about this they can come forward about it.

 

Anyway, the first thing that I noticed right away towards the beginning of the ROM were some of the same "error messages" that I've been seeing in pretty much every Doom console port that I've viewed in a hex editor. Upon also looking at the Jaguar port of Doom and the SNES port of Wolf 3D in a hex editor, here is how Jag Wolf 3D is broken down:

 

Starting at memory address 00011310 in the ROM of Jag Wolf 3D are the same set of info/error messages that also appear in Jag Doom, these messages are:
-NuIWAD.Wad file doesn't have IWAD id
-NuW GetNumForName
-NuILumpLength
-NuIReadLump
-NuiCacheLump


Then, several error messages (I'm leaving out some of the descriptions here):
-NuZFree
-NuZMalloc
-NuZCheckHeap
-NuZChangeTag


Following these are several error messages that have been brought over from SNES Wolf 3D, and generally relate to both actor and door behavior ingame, as well as a message for static overload, actor overload, door overload, etc.

 

In Kaiser's extremely old thread about Console Doom Hacking, he stated that the IWAD address of Jaguar Doom was at 0X4000 in the ROM. Upon doing a search in Jaguar Wolf 3D, this port ALSO has an IWAD, and it starts at 0X2000 in the ROM. The difference in values is likely due to Jag Doom being a 4 meg cartridge, whereas Jag Wolf 3D was only a 2 meg cartridge.

 

The rest of the ROM is rather uneventful, but the end of it reveals another curiosity. Starting at Address 001ED670 is what looks very much like how a Doom IWAD file is laid out:

 

The first "category" features a list of all the maps in game (numbered from 0-29). The second category lists out all the sprites (1-154). The third category lists out wall textures (1-36). Following that is what looks like the information for the intermission screen, followed by information for the main menu(?). Other stuff that I'm able to distinguish here include what look like the references for the 3 demos (listed as DEMO1, DEMO2, DEMO3), a list of all ingame sound effects (ex. D BONUS, D OPENDR, D FTHROW, D KNIFE) and a list of all the songs ingame. For comparison, Jaguar Doom has the list of all it's data at the end of the ROM as well, and it's arranged in a very similar way (Sprites, then textures, and ending with sound effects and music).


To wrap this up, I think it can be said that Jaguar Wolfenstein 3D is a hybrid which uses elements from both the Jaguar Doom engine and SNES Wolf 3D engine. Again, I'm not sure if any of this information is common knowledge, but it is fascinating none-the-less. Any thoughts?

 

EDIT: Fixed some grammatical errors, guess that's what happens when you post while half-asleep. :)

Edited by Mattfrie1

Share this post


Link to post

Well to be honest the Atari jaguar was a rare specimen not only because it managed to Fuse a 32 Bits Console (Which was the Panther) into a 64 Bits one, but because it was hard to develop or port games into this console because of the mentioned.

Share this post


Link to post

I remember reading that the Jaguar Wolfenstein port was Carmack's testbed to see if the Jaguar could handle a fast action game like Doom, so it makes sense that it would also test certain Doom code, such as the WAD loading code. Sadly I don't have a source on this and I don't remember where I originally read it

Share this post


Link to post

It almost sounds like it IS the Doom engine. I was curious about this possibility previously but never got around to looking deeply into it. It's too bad there aren't disassemblers for Jag ROMs - given the mix of code for multiple different CPUs, it'd be really complicated to figure out what is what in there.

Share this post


Link to post

A long time ago I looked at the WAD to see what kind of format they used for music. The songs were actually MIDI (SMF) sequences (there's the MThd header at least) but somehow non-standard. Winamp did load them but the song length was shown as something over a few hundred minutes. It played some notes at the start and then just silence. Difficult to say for sure now but I think the instrument mappings might've actually been GM compatible. So if you could figure out how to fix the MIDIs you could perhaps get a partial Wolf3D+SOD soundtrack in General MIDI from there for use with a quality synth.

 

EDIT: Also just checked it and the MAP format looks like it's tile-based (always seemed that way in the game too, I've played through it a couple of times on my Jaguar). So this is most likely not using the Doom engine except for some parts like the WAD manager. Each MAP* lump begins with 0x1000 bytes that look like they could be a tilemap, followed by some variable length data in an unknown format.

Edited by xttl

Share this post


Link to post

Looking into the "IWAD" data at the end of the ROM a little bit more, I've also managed to figure out that the definitions for each of the midi "instruments" appear to be stored right at the end after the music.

 

Along with that, there also appears to be several color palettes scattered about around as well, including RGBPALS, CRYPALS, PALMAP, and BRIEFPAL. I also see what looks like the info for BJ's face in the status bar (FACE 1-25, plus FACEL and FACER as well), and also the definition for the logo screen at the start of the game (called BALLMAP).

Share this post


Link to post

Looks like somebody has already extracted the MIDIs: http://www.vgmpf.com/Wiki/index.php/Wolfenstein_3D_(JAG)#Game_Rip I tried them in a MIDI player and GM synth and they work and sound great, even though it says "The game uses custom General MIDI instrument patches, so a recording can't yet be made outside of the game." on the page.

 

The page also says: "The soundtrack is compressed in the game ROM using an unknown form of compression. Project Tempest v0.95 and WinHex were used to extract the files after the game was loaded into memory."

 

So I guess there's an additional compression layer in addition to the console Doom lump compression? Or maybe the lump compression algorithm differs slightly so you get almost but not quite working MIDIs if you use tools intended for handling console Doom WADs?

 

EDIT: It's probably the latter (the lump compression algorithm is slightly different). I attached a picture which shows how the credit screen graphic (it's in a raw pixmap format) looks when extracted with SLADE. Obviously there are more problems here than just a wrong palette...

CREDITS.png

Edited by xttl

Share this post


Link to post

Jaguar Wolf3D obviously uses the same resource management code as Jaguar Doom (not unlike how ROTT uses Doom WADs).  The map format is the same as the SNES/Mac/3DO although if I recall correctly (been awhile) it uses 16-bit words instead of bytes.

 

Someone would really need to dig in to claim that it's running on the Doom engine since it's going to look similar on the surface.  Doom and Wolf3D aren't that far removed from how they handle actor logic (which is why ECWolf can easily map things to ZDoom concepts).  The SNES version of Wolf3D uses a BSP tree for rendering, and I'm pretty sure I saw the same nodes in the Jaguar version.  Obviously this change was done with research done for Doom so it should come as no surprise if the renderer has some similarities.  That said it probably has the same limits as the SNES renderer.

 

Ignoring the new renderer, similar to Jaguar Doom vs PC Doom the optimizations that happened going to the SNES largely comes down to reworking some formulas to use bit shifts and masks instead of division.  So I don't really see a reason that the core wouldn't be the SNES Wolf3D engine.

 

xttl: The folks behind Wolf3D Redux made a program for extracting resources from the Jaguar version.  Might be a little more helpful.  I do believe the compression is the same LZSS compression used in Jaguar Doom which is why Slade can open the wad.

Share this post


Link to post
2 hours ago, Blzut3 said:

xttl: The folks behind Wolf3D Redux made a program for extracting resources from the Jaguar version.  Might be a little more helpful.  I do believe the compression is the same LZSS compression used in Jaguar Doom which is why Slade can open the wad.

Well I just looked at their code in here: http://wolf3dredux.cvs.sourceforge.net/viewvc/wolf3dredux/wolfextractor/wolf/jaguar/jaguar.c?revision=1.3&view=markup

 

In addition to variable type changes, there is one small difference in their decode function compared to the decode function as seen in JagDoom source code (and probably used as is in SLADE?) and this is what causes the corrupt MIDIs and also corrupt graphics. -1 must be removed from this line: https://github.com/Arc0re/jaguardoom/blob/master/w_wad.c#L84

 

Properly decompressed CREDITS screen attached.

output.png

 

EDIT: and yeah the tile maps also make more sense now.

Edited by xttl

Share this post


Link to post
6 hours ago, Blzut3 said:

Jaguar Wolf3D obviously uses the same resource management code as Jaguar Doom (not unlike how ROTT uses Doom WADs).  The map format is the same as the SNES/Mac/3DO although if I recall correctly (been awhile) it uses 16-bit words instead of bytes.

 

Someone would really need to dig in to claim that it's running on the Doom engine since it's going to look similar on the surface.  Doom and Wolf3D aren't that far removed from how they handle actor logic (which is why ECWolf can easily map things to ZDoom concepts).  The SNES version of Wolf3D uses a BSP tree for rendering, and I'm pretty sure I saw the same nodes in the Jaguar version.  Obviously this change was done with research done for Doom so it should come as no surprise if the renderer has some similarities.  That said it probably has the same limits as the SNES renderer.

 

Well looks like the map format (after decompression) might indeed match this struct from MacWolf source:

typedef struct {
        Byte tilemap[64][64];
        Byte areasoundnum[64];
        unsigned short numspawn;                /* Must be short */
        unsigned short spawnlistofs;    /* Must be short */
        unsigned short numnodes;                /* Must be short */
        unsigned short nodelistofs;             /* Must be short */
        Byte data[1];           /* nodes, and spawn list */
} loadmap_t;

 

Also if somebody wants to look at this in a Motorola 68000 disassembler (bulk of the code is fortunately C compiled for M68k, not handmade assembly for the Jaguar's custom processors) here are some offsets for you (same offsets apply to both the 2MB ROM file on disk and Jaguar memory space when the game is running):

 0000:00004000       start
 0000:00008FA8       Initsub_8FA8
 0000:00009738       I_WadBase
 0000:00009746       I_ZoneBase
 0000:0000E796       CastHitler
 0000:0000E7A3       CastMechaHitler
 0000:0000E7B0       CastDeathKnight
 0000:0000E7BD       CastUbermutant
 0000:0000E7CA       CastTrans
 0000:0000E7D7       CastHans
 0000:0000E7E4       CastSchabbs
 0000:0000E7F1       CastDog
 0000:0000E7FE       CastMutant
 0000:0000E80B       CastSS
 0000:0000E818       CastOfficer
 0000:0000E825       CastGuard
 0000:0000FD4E       Random1
 0000:0000FD7A       Random2
 0000:00010FC8       wolfmain_c_10FC8
 0000:000110D4       Initsub_110D4
 0000:00011342       W_Init
 0000:00011404       W_CheckNumForName
 0000:000114B4       W_GetNumForName
 0000:0001150C       W_LumpLength
 0000:0001155E       W_ReadLump
 0000:00011672       W_CacheLumpNum
 0000:00011712       W_CacheLumpName
 0000:000117AC       ShortSwap
 0000:000117C0       LongSwap
 0000:00011A46       Error
 0000:00011B30       comnjag_c_11B30
 0000:00011BC4       SetupLevel
 0000:00011F80       Z_Init
 0000:00012006       Z_Free
 0000:0001210C       Z_Malloc
 0000:00012302       Z_CheckHeap
 0000:000123E0       Z_ChangeTag
 0000:00019C80       BriefText1
 0000:00019CC0       BriefText2
 0000:00019D10       BriefText3
 0000:00019D40       BriefText4
 0000:00019D88       BriefText5
 0000:00019DC4       BriefText6
 0000:00019E08       BriefText7
 0000:00019E4C       BriefTextOffsets
 0000:00019ED8       CastOffsets
 0000:0001CFDC       rndtable
 0000:0001D0DC       rndindex1
 0000:0001D0E0       rndindex2
 0000:00036D64       map_tilemap
 0000:00037D64       map_areasoundnum
 0000:00037DA4       map_numspawn
 0000:00037DA6       map_spawnlistofs
 0000:00037DA8       map_numnodes
 0000:00037DAA       map_nodelistofs

On a Jaguar, the cartridge ROM is mapped at 0x800000. There's 2MB of RAM at 0x000000-0x1FFFFF (mirrored 3 more times after that before the ROM) and it seems that game code copies itself (or maybe the Jaguar's firmware does it?) to RAM and executes from there. The code for the whole game takes only 128kB so it fits easily.

Share this post


Link to post

Definitely hybridized, I suppose that makes a lot more sense :)  I'd be really curious to find out how similar the BSP rendering is to Doom's.

Share this post


Link to post

Did you also have Cybermorph and Kasumi Ninja by any chance? Those were the other two games with the listing. I bought it on eBay earlier this month, and was primarily interested because the listing included Doom, Wolf 3D and the composite cable (most other listings only had the RF cable, which mine also came with).

Share this post


Link to post

Some more offsets:

 

 0000:00016D8C       RenderView
 0000:00016B0C       R_DrawHUD
 0000:0001032E       R_DoPaletteEffects
 0000:00011740       R_sub_11740
 0000:00011F2C       R_sub_11F2C
 0000:000165E0       R_sub_165E0

; disabling this causes walls to not be drawn and also only sprites from
; the starting room are drawn even if you open doors and move about the
; level blindly...
 0000:000094B0       R_sub_94B0          

; disabling this causes doors & tracks to be drawn using the gray wall
; tile (#0 i guess?)
 0000:0000FCE0       R_door_sub_FCE0


 0000:00027AD4       bspcoord_bsptop
 0000:00027AD8       bspcoord_bspbottom
 0000:00027ADC       bspcoord_bspleft
 0000:00027AE0       bspcoord_bspright


 0000:00011BC4       LoadMap
 0000:00014032       SpawnStatic
 0000:00014146       SpawnPlayer
 0000:00014216       SpawnStand
 0000:000143A0       SpawnAmbush
 0000:000143CE       SpawnDoor
 0000:00014540       AddPWallTrack
 0000:000145A0       SpawnPushwall
 0000:00014710       SpawnElevator
 0000:0001474A       SpawnOut
 0000:00014752       SpawnSecret
 0000:00014788       SpawnThings
 0000:000148DC       SetupGameLevel
 0000:000166F0       LoadMap_nodes_sub_166F0


 0000:00010A7E       PlayLoop
 0000:00015B2A       Cmd_Fire
 0000:00015BA2       Cmd_Use
 0000:00015CEC       Cmd_ChangeWeapon
 0000:00015D8A       TargetEnemy
 0000:00015E38       KnifeAttack
 0000:00015E8E       GunAttack
 0000:00015F38       FlameAttack
 0000:00015FFE       MissileAttack
 0000:000160B4       MovePlayer


 0000:00011B04       StopSong
 0000:00011B30       StartSong


 0000:00012D0E       str_err_baddir
 0000:00012D1C       str_err_enemyinwall
 0000:00012D3C       TryWalk
 0000:0001300A       SelectDodgeDir
 0000:00013156       SelectChaseDir
 0000:000132DC       str_err_moveactor_baddir
 0000:000132F2       MoveActor


 0000:0000FD4E       P_Random
 0000:0000FD7A       M_Random

 

So far things on the playsim side seem to match the MacWolf source code closely (so easy to map the function names to binary offets there). Rendering not so much.

Share this post


Link to post

I seem to remember there being some utility that already existed that rips the contents of the IWAD. I can't remember its name, but I do remember that it was command-line based and split things out to various subdirectories.

Share this post


Link to post

On a tangentially related note, I think it's hilarious how the GBA port of Wolfenstein 3D has a crack intro text in the ROM data: https://tcrf.net/Wolfenstein_3D_(Game_Boy_Advance)

Share this post


Link to post
On 6/25/2017 at 5:52 PM, xttl said:

So far things on the playsim side seem to match the MacWolf source code closely (so easy to map the function names to binary offets there). Rendering not so much.

Hmm, that's pretty interesting since MacWolf was coded by Burger Becky and was released AFTER both SNES and Jaguar Wolf 3D. It pretty much seems like Carmack back-ported the game behavior of Wolf 3D into the Doom engine to make this version work from what I can tell so far.

 

11 hours ago, betabox said:

On a tangentially related note, I think it's hilarious how the GBA port of Wolfenstein 3D has a crack intro text in the ROM data: https://tcrf.net/Wolfenstein_3D_(Game_Boy_Advance)

The GBA version of Wolf 3D was actually handled by ONE programmer. Pretty crazy that it's the most accurate of all the ports as well...

Share this post


Link to post
23 minutes ago, Mattfrie1 said:

Hmm, that's pretty interesting since MacWolf was coded by Burger Becky and was released AFTER both SNES and Jaguar Wolf 3D. It pretty much seems like Carmack back-ported the game behavior of Wolf 3D into the Doom engine to make this version work from what I can tell so far.

i guess both of them just had the same idea of what to do.

Share this post


Link to post
7 hours ago, roadworx said:

i guess both of them just had the same idea of what to do.

Or that the later version of the software was obviously based on the earlier version?

Share this post


Link to post
On 6/23/2017 at 0:30 AM, xttl said:

Well I just looked at their code in here: http://wolf3dredux.cvs.sourceforge.net/viewvc/wolf3dredux/wolfextractor/wolf/jaguar/jaguar.c?revision=1.3&view=markup

 

In addition to variable type changes, there is one small difference in their decode function compared to the decode function as seen in JagDoom source code (and probably used as is in SLADE?) and this is what causes the corrupt MIDIs and also corrupt graphics. -1 must be removed from this line: https://github.com/Arc0re/jaguardoom/blob/master/w_wad.c#L84

 

Properly decompressed CREDITS screen attached.

output.png

 

EDIT: and yeah the tile maps also make more sense now.

Have you tried loading the graphics with Mac Wolf3D's palette? Pretty sure the Mac version is ported from the Jaguar.

Share this post


Link to post
18 hours ago, VGA said:

Ha! What does this mean, though? Did they rip off any code from that game?

Not really sure, it could be. It's worth noting that Wolf 3D on GBA shares a publisher with Ecs vs Sever.

Share this post


Link to post
2 hours ago, Woolie Wool said:

Have you tried loading the graphics with Mac Wolf3D's palette? Pretty sure the Mac version is ported from the Jaguar.

 

Nope. The palette from the Jaguar WAD should be easy enough to convert into a usable format anyway if I need it. Unless you specifically wanted me to check whether Jaguar and Mac use the same palettes?

 

Btw. here are some screenshots from outside of the map. If somebody wants to play around with no clipping and maybe take guesses on how the renderer works you can do this: open the ROM dump in a hex editor, go to offset 0x14F20 and change bytes 4E 56 there to 4E 75 (it changes the beginning of function TryMove used in player movement clipping to a RTS instruction). You can easily make the game start glitching or completely crash with this though, I guess due to some buffer the renderer uses overflowing.

 

On the last pic you can see some timing information (you can get this display by pressing 4,8,8,7 on the controller when in game), I guess the renderer is split into multiple phases like in JagDoom.

 

I think I'll try importing custom maps into the game next. Hopefully I can figure out how to generate the BSP data or find some code to do it (maybe from a map editor for MacWolf?).

 

 

map1_1.png

map1_3.png

map1_2.png

testmap.png

Share this post


Link to post

Today I'm continuing work on this. (yeah... I haven't been doing anything at all related to this since the last post :) I just coded a simple wall texture viewer and tilemap viewer using C and SDL2, I'll have to go through the tile graphics and see which tile number maps to which texture and add that information to the map viewer. The eventual goal is to add a nodes viewer to it.

 

Btw. there is only one version of each wall texture, so unlike PC Wolf3D it's using colormapping for the darker walls.

 

EDIT: Oh yeah, the wall texture format is similar to JagDoom in case anybody's interested. They're raw 128*128 pixel paletted images rotated 90 degrees (column-major format). First palette from RGBPALS works well (the RGB palette format is of course uint8_t r,g,b). I haven't checked this yet but I'd guess CRYPALS has the same palettes but in CRY color values instead of RGB.

Edited by xttl

Share this post


Link to post

So I guess it's ok to double/triplepost in threads like this here, at least if it's been a while since my last own post? (been looking at the Shadowcaster RE thread going on under EE)

 

Anyway I got a bit sidetracked again, but now I finally made a working tilemap viewer up (the window size is fixed, tile scaling is fixed and it's not very pretty code at all but at least it somewhat works...). I tried to add some code to display all objects from the spawn list data on top of the tilemap as rectangles but it's not working quite right yet... some (but not all) objects are drawn in wrong positions. I already read from the MacWolf source that for eg. doors the x/y coordinates in the spawnlist point to the target tile, but for some things such as enemies the x/y values are instead supposed to be the integer part of a 8.8 fixed point number (the final game world coordinate where the object is spawned) but maybe the spawn IDs are different on Jaguar or I just didn't get something else right yet, heh.

 

I think I should try to get everything from the spawnlist show up correctly first before even attempting to parse and draw nodes/segs info.

jwt1.png

Share this post


Link to post

Thanks much for looking into this stuff. Very interesting. :)

 

I haven't commented much but I have been keeping an eye on this. I can't speak for others, but know that the lack of heavy feedback is not a lack of interest. ;)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×