SNES Doom source released under GPLv3

[RandalLinden]

5 hours ago, InDOOMnesia said:

Several days and no another news on this. I wonder if Randy has to take care of Phase 4's legal stuff as of now or is just cleaning up some of the code.

 

Still working on the legal stuff for Phase 4.

 

I'll be posting the source to the development tools in the next few days -- I have to finish the sound effects for two monsters for Cyboid first.

 

Rand.

[taufan99]

1 minute ago, RandalLinden said:

 

Still working on the legal stuff for Phase 4.

 

I'll be posting the source to the development tools in the next few days -- I have to finish the sound effects for two monsters for Cyboid first.

 

Rand.

All the best of luck, Randy!

[RandalLinden]

Bethesda has replied to my inquiry and they are not able to license and/or release the assets.

They didn't give any specific reason...
 

Quote

 

Thank you for contacting the Bethesda Customer Support Team.

 

While we appreciate your inquiry, as it turns out we cannot give you permission or a license for such use of our intellectual property.

 

Please feel free to reach back out to us at any time in the future should the need arise.

 

 

Rand.

[taufan99]

Well... That's unfortunate. Guess it's time to use the Freedoom assets then.

[Jayextee]

FreeDOOM's maps may prove to be a little complex in places for the SNES to handle well; bear in mind some of the original maps were cut for what I presume is a similar reason?

I've offered my 900 Deep in the Dead maps for such a purpose, being small 100-linedef maps; but this wouldn't fill out three episodes. Not entirely.

 

Spoiler

So. Community project when? :P 

 

[Dark Pulse]

56 minutes ago, RandalLinden said:

Bethesda has replied to my inquiry and they are not able to license and/or release the assets.

They didn't give any specific reason...
 

 

Rand.

The way to get around this would probably be to do one of two things:

1. Basically do what you did all those years ago: Create a program that will take a Doom IWAD (though nowadays, probably would want to also consider Doom 2, Ultimate Doom, and Final Doom as those all have some other different stuff) and spit it out into the formats that your toolchain would need to build a ROM. This way the end-user has to have a valid IWAD to generate the stuff, and it keeps you in the legal clear as you're not distributing assets.
2. The way Kaiser did it for Doom 64 EX: Use the original game ROM and create a program that will actually rip the data back out of the ROM into lumps. The difference here being that he did that to generate a Doom 64 IWAD for his engine to run; here we'd literally just be extracting the lumps to be used.

The first method would probably be better though, especially as then the code can be adapted (for if, say, someone wanted to try porting Doom 2 to the Reality Engine somehow). The second would be more a case of "can extract the right assets but more new code would have to be done for new stuff."

[RandalLinden]

13 minutes ago, Dark Pulse said:

The way to get around this would probably be to do one of two things:

1. Basically do what you did all those years ago: Create a program that will take a Doom IWAD (though nowadays, probably would want to also consider Doom 2, Ultimate Doom, and Final Doom as those all have some other different stuff) and spit it out into the formats that your toolchain would need to build a ROM. This way the end-user has to have a valid IWAD to generate the stuff, and it keeps you in the legal clear as you're not distributing assets.
2. The way Kaiser did it for Doom 64 EX: Use the original game ROM and create a program that will actually rip the data back out of the ROM into lumps. The difference here being that he did that to generate a Doom 64 IWAD for his engine to run; here we'd literally just be extracting the lumps to be used.

The first method would probably be better though, especially as then the code can be adapted (for if, say, someone wanted to try porting Doom 2 to the Reality Engine somehow). The second would be more a case of "can extract the right assets but more new code would have to be done for new stuff."

 

The first method is already operational -- that's what the RIPDOOM program does.

I can't supply the post-processed data... but if you were to take the various level .WADs and run them through the RIPDOOM program, it outputs all the necessary pieces.

Rand.

[Dark Pulse]

8 minutes ago, RandalLinden said:

 

The first method is already operational -- that's what the RIPDOOM program does.

I can't supply the post-processed data... but if you were to take the various level .WADs and run them through the RIPDOOM program, it outputs all the necessary pieces.

Rand.

Then yeah, it's basically just a case of "You'll need to have a valid Doom.wad IWAD in order to rip the data."

 

The code would presumably have to be altered for Doom 2/Ultimate Doom/Final Doom though, as all of those added new content.

 

For that matter, it's a good question to ask if RIPDOOM is sensitive to a specific version of the Doom IWAD - based upon E1M4's swastika being missing (unless you edited that yourself), you probably worked with a 1.4 (June 1994) or 1.666 (September 1994) IWAD. 1.8 or 1.9 is possible, but by the time of 1.8 we're into January of 1995 and you were presumably quite at work on the game by then. :)

[RandalLinden]

21 hours ago, Dark Pulse said:

For that matter, it's a good question to ask if RIPDOOM is sensitive to a specific version of the Doom IWAD

 

Shouldn't be... although I can't guarantee 100% that's the case, it is 25+ years on now.

[Gez]

You probably can distribute the modified levels -- those that needed to be changed before they could be sent through RIPDOOM. As long as it's not the entire IWAD with textures and sprites and sounds and music... Modified levels are allowed after all. And if you still have a copy of the tweaks your colleague did that id eventually nixed for SNES Doom, it'd be cool.

 

But yeah, just the levels are needed; for everything else people can provide their own IWADs.

[Dark Pulse]

@Gez Good point. The level data itself should be in the clear - it's the sprites/textures that RIPDOOM would really need to deal with.

 

That said, it should also be possible for someone to take the ROM and dump its contents as well, to get the levels "back" if for some reason the edited map sources can't be provided (or no longer exist).

[RandalLinden]

Every script for processing all the data should be there -- including the sprites, etc. -- so no need to fiddle and try to get the data out of the ROM binary.

 

There may be an issue with sound and music because I don't own the rights to the sound driver; That belongs to whomever owns whatever became of Sculptured Software.

 

Rand.

 

[Impboy4]

Scriptured Software got bought by Acclaim Entertainment in 1995 which then was renamed to Iguana West in 1997 and then Acclaim Studios Salt Lake City in 1999.  The company closed in 2002 due to Acclaim's financial problems and whatever was left was moved to Acclaim Studios Austin which then later shut down in 2004 due to the company declaring bankruptcy.

[Dark Pulse]

Sounds like this guy owns the rights:

 

¯\_(ツ)_/¯

 

2 hours ago, RandalLinden said:

Every script for processing all the data should be there -- including the sprites, etc. -- so no need to fiddle and try to get the data out of the ROM binary.

 

There may be an issue with sound and music because I don't own the rights to the sound driver; That belongs to whomever owns whatever became of Sculptured Software.

 

Rand.

 

Well, that also depends - for example, E2M2 (PC E2M3) was modified since you (or someone else) added that little bit near the exit to give a secret exit for E2M6 (PC E2M9), since the level it was originally in (PC E2M5) was cut from the SNES version. So for that map, at least, a 1:1 version would need to be pulled from the ROM unless you've still got the PWAD for it floating around to be converted or something.

 

In practice, a rip from the ROM would be needed in case there's other significant alterations, but to be honest that's the only one I can remember where it was new geometry added to the level.

[Quasar]

On 8/7/2020 at 10:20 AM, RandalLinden said:

Bethesda has replied to my inquiry and they are not able to license and/or release the assets.

They didn't give any specific reason...
 

 

Rand.

Having worked with Bethesda on a commercial project, I can tell you that you definitely can't get anywhere by going at it this way and that's just a boilerplate response from customer support. In order to really get anywhere you'd need to talk to somebody at id, who could then hook you up with the right legal people at ZeniMax. Kevin Cloud is still there from way back, don't know if you ever met or talked with him, but he's a good guy. Bit hard to get a hold of externally though.

 

As far as Sculptured Software goes, those copyrights for internal resources are definitely 100% orphaned. Not to be construed as legal advice, but I think you'd be absolutely safe to release it. The stuff that got auctioned off/bought in the Acclaim bankruptcy was all rights to particular games and not stuff like that, as far as I'm aware.

[lunaark]

Looking into the Acclaim liquidation further, I think the sound driver can be considered orphaned work. I have looked into the companies who purchased Acclaim's assets and none of them appear to have purchased any SNES games, and I presume that's why Randy was able to release the source code so easily. In the credits of the game, 2 people are mentioned who are known to have worked on music and driver coding, those 2 people being Bob Dayley and Paul Webb. VGMPF says it is likely that Bob Dayley did the actual writing of the sound driver. Given that presumably no company holds the rights to the driver code, it is likely Bob Dayley.

 

Quote

An orphan work is a copyright-protected work for which rightsholders are positively indeterminate or uncontactable. Sometimes the names of the originators or rightsholders are known, yet it is impossible to contact them because additional details cannot be found.[1] A work can become orphaned through rightsholders being unaware of their holding, or by their demise (e.g. deceased persons or defunct companies) and establishing inheritance has proved impracticable.[2] In other cases, comprehensively diligent research fails to determine any authors, creators or originators for a work. Since 1989, the amount of orphan works has increased dramatically since registration is optional and, thus, many works' statuses remain unknown.

 

This is Wikipedia's definition of orphaned work, so take it with a massive grain of salt, but if whoever wrote the sound driver is unable to be found, it is likely ok to release it. I am not a lawyer by any means so please take this very lightly, but I'm sure some legal professionals could figure this out. As for asset licensing, I presume Rebecca Heineman would be a good person to contact. She was able to release the assets for 3DO Doom, and this was done while iD was owned by Bethesda. Heineman is very easy to contact, as far as I know.

[Jon]

3 hours ago, lunaark said:

2 people are mentioned who are known to have worked on music and driver coding, those 2 people being Bob Dayley and Paul Webb. VGMPF says it is likely that Bob Dayley did the actual writing of the sound driver. Given that presumably no company holds the rights to the driver code, it is likely Bob Dayley.

Do you believe that an employee gains ownership of a asset they worked on when the company is liquidated and said asset orphaned?

 

3 hours ago, lunaark said:

Rebecca Heineman would be a good person to contact. She was able to release the assets for 3DO Doom, and this was done while iD was owned by Bethesda. Heineman is very easy to contact, as far as I know.

Do you think she got permission to release it or just treated it as abandonware and put it out there anyway? I think the latter, especially since she chose a BSD license. 

[RandalLinden]

On 8/16/2020 at 2:26 AM, Jon said:

Do you think she got permission to release it or just treated it as abandonware and put it out there anyway? I think the latter, especially since she chose a BSD license. 

 

I've spoken with Becky and she received permission, unfortunately the person she worked with is no longer at the company.

[Jon]

3 hours ago, RandalLinden said:

 

I've spoken with Becky and she received permission, unfortunately the person she worked with is no longer at the company.

That's good to know, thanks!

[RandalLinden]

I have some other avenues that I'm pursuing regarding the rights to the data.

 

I'll follow up when I hear something back.

 

Rand.

 

[taufan99]

2 minutes ago, RandalLinden said:

I have some other avenues that I'm pursuing regarding the rights to the data.

 

I'll follow up when I hear something back.

 

Rand.

 

[Dark Pulse]

Good luck, Randy!

[Job]

@RandalLinden, I want you to know that we really appreciate all your effort and hard work with this project. It means a whole lot to us!

[RandalLinden]

I'll need an emulator to test the ROM and would appreciate recommendations.

 

Importantly, the emulator must NOT exhibit the random incorrect pixels that most emulators appear to have.

 

Thanks!

 

Rand.

 

[taufan99]

9 minutes ago, RandalLinden said:

I'll need an emulator to test the ROM and would appreciate recommendations.

 

Importantly, the emulator must NOT exhibit the random incorrect pixels that most emulators appear to have.

 

Thanks!

 

Rand.

 

bsnes and higan are emulators that aim for perfect accuracy of the original SNES hardware.

[Dimon12321]

Bizhawk utilizes both BSNES and Snes9x cores and doesn't require any firmware to play SNES games. You may need to change the core in the configs.

Spoiler

 

Edited August 24, 2020 by Dimon12321

[RandalLinden]

Thanks, bsnes works great!

 

Since I don't have the binaries for many of the pieces, my plan is to use the "rl.sec" output map to take the ROM and generate the required pieces...  a simple script that chops a .SFC into various chunks should do the trick.

 

Rand.

 

Edited August 24, 2020 by RandalLinden

[Dark Pulse]

Late to the party, but seconding bsnes/higan for sure. byuu focused his emulator intensely on accuracy, to the point that it's cycle-accurate.

 

While I'm sure Randy doesn't need me to explain the concept, for the rest of you, cycle-accuracy in an emulator means that the emulator takes the exact same amount of emulated clock cycles to do the same amount of work as the real machine - the calculations on the processor take the same amount of time, reading the inputs has the same lag, etc. It's easy, for example, to get an emulator's speed up by doing stuff faster than normal, and while there's plenty of games that will work just fine with that, games that have highly sensitive timings will begin to break in all sorts of strange and unusual ways.

 

Cycle-accuracy means that the emulator is basically at a level where even unusual and odd system quirks should be successfully caught, emulated, and reproduced accurate to the original hardware. It ensures that all the components that generate the output are properly in sync, responding accurately in time in relation to each other, and is properly mixed/calculated so that interrupts are firing at the right times compared to the original console.

 

A lot of the popular emulators AREN'T cycle-accurate. ZSNES is one of the worst offenders you could play SNES games with now. SNES9x is better, and fine for most general emulation (and indeed, cycle-accuracy isn't always required for 100% game compatibility!), but it's still not perfect (it can choke on certain instructions, namely ADC/SBC, and some edge-case OAM stuff, and there are a few games it still can't run). Bizhawk is actually really damn good (as it's a fork of bsnes v087)... but it actually will fail Super Scope and SNES Mouse tests, so it, too, isn't perfectly accurate (although besides those, it passes all the tests the emulation community has thrown at it - caveat: that comparison hasn't been updated in almost six years). Only bsnes and lsnes can claim 100% accuracy.

 

There are, in fact, even lower (i.e; more accurate) levels of accuracy than this. Subcycle accuracy would emulate the actual low-high pulses of the chips; doing it at cycle accuracy would mean, essentially, doing both the low and high pulse as one tick. Bus accuracy would emulate the actual electrical signal propagation to and from the chips. Chip accuracy emulates the very logic circuits of the chips themselves (this is what a SD2SNES does via its FPGA). And if you go all the way back to the early 70s when arcade games (think Pong) had no CPU at all, it was entirely discrete, analog logic - and emulating them means you have to simulate all that circuitry.

 

However, for a general-purpose emulator, 99.99% of the time, none of the above lower levels of accuracy are necessary.

 

I'd say the key thing we'd want is that as people begin to mod the game code and reinstate levels or even remake new ones, we should be making sure that they'll run on authentic hardware via SD2SNES and the like. For that, it's definitely good to have Randy working off at least a cycle-accurate emulator - there's a LOT of ROM hacks that relied on ZSNES, for example, and they will absolutely diarrhea everywhere on a different emulator, or a more accurate one, or actual hardware. It'd be good to avoid that for SNES Doom.

 

That said, at this point, basically an SD2SNES and an actual SNES to work on is the most accurate one can get.

Edited August 24, 2020 by Dark Pulse

[RandalLinden]

46 minutes ago, Dark Pulse said:

For that, it's definitely good to have Randy working off at least a cycle-accurate emulator - there's a LOT of ROM hacks that relied on ZSNES, for example, and they will absolutely diarrhea everywhere on a different emulator, or a more accurate one, or actual hardware. It'd be good to avoid that for SNES Doom.

 

I'm actually just using the emulator to test a ROM image built with the toolchain so I can make sure that the instructions I'll put together work correctly.

 

Rand.

[Redneckerz]

1 hour ago, Dark Pulse said:

Late to the party, but seconding bsnes/higan for sure. byuu focused his emulator intensely on accuracy, to the point that it's cycle-accurate.

Thirding (is that a thing) BSNES but even more so Higan. Because this is low level emulation,  or LLE. it requires a hefty PC to run, but there are very few, if any, emulators that possess the level of refinement in emulation that Higan has. Its absolutely bonkers and one of the most impressive pieces of community code i have seen bar demoscene work.

 

Useless but fun fact for the rest of you: The first N64 emulator for PC's in the 90s was a HLE (High Level Emulator).