SNES Doom source released under GPLv3

[Dark Pulse]

@xttl Definitely don't test with ZSNES - it's ancient and full of hacks. There's all sorts of ROM hacks made for it that will immediately shit the bed on real hardware or more accurate emulators.

 

SNES9x is better and more accurate, but the true acid test would be higan, which aims for 100% cycle-accuracy. In other words, should be as good as real hardware pretty much.

Edited July 16, 2020 by Dark Pulse

[Revenant]

On 7/15/2020 at 3:00 PM, xttl said:

how to set SuperFX breakpoints in bsnes-plus

Just be sure to set "SuperFX bus" as the breakpoint source, and the rest is the same as setting regular CPU breakpoints. Keep in mind that the breakpoints use CPU addresses rather than raw ROM offsets.

[xttl]

On 7/16/2020 at 4:28 PM, Dark Pulse said:

Definitely don't test with ZSNES - it's ancient and full of hacks

 

Yes, I know.

 

On 7/16/2020 at 4:32 PM, Revenant said:

Just be sure to set "SuperFX bus" as the breakpoint source, and the rest is the same as setting regular CPU breakpoints. Keep in mind that the breakpoints use CPU addresses rather than raw ROM offsets. 

 

Thanks, that worked. It's still a bit confusing how the integrated disassembler likes to show eg. 29 10 as "with r9" and "to r0" (it's just "move r0, r9" in gsudis and Randy Linden's sources).

 

edit: New patch attached. It is now using the zeroes in rlmove7.a jumptables for new code.

 

I hope I got everything right. The GSU has branch delay slots, but it also has varying instruction lengths (1-3 bytes), and for multibyte instructions it actually only takes the first byte from the delay slot and the rest from the target address! I used delay slots to save space and maybe make the code execute a tiny little irrelevant bit faster, but it's hard to verify code which puts parts of multibyte instructions (instead of just single byte instructions like NOPs) into delay slots using gsudis. :(

 

IPS: see multiregion zip in newer post

 

Bytes (without header changes which don't affect functionality):

Spoiler

000001DA: 3D FB
000001DB: A6 A1
000001DC: F9 AC
000001DD: 3D 9B
000001DE: A0 29
000001DF: 04 01
00000225: 05 01
00000226: 1F 01
00002CA1: 00 10
00002CA2: 00 F1
00002CA4: 00 80
00002CA5: 00 05
00002CA6: 00 0A
00002CA7: 00 71
00002CB1: 00 09
00002CB2: 00 06
00002CB3: 00 F6
00002CB4: 00 40
00002CB5: 00 0B
00002CB6: 00 05
00002CB7: 00 79
00002CB8: 00 3D
00002CB9: 00 80
00002CBA: 00 07
00002CBB: 00 05
00002CBC: 00 74
00002CBD: 00 3D
00002D31: 00 A0
00002D32: 00 04
00002D33: 00 FB
00002D34: 00 E1
00002D35: 00 81
00002D36: 00 9B
00002D37: 00 3D
001C0929: F0 80
001C0941: F0 80
001C0993: F0 80

 

 

This is the final version unless there are problems or you can think of other possibly simple to fix things.

^{(crap framefrate without overclocking GSU unfortunately isn't simple to fix with high probability ;)}

 

edit2: I added a little bugfix (picking up green armor now says "picked up the armor" instead of "the megaarmor"), originally the message pointers for both green and blue armours are set identically for some reason, you can see it in the published sources too (though no actual message data is included in there yet, I wonder if it even will ever be included since it's technically copyrighted game content). IPS updated.

Byte changes:

Spoiler

 

00002E7B: B2 A6
00002EDD: BC B0

 

 

Edited July 17, 2020 by xttl

[Revenant]

6 hours ago, xttl said:

It's still a bit confusing how the integrated disassembler likes to show eg. 29 10 as "with r9" and "to r0" (it's just "move r0, r9" in gsudis and Randy Linden's sources).

It's a weird setup, but that's how the GSU architecture actually works - since there's multiple-byte instructions but only a 1-byte pipeline, there are actually dedicated instructions for setting the source/destination registers of the following instruction(s), since it's otherwise not really possible to encode the register numbers directly into the instruction like you'd see in a "normal" RISC architecture.

 

(In other words - "move r0, r9" and such are just common (dis)assembler shorthand, not an actual single instruction that the GSU can execute "atomically")

[Vic Vos]

Oh hell ye.

GEC Master Edition for SNES when

Edited July 17, 2020 by Vic Vos

[Dexiaz]

52 minutes ago, Vic Vos said:

GEC Master Edition for SNES when

*xttl Master Edition :>

[seed]

1 hour ago, Vic Vos said:

Oh hell ye.

GEC Master Edition for SNES when

 

Indeed, I'd love something like this. I think they brothers are currently reverse-engineering another console port, but forgot exactly which. Sega Saturn Doom, I think?

 

I hope tacoman will try his luck on this in the future, after PSX Doom honestly :D.

[Job]

16 minutes ago, seed said:

 

Indeed, I'd love something like this. I think they brothers are currently reverse-engineering another console port, but forgot exactly which. Sega Saturn Doom, I think?

 

I hope tacoman will try his luck on this in the future, after PSX Doom honestly :D.

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

And, in full disclosure, I LOVE PSX Doom to an unhealthy degree.

[xttl]

14 hours ago, Revenant said:

It's a weird setup, but that's how the GSU architecture actually works - since there's multiple-byte instructions but only a 1-byte pipeline, there are actually dedicated instructions for setting the source/destination registers of the following instruction(s), since it's otherwise not really possible to encode the register numbers directly into the instruction like you'd see in a "normal" RISC architecture. 

  

(In other words - "move r0, r9" and such are just common (dis)assembler shorthand, not an actual single instruction that the GSU can execute "atomically") 

 

I suspected it'd be something like that, it was just a bit confusing when the documentation I looked at only talked about how from/to are used to change the source/destination registers for other instructions.

 

Btw. for anyone who might be interested: I "ported" the changes so far to the PAL and Japanese ROMs, IPSes for all three regional variants in the attached zipfile.

 

I've played this quite a lot using latest SNES9x and latest bsnes by now (and also quickly tried it in latest Higan) so I'm pretty sure it works as it should. (it's a very little, simple change to the base code anyway)

 

^{Now I just need to buy a cheap Winter Gold cart and mod it to play this instead. (I'm a bit worried about changing the CIC since it's apparently a SMD component in newer carts, it's either that or attempt at a 50/60Hz switch mod in my PAL SNES... also I'll have to get someone to program the ROM or buy a programmer myself...)}

doom_circlestrafe_r2c.zip

[seed]

18 minutes ago, Job said:

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

  Hide contents

And, in full disclosure, I LOVE PSX Doom to an unhealthy degree.

 

I love PSX Doom to the same degree, but no, first PSX Doom, more cool stuff later :).

[xttl]

Note that Randy already gave us source to the tools to convert levels (and other data) from PC WADs to his engine's formats, it's just that he wrote all that code in 68000 assembly for Amiga. :D

 

See the ripdoom* files in the github repo.

 

He also uploaded binary versions of those tools into the git repo so it shouldn't be too hard to play around with them in UAE if somebody wants to. I might do that at some point, but not now. I don't think I could (or should) upload converted IWAD maps or especially PWAD maps without permission from authors here anyway. (the first content I'd try to convert is some older, "simpler" Doom 1 PWADs such as Fava Beans)

[Reisal]

This is nice. This is very, very nice. SNES Doom has some significance and since I had an SNES at the time, this is something I liked to play, plus it gave me the first looks of episodes 2 and 3.

[Dark Pulse]

1 hour ago, xttl said:

Note that Randy already gave us source to the tools to convert levels (and other data) from PC WADs to his engine's formats, it's just that he wrote all that code in 68000 assembly for Amiga. :D

 

See the ripdoom* files in the github repo.

 

He also uploaded binary versions of those tools into the git repo so it shouldn't be too hard to play around with them in UAE if somebody wants to. I might do that at some point, but not now. I don't think I could (or should) upload converted IWAD maps or especially PWAD maps without permission from authors here anyway. (the first content I'd try to convert is some older, "simpler" Doom 1 PWADs such as Fava Beans)

Or Freedoom. Since, y'know... free.

 

Also...

 

2 hours ago, Job said:

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

Yes. Yes you are. Especially since he said earlier in the thread he's got his hands full with PsyDoom and will pass on it for now.

 

Now go rescue President Ronnie from the ninjas and prove your badness.

Edited July 17, 2020 by Dark Pulse

[xttl]

10 hours ago, Dark Pulse said:

Or Freedoom. Since, y'know... free. 

 

Well that's not a bad idea. Are all the Freedoom D1 maps 100% vanilla compatible? (I'm pretty sure trying to convert maps that require even just a "limit removing port" instead of being strictly vanilla compatible isn't a good idea, for obvious reasons ;) The page and readme recommend Crispy Doom and GZDoom instead of Chocolate...

Edited July 17, 2020 by xttl

[Dark Pulse]

14 minutes ago, xttl said:

 

Well that's not a bad idea. Are all the Freedoom D1 maps 100% vanilla compatible? (I'm pretty sure trying to convert maps that require even just a "limit removing port" instead of being strictly vanilla compatible isn't a good idea, for obvious reasons ;) The page and readme recommend Crispy Doom and GZDoom instead of Chocolate...

Per the Doom Wiki:

 

Quote

Phase 1 and Phase 2 are limit removing, with a compatibility goal for full Vanilla Doom planned for a future release. FreeDM, on the other hand, maintains a strict vanilla-compatibility requirement.

So I guess FreeDM would be, but the downside is it has no monsters. No idea if any of the "regular" Phase 1 maps would break Vanilla Doom though - just because it's limit removing as a max doesn't necessarily mean all the maps absolutely break vanilla limits, for example. And I'd bet that since they plan on eventual 100% vanilla compatability, the maps are generally made with this goal in mind.

 

EDIT: Further notes...

 

Quote

On December 17, 2015, Mike Swanson announced that the project goal of Freedoom had changed from Boom to vanilla. By doing so, many changes were made to both Phase 1 and 2 to make them vanilla-compatible as much as possible, starting with converting legible Boom maps to vanilla.

 

In February 2017, version 0.11 had been released. This version marked the first release to be compatible in limit removing engines. Limit removing was chosen as an interim goal for version 0.11's release, and as a milestone for making version 1.0 vanilla-compatible, except for possible savegame buffer overflows of certain levels.

So you *SHOULD* be fairly good for it, I think. At least, it's worth a try.

 

EDIT 2: Per the project website on the 0.12.0 release:

 

Quote

A strong focus on vanilla compatibility has been sought for this release. Most, if not all, levels should work now.

 

Edited July 17, 2020 by Dark Pulse

[xttl]

Ah crap, I setup AmigaOS 3.1 in UAE before noticing that ripdoom is one of the tools he didn't upload as a binary (at least not yet). And I also have no idea what Amiga assembler he might have used to assemble the sources... the Amiga-side linker (slink) referenced in smakefile seems like it could be part of the SAS C package. Maybe I'll try the assembler from that.

 

edit: ripdoom2.asm is still missing. All the other asm files assembled ok to objects using the assembler from SAS C though, and the makefile (called smakefile) is also intended for use with the smake program from that same toolkit. But without ripdoom2.asm, I cannot build the ripdoom program and try converting new maps. :(

Edited July 17, 2020 by xttl

[taufan99]

3 hours ago, seed said:

Indeed, I'd love something like this. I think they brothers are currently reverse-engineering another console port, but forgot exactly which. Sega Saturn Doom, I think?

It's D64, but Erick has mentioned that they're also spending some time on the Saturn port too.

[Gez]

3 hours ago, Job said:

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

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

 

I'd rather see PsyDoom feature-complete and then maybe building upon it to make PsyDoom 64... Other people can take care of SNES Doom.

 

[Job]

2 hours ago, Dark Pulse said:

Or Freedoom. Since, y'know... free.

 

Also...

 

Yes. Yes you are. Especially since he said earlier in the thread he's got his hands full with PsyDoom and will pass on it for now.

 

Now go rescue President Ronnie from the ninjas and prove your badness.

 

8 minutes ago, Gez said:

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

 

I'd rather see PsyDoom feature-complete and then maybe building upon it to make PsyDoom 64... Other people can take care of SNES Doom.

 

I agree on both counts, and I do remember Taco saying he wasn't really interested in branching off on this at the moment. There's enough wonderful console goodness to keep us happy for some time. On the surface, it looks sort of "easy" but I think because of the Amiga tool chain and other factors, this SNES DOOM sourceport is probably the more difficult project all said and done. It's times like this I wish I could program, I'd be happy to help move this along.

[Revenant]

1 hour ago, Dark Pulse said:

So I guess FreeDM would be, but the downside is it has no monsters. No idea if any of the "regular" Phase 1 maps would break Vanilla Doom though - just because it's limit removing as a max doesn't necessarily mean all the maps absolutely break vanilla limits, for example. And I'd bet that since they plan on eventual 100% vanilla compatability, the maps are generally made with this goal in mind.

Keep in mind, as well, that "vanilla compatible" doesn't imply "SNES Doom compatible". You'll have to at least get rid of all midtextures on 2-sided lines, for example, since the SNES version's renderer doesn't support them.

[Dark Pulse]

3 minutes ago, Revenant said:

Keep in mind, as well, that "vanilla compatible" doesn't imply "SNES Doom compatible". You'll have to at least get rid of all midtextures on 2-sided lines, for example, since the SNES version's renderer doesn't support them.

Of course, but well, vanilla-compatible maps are definitely the place you'd want to START since that will be the lowest base form of the maps that there can be.

[taufan99]

I know xttl is already aware of this, but for those who aren't, Phase 3 is out now.

[Dark Pulse]

Admittedly I'm curious as to why it's being released in phases... and how many more are left. Can't be too much more, right?

[taufan99]

15 minutes ago, Dark Pulse said:

Admittedly I'm curious as to why it's being released in phases... and how many more are left. Can't be too much more, right?

I guess he does so to give him some time to clean the rest up.

Also, given how the ACCESS toolchain is still empty...

[lunarmeadow]

I got curious and wanted to use the original random number table from the Doom executable, seeing as it is also a 256 byte array of 8-bit values.

 

Turns out, the game already uses the original random table, you can even copy the entire contents of the randomtable.bin file and search for it in the doom executable. The even weirder part is that it's literally located at offset 0 in the ROM. I wonder if Randy reverse engineered the original DOS executable to any degree, and if he truly only used the unofficial doom specs and whatnot, or if ID gave him a little bit of engine documentation, as it was made explicitly clear that Randy and the team had direct communications with iD during this time. I also noticed that when watching footage of XBand deathmatch, that players seem to move pretty similar to how you would expect from vanilla doom, looks to be a similar amount of friction and whatnot, maybe my eyes are just fucking with me and I'm overanalyzing. Regardless, this is all super cool and I've been waiting for this for an incredibly long time. Also, I can't compile any of the C utilities under Linux, I figured they stuck to the standard library, but there appears to be a library from the SAS C compiler that is needed for all of them.

[Dark Pulse]

2 hours ago, lunaark said:

I got curious and wanted to use the original random number table from the Doom executable, seeing as it is also a 256 byte array of 8-bit values.

 

Turns out, the game already uses the original random table, you can even copy the entire contents of the randomtable.bin file and search for it in the doom executable. The even weirder part is that it's literally located at offset 0 in the ROM. I wonder if Randy reverse engineered the original DOS executable to any degree, and if he truly only used the unofficial doom specs and whatnot, or if ID gave him a little bit of engine documentation, as it was made explicitly clear that Randy and the team had direct communications with iD during this time. I also noticed that when watching footage of XBand deathmatch, that players seem to move pretty similar to how you would expect from vanilla doom, looks to be a similar amount of friction and whatnot, maybe my eyes are just fucking with me and I'm overanalyzing. Regardless, this is all super cool and I've been waiting for this for an incredibly long time. Also, I can't compile any of the C utilities under Linux, I figured they stuck to the standard library, but there appears to be a library from the SAS C compiler that is needed for all of them.

IIRC, from what's been said about it, Randy totally reverse-engineered it himself, but he relied on some of the documentation the community dug up as well. id knew pretty much nothing about the port until he presented it to them, pretty much finished - no access to the source code or anything like that.

[Jon]

11 hours ago, Dark Pulse said:

And I'd bet that since they plan on eventual 100% vanilla compatability, the maps are generally made with this goal in mind.

Vanilla compatible is a relatively recent freedoom goal. For the first 10(?+) years they were boom compatible. I don’t know what the current state is but I’d be surprised if any of the maps from before the change in direction are within the visplane limit. (I just removed my map entirely when the decision was made to switch to vanilla, rather than try to butcher it down)

[Dark Pulse]

1 hour ago, Jon said:

Vanilla compatible is a relatively recent freedoom goal. For the first 10(?+) years they were boom compatible. I don’t know what the current state is but I’d be surprised if any of the maps from before the change in direction are within the visplane limit. (I just removed my map entirely when the decision was made to switch to vanilla, rather than try to butcher it down)

Well, per the Freedoom website, most, if not all, of the maps should be vanilla compatible now.

 

Either way, it seems Randy is still releasing necessary stuff to properly build the ROM, so we'll have to wait and see.

[xttl]

19 hours ago, Dark Pulse said:

Admittedly I'm curious as to why it's being released in phases... and how many more are left. Can't be too much more, right? 

 

Somebody from NESDev emailed Randy, and he said that there are going to be first phases 1-4 for Doom, then phases 1-4 for ACCESS. As to why it's being released in phases, maybe he's going through the files checking there's nothing infringing, or going through his closets searching old floppies? :D

^{(or he just wants to keep the buzz around this going longer ;)}

 

16 hours ago, lunaark said:

lso, I can't compile any of the C utilities under Linux, I figured they stuck to the standard library, but there appears to be a library from the SAS C compiler that is needed for all of them. 

 

Just comment out #include <mffp.h> and do link with math library (-lm), and they seem to work.

^{(and add #include <math.h> if you want to get rid of warnings)}

 

It seems many of the freedoom1.wad maps require flats or wall textures that aren't found in doom.wad. Only E1M3, E2M2, E3M1, E3M8, and all of E4 except E4M2 and E4M8 don't require graphics not found in that IWAD. Flats don't matter much because SNES Doom doesn't have them anyway, I'll have to see what I'll do about the textures if/when map conversion works. The maps that do load seem to run well enough in vanilla 1.9.

^{(well SNES Doom doesn't have all of the textures in doom.wad anyway though the texture variety might have been reduced less than on Jaguar/3DO/PSX so...)}

Edited July 18, 2020 by xttl

[taufan99]

@xttl Thanks for sharing that NESDev thread! It offers more insight within the SNES DOOM source release, and I'm glad he has gone this far to make sure we will get the exact shape of the port as it was developed by him (or at least the closest to exact).