SNES Doom source released under GPLv3

[Revenant]

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.

[esselfortium]

Awesome! This port is a technical marvel, it's great to have the source released for it.

[seed]

Indeed, this is pretty fucking sick.

 

I wonder how long will it take for source ports to show up now, I can't wait for that. Maybe, hm... @intacowetrust, may I interest you into a port :D ?

[Dimon12321]

Hah, it was already forked by 3 people, none of whom has ever worked in Assembler, according to GitHub statistics. I'm interested in their possible efforts =)

Edited July 14, 2020 by Dimon12321

[Dark Pulse]

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

Edited July 14, 2020 by Dark Pulse

[Gez]

Nice to see it finally happened. :)

[Roebloz]

This is good news for the SNES Doom. Will we finally get a level builder??? I know @CacodemonTubemade one but it isn't publicly available.

[Redneckerz]

This is brilliant stuff, so happy that Randy Linden made the effort possible.

 

Lets see what people come up with it. A proof op concept Windows port is an obvious idea.

 

Paging @InDOOMnesia for this one.

 

The world IRL might be a little like DoomGuy's hell, but in the world of Doom and consorts, 2020 has been a stellar year so far.

 

Downloading.....

Edited July 14, 2020 by Redneckerz

[Chopkinsca]

Cool beans. I wish I was more interested in coding so I could dive into this. SNES kind of has a special spot in my heart since for a time it was my only Doom. I think I have the game laying in some clutter pile around here too.

[Job]

Wow! I've been checking Randy's Github almost every day since his interview about the source code. Go figure this slips by the one time I don't look. 😅

[Spie812]

This is rad as hell. The SNES port is a compromised one though impressive technically, yet I still have a great appreciation for it as the first version of Doom that I played. Curious to see what interesting stuff can come out of this.

[Redneckerz]

Some initial bullet points:

• Most of the source code is made as modules. So there is an object module, a music driver, and so on.
• A lot of activity goes on in rage.i and rle.i as these get called pretty frequently.
• Surprisingly good commentary in the code. It is pretty readable, even for a non-programmer like myself. Very impressive.
• The engine name is named differently in different files So far ive come across: Rage/Reality, RL Engine, Project: Reality_Engine, Reality Engine
• Internal codename was seemingly Project: Rage or Project: Reality
• rle.i carries a very interesting section called Engine maximums. These showcase what the limits of the engine are in terms of max amount of enemies, but also sectors, vertexes, textures and what not.
• rle.i is an interesting file anyway since it describes every structure present from the engine. Beautifully commented, its very clear.
• ripdoom.i is callled Doom Ripper and seems to describe a set of parameters of for levels. Interestingly, they carry higher values than the engine maximums found in rle.i.

Code stub of Engine maximums as found in rle.i:

;
;	* * * * * * *       ENGINE MAXIMUMS       * * * * * * *
;
MaxRLVertexes		equ	1056	; E2M4		; *Maximum VERTEXES per Level
MaxRLSectors		equ	205	; E2M4		; *Maximum SECTORS per Level
;MaxRLAreas		equ	512			; Maximum AREA Nodes per Level
;MaxRLSegs		equ	2438			; Maximum SEGS per Level
MaxRLLines		equ	1118	; E2M4 (1117)	; *Maximum LINES per Level
;MaxRLFaces		equ	1440			; Maximum FACES per Level
;
MaxRLTextures		equ	256			; Maximum TEXTURES
;
MaxRLFObjects		equ	180 ; 160		; *Maximum FIXED OBJECTS per Level
MaxRLMObjects		equ	100			; *Maximum MOVABLE OBJECTS per Level
MaxRLObjectTypes	equ	256			; Maximum OBJECT Types
MaxRLImages		equ	256			; Maximum IMAGES
;
RLScreenPlane		equ	4			; Distance from Eye to ScreenPlane
RLAspectRatio		equ	$00014000		; AspectRatio (%Increase in Y)
RLMaxViewDistance	equ	7168			; Maximum Viewing Distance
	ife	useHIGHDETAIL
MaxRLClipZones		equ	(RLViewPixX/2/(2+1))	; Maximum CLIPZONES (2SOLID+1BLANK)
	endif
	ifn	useHIGHDETAIL
MaxRLClipZones		equ	(RLViewPixX/(2+1))	; Maximum CLIPZONES (2SOLID+1BLANK)
	endif
;
MaxRLVSegs		equ	168 ; 160		; Maximum Visible Segments
MaxRLVFloors		equ	40 ; 32			; Maximum Visible Floors/Ceilings
;MaxRLVAreas		equ	256			; Maximum Visible Areas
MaxRLVSectors		equ	(64-1)			; Maximum Visible Sectors
MaxRLVObjs		equ	28 ; 32			; Maximum Visible Objects
;
MaxRLTasks		equ	48 ; 64			; Maximum TASKS
;
;MaxRLMoveLines		equ	(64-1)			; Maximum Lines Checked when Moving
MaxRLUseLines		equ	(64-1)			; Maximum Lines Checked to Use/Operate
;
MaxRLMPlats		equ	48 ; 64			; Maximum Movable Platforms
MaxRLToggles		equ	12			; Maximum Toggles
;
MaxRLSounds		equ	8			; Maximum Sound Effects
;
;MaxRLEnemies		equ	MaxRLMObjects		; Maximum Enemies
MaxRLTargetEnemies	equ	24			; Maximum Targetting Enemies
MaxRLMoveEnemies	equ	24			; Maximum Moving Enemies
MaxRLAttackEnemies	equ	20			; Maximum Attacking Enemies
MaxRLBirthEnemies	equ	MaxRLAttackEnemies	; Maximum Birthing Enemies
MaxRLMoveProjectiles	equ	24			; Maximum Moving Projectiles
MaxRLRadiusDamages	equ	14			; Maximum Radius Damages

RLMaxCutSprOAMs		equ	(128-(3+8+12+3+3+3))		; Max CutSpriteOAMs (98)
;RLMaxCutSprCHRs	equ	(512-((vmWEAPONDEF&$1fff)>>4))	; Max CutSpriteCHRs (168)
RLMaxCutSprCHRs		equ	RLMaxCutSprOAMs
;
RLMaxCharDefXFer	equ	1024			; Maximum .CHARDEF Bytes per XFer

Code stub of ripdoom.i:

rllSize			equ	12
rlbSize			equ	28
rlaSize			equ	4
rlgSize			equ	11
rlfSizeS		equ	2
rlfSizeT		equ	4
rlsSize			equ	10
rlsdSize		equ	14
rlpSize			equ	8

;MaxRLVertexes		equ	1626			; Maximum VERTEXES per Level
MaxRLSectors		equ	205			; *Maximum SECTORS per Level
;MaxRLAreas		equ	512			; Maximum AREA Nodes per Level
;MaxRLSegs		equ	2438			; Maximum SEGS per Level
;MaxRLLines		equ	1764			; Maximum LINES per Level
;MaxRLFaces		equ	2252			; Maximum FACES per Level
MaxRLFObjects		equ	250			; *Maximum FIXED OBJECTS per Level
MaxRLMObjects		equ	180			; *Maximum MOVABLE OBJECTS per Level
MaxRLObjectTypes	equ	256			; Maximum OBJECT Types

MaxWADSectors		equ	512			; Maximum SECTORS per WAD Level
MaxWADFaces		equ	3072			; Maximum FACES per WAD Level

rlSectorData		equ	$00703080
rlVertexData		equ	rlSectorData+(MaxRLSectors*rlsdSize)


MEMF_PUBLIC		equ	$00001
MEMF_CHIP		equ	$00002
MEMF_FAST		equ	$00004
MEMF_CLEAR		equ	$10000

 

Edited July 14, 2020 by Redneckerz

[fraggle]

3 hours ago, Revenant said:

The actual game assets (graphics, maps, etc) aren't included

Maybe someone can substitute in some of the Freedoom assets.

[intacowetrust]

2 hours ago, seed said:

I wonder how long will it take for source ports to show up now, I can't wait for that. Maybe, hm... @intacowetrust, may I interest you into a port :D ?

 

Hah! I'll have my hands full with PsyDoom for a while a least :P Awesome news though, happy to see the sources for this finally released!

[MxCraven]

2 hours ago, Dimon12321 said:

Hah, it was already forked by 3 people, none of whom has ever worked in Assembler, according to GitHub statistics. I'm interested in their possible efforts =)

Forking has long been a thing many people on Github see the same as staring something for some reason. It's like a superfave. Hopefully someone gets around to it though, that would be cool to see :D

[Dark Pulse]

8 minutes ago, MxCraven said:

Forking has long been a thing many people on Github see the same as staring something for some reason. It's like a superfave. Hopefully someone gets around to it though, that would be cool to see :D

Practical effect: Forking also gives them a copy of the repository, in case something mysteriously "disappears."

 

Granted that'd be really hard to do in this case - no game assets are included, Randy wrote the engine himself, and the platform it's for is most certainly dead from a commercial standpoint.

[taufan99]

I have waited for this time to come! Thanks for the mention, @Redneckerz!
 

5 hours ago, fraggle said:

Maybe someone can substitute in some of the Freedoom assets.

Or also make an assets extractor based on the original ROM of the port.

Edited July 14, 2020 by InDOOMnesia
Slight grammatical blurp.

[Dexiaz]

1 minute ago, InDOOMnesia said:

Or also make an assets extractor based on the original ROM of the port.

 

This is what exactly did the Doom 64 EX ;)

[Ecafr8708]

polishedshoe777 was not only the first fork (before the release, even) but also me! gonna need to update it now 

edit: actually I’ll just find out how to delete it

Edited July 14, 2020 by Ecafr8708

[Jon]

I'd be pretty astonished if Randal Linden actually owned the rights to the code in order to license it under the GPL-3.

[Dark Pulse]

11 minutes ago, Jon said:

I'd be pretty astonished if Randal Linden actually owned the rights to the code in order to license it under the GPL-3.

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.

[Gez]

I don't think "figuring out the license" was the issue, because that was the first commit, on February 26. So there was four and a half month before committing to the GPL and actually uploading the files.

[Job]

I'm sure he was being thorough in avoiding any potential liabilities or conflicts. That said, I assume someone will need to pull assets from another...um, resource, in order to restore the fileset, engine and all.

[Jayextee]

All I want now is a ROM where I can turn and strafe at the same time, thanks.

[lunarmeadow]

There's still alot more to be released, quite a few source files are inexplicably missing (the random number table comes immediately to mind), the sound driver itself, various bits of source code, and of course the data. Given that Rebecca Heineman could fully release the 3DO port's source code with data, Randy could probably do the same. Probably just cleanup work, plus a few minor legal hoops for the data itself.

[Dark Pulse]

40 minutes ago, Jayextee said:

All I want now is a ROM where I can turn and strafe at the same time, thanks.

That would be hard due to having no sprite rotations. It's the same reason you can't do that in 32X Doom.

 

Like, you COULD do it, but it'd be visually confusing as heck.

 

And you can't fit more ROM for more frames in since the SuperFX can only address 2 MB itself. There'd need to be some clever hackery done.

[Jayextee]

2 minutes ago, Dark Pulse said:

Like, you COULD do it, but it'd be visually confusing as heck.

Yes, this is okay. Gimme muh circle-strafing.

Honestly I don't think the lack of rotations is the reason, else the Saturn version of Hexen; which also lacks rotation sprite frames; wouldn't allow circle-strafing. Which it does. Can't speak of the PlayStation version, literally never played it.

[Doomkid]

The thought of not being able to release the source with assets “because someone might build some weird Frankenstein Doom to avoid paying the 3 bucks for a legal copy” is just so absurd. I know when it comes to legal stuff you have to dot your i’s and cross your t’s, but from a realistic perspective it’s hyper absurd.

 

2 hours ago, Jayextee said:

All I want now is a ROM where I can turn and strafe at the same time, thanks.

Finally, someone said it!

 

1 hour ago, Dark Pulse said:

That would be hard due to having no sprite rotations. It's the same reason you can't do that in 32X Doom.

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.

Edited July 15, 2020 by Doomkid

[sector666]

32 minutes ago, Dark Pulse said:

Like, you COULD do it, but it'd be visually confusing as heck.

 

It already looks strange turning when there's enemies on screen anyway. I can imagine that would be even more apparent with turn+strafe. But visual oddness isn't what keeps me from going back and enjoying the SNES version again these days. It's the no turn+strafe control scheme.

 

If there was a toggle for allowing turn+strafe then it could be added in without bothering people who don't like the lack of sprite rotations.

 

Hopefully it will become possible now to have more than just one custom level at a time too.

Edited July 14, 2020 by sector666

[Mr.Rocket]

Shweet.. Way over my head but ~ gotta check this out! :D

Edited July 15, 2020 by Mr.Rocket