SNES Doom source released under GPLv3

[taufan99]

Phase 3C is up now. Changes on the "binaries" and "source" folders. Apparently he also thanks @xttl in the phase 3C.1 commit. ;)

Edited July 18, 2020 by InDOOMnesia

[Dark Pulse]

He's very definitely aware of this thread then.

 

So if you're reading this, thank you for my first Doom experience, Randy! I enjoyed it.

[intacowetrust]

On 7/17/2020 at 10:00 AM, Job said:

Am I a bad dude to want @intacowetrust to shelf PsyDoom while he knocks this out quick? :O

You are a very bad man for thinking that. Please do a full playthrough of PsyDoom as your penance! :P /joking

 

On 7/17/2020 at 1:57 PM, Gez said:

Bad idea, jumping from one unfinished project to the next shiny thing is the best way to never ever complete anything.

You’re absolutely right! And not to worry I’ve no intention of dropping what I’m doing right now on PsyDoom. My time is quite limited, I have a full time job as a game developer, a wife and also a 9 month old son so if anything it forces me to stay focused on what projects I’m doing on the side and manage my time well.

[taufan99]

xttl's circle strafing hack is up on ROMhacking.net now. Go here in case you're confused as to which patch on this thread to use.

[xttl]

10 hours ago, InDOOMnesia said:

xttl's circle strafing hack is up on ROMhacking.net now. Go here in case you're confused as to which patch on this thread to use.

 

It's only the first version with wrong strafing speed though. I thought I'd wait until that gets approved and it's sure there are no problems with the updated version (with different strafing speed when running vs. walking) before submitting it. I'll probably do that later today. Until then, I recommend everyone use the patches from the latest zip I uploaded here instead.

 

doom_circlestrafe_r2c.zip

 

(na = for North American ROM, pal = European ROM, jp = Japanese ROM, all are for ROMs with no extra copier header)

[xttl]

I got ripdoom to build now. Btw, it seems the 68k asm sources actually have a slightly newer version (1.111) than the one Randy included as a binary (1.3). The usage instructions in ripdoom.txt don't match the newer version perfectly (it eg. needs a -w parm in addition to -r instead of being hardcoded to always load "doom.wad"), but at least the original build scripts gave some clues how to use it.

 

It also took me a little while to figure out wtf it means if a path has a colon as the starting character on AmigaOS. :D (it refers to the root directory of the current volume)

 

I still don't get why SAS C slink does not like it ("LIB:amiga.lib is not a valid object file") if I put the library files to a directory on a image backed ("hardfile") drive, but it works ok if I keep them in a the directory backed drive / shared directory. Perhaps some kind of permissions issue, but the flags look the same ("----rwed") using list command in AmigaShell... but it doesn't matter, I have a working ripdoom binary.

 

Then I got it do something interesting finally, I converted e2m2 (a map not included originally) and got some files: AREAS, BLOCKMAP, BSP, CEILINGS, DOORS, FACES, FLOORS, IFF, LIFTS, LINES, OBJECTS, REJECT, SECTORS, SEGS, STAIRS, VERTEXES

 

I also tried converting some maps which are included from the registered v1.9 WAD, and can find matches in the ROM by searching for eg. the first 40 bytes of the generated BSP file. I don't understand the level data pointer tables though, EMBSPTable from rllevels.a seems to start at 0x1F32AC in the North American ROM, but the first pointer in it is for E1M2, not E1M1, and everything after that is off by one. I can even overwrite the first pointer with garbage and the game doesn't crash until E1M2. WTF?

 

I can't even find where the bytes for E1M1's BSP are and then try to proceed from that, because E1M1 changed between versions and I don't know exactly what WAD was used the source. :(

 

Well, it could be that my address of table is off by 4, but then the data the target address for the 1st map looks a bit different than what the start of BSP for most maps looks like. (and doesn't look like any E1M1 variant I converted yet) yes, it was off by 4, i overwrote some of that data and got rendering errors in e1m1, I wonder what version was used as the source and were there some custom modifications?

tried: v1.2 registered, v1.9 registered, v1.9 ultimate

 

Also UAE's host directory sharing thing sucks: if I delete rip data directly from the host (much faster than waiting emulated AmigaOS to delete it) I can't use ripdoom again without restarting UAE, at least not with the same destination directory. That's why it's very annoying to have to try different IWAD versions.

 

yeah now I tried v1.1 registered too and there is no match for converted BSP data from that version of E1M1 either, I give up

 

I just noticed something interesting though: original NODES and converted BSP data are always the same size.

 

It's also weird how the BSP data pointer is 4 bytes, but almost everything else (areas, vertexes, segs, ..., all except sectors) is only 2 bytes. How does that even work? Are the others relative to the BSP base address or something like that? (yes)

Edited July 19, 2020 by xttl

[RandalLinden]

2 hours ago, xttl said:

I got ripdoom to build now.

Congrats!  I haven't built the code in 25 years now... but if you help me get UAE running reasonably I can help get the toolchains operational again...

I have UAE but need pointers/links to appropriate Workbench/etc. files so I can get a CLI operational.

BTW, IIRC the compiler was Aztec C.

Yes, the uploaded binary is different -- it was the only one I found in the archive and doesn't necessarily match the source unfortunately.

Rand.
 

[Job]

8 minutes ago, RandalLinden said:

Congrats!  I haven't built the code in 25 years now... but if you help me get UAE running reasonably I can help get the toolchains operational again...

I have UAE but need pointers/links to appropriate Workbench/etc. files so I can get a CLI operational.

BTW, IIRC the compiler was Aztec C.

Yes, the uploaded binary is different -- it was the only one I found in the archive and doesn't necessarily match the source unfortunately.

Rand.
 

Thanks for checking into this conversation, @RandalLinden! Thanks also for the original development of SNES Doom and recent source release! 

[betabox]

^Seconded. Thanks so much for your work on SNES Doom, @RandalLinden

[RandalLinden]

@Job: Thanks! :-)

 

@xttl et al:

 

I did a DIR of the "DOOMWAD" directory and this may be helpful in determining which version of the original files was used:

 

06/08/1995  05:28 PM            54,972 e1m1.wad
06/08/1995  05:28 PM           114,692 e1m2.wad
06/08/1995  05:28 PM           112,394 e1m3.wad
06/08/1995  05:28 PM            88,096 e1m4.wad
06/08/1995  05:28 PM            89,499 e1m5.wad
06/08/1995  05:28 PM           105,573 e1m7.wad
06/08/1995  05:28 PM            57,423 e1m8.wad
06/08/1995  05:28 PM            75,389 e1m9.wad
06/08/1995  05:28 PM            45,240 e2m1.wad
06/08/1995  05:28 PM            94,485 e2m3.wad
06/08/1995  05:29 PM           121,618 e2m4.wad
06/08/1995  05:29 PM           113,212 e2m6.wad
06/08/1995  05:29 PM            28,914 e2m8.wad
06/08/1995  05:29 PM            18,394 e2m9.wad
06/08/1995  05:29 PM            29,907 e3m1.wad
06/08/1995  05:29 PM            57,372 e3m2.wad
06/08/1995  05:29 PM           112,644 e3m3.wad
06/08/1995  05:29 PM           116,571 e3m4.wad
06/08/1995  05:29 PM            98,681 e3m6.wad
06/08/1995  05:29 PM           104,931 e3m7.wad
06/08/1995  05:29 PM            20,403 e3m8.wad
06/08/1995  05:29 PM            60,113 e3m9.wad

 

You can look at the "rl.sec" file in the Source subdir to find out where everything was located in the binary for the (IIRC) US version.

 

So for example "E1M1" ... from "rl.sec"

 

                          E1M1_A $80179ED4 $00579ED4 $00005FBA
                          E1M1_B $801D7097 $005D7097 $0000162C
 

File "exmy.i" includes the macro which generates the sections, so you can see the order of the data blocks within the "E1M1_A" and "E1M1_B" sections.

 

Make sense?

 

Rand.

 

[Redneckerz]

Have to say, having the man himself in here just made the thread even more awesome than it was. I am sure you know Pip Nayler who worked on your Cyboid stuff :)

 

37 minutes ago, RandalLinden said:

Congrats!  I haven't built the code in 25 years now... but if you help me get UAE running reasonably I can help get the toolchains operational again...

I have UAE but need pointers/links to appropriate Workbench/etc. files so I can get a CLI operational.

What specificaly do you need? A Kickstart ROM, or a toolchain. I might be able to help you out. Its the least anyone can do given the work you have done :)

 

 

[RandalLinden]

1 minute ago, Redneckerz said:

Have to say, having the man himself in here just made the thread even more awesome than it was. I am sure you know Pip Nayler who worked on your Cyboid stuff :)

 

What specificaly do you need? A Kickstart ROM, or a toolchain. I might be able to help you out. Its the least anyone can do given the work you have done :)

 

Yes, Pip is *AWESOME* -- he's among the handful of exceptional beta testers for Cyboid and I truly appreciate (and rely upon) his help with each Cyboid release.

 

I have Kickstart ... or at least I can get WinUAE to boot and show a workbench desktop, but I'm using a "hardfile" from "WinUAE\ClassicWB_UAE_v28\ClassicWB_UAE_v28\Hard Disk\" called "System_P96.hdf" ... the other choice I have is "System_ADVSP.hdf"

 

Unfortunately, nothing actually works per se: any command I enter results in a "No disk present in unit  0" error.

 

I've tried assigning a directory as a hard drive (DH1) and doing a "dir" results in the same error message.

 

I'm sure it's something really simple, like the HD image I'm using ... but until I can get a CLI operational I can't really help much.

 

Rand.

 

[xttl]

10 hours ago, Redneckerz said:

Have to say, having the man himself in here just made the thread even more awesome than it was.

 

Indeed!

 

I had to take a little break (take the thrash out and have a little walk while I'm at it), but before that I started writing a tool which inserts a level converted by ripdoom (replacing one of the existing ones) into the ROM since I think I understand the level pointer table now.

 

11 hours ago, RandalLinden said:

BTW, IIRC the compiler was Aztec C.

 

Seems the assembler and amiga.lib from SAS C are compatible with the ones from Aztec C then, heh. Btw., SAS C was apparently earlier known as Lattice C if that name sounds at all familiar. As for the OS itself, I created an empty 2GB hardfile and installed it from scratch using WB 3.1 ADFs. I can also PM the links to the OS stuff (Workbench install ADFs, Kickstart ROM) I used if someone else didn't already do it. :) Amiga Forever from Cloanto should also have them (but the cheapest edition only has 1.x, 3.1 is only included on plus and up) if you want to pay for them.

 

The only working download for the SAS C toolchain I found was a LHA archive which didn't extract correctly with the latest AmigaOS version of LHA (unsupported compression method used on some files). I had to use lhasa (apparently coded by fraggle on these forums!) on Linux instead to get all the files. (and unlike the OS I don't think the old Amiga versions are available for purchase anymore)

Edited July 19, 2020 by xttl

[RandalLinden]

5 minutes ago, xttl said:

Seems the assembler and amiga.lib from SAS C are compatible with the ones from Aztec C

Well, that's a plus :-)

 

5 minutes ago, xttl said:

I can also PM the links to the OS stuff (Workbench install ADFs, Kickstart ROM) I used if someone else didn't already do it. :)

Not yet, so please do... or email works, too.

 

5 minutes ago, xttl said:

The only working download for the SAS C toolchain I found was a LHA archive which didn't extract correctly with the latest AmigaOS version of LHA (unsupported compression method used on some files). I had to use lhasa (apparently coded by fraggle on these forums!) on Linux instead to get all the files. (and unlike the OS I don't think the old Amiga versions are available for purchase anymore)

Have you tried using 7ZIP (or equivalent) to unarchive on the Windows side?

 

Rand.

[Dark Pulse]

Just as a heads-up to @RandalLinden - don't worry if Doomworld won't let you post after a handful of posts, it's a new member/anti-spambot measure. Once you move up to 5-10 posts I think, then you get promoted and there's no more posts-per-day limit.

 

Also, thank you again. :)

[xttl]

Does that affect PMs too?

[Redneckerz]

1 hour ago, RandalLinden said:

Yes, Pip is *AWESOME* -- he's among the handful of exceptional beta testers for Cyboid and I truly appreciate (and rely upon) his help with each Cyboid release.

A very delightful fellow, i have to say. He does a lot of good work (After the Fall for Sega Dreamcast being his latest)

 

1 hour ago, RandalLinden said:

I have Kickstart ... or at least I can get WinUAE to boot and show a workbench desktop, but I'm using a "hardfile" from "WinUAE\ClassicWB_UAE_v28\ClassicWB_UAE_v28\Hard Disk\" called "System_P96.hdf" ... the other choice I have is "System_ADVSP.hdf"

 

Unfortunately, nothing actually works per se: any command I enter results in a "No disk present in unit  0" error.

 

I've tried assigning a directory as a hard drive (DH1) and doing a "dir" results in the same error message.

 

I'm sure it's something really simple, like the HD image I'm using ... but until I can get a CLI operational I can't really help much.

 

Rand.

 

It does seem you are missing the Kickstart ROM.

 

Have you tried using AROS instead? Its a free Amiga OS clone supporting much of the same functionality. (Wiki)

51 minutes ago, xttl said:

Seems the assembler and amiga.lib from SAS C are compatible with the ones from Aztec C then, heh. Btw., SAS C was apparently earlier known as Lattice C if that name sounds at all familiar. As for the OS itself, I created an empty 2GB hardfile and installed it from scratch using WB 3.1 ADFs. I can also PM the links to the OS stuff (Workbench install ADFs, Kickstart ROM) I used if someone else didn't already do it. :) Amiga Forever from Cloanto should also have them (but the cheapest edition only has 1.x, 3.1 is only included on plus and up) if you want to pay for them.

I was going to say: Yeah Kickstart ROM's are a paid thing so linking them would be illegal.

However, a cheaper option is the Google Playstore, with the Amiga Forever Essentials containing the Kickstart ROM for 2 dollars/euros.

[Quasar]

Is anybody currently looking at doing an extractor/reverse converter that would put the SNES level data back into a vanilla Doom compatible format? This is one thing I've been interested in having for several years now as it would benefit the wiki enormously in being able to document the SNES versions of the levels. I'd rather not duplicate effort anybody else has done or is planning on doing by looking into it myself.

[Dark Pulse]

21 minutes ago, xttl said:

Does that affect PMs too?

I don't believe so, but I honestly don't remember.

 

EDIT: Yes, it does. He shot me a message to let you know he can't reply to your PM, @xttl.

 

18 minutes ago, Quasar said:

Is anybody currently looking at doing an extractor/reverse converter that would put the SNES level data back into a vanilla Doom compatible format? This is one thing I've been interested in having for several years now as it would benefit the wiki enormously in being able to document the SNES versions of the levels. I'd rather not duplicate effort anybody else has done or is planning on doing by looking into it myself.

 

This would be very cool indeed. E2M2 (the PC E2M3) has that extra area added for the secret exit, after all.

 

Curious to know what editor Randy used for that. Did he do it on a PC editor like DEU or DCK and then convert it to the RAGE engine's format? Or was there some kind of specific editor that worked directly in the map format it needed?

Edited July 19, 2020 by Dark Pulse

[xttl]

11 hours ago, Dark Pulse said:

EDIT: Yes, it does. He shot me a message to let you know he can't reply to your PM, @xttl.

 

He managed to create a new PM thread though, so I got his email address now.

 

I might try a SNES->PC converter at some point (since I want to understand the data format anyway, to do conversion the other way without using the original AmigaOS/M68K only tools), but no promises there.

 

Vertex data is definitely in identical format on both (as was found years ago already, I'm almost sure I saw a post by Quasar about it here when searching the webs today/yesterday). BSP on SNES is always the same size as NODES on PC, and the bytes look very similar but ordered differently (it's not just endian swapped though, the GSU seems to be LE like x86 anyway). AREAS is the same size as SSECTORS on PC.

Edited July 19, 2020 by xttl

[Gez]

1 hour ago, Dark Pulse said:

Curious to know what editor Randy used for that. Did he do it on a PC editor like DEU or DCK and then convert it to the RAGE engine's format?

AFAIR it's what was told explained in, I think, the interview video.

 

Also that some of the levels had been tweaked in-house further but id vetoed map flow changes not required by technical constraints.

[xttl]

Ok, I can confirm SNES BSP files are pretty much the same as PC NODES, just with values rearranged. I wonder why? Obfuscation or some technical reason?

(leftchild/rightchild values seem to be actually different, I still need to look more into that in ripdoom3.asm)

PC struct looks like this:

Spoiler

// straight out from doomdata.h
typedef struct
{
  /* 0 */ int16_t x;
  /* 2 */ int16_t y;
  /* 4 */ int16_t dx;
  /* 6 */ int16_t dy;

  /* 8 */ int16_t bbox[2][4];
  
  // 8 = bbox[0][0]    right ymax
  // 10 = bbox[0][1]   right ymin
  // 12 = bbox[0][2]   right xmin
  // 14 = bbox[0][3]   right xmax
  
  // 16 = bbox[1][0]   left ymax
  // 18 = bbox[1][1]   left ymin
  // 20 = bbox[1][2]   left xmin
  // 22 = bbox[1][3]   left xmax

  /* 24 */ uint16_t children[2]; 

  // 24 = children[0]  right child
  // 26 = children[1]  left child
}
pcnode_t;

 

 

SNES struct looks like this:

Spoiler

typedef struct
{
  /* 0 */ int16_t y;
  /* 2 */ int16_t dx;
  /* 4 */ int16_t x;
  /* 6 */ int16_t dy;
  
  /* 8 */ int16_t bbox_left[4];
  
  // 8 = left bbox ymax
  // 10 = left bbox ymin
  // 12 = left bbox xmin
  // 14 = left bbox xmax
  
  /* 16 */ int16_t leftchild;
  
  /* 18 */ int16_t bbox_right[4];
  
  // 18 = right bbox ymax
  // 20 = right bbox ymin
  // 22 = right bbox xmin
  // 24 = right bbox xmax
  
  /* 26 */ int16_t rightchild;
}
snesnode_t;

 

 

edit: I tested it and hey, RipDoom runs under AROS 68k. It was necessary to disable the code which generates a IFF picture of the converted level, but it seems to be not used at all by the game anyway. This ready made m68k AROS distribution I downloaded seems a bit bloated and slow compared to the original WB3.1 though, and even the top menu bar thing has glitched drawing, lol. (size is over 500MB uncompressed vs. about 5MB for the original disk images and not much more than that installed, and it also clutters up the host drive with a zillion small files because it doesn't come as a hard disk image)

 

I wonder what is the absolute minimum amount of stuff needed to get the AROS AmigaShell copy and ripdoom running. If I can get it small enough, I could post a HD image for converting levels with UAE here.

Edited July 20, 2020 by xttl

[taufan99]

Godspeed, @xttl! Hope Randy can directly help your effort soon.

[Jon]

I’m loving the Amiga (one of my other passions) Is on the critical path here 

[Redneckerz]

11 hours ago, xttl said:

Ok, I can confirm SNES BSP files are pretty much the same as PC NODES, just with values rearranged. I wonder why? Obfuscation or some technical reason?

(leftchild/rightchild values seem to be actually different, I still need to look more into that in ripdoom3.asm)

PC struct looks like this:

  Reveal hidden contents

// straight out from doomdata.h
typedef struct
{
  /* 0 */ int16_t x;
  /* 2 */ int16_t y;
  /* 4 */ int16_t dx;
  /* 6 */ int16_t dy;

  /* 8 */ int16_t bbox[2][4];
  
  // 8 = bbox[0][0]    right ymax
  // 10 = bbox[0][1]   right ymin
  // 12 = bbox[0][2]   right xmin
  // 14 = bbox[0][3]   right xmax
  
  // 16 = bbox[1][0]   left ymax
  // 18 = bbox[1][1]   left ymin
  // 20 = bbox[1][2]   left xmin
  // 22 = bbox[1][3]   left xmax

  /* 24 */ uint16_t children[2]; 

  // 24 = children[0]  right child
  // 26 = children[1]  left child
}
pcnode_t;

 

 

SNES struct looks like this:

  Reveal hidden contents

typedef struct
{
  /* 0 */ int16_t y;
  /* 2 */ int16_t dx;
  /* 4 */ int16_t x;
  /* 6 */ int16_t dy;
  
  /* 8 */ int16_t bbox_left[4];
  
  // 8 = left bbox ymax
  // 10 = left bbox ymin
  // 12 = left bbox xmin
  // 14 = left bbox xmax
  
  /* 16 */ int16_t leftchild;
  
  /* 18 */ int16_t bbox_right[4];
  
  // 18 = right bbox ymax
  // 20 = right bbox ymin
  // 22 = right bbox xmin
  // 24 = right bbox xmax
  
  /* 26 */ int16_t rightchild;
}
snesnode_t;

 

 

edit: I tested it and hey, RipDoom runs under AROS 68k. It was necessary to disable the code which generates a IFF picture of the converted level, but it seems to be not used at all by the game anyway. This ready made m68k AROS distribution I downloaded seems a bit bloated and slow compared to the original WB3.1 though, and even the top menu bar thing has glitched drawing, lol. (size is over 500MB uncompressed vs. about 5MB for the original disk images and not much more than that installed, and it also clutters up the host drive with a zillion small files because it doesn't come as a hard disk image)

 

I wonder what is the absolute minimum amount of stuff needed to get the AROS AmigaShell copy and ripdoom running. If I can get it small enough, I could post a HD image for converting levels with UAE here.

Are you using AROS Vision or Icaros?

[taufan99]

Pardon for the slight topic bumping, but Modern Vintage Gamer just made a video on the source code.

 

[xttl]

12 hours ago, Redneckerz said:

Are you using AROS Vision or Icaros?

 

Icaros is x86 only, so AROS Vision. It seems there's a minimal boot floppy available from the AROS site under nightly snapshots. For some reason it crashes to a black screen running any command (like list) from the shell without copying the AROS ROM files from Icaros though.

 

ripdoom -l isn't very stable under AROS, it might be just that I haven't disabled the IFF writing code correctly but I don't know (it's too bad this has to be all in m68k asm :-). It sucks that it's even necessary to disable it under AROS. (program always fails with "Error opening Display Picture!" under AROS if it isn't disabled)

 

Also, just got a PM from Randy saying he still can't post replies, heh. That, and ACCESS Phase 1 is now up at Github.

Edited July 20, 2020 by xttl

[taufan99]

53 minutes ago, xttl said:

Also, just got a PM from Randy saying he still can't post replies, heh. That, and ACCESS Phase 1 is now up at Github.

Hmm. Definitely must ask for a moderator's help.
Or the last resort... ^{The Badministrator.}

 

Also, duuuude! Can't wait for the next phases of the ACCESS toolchain source code.

[Doomsday]

SNES DooM: The Golden Souls.

[Kroc]

-- edit: MVG video was already posted ---

Edited July 20, 2020 by Kroc
MVG YouTube video was already posted