Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Revenant

SNES Doom source released under GPLv3

Recommended Posts

4 hours ago, InDOOMnesia said:

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

 

 

Was only a matter of time.

Share this post


Link to post
5 hours 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.

 

I can finally post again :-)

 

Thanks to help from @xttl getting UAE operational, I've been able to upload binaries of the ACCESS development toolchain (ie. Phase 1)

Phase 2 will include source code for the tools, but I wanted to get the binaries out so people could start using them immediately.

 

Rand.

Share this post


Link to post

Wonder if @fabiensanglard will do a write-up on the code once it gets converted over to C or something...

 

Still wondering where this little nugget of uncompiled source is hiding. Clearly somewhere music related...

mov tempword,A            ; save ID code
mov PlayChan+X,A
mov PlayCurVelocity+

Also kinda curious if Jodi ever knew of that texture easter egg - hopefully she's doing well. Not trying to nose into devs' personal lives or anything, but I always find little things like that rather sweet and kind; a snapshot to a happier time. Hopefully it's not a reminder of pain decades later though...

Share this post


Link to post
2 minutes ago, Dark Pulse said:

Wonder if @fabiensanglard will do a write-up on the code once it gets converted over to C or something...

 

Still wondering where this little nugget of uncompiled source is hiding. Clearly somewhere music related...

 

Fabien interviewed me for his excellent book, the "GAME ENGINE BLACK BOOK: DOOM".  There's a writeup of the SNES version as well as an interview with me in Appendix I.

 

You can get the entire book for free, but I bought a copy myself and urge everyone else to do the same.

 

https://fabiensanglard.net/gebbdoom/index.html

 

The uncompiled source is from the Sculptured Software sound driver -- probably just a reused buffer during compilation or something.

Share this post


Link to post

I pre-ordered that book and enjoyed the hell out of it, yes. It was a fascinating read. That's why I mentioned him, because I'd love to see someone doing a technical breakdown of your code and just managing to make the virtually impossible, possible. :)

 

Really looking forward to if he does a third. Would love to see his thoughts on the Quake or Unreal Engine... the main problem with the latter being that the sources for the first two Unreal Engines aren't released yet. (They are leaked and floating around on the internet though - or at least, what's claimed to be them.)

 

Tim Sweeney's said that a release of UE1's source would "need to be cleaned up" to be released, but well, the community would be more than happy to do that - don't see why that'd be an issue. UE2, on the other hand, may never get a source release, as they integrated all sorts of middleware (SpeedTree, Havok, etc.) directly into the engine, and so that'd be way trickier to push out there.

 

I just wanna play UT99 on my Switch sometime, damn it. :(

Share this post


Link to post
1 hour ago, RandalLinden said:

Thanks to help from @xttl getting UAE operational, I've been able to upload binaries of the ACCESS development toolchain (ie. Phase 1)

 

Take 2:

 

I tried building the game code and got an error when assembling the very first file... so that's not good.

 

Digging further, I found a more recent archive of the ACCESS toolchain and rebuilt everything which appears to have fixed the error. :-)

 

I've now published Phase1A of the ACCESS GitHub which includes the latest (and working) version of the assembler, linker, debugger, etc.


On a related note, it appears that ripdoom also suffers from "archive rot" -- I'm working on it.

 

Sorry for the inconvenience!

 

Rand.

 

Share this post


Link to post

He’s written some good blog posts on quake 2’s renderer at least

Share this post


Link to post

e2m3.png.f01b4914fa9c4ef744d124f508f35b7a.png

 

It's not hard to draw all the lines from a SNES map correctly if you have the pointers to data right, and understand that the SNES line struct vertex values are for some reason (speed/space savings?) direct pointers into vertex data instead of vertex indices.

 

However, I can't figure out how the main pointers to the vertex data itself work. One "formula" I tried gives correct ROM offsets to vertex data for most but not all maps (E2M3 is one of the maps which works):

vtxrompos = (uint16_t)(vertices_ptrs[mapindex]+0x703BB6) + bsp_ptrs[mapindex] - 0x400000;

or

vtxrompos = ((vertices_ptrs[mapindex]+0x703BB6)&0x0000FFFF) + bsp_ptrs[mapindex] - 0x400000;

(0x703BB6 = _RLVertexes address from rlram7.a and 0x400000 always needs to be subtracted to get a disk instead of memory offset)

 

The definitions for all data pointers in the source code for any map data except BSP and sectors are just 16 bits instead of 32 bits, and most seem to be just straightforward 16-bit offsets to be added to the main BSP/sector pointer, but some such as the vertex data pointers seem to maybe rely on weird ROM banking and/or 16-bit integer overflowing magic stuff I don't understand at all.

 

Nevertheless, it isn't hard to search the ROM for eg. the first 32-64 bytes of any original map's vertex data and just build an array of vertex data offsets for all maps that way. Well except for E3M1 which seems impossible to find. There's no match in the ROM for any version of E3M1 I've tried.

 

Pastebin with all map data pointers from US/Canada ROM if someone wants to try to figure it. (maps which don't work with the "formula" above: E1M1, E1M8, E2M1, E2M8, E2M9, E3M1, E3M2, E3M8, E3M9)

 

All pointers from bsproot to faces (inclusive) are relative to bsp, but the vertex pointers are defined like this in the source:

dc.w    <(E1M1VERTEXES-_RLVertexes)     ; VERTEXES Array

instead of just:

dc.w    <E1M1LINES                      ; LINES Array

 

Edited by xttl

Share this post


Link to post

This may be a little out of leftfield here, but if any modding efforts require some lightweight maps for any reason (keep framerates high-ish, testing purposes, whatever) then I offer my 900 Deep in the Dead for this purpose. 100 linedefs per map shouldn't strain the Super NES much, even if I do use some midtextures here and there (small effort to edit these out though).

Share this post


Link to post
12 hours ago, Jayextee said:

This may be a little out of leftfield here, but if any modding efforts require some lightweight maps for any reason (keep framerates high-ish, testing purposes, whatever) then I offer my 900 Deep in the Dead for this purpose. 100 linedefs per map shouldn't strain the Super NES much, even if I do use some midtextures here and there (small effort to edit these out though). 

 

Cool, thanks.

 

I was about to post at some point that I'm going to give up on replacing maps in the original ROM because it seems more complex than I expected, there's just too much stuff going on I don't completely understand with truncated data pointers and I guess memory banking(?). That, and the map data seems spread around the ROM (at least the maps definitely aren't stored in order, BSP data for all of E1M2-E1M8 comes before E1M1 in the ROM, for example). I think inserting a map larger than the original in a slot may destroy some more critical data than just the next map in some cases, even if it's not the last map slot. I don't want to spend too much time and effort on this, because honestly I don't even like the SNES version and hacking it that much (the DOS/Watcom/LE stuff is just more enjoyable).

 

(I think Randy is still pretty cool for engaging with fans personally like this, and also for programming Bleem and Bleemcast back in the day, even though I only got into PSX emulation a few years later with ePSXe, and that having the circle strafe hack running on a SuperFX cart would be nice ;)

 

Your maps, being very small, might be easier to get working.

 

@Quasar, how much info do you need on the SNES maps for the wiki? Generating top-down maps is no problem at this point (except for E3M1 until I find the vertex data offset). Maps hopefully loadable on PC (after rebuilding nodes) later today or tomorrow (but no promises about all triggers working since SNES has those weird separate DOORS, STAIRS and LIFTS files for each map)

Edited by xttl

Share this post


Link to post
27 minutes ago, xttl said:

how much info do you need on the SNES maps for the wiki?

Ideally, maps should be generated with a color settings as close as possible to the rest of them (see info here) and map articles generally get little tables with map stats (number of vertices, lines, sides, sectors, and things) and a detailed breakdown by skill level of the gameplay-relevant thing types (monsters, items, etc.).

Share this post


Link to post
40 minutes ago, xttl said:

I was about to post at some point that I'm going to give up on replacing maps in the original ROM because it seems more complex than I expected, there's just too much stuff going on I don't completely understand with truncated data pointers and I guess memory banking(?). That, and the map data seems spread around the ROM (at least the maps definitely aren't stored in order, BSP data for all of E1M2-E1M8 comes before E1M1 in the ROM, for example). I think inserting a map larger than the original in a slot destroys some more critical data than just the next map in some cases. I don't want to spend too much time and effort on this, because honestly I don't even like the SNES version that much.

Memory banking would definitely be needed, because the SNES operated on a pretty complex set of memory bank schemes. This might help. (The whole series might help, for that matter.)

 

 

Share this post


Link to post
16 hours ago, xttl said:

However, I can't figure out how the main pointers to the vertex data itself work. One "formula" I tried gives correct ROM offsets to vertex data for most but not all maps (E2M3 is one of the maps which works):


vtxrompos = (uint16_t)(vertices_ptrs[mapindex]+0x703BB6) + bsp_ptrs[mapindex] - 0x400000;

or


vtxrompos = ((vertices_ptrs[mapindex]+0x703BB6)&0x0000FFFF) + bsp_ptrs[mapindex] - 0x400000;

(0x703BB6 = _RLVertexes address from rlram7.a and 0x400000 always needs to be subtracted to get a disk instead of memory offset)

 

I believe all (or most, possibly excluding bsproot) of the 16-bit pointers are relative to the start of the 64kb bank that either the BSP or sector structs are in, e.g.:

E1M1 BSP: 589ED4

E1M1 lines: 58C270

E1M1 vertices: 58BB38 (after adding the _RLVertexes offset)

 

From what I can tell, the first four bytes of the linedef structure are 16-bit absolute pointers to the line's first and second vertices in RAM, starting with the address of _RLVertexes, which is where they're stored in RAM at map load time. For example, at 58C270 there are pointers to 703BB6 and 703BBA, which are vertices #0 and 1 (assuming a vertex is 4 bytes).

 

Likewise for E3M1, for example:

E3M1 BSP: 52CF59

E3M1 lines: 52E0C5

E3M1 vertices: 52DD1D

Edited by Revenant

Share this post


Link to post
12 hours ago, Revenant said:

I believe all (or most, possibly excluding bsproot) of the 16-bit pointers are relative to the start of the 64kb bank that either the BSP or sector structs are in

 

Earlier, I figured out I could get the sectors-relative values by taking the high bits from the sectors offset (&0xFFFF0000) and then adding eg. objects/doors/floors to it. For most of the bsp-relative values either that or simple addition seemed to work, and for vertices the weird formula (if you can call it that) worked for most maps.

 

12 hours ago, Revenant said:

Likewise for E3M1, for example:

E3M1 BSP: 52CF59

E3M1 lines: 52E0C5

E3M1 vertices: 52DD1D

 

Yes, that seems to be the correct offset for E3M1's vertices:

 

e3m1.png.9d4f2424971cb1d0677a710e8064fe11.png

 

I don't think there's any guarantee that the first linedef's v1 and v2 are actually always vertex #0 and #1 though? (ie. the first two in ROM/RAM) There's no requirement, at least on PC, for the first linedef in a map to use vertices #0 and #1 as its endpoints. But yes, the vertex values are indeed pointers instead of indices like on PC.

 

Currently I'm trying to map texture numbers from faces (equivalent of PC sidedefs) to texture names. By changing the second byte of E1M1 faces data (at 58FACE+1, or 18FACE+1 on disk, originally 0x10 = DOOR3), it's possible to change the texture of the door behind the player's spawn point. The values don't seem to unfortunately match with the WallList or TextureList files in the source dump, so I'm not sure if there's a quick way to get them all at once...

 

Some values (eg. 0x01, 0x02) also cause garbage to be drawn, and the game may crash. So it seems there are either gaps or not all textures work in all maps, or the values are even map dependent? (in the second/third case: why? don't they all come from ROM anyway? all of a level's textures must fit into a single bank? still, why not sequential numbering?)

 

I started testing them sequentially and BIGDOOR7 (0x06) works, that's a hell texture which definitely doesn't belong into E1M1.

 

It also seems only even texture index values work, the odd values display garbage (though 0x02 doesn't work either):

 

0x04 (4)  = BIGDOOR2
0x06 (6)  = BIGDOOR7
0x08 (8)  = BROWN1
0x0A (10) = COMP2
0x0C (12) = COMPTILE
0x0E (14) = COMPUTE1
0x10 (16) = DOOR3
0x12 (18) = DOORBLU

 

Also, looking at that now, I think the ordering does match WallList after all, just SKY1 & SKY2 need to be removed from the beginning.

 

Before anyone says anything about it: I don't think it has anything to do with texture size at least: STARTAN1 (0x42), COMPUTE1 (0x0E) and BROWN1 (0x08) work even though they're larger textures than DOOR3 and the surface is small.

Edited by xttl

Share this post


Link to post
2 minutes ago, xttl said:

 

I don't think there's any guarantee that the first linedef's v1 and v2 are actually always vertex #0 and #1 though? (ie. the first two in ROM/RAM) There's no requirement, at least on PC, for the first linedef in a map to use vertices #0 and #1 as its endpoints. But yes, the vertex values are indeed pointers instead of indices like on PC.

Right, I meant specifically in E1M1's case as an example.

 

26 minutes ago, xttl said:

Currently I'm trying to map texture numbers from faces (equivalent of PC sidedefs) to texture names. By changing the second byte of E1M1 faces data (at 58FACE+1, or 18FACE+1 on disk, originally 0x10 = DOOR3), it's possible to change the texture of the door behind the player's spawn point. The values don't seem to unfortunately match with the WallList or TextureList files in the source dump, so I'm not sure if there's a quick way to get them all at once...

Dividing the value by 2 seems to get the same texture order as in WallList:

04 = BIGDOOR2

06 = BIGDOOR7

08 = BROWN1

etc.

 

SKY1 and SKY2 (i.e. 00 and 02) don't show up correctly, but I'm guessing that's just due to sky textures expecting to be drawn differently.

Share this post


Link to post

I got SNES E1M1 to load in PC Doom finally (nodes/segs/ssectors/blockmap/reject not converted, I rebuilt everything with ZenNode). I wonder what to do about the lightlevels? SNES has two light levels for each sector, far and near. I just used near for every sector as is and it's clearly too dark. Perhaps the scale is different too?

 

For floors/ceilings, I already generated a WAD with a solid colored flat for each color of the palette and I'm going to just pick the closest one to the SNES floor/ceiling color of those. Right the converter just puts "FLOOR0_3" everywhere.

 

d.png.113015bffa1a0b4c885128c04d46f60f.png

 

oh yeah, also no objects->things conversion yet

Edited by xttl

Share this post


Link to post

https://revenant1.net/crap/snesdoom/

 

Wiki-style outlines of all of the SNES Doom maps, along with an adapted version of drawmaps.py for generating them (based on the US ROM).

 

Pending some more information about the things/objects structure, I can later on spit out some tables of thing statistics with wiki markup, etc.

Share this post


Link to post
10 hours ago, Revenant said:

Pending some more information about the things/objects structure, I can later on spit out some tables of thing statistics with wiki markup, etc. 

 

rle.i seems to have the definitions for all of the structures used. (too bad I didn't find that out before spending some time on figuring out the nodes, sectors and lines structs from the asm code)

Share this post


Link to post
1 hour ago, xttl said:

I got SNES E1M1 to load in PC Doom finally (nodes/segs/ssectors/blockmap/reject not converted, I rebuilt everything with ZenNode). I wonder what to do about the lightlevels? SNES has two light levels for each sector, far and near. I just used near for every sector as is and it's clearly too dark. Perhaps the scale is different too?

 

For floors/ceilings, I already generated a WAD with a solid colored flat for each color of the palette and I'm going to just pick the closest one to the SNES floor/ceiling color of those. Right the converter just puts "FLOOR0_3" everywhere.

 

Maybe you could try to investigate existing SNES Doom hacks? Or hacking tools? I mean, maybe it will help you to understand more?

 

 

 

Share this post


Link to post

Seeing that video reminded me - anything in the source code explain the extremely specific glancing pattern for Doomguy's HUD face? It's always center, left, center, right, center, left, center, left, center, right, center, left, center, right, center, right, repeat.

 

Coincidentally (or perhaps not), that's 16 states - precisely the amount you could store in half a byte, assuming you went from 0x0-0xF. But does it take that much power that a random number can't simply be rolled, to be more like the PC version?

 

Also, very notably, the pattern resets back to the beginning when the face changes damage levels. You get a clear look at that in the transition at about 1:40 in the video above - Doomguy's just finished looking right, but he immediately returns to center again and begins looking left, then re-centers, then looks right (as per the usual pattern), whereas if the pattern were to continue regardless of face state, it should have gone to center, left, center, left.

Share this post


Link to post
12 hours ago, xttl said:

rle.i seems to have the definitions for all of the structures used

 

...which may not always be so useful. I had no idea why my object converter wasn't working right, everything was correct according to the struct def there. Well guess what? Turns out the objects have variable size (like faces) and that only became clear reading and trying to understand the asm code. Not all object types have angles stored because somebody wanted to save space by not storing angles for decorations and pickups.

 

Actually, angles aren't stored for anything except player spawn points and teleport destinations (because enemies always face the player anyway), so I don't really know what to do about them when converting to PC format. Probably not possible to make them work as intended without resorting to GZDoom/Eternity features? :( (and I don't know if it's possible even then, but probably yes). That, or a custom patched vanilla engine.

 

Otherwise, objects->things conversion is working perfectly now, I think.

Edited by xttl

Share this post


Link to post

Hey, seems like I got floor/ceiling texture (or color) conversion right the first time, except the sky isn't there yet. Nice, something worked without any effort at all.

 

d2.png.e95c9f44d95e0417cbc33a2e662b6b08.png

 

I wonder what would be the best program/algorithm nowadays to find nearest colors from another palette?

 

This is the SNES palette:

 

snespal.png.ef6d75fc9cfdc4c1786a534fc008390b.png

 

This old creaky graphics program I'm using to find nearest colors in the PC Doom palette for them turns for example many of the greens near the middle to the same shade, I'm not sure if that's really necessary or optimal?

 

snes2doompal.png.0a4d322038c05ee9a95997b7d7e4040c.png

 

(also looks like I forgot gamma correction on when taking that screenshot, oh well)

 

...and seems sky is marked simply by setting texture/color to 255

 

d3.png.c8c18845f547565112e9026440324cab.png

 

Speaking of sky, there's this spot in E2M3/E2M2 where I still don't know wtf is going on:

 

d4.png.d688ee390e63c458f6e60d9bb20ed267.png

 

Looking at the converted map in an editor, the only place with PIPE4 (the correct texture from SNES) on that line 1) on the wrong side and also 2) bottom instead of top texture. All other slots get set to SKY2 by the converter (because I guess original texture ID on face is 0x02 but I haven't checked it yet, however if it is, why does the SNES engine draw PIPE4 there?).

 

Also regarding the enemy angles problem I just recalled that in vanilla, enemies with the ambush flag set will wake up no matter which angle the player approaches from if they've already been alerted by a sound. However, how to automate sound propagating everywhere on converted maps? It's not a good idea to just start merging sectors blindly.

Edited by xttl

Share this post


Link to post

I read in the black book that the engine support textures for the floor and roof. 

 

Its't imposible add it?. I read was droop back her day due to space in rom. 

 

But today, apart from have the original cartridge as collector, The only way of play a modified doom version was use a sd2snes/pro. That's mean you can't use devices as  xband or something. So it's imposible add the textures simply deleting the things we can't use today and reuse the space?. 

 

Because the other approach was made a fx2.1 that support more rom space. 

Share this post


Link to post

Well, you can try to rebuild it from the sources with floors/ceilings enabled if you want it. I'm not really interested in this, I don't even own a SD2SNES/FXPAK Pro. Besides the game is already too slow without overclocking the GSU, floor/ceiling textures can only make it worse.

 

I don't own any hacked Winter Gold kusogecartridges either. :-) And if I were ever to build my own modded SuperFX cart I'm not going to even attempt anything more complex than just swapping the ROM chip with another or a socket. That, and perhaps an oscillator swap to make the game not too damn slow.

 

I am not going to do anything with regards to adding floor/ceiling textures to the game. Perhaps someone else will do it. If/when it's possible to rebuild the ROM from scratch using Randy's tools it might not even be hard.

Edited by xttl

Share this post


Link to post

I think at least cold be a good experiment as sd2snes support overclooking the fx. View how the game work with full textures. 

 

I dobut today many people destroy a winter gold cartridge to put a  doom rom :D. 

 

But for the normal people. Sd2snes is the only(and best) way of play modified doom in real snes. I recommend you buy one. Even if you don't want enable the textures. I play these amateur  doom level I found here in doom world  in my snes and was enjoyed. 

Share this post


Link to post

There's a mystery I've always been curious about with the SNES port, and that's the extra Doomguy rotation frames that can be found in the ROM. I'm 99% sure they are just leftovers that were never intended to be used, but it seems strange when cart space was an issue - or was it? Just a question that doesn't directly pertain to the awesome work being done here. Keep it up.

Share this post


Link to post

I'm not logging don't mean I not read the forum, just nothing to say. :D.

 

 

 

 

Share this post


Link to post
4 minutes ago, Doomkid said:

There's a mystery I've always been curious about with the SNES port, and that's the extra Doomguy rotation frames that can be found in the ROM. I'm 99% sure they are just leftovers that were never intended to be used, but it seems strange when cart space was an issue - or was it? Just a question that doesn't directly pertain to the awesome work being done here. Keep it up.

I have a feeling they were intended to be used, but with how little space is left in the ROM (16 BYTES, people!), there was literally no room to even add the code to display them, not without removing something else.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×