SNES Doom source released under GPLv3

[Dark Pulse]

1 hour ago, Doomkid said:

Buh? There are loads of objects with no sprite rotations in doom (literally every item, powerup, weapon and decoration object) and it causes no problems at all with circle strafing. I think the issue is down to either an inefficiency in the code or bottlenecked hardware, not really related to lack of sprite rotations.

Those other objects also didn't exactly move, now did they?

 

You telling me you ain't gonna be confused when that Pinky starts crabwalkin' while staring you down the whole time?

 

(The easiest way to see this if you die in SNES Doom. Start on Inferno and get smoked by the Imps.)

 

PS: As punishment for your sin, I expect a MIDI of The Black Page #1.

Edited July 15, 2020 by Dark Pulse

[Doomkid]

I understand that it looks weird, but my point is the fubar'd circle strafing wasn't intentionally implemented because of that - it's some weird problem with the control input where it can only accept so many directional inputs at a time, thus making "strafing left and also turning" impossible. It's an arbitrary limitation that I'm certain could be fixed.

 

I'd really love to see that pesky input delay fixed as well, but who knows if that's possible. Imo, the lack of circle strafing and input delay were the only problems I had with the SNES port. Graphically, musically and in terms of map geometry, it's great considering the hardware.

[Dark Pulse]

2 minutes ago, Doomkid said:

I understand that it looks weird, but my point is the fubar'd circle strafing wasn't intentionally implemented because of that - it's some weird problem with the control input where it can only accept so many directional inputs at a time, thus making "strafing left and also turning" impossible. It's an arbitrary limitation that I'm certain could be fixed.

I'd love to see where you heard that, since plenty of other games have no problem with you holding down L/R trigger and Left/Right on the D-Pad at the same time. I do it literally all the time in F-Zero.

[Doomkid]

I didn't mean it was a limit of the SNES itself, I meant it's a limit of this particular engine in it's unaltered state. I've always cited the Wolf3D port for SNES as my proof that the controls could be better!

[Dark Pulse]

1 minute ago, Doomkid said:

I didn't mean it was a limit of the SNES itself, I meant it's a limit of this particular engine in it's unaltered state. I've always cited the Wolf3D port for SNES as my proof that the controls could be better!

Well that's what I'm saying, I think that rather than some weird controller nonsense it was just there because it'd look silly with one-sided monster sprites to try to circle-strafe it :P

[taufan99]

1 hour ago, Dark Pulse said:

(The easiest way to see this if you die in SNES Doom. Start on Inferno and get smoked by the Imps.)

Speaking of which, I've noticed that in SNES DOOM, monsters notice you in a similar sector to where they are, regardless of height, so they'll immediately notice and attack you, unlike in PC.

[Job]

4 hours ago, Dark Pulse said:

You telling me you ain't gonna be confused when that Pinky starts crabwalkin' while staring you down the whole time?

LOL'd internally at this, thanks. 

[andrewj]

1 hour ago, Job said:

LOL'd internally

You laughed out loud silently?

Or has "lol" become a generic term for laughing now?

(sorry if this is off-topic)

[Job]

13 minutes ago, andrewj said:

You laughed out loud silently?

Or has "lol" become a generic term for laughing now?

(sorry if this is off-topic)

Well, it started as a bona-fide LOL, but I had to suppress and internalize it for fear of waking the kids. Comes with the territory of being an old adult I suppose. 

 

To answer your question though, I do think it's become synonymous with, or shorthand for, actually laughing. 

[BBQgiraffe]

would be fun to port to C, too bad I'm horse shit at assembly, but hey at least it's well commented

[Jon]

8 hours ago, Dark Pulse said:

He wrote the engine himself, and presumably the fact it took months was due to him tracking down whatever legal things might hang it up. It was said that him figuring out what license to put it under was the thing holding the release back.

I don’t doubt that he did, just like Burger Becky wrote the 3do stuff. That’s not the same as owning the rights. It’s typical for employees of a software company not to own the code they write: their employer does.

 

the fact there was a delay whilst “something” was worked out is encouraging but it’s not proof of ownership.

 

i think it’s great, really great, when historic source code is made public. But at the same time it’s potentially dangerous for any code to be licensed open source when ownership is in doubt. 

[Dark Pulse]

15 minutes ago, Jon said:

I don’t doubt that he did, just like Burger Becky wrote the 3do stuff. That’s not the same as owning the rights. It’s typical for employees of a software company not to own the code they write: their employer does.

 

the fact there was a delay whilst “something” was worked out is encouraging but it’s not proof of ownership.

 

i think it’s great, really great, when historic source code is made public. But at the same time it’s potentially dangerous for any code to be licensed open source when ownership is in doubt. 

Well, 3DO Doom was under the MIT license. In some ways, GPL3 goes further than that, but unlike 3DO Doom, Randy didn't release the assets with it. Don't exactly see anyone C&Ding 3DO Doom's source yet, so I doubt that will be the case here - IMO it'd be way more likely for 3DO Doom to be taken down than SNES Doom.

 

Also notable, like 3DO Doom's "developers" (Art Data Interactive), Williams has effectively gone poof - they reverse tookover Midway, the videogame part of their biz was spun off as Midway in 1998, Midway went bankrupt in 2009, and most of the assets were bought up by Time Warner. Obviously, Doom would not be included in that - Bethesda most likely holds the rights to it, as indicated by the recent re-release of Doom 64, but you'd have to be insane to put up a new commercial port of the SNES version.

 

Interestingly enough, the pinball half of Williams has survived and outlived Midway, but it exited the pinball business around 1999 and went into slot machines. They were bought out by a company known as Scientific Games, becoming a brand of theirs as of 2016. Today they're known simply as WMS; the same company owns the SG, Bally, and Shuffle Master brands.

 

Anyway, again, I'm pretty sure Randy did his homework here and figured out what he needed if he was going to ensure it was under GPL. After all, he easily could've put it under a more restrictive license if he didn't feel confident in that. Guys who've been programming for decades probably don't just put out their source code all willy-nilly like that without dotting their i's and crossing their t's.

 

And again, to make your argument even hold a cred of truth, you basically need to argue that somehow id owns the Rage/Reality Engine, which I seriously doubt would fly. They certainly own all the Doom-related asset data, but there's nothing that ties it so inherently to the engine that it can't run another game. Fraggle was just saying earlier in this thread that it might be possible to port Freedoom to it.

[Jon]

 

that’s all lovely but has nothing to do with what I wrote. 
 

30 minutes ago, Dark Pulse said:

And again, to make your argument even hold a cred of truth, you basically need to argue that somehow id owns the Rage/Reality Engine,

 

no I don’t. If you think that then you don’t understand what I’m saying.  I haven’t said anything at all about Id. 

 

30 minutes ago, Dark Pulse said:

 

Fraggle was just saying earlier in this thread that it might be possible to port Freedoom to it.

also lovely and still irrelevant. 

[xttl]

https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer2.a#L215

 

Just remove that somehow to get your circlestrafing.

 

I'm currently trying to find an assembler for this thing, found something called ARGOS2.EXE but it needs either OS/2 or old WinNT/Win2K to run apparently, lol.

 

edit: and this https://sourceforge.net/p/sfxasm/code/ci/master/tree/ somehow doesn't have an .include feature (at least so the documentation says, and changing all the includes to .includes doesn't work)

Edited July 15, 2020 by xttl

[taufan99]

@xttl Dude, that's a nice discovery!

 

[xttl]

Actually it's not that simple after all. I think I correctly nop'd out that jump by hex editing the ROM (change 05 1F to 01 01 at 0x225) but now the player is always turning left when strafing to either direction.

[xttl]

Well, I setup a Win2K VM just to run argos2.exe (it's a 16-bit OS/2 console mode executable, older 32-bit versions of WinNT like 2K can run them), but it doesn't assemble rlplayer2.a (or some other files I tried) either. :(

 

According to info from the Doom Wiki, https://github.com/RandalLinden/ACCESS is what was originally used to build this but the repo is currently empty.

 

It seems https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlinc.i#L35 there is a define to change between ACCESS and SASM, but there are no references to either in the code, and what is SASM anyway?

[Gez]

51 minutes ago, xttl said:

and what is SASM anyway

https://en.wikipedia.org/wiki/SASM maybe? Depends on whether that switch is a new thing as part of an attempt at making the project buildable on modern machines (and the lack of references would then be explained by that work not having actually been done yet) or not.

 

If, on the other hand, it's a 1990s-vintage Amiga assembler, it's going to be harder to track down...

[xttl]

10 hours ago, Gez said:

https://en.wikipedia.org/wiki/SASM maybe?

 

I think that one supports x86 assemblers only. maybe not, GAS is there

 

I suspect SASM might be something from an official Nintendo SDK:

https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=62303#Post62303

 

Also, it seems the code is using the same variable in memory (PlayerMouseX) for both strafing and turning. :( (I think 65816 controller code in rlplayer.a sets PlayerMouseX in either case, and then depending on whether strafing or not it is used differently by GSU code in rlplayer2.a)

 

So it becomes a little more complex to add turning and strafing at the same time without being able to properly rebuild the ROM.

Edited July 15, 2020 by xttl

[ImpieEyez95]

20 hours ago, Revenant said:

https://github.com/RandalLinden/DOOM-FX

 

Randy Linden has posted the original SNES Doom source to GitHub today.

 

The actual game assets (graphics, maps, etc) aren't included, but there's still plenty of interesting material in here, including (of course) the actual SuperFX renderer code as well as XBAND multiplayer support.

 

18 hours ago, Dark Pulse said:

I was just wondering about this last night. Good to see it's FINALLY moving forward.

 

"Source Phase 1" seems to indicate there will be more to it later, as well. Hmm...

 

But yeah, a port is definitely gonna be tricky. Better know 65C816 assembly (essentially a variant of the 6502) to get anywhere. :P

Exactly DarkPulse, which i think most seem to have glanced over - that this isn't the "full release" of the source code.. I assume there will be more released (ie tools, assemblers, tool source etc) which will be great for the SNES Homebrew/Development Community! 

With the prevalence of flash carts, you could potentially add in new levels etc (ie Thy Flesh Consumed (possibly) and other such things, by expanding the engine, real excited to see what comes of this! ... SIGIL on SNES? Who da thunkit? 

Great Discord server regarding SNES homebrew dev here: https://discord.gg/vwskGDV 

Edited July 15, 2020 by ImpieEyez95

[xttl]

Success! I managed to patch the US ROM to have strafing and turning at the same time. Strafing speed is too fast though, I'll try to adjust the speed. For anybody who wants to try it:

 

offset: oldbyte newbyte

000001DA: 3D F6
000001DB: A6 07
000001DC: F9 80
00000225: 05 01
00000226: 1F 01
001C0929: F0 80
001C0941: F0 80

 

[xttl]

Explanation:

 

F0=>80 at 0x1C0929 and 0x1C0941 changes these two 65816 beq instructions into unconditional branches

 

https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer.a#L378

https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer.a#L391

 

05 1F => 01 01 at 0x225 changes this branch into two NOPs in GSU (SuperFX) code:

 

https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer2.a#L215

 

Then finally 3D A6 F9 => F6 xx xx at 0x1DA changes this instruction to write a 16-bit immediate value into the R6 register instead of using the contents of PlayerMouseX from RAM:

 

https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer2.a#L128

 

I think F6 00 10 or F6 00 0F F6 00 08 starts to feel about right, I didn't figure out the exact PlayerMouseX value that is normally used for strafing yet.

 

A problem is that now running does not affect the strafing speed at all. That will need more GSU code patching (or maybe a different approach altogether). Also even the unmodified ROM  seems to have other, bigger problems with controls than no circlestrafing, like not being able to turn and move forward/backward at the same. Did I screw up my SNES emu config somehow? (I admit: I haven't ever played this on real hardware) ^{(yes, my pad config is somehow wrong, I don't often play games on this machine since it's an old laptop...)}

 

If I get this working completely, I really wish I had a flashcart with SuperFX support, but those are kinda pricy. :(

 

another problem I noticed: strafing left/right makes turning slower, especially if run button is held down.

Edited July 15, 2020 by xttl

[betabox]

Nice work, xttl!

 

And awesome news in general about this source release. Easily one of the best console Doom related developments this year, to me.

[Dark Pulse]

9 hours ago, Jon said:

that’s all lovely but has nothing to do with what I wrote. 

 

no I don’t. If you think that then you don’t understand what I’m saying.  I haven’t said anything at all about Id. 

also lovely and still irrelevant. 

Well, it's pretty damn simple in the end, isn't it?

 

If he owns the code and has done his diligent homework in working out what legal complications may arise from the code getting opensourced (or acquiring the rights back to it, if necessary), he's fully under right to say it's under GPL3 and the repository will stay up and that will be the end of it.

 

If he doesn't own the code, and someone else who does wants to take it down, it will get taken down, though squashing it now is very hard since several other people have forked/downloaded it. Making something out of it will be technically forbidden due to GPL3 requiring anything using it to likewise be opensourced (which can't exactly happen if the original baseline source is made illegal), but the code will float around the internet.

 

That's pretty much all my point is. Only he knows if he actually owns the code or not; my argument is a guy who's programmed for decades and had to deal with all sorts of legal fun before (remember Bleem! the PS1-on-PC, and its offshoot Bleemcast, the PS1-on-DC emulator? Yeah, he wrote those too - Sony sued, lost, and only got Bleem! pulled off the shelves by tying the company up in legal woes until it couldn't fight it anymore) would be quite experienced with dealing with legal hurdles, and so I'm pretty damn sure that if he's putting it up under GPL3, he's got a pretty damn good idea of who owns the code - and that it's him, and thus he knows exactly what he's doing.

[xttl]

I got the PlayerMouseX value right the first time after all (it IS 0x780 when not running, I confirmed it using this because I couldn't figure out how to set SuperFX breakpoints in bsnes-plus :D), but I got the endianness wrong so it became 0x8007, that's why it was too fast. So to enable circlestrafing with the original walking strafe speed, the correct patch is:

 

000001DA: 3D F6
000001DB: A6 80
000001DC: F9 07
00000225: 05 01
00000226: 1F 01
001C0929: F0 80
001C0941: F0 80

 

When running, it should be set to 0xB40 instead but to make that work using this method needs adding more GSU code in. I might try to convert at least part of rlplayer2.a to assemble with https://github.com/ARM9/bass later (it seems least crappy of the GSU assemblers I've found so far, except maybe the leaked Argonaut one but too bad it's only for OS/2) to make adding code easier.

[Redneckerz]

Oh, give this man (xttl) a Caco (Espi) award already.

 

^{(Atleast consider it folks. Some pretty 1337codefu comes from this magician.)}

[Dexiaz]

This is exactly what I wanted to say too.

[xttl]

Well, honestly this isn't rocket science, I just have too much time to spend on things like this currently, I'm not even that good at RE/assembly or programming in general and there hasn't been any big, long-term or significant Doom community project I've been involved in, so I don't think I'd really deserve it.

 

If there was a cacoward for just hacking Doom, I think it shouldn't be awarded for anything less than figuring out a way to get code execution from WAD on vanilla, preferably the latest version (ie. v1.9). :-) If not that, then at least code exec from savegame, that would be the minimum level where I wouldn't be embarassed to receive it. It would be pretty cool, you could just patch in any feature you might want for your vanilla mod into the engine on the fly. Of course it could also be dangerous, but how many people are using DOS computers that they also play Doom on for anything serious these days?

 

Anyway, to fix slow turning when run button is pressed while (circle)strafing add this to the previous patch:

001C0993: F0 80

(it changes yet another beq to bra on the 65816 side, https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer.a#L435)

 

Also, I thought a good value to use for the strafing speed (until code to check for run button is added on the GSU/SuperFX chip side) might be 0x960 which is halfway between 0x780 and 0xB40

 

So the complete patch thus far is:

000001DA: 3D F6
000001DB: A6 60
000001DC: F9 09
00000225: 05 01
00000226: 1F 01
001C0929: F0 80
001C0941: F0 80
001C0993: F0 80

(but you can try different values for the next two bytes after the first F6 based on your preferences)

 

edit: IPS patch attached (sucks how it must be packaged into a zip because it is small enough that zipping only increases size :)

see later post for new patch

 

Edited July 17, 2020 by xttl

[xttl]

New patch with run on/off while strafing implemented.

I noticed there are some strings of 0x00 bytes (GSU stop instruction) which seem like they could be just padding or areas to catch bad calls/jumps, eg. at 0x917, 0xA2F and 0xC01. I reused them for adding some new code by jumping back&forth from the original input handler. I hope it doesn't cause any problems. At least the game hasn't crashed so far on SNES9X or BSNES...

Now, anybody want to put this into a Winter Gold FX2 cartridge with (de)soldering equipment and mail that to me? :D

^{(preferably with NTSC or multiregion CIC and North American or universal cartridge shell, and with overclocked FX2 chip)}

 

IPS:  see later post for new patch

 

Bytes:

Spoiler

000001DA: 3D FB
000001DB: A6 18
000001DC: F9 89
000001DD: 3D 9B
000001DE: A0 01
000001DF: 04 01
00000225: 05 01
00000226: 1F 01
00000918: 00 29
00000919: 00 10
0000091A: 00 F1
0000091C: 00 80
0000091D: 00 FB
0000091E: 00 2F
0000091F: 00 8A
00000920: 00 9B
00000921: 00 01
00000A2F: 00 F6
00000A30: 00 80
00000A31: 00 07
00000A32: 00 71
00000A33: 00 09
00000A34: 00 04
00000A35: 00 01
00000A36: 00 F6
00000A37: 00 40
00000A38: 00 0B
00000A39: 00 FB
00000A3A: 00 01
00000A3B: 00 8C
00000A3C: 00 9B
00000A3D: 00 01
00000C01: 00 3D
00000C02: 00 A0
00000C03: 00 04
00000C04: 00 FB
00000C05: 00 E0
00000C06: 00 81
00000C07: 00 9B
00000C08: 00 01
001C0929: F0 80
001C0941: F0 80
001C0993: F0 80

 

 

edit: modified header game name ("DOOM CIRCLESTRAFE ED") + header checksum fix in IPS

 

edit2: I think what I overwrote with new code chunks might have been parts of jump tables such as this and this. It looks like some of those nulls are ok to overwrite (can you ever pick up PlayerStarts or TeleportSpots? it looks like there are other checks made other than just if table[type]!=0 which in fact seems to be not made if the code gets far enough to use the table to jump) but maybe not all, will need to investigate and map the ROM more...

 

edit3: those aren't the rlmove7.a tables (rlmove7.a is located much later in the ROM, code starts at 0x2AEB and the tables start at 0x2CA1), and I still don't know what they are... I'll rewrite the patch later to use those rlmove7 jumptable zeroes instead because it looks they're safe to use

 

Edited July 17, 2020 by xttl

[taufan99]

Phase 2A and B are up now! Commit summary:

 

Quote

Each assembled source file has a corresponding version file which is "bumped" with each change. The resulting "*.a.i" file can be included to embed the file version infomration in the output binary. Although this functionality was rarely used, an example can be seen here (14 seconds into the video, the version of "xb" is displayed):

The pair of scripts "rlvers" and "rlvers0" generate a listing file "rl.ver" which indicates the version of each source file.

 

Edited July 16, 2020 by InDOOMnesia