Doom SNES Hacking Guide/Documentation

[lunaark]

My original post: http://www.romhacking.net/forum/index.php/topic,20843.0.html (I am bringing it here to doomworld)

Ok, I have nothing better to do right now so I am going to make 
a thread (this one) about how to hack Doom for the SNES and how it works (as far as I can tell)

This is purely off memory, due to the fact I have not worked on Doom SNES hacking in a little while, but I thankfully have good and reliable memory.

First of all, the SPC format used in Doom is N-SPC (The format Nintendo used for music on the SPC700 chip, this is as far as I can tell the most documented and easiest to hack of SPC formats)

If you are wondering what I mean by SPC formats, is that developers would sometimes use their own method of playing music on the SPC700, such as playing MIDI on a SNES, A notable example is Capcom, which used an SPC format called MMC5, if I remember correctly.

Why is it N-SPC, you may ask.

Well, I am no expert at the SNES but from analysis, the SPC engine seems to be similar to the one found in Super Mario World (N-SPC) because in an N-SPC format SPC file, there is a block of SPC700 ASM code starting at 0x700 in the SPC RAM. The first 3 hex bytes are 20 CD FF, and when playing E1M1 in BSNES-Plus with the debugger open, viewing the SPC700 RAM, I decided to press the next code button (It finds blocks of ASM, which is impressive that it can sort it out) and I instantly noticed that one of the blocks of code it brought me to was the block at 0x700, starting with 20 CD FF. Because it is (what I can tell to be) the SPC engine, it makes sense that it would be loaded into the SPC700 RAM all the time. Second, it seems to have the same structure if not very similar structure as the N-SPC format. Third, it is licensed by Nintendo so maybe they got access to using the N-SPC format.  Last of all, the music works on all SPC players, even if they only have N-SPC support (I am almost sure, at least.) 

Then comes the levels, which use a colour index for the floor and ceiling, rather than texture mapping, and the level data is similar to the original DOS data, but simplified, and made compatible with the engine used to make Doom SNES, but also to work on a SNES in the first place. The colour index for floor ceiling colours are as fallows (BTW, the sky texture is colour $FF, and thanks mopoz for the colour index and level loading asm code along with structure he posted on one of my other threads)

256 colors for the floor and ceiling.

BTW, color $FF -> F_Sky

Now here is the level loading ASM code (as far as I can tell) and some level data structures

thing #0 - #5 (1 - 4 spawn, 5 - teleport) = 8 byte (8 bit - settings; 8 bit - index things; 16 bit - X; 16 bit - Y; 16 bit - angle)  
         {Player}
things_name[$00]:='Player 1 start';          
things_name[$01]:='Player 2 start';          
things_name[$02]:='Player 3 start';          
things_name[$03]:='Player 4 start';         
things_name[$04]:='Player Deathmatch start'; 
        {Teleport}
things_name[$05]:='Teleport Destination';

thing #6-#$3F - 6 byte (8 bit - settings; 8 bit - index things; 16 bit - X; 16 bit - Y)  

============================================
Sector 10 byte settings
0 = sector_special; (sector_special shr 2)
1 = bright_room
2 = sector_bright_flash;
3-4 = sector_floor_height;
5-6 = sector_ceil_height
7 = sector_floor_color
8 = sector_ceil_color
9 = sector_tag
============================================
Lindefs 16 bytes settings
0-1 = linedefs_vertx_strt
2-3 = linedefs_vertx_end
4-5 = linedefs_type
6-7 = linedefs_angle
8-9 = linedefs_texture_offset
10 = linedefs_action
11 = linedefs_tag
========================================
SideDefs 12 byte
0-1 = sidedefs_vertx_strt
2-3 = sidedefs_vertx_end
4 = sidedefs_flags
5 = sidedefs_horizontal_scroll
6 = sidedefs_vertical_scroll
7-8 = sidedefs_texture_offset
9-10 = sidedefs_linedf_number
11 = sidedefs_sector_number

$5F/FAF2 22 2E 31 5F JSL $5F312E[$5F:312E]   load map


$5F/312E AD D1 06    LDA $06D1  [$3F:06D1]   map number
$5F/3131 48          PHA                     A:0000 X:2806 Y:0001 P:envmxdIZc
$5F/3132 0A          ASL A                   A:0000 X:2806 Y:0001 P:envmxdIZc
$5F/3133 AA          TAX                     A:0000 X:2806 Y:0001 P:envmxdIZc
$5F/3134 4B          PHK                     A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/3135 AB          PLB                     A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/3136 BD 82 37    LDA $3782,x[$5F:3782]   A:0000 X:0000 Y:0001 P:envmxdIzc
$5F/3139 8F BF 06 00 STA $0006BF[$00:06BF]   A:0402 X:0000 Y:0001 P:envmxdIzc
$5F/313D BD 14 33    LDA $3314,x[$5F:3314]   A:0402 X:0000 Y:0001 P:envmxdIzc
$5F/3140 8F 80 00 70 STA $700080[$70:0080]   A:18B8 X:0000 Y:0001 P:envmxdIzc
$5F/3144 BD 4A 33    LDA $334A,x[$5F:334A]   A:18B8 X:0000 Y:0001 P:envmxdIzc
$5F/3147 8F 82 00 70 STA $700082[$70:0082]   A:37A8 X:0000 Y:0001 P:envmxdIzc
$5F/314B BD 80 33    LDA $3380,x[$5F:3380]   A:37A8 X:0000 Y:0001 P:envmxdIzc
$5F/314E 8F 84 00 70 STA $700084[$70:0084]   A:7F82 vertex add
$5F/3152 BD B6 33    LDA $33B6,x[$5F:33B6]   A:7F82 X:0000 Y:0001 P:envmxdIzc
$5F/3155 8F 8E 00 70 STA $70008E[$70:008E]   A:01CE  vertex value
$5F/3159 BD EC 33    LDA $33EC,x[$5F:33EC]   A:01CE X:0000 Y:0001 P:envmxdIzc
$5F/315C 8F 86 00 70 STA $700086[$70:0086]   A:C270 linedefs
$5F/3160 BD 22 34    LDA $3422,x[$5F:3422]   A:C270 
$5F/3163 8F 90 00 70 STA $700090[$70:0090]   A:01D5  lindefs value
$5F/3167 BD 58 34    LDA $3458,x[$5F:3458]   A:01D5 X:0000 Y:0001 P:envmxdIzc
$5F/316A 8F 88 00 70 STA $700088[$70:0088]   A:D861 X:0000 Y:0001 P:eNvmxdIzc
$5F/316E BD 8E 34    LDA $348E,x[$5F:348E]   A:D861 X:0000 Y:0001 P:eNvmxdIzc
$5F/3171 8F 8A 00 70 STA $70008A[$70:008A]   A:D86B siddefs D86B+1;
$5F/3175 BD FA 34    LDA $34FA,x[$5F:34FA]   A:D86B X:0000 Y:0001 P:eNvmxdIzc
$5F/3178 8F 8C 00 70 STA $70008C[$70:008C]   A:F746 X:0000 Y:0001 P:eNvmxdIzc
$5F/317C BD 30 35    LDA $3530,x[$5F:3530]   A:F746 X:0000 Y:0001 P:eNvmxdIzc
$5F/317F 8F 94 00 70 STA $700094[$70:0094]   A:FACE Texture
$5F/3183 BD C4 34    LDA $34C4,x[$5F:34C4]   A:FACE X:0000 Y:0001 P:eNvmxdIzc
$5F/3186 8F 92 00 70 STA $700092[$70:0092]   A:02CE  texture value
$5F/318A BD D2 35    LDA $35D2,x[$5F:35D2]   A:02CE X:0000 Y:0001 P:envmxdIzc
$5F/318D 8F 9A 00 70 STA $70009A[$70:009A]   A:0055 X:0000 Y:0001 P:envmxdIzc
$5F/3191 BD 08 36    LDA $3608,x[$5F:3608]   A:0055 thing numb (thing)
$5F/3194 8F 9C 00 70 STA $70009C[$70:009C]   A:EBC2 X:0000 Y:0001 P:eNvmxdIzc
$5F/3198 BD 3E 36    LDA $363E,x[$5F:363E]   A:EBC2 things
$5F/319B 85 00         STA $00    [$00:0000]   A:EEEE 
$5F/319D 18              CLC                     A:EEEE X:0000 Y:0001 P:eNvmxdIzc
$5F/319E 69 06 00     ADC #$0006              A:EEEE X:0000 Y:0001 P:eNvmxdIzc
$5F/31A1 8F 9E 00 70 STA $70009E[$70:009E]   A:EEF4 X:0000 Y:0001 P:eNvmxdIzc
$5F/31A5 BD 74 36    LDA $3674,x[$5F:3674]   A:EEF4 X:0000 Y:0001 P:eNvmxdIzc
$5F/31A8 8F A0 00 70 STA $7000A0[$70:00A0]   A:FE42 
$5F/31AC BD AA 36    LDA $36AA,x[$5F:36AA]   A:FE42 X:0000 Y:0001 P:eNvmxdIzc
$5F/31AF 8F A4 00 70 STA $7000A4[$70:00A4]   A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31B3 BD E0 36    LDA $36E0,x[$5F:36E0]   A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31B6 8F A6 00 70 STA $7000A6[$70:00A6]   A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31BA BD 16 37    LDA $3716,x[$5F:3716]   A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31BD 8F A2 00 70 STA $7000A2[$70:00A2]   A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31C1 BD 4C 37    LDA $374C,x[$5F:374C]   A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31C4 8F A8 00 70 STA $7000A8[$70:00A8]   A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31C8 8A          TXA                     A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31C9 0A          ASL A                   A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CA AA          TAX                     A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CB BD A8 32    LDA $32A8,x[$5F:32A8]   A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CE 8F 7C 00 70 STA $70007C[$70:007C]   A:9ED4 nodes
$5F/31D2 BD AA 32    LDA $32AA,x[$5F:32AA]   A:9ED4 X:0000 Y:0001 P:eNvmxdIzc
$5F/31D5 8F 7E 00 70 STA $70007E[$70:007E]   A:0058 X:0000 Y:0001 P:envmxdIzc
$5F/31D9 BD 66 35    LDA $3566,x[$5F:3566]   A:0058 Bank 2
$5F/31DC 8F 96 00 70 STA $700096[$70:0096]   A:E86E sectors (end $524c - stop bytes)
$5F/31E0 BD 68 35    LDA $3568,x[$5F:3568]   A:E86E X:0000 Y:0001 P:eNvmxdIzc
$5F/31E3 8F 98 00 70 STA $700098[$70:0098]   A:005B Bank for adress
$5F/31E7 85 02       STA $02    [$00:0002]   A:005B X:0000 Y:0001 P:envmxdIzc

Credits to mopoz for the colour index and map loading ASM code and map data structure.

The sounds are normal, typical BRR samples that can be easily edited with BRR editors that work with ROMs, such as SNESSor, which I use to make SNES BRR hacks (The windows version of SNESSOR is not good, use the DOS version under DOSBox or if you want to go hardcore, even a real DOS PC to use SNESSOR, as a DOS version that is better than the windows version exists,
Some sounds are loaded into SPC, and can not be edited according to the Doomworld user ShaneAmp. 

The graphics are what I know the most about, and are pretty easy once you learn where they are and what settings to use in Tile Molester (best tool for graphics hacking I have seen).

The wall textures (and sky textures) start at hex ofset 0x8000 in the ROM. In Tile Molester, I remember that textures used either 8bpp linear or 8bpp planar (8bpp is 256 colour bitplanes) (I think it was planar, if it is even called planar, but I forget and will check all of this soon.) The sprites were pretty close to the end of the ROM and were 4bpp (16 colour bitplane) linear, if I remember correctly but I am almost positive it was) and were split up, I guess they split it up so that if one part of a frame can be used for another they just use 1 part of a frame, rather than have 2 identical parts of a frame, which just wastes ROM space. The font was at the far end of the ROM almost, and was certainly 8bpp linear but you will have to hold minus quite a bit to get the rows to line up and form a clear, undivided font.

The text is the easiest part, you literally find the text you want to replace in a hex editor, and replace the text but remember that any text you add MUST be in uppercase, or the letters/numbers will be a glitchy colourful tile ingame. Your text also has a limit of the original text size, so replace your text wisely. If your text is shorter than the original text, replace the characters left over from the original text with spaces, which I have not tested but should work, considering spaces between words work (no special space code by the way, literally just hit space when making spaces.)

Edit 1:

I have dissected the SPC engine from the E1M1 SPC RAM. It is as follows

20cdffbd8fa0fa8fa0fb8f20fc8f87f1
3f83108f00268f1f278f01f662083fba
0b3f600b3307f78d103f4a07830712e4
fef00ee4cbf0076084ccc4cc90033fd4
16e4fdf0d93f2d082fd4e4ffd003e801
6fcb3d8f003ccd14e4f6f0033fba0beb
3df5fc07c4f2f52802faf33e643ef00f
b0098b3edcd0f5ab3c2f04ab3e2ff5fa
3ef31d10d3e43c6fe2082f02f2087208
8d803fee0c3fd1108f6cf28f3ff3e308
0ccd00f580feafc86190f84fc05f

The e2082f02f2 part is recognized by BSnes as data. Here is a screenshot of the SPC engine:

Sorry for the crude handwriting, I did it really fast and also I am not used to using a mouse to draw. I blacked out any extra hex code that snipping tool showed that is not a part of the engine.

Edit 2: The sound driver starts at 0xED611 in the ROM.

[Job]

This is awesome. I felt it deserved a reply, but what can we do with all this information?

[Impboy4]

Lol, and I posted a fake screenshot of a would-be lost E1M6: Central Processing if it were ported to SNES Doom in the picture thread.

Cool that you're still looking into this, the fake picture may come to a reality soon. ;)

[Revenant]

TheLoneSurvivor said:

Third, it is licensed by Nintendo so maybe they got access to using the N-SPC format. Last of all, the music works on all SPC players, even if they only have N-SPC support (I am almost sure, at least.)

Nintendo probably provided their SPC driver as part of some official development kit, as there are a lot of third-party games that use it as well. This page (based on notes by loveemu) doesn't list Doom, but I'd be surprised if it was missing a lot of other games too.

(There's a tool called SIDId which is very good at identifying specific sound driver versions found in Commodore 64 music rips, and I've been interested in making a similar utility for console ROMs and music, but haven't really had the time to dedicate to it.)

Also, of course it works on all SPC players; SPC files are savestates of the sound chip and DSP, and SPC players are just emulators for those two things.

I'd eventually like to add some better Super FX debugging stuff to bsnes-plus. The disassembler I originally added is pretty lousy and doesn't help much for being able to modify existing routines the same way the other ones are, but at least you can monitor memory reads/writes once you know what to look for, and trace your way to a decent understanding of how the renderer works.

[lunaark]

Revenant said:

Nintendo probably provided their SPC driver as part of some official development kit, as there are a lot of third-party games that use it as well. This page (based on notes by loveemu) doesn't list Doom, but I'd be surprised if it was missing a lot of other games too.

(There's a tool called SIDId which is very good at identifying specific sound driver versions found in Commodore 64 music rips, and I've been interested in making a similar utility for console ROMs and music, but haven't really had the time to dedicate to it.)

Also, of course it works on all SPC players; SPC files are savestates of the sound chip and DSP, and SPC players are just emulators for those two things.

I'd eventually like to add some better Super FX debugging stuff to bsnes-plus. The disassembler I originally added is pretty lousy and doesn't help much for being able to modify existing routines the same way the other ones are, but at least you can monitor memory reads/writes once you know what to look for, and trace your way to a decent understanding of how the renderer works.

Just because they did not list it does not mean that Doom does not use N-SPC, as they may have not looked into Doom at all, as Doom ROM hacking has never really been attempted.

[Jaxxoon R]

You realize he wasn't actually disagreeing with you, right?

[Quasar]

Would it be possible to get a listing of offsets to all of the levels' data lumps?

[Maes]

Job said:

This is awesome. I felt it deserved a reply, but what can we do with all this information?

Not getting a life? ;-)

[ShaneAmp]

If the dos version of snessor is considered better, maybe give that a shot. I seem to recall having 3 sounds I could only get from ripped spc files, one of them was the shotgun. Maybe another version of the Rom could work also, I dont think I tried a different region..

[lunaark]

ShaneAmp said:

If the dos version of snessor is considered better, maybe give that a shot. I seem to recall having 3 sounds I could only get from ripped spc files, one of them was the shotgun. Maybe another version of the Rom could work also, I dont think I tried a different region..

What SPC files did you rip them from? Is there hidden SPC data in the ROM?

[Face23785]

Why would you start with 0-9 when labeling the columns and rows of the palette? Since there's more than 10 but less than 26 wouldn't it be more natural to just use all letters? Forgive me if that's standard procedure, I don't know anything about this stuff, it just seemed strange to me and I'm curious.

[Linguica]

Face23785 said:

Why would you start with 0-9 when labeling the columns and rows of the palette? Since there's more than 10 but less than 26 wouldn't it be more natural to just use all letters? Forgive me if that's standard procedure, I don't know anything about this stuff, it just seemed strange to me and I'm curious.

https://en.wikipedia.org/wiki/Hexadecimal

[ShaneAmp]

TheLoneSurvivor said:

What SPC files did you rip them from? Is there hidden SPC data in the ROM?

It was at least 7 years ago now, I can't remember. It was from the spc soundtrack for my snes mod. I believe it came from zophars domain back in the day. I might beable to check myself. If you have everythibg handy, just try loading up some files. I seemed to have the same issue ripping instruments for a sound font, in an attemp to replace the spc soundtrack. Someone was able to do it, I havnt updated the mod with it yet..

[Revenant]

Revenant said:

(There's a tool called SIDId which is very good at identifying specific sound driver versions found in Commodore 64 music rips, and I've been interested in making a similar utility for console ROMs and music, but haven't really had the time to dedicate to it.)

I eventually started doing this.

I had forgotten when writing this post that Sculptured Software (who developed the SNES port of Doom) had their own SNES music driver(s), which Doom does use, not N-SPC. (Searching for "SNDDRVR" followed by 0x01 and 0x03 is one way to find it).

ROMs in my collection that I believe to all use the same driver: http://pastie.org/private/yncvaf8pzaxsiyan77hxfw

[lunaark]

Revenant said:

I eventually started doing this.

I had forgotten when writing this post that Sculptured Software (who developed the SNES port of Doom) had their own SNES music driver(s), which Doom does use, not N-SPC. (Searching for "SNDDRVR" followed by 0x01 and 0x03 is one way to find it).

ROMs in my collection that I believe to all use the same driver: http://pastie.org/private/yncvaf8pzaxsiyan77hxfw

OH. MY. GOD. THANKS

Any info on how it works?

[lazygecko]

There are several programs you can use to browse and extract sounds from .spc files. SPCTool supports both exporting and importing in .wav as well as .brr

SNES GSS might also be relevant, even though it is a tracker.

[Mattfrie1]

Revenant said:

I eventually started doing this.

I had forgotten when writing this post that Sculptured Software (who developed the SNES port of Doom) had their own SNES music driver(s), which Doom does use, not N-SPC. (Searching for "SNDDRVR" followed by 0x01 and 0x03 is one way to find it).

ROMs in my collection that I believe to all use the same driver: http://pastie.org/private/yncvaf8pzaxsiyan77hxfw

I can tell Doom and the SNES Mortal Kombat games feature the same sound driver. These games appear to feature a sort of "bug" in which certain sound effects seem to disable one of the sound channels used for music.

Examples:
-E3M2's track loses it's lead guitar after I use a weapon, and doesn't come back till the song loops back to the beginning.
-E1M1's track (At Doom's Gate) loses one of the channels used for the lead guitar after I fire a weapon, and doesn't return till the track loops over
-In MK3/UMK3, the track used for the windy street level has a vocal sample which drops out whenever a hit is landed.

At first I thought it was an issue with my SNES, but then I realized it only happened with these few games, it seems like Sculptured Software's sound driver is the issue. Would it be possible to identify what causes this bug?

[lunaark]

Mattfrie1 said:

I can tell Doom and the SNES Mortal Kombat games feature the same sound driver. These games appear to feature a sort of "bug" in which certain sound effects seem to disable one of the sound channels used for music.

Examples:
-E3M2's track loses it's lead guitar after I use a weapon, and doesn't come back till the song loops back to the beginning.
-E1M1's track (At Doom's Gate) loses one of the channels used for the lead guitar after I fire a weapon, and doesn't return till the track loops over
-In MK3/UMK3, the track used for the windy street level has a vocal sample which drops out whenever a hit is landed.

At first I thought it was an issue with my SNES, but then I realized it only happened with these few games, it seems like Sculptured Software's sound driver is the issue. Would it be possible to identify what causes this bug?

Well, the SPC700 handles both music and sound, and if a sound is played, one of the SPC700 channels plays that sound. My theory is that they did not code the game to detect unused channels, and to start at channel 1 when a sound is played (I am unsure if Doom SNES can play more than 1 sound at a time.)

Also, they do because according to TCRF, MK3 uses SNDDRVR.

[lunaark]

I have been going nuts trying to figure out how to expand a Super FX ROM beyond 2MB (max Super FX ROM size) using some crazy bank switching, and in my google search I learned something.

You can expand a Super FX ROM to 8MB and it will still work. The misconception I had was that the Super FX limited the WHOLE ROM to 2MB, but actually it's that the Super FX can only address 2MB, but the CPU can address 8MB.

This means theoretically, you can sort out 65816 code from Super FX code (you would have to leave the code dealing with system level stuff behind I think, but 65816 side game related code could be put in the 6MB after some repointing. This could leave alot of space at the first 2MB, for data and Super FX code, and the last 6MB for 65816 code.

Maybe the person who said that Super FX ROMs can have 8mb, but the Super FX itself can only use 2MB was wrong however, meaning any Super FX ROM MUST be 2MB no matter what, but this is just an idea if I am correct on this.

[Job]

This is fascinating, but pardon my ignorance - how can this be implemented beneficially?

[petePESTILENCE]

Custom wads!!!
(Unlikely) :D

[Jaxxoon R]

I've seen patches that port Super Mario World to an 8MB SuperFX ROM. So yeah, it should probably be possible.

[lunaark]

Job said:

This is fascinating, but pardon my ignorance - how can this be implemented beneficially?

Ok, for the sake of simplicity lets just call the first 2MB the lower ROM and the last 6MB the upper ROM.

Normally, there is only 2MB in a Super FX ROM, and naturally the bigger the game the more space it takes up. Since Doom is a large game, there is only around 60 bytes of free space, or to be clear, essentially nothing. Since there is alot of code on the 65816 side, and typically a 65816 instruction in hex is around 2 to 4 bytes, think about how much code it takes to do everything that is not done on the SPC700 or Super FX. Basically, every line of code not for rendering or sound (Super FX and SPC700). That's quite a considerable amount of code, probably takes up over at least 25kb

25KB is alot more than you think for the SNES, due to the amount of compression everything uses. Just google how much compression the SNES uses, and you will realize you can cram a reasonable amount of data in there (Maps, Graphics, Sounds, and Super FX code [If you want to modify some Super FX routines or add some for whatever reason]) The reason you would want this free space in the lower ROM is because the Super FX should be able to address the graphics and levels [I think the Super FX addresses the levels but I am unsure].

Basically, you turn the lower ROM into a 2MB section for data, some 65816 code, and some Super FX code.

You then turn the upper half into a 6MB section for 65816 ASM. You maybe wondering, why so much space? Because, 8MB takes up little space on modern hard drives, and you can basically add/modify routines as much as you desire, as there is enough space in lower ROM to add/modify Super FX routines, and way more than enough space in upper ROM to add/modify 65816 routines.

Examples of routines that would be 65816 side:

-Better Player Code (fixes for movement bugs/limitations such as adding circlestrafing, fixing the sticky walls glitch (based on my experience it is more vertices you get stuck on, not linedefs most of the time)

-Better Weapon Code (add a decrease in damage based on distance like PC Doom, add weapon spread, make your weapon automatically switch when you run out of ammo)

-Better AI (more intelligent demons, maybe make them retreat when at low health and have them be more unpredictable)

-Add Sound Propagation (The reason they did not add it is many people think it was to conserve processing power, but who cares if the CPU is under more load, most people won't be using flashcarts to play on a SNES anyways, and people probably would keep an eye out for their SNES overheating, but the SNES can do surprisingly well under load, IIRC. I don't think it would use too much processing if done carefully and correctly. This and the Better AI routine would be nice together.)

BTW: The lack of sound propagation in SNES Doom is why enemies are deaf, incase you did not know

Examples of Super FX side routines:

-Better Rendering Engine (Due to the lack of space in the ROM, they probably wrote a more basic rendering engine (probably has little optimization) to save space, but with a better one you can write a more advanced one written to push the Super FX to it's limits to get better speed, and write more optimized code to get even better speed.)

-Floor and Ceiling Textures (Self explanatory, would also need the Better rendering engine routine, and you would put your floor and ceiling textures in the new free space in the lower ROM)

-Textured automap (Would be pretty cool, since the Super FX does the automap too, it would have pretty good texture mapping, and would need the Better Rendering Engine and Floor and Ceiling Textures routines)

So personally if I had the ability to do this right now, I'd be getting straight to work.

Jaxxoon R said:

I've seen patches that port Super Mario World to an 8MB SuperFX ROM. So yeah, it should probably be possible.

SMW on a Super FX ROM is really, REALLY stupid. I can understand using the SA-1 but, really the Super FX?

[Job]

Ok, for the sake of simplicity lets just call the first 2MB the lower ROM and the last 6MB the upper ROM.

Normally, there is only 2MB in a Super FX ROM, and naturally the bigger the game the more space it takes up. Since Doom is a large game, there is only around 60 bytes of free space, or to be clear, essentially nothing. Since there is alot of code on the 65816 side, and typically a 65816 instruction in hex is around 2 to 4 bytes, think about how much code it takes to do everything that is not done on the SPC700 or Super FX. Basically, every line of code not for rendering or sound (Super FX and SPC700). That's quite a considerable amount of code, probably takes up over at least 25kb 

25KB is alot more than you think for the SNES, due to the amount of compression everything uses. Just google how much compression the SNES uses, and you will realize you can cram a reasonable amount of data in there (Maps, Graphics, Sounds, and Super FX code [If you want to modify some Super FX routines or add some for whatever reason]) The reason you would want this free space in the lower ROM is because the Super FX should be able to address the graphics and levels [I think the Super FX addresses the levels but I am unsure].

Basically, you turn the lower ROM into a 2MB section for data, some 65816 code, and some Super FX code.

You then turn the upper half into a 6MB section for 65816 ASM. You maybe wondering, why so much space? Because, 8MB takes up little space on modern hard drives, and you can basically add/modify routines as much as you desire, as there is enough space in lower ROM to add/modify Super FX routines, and way more than enough space in upper ROM to add/modify 65816 routines.

Examples of routines that would be 65816 side:

-Better Player Code (fixes for movement bugs/limitations such as adding circlestrafing, fixing the sticky walls glitch (based on my experience it is more vertices you get stuck on, not linedefs most of the time)

-Better Weapon Code (add a decrease in damage based on distance like PC Doom, add weapon spread, make your weapon automatically switch when you run out of ammo)

-Better AI (more intelligent demons, maybe make them retreat when at low health and have them be more unpredictable)

-Add Sound Propagation (The reason they did not add it is many people think it was to conserve processing power, but who cares if the CPU is under more load, most people won't be using flashcarts to play on a SNES anyways, and people probably would keep an eye out for their SNES overheating, but the SNES can do surprisingly well under load, IIRC. I don't think it would use too much processing if done carefully and correctly. This and the Better AI routine would be nice together.)

BTW: The lack of sound propagation in SNES Doom is why enemies are deaf, incase you did not know

Examples of Super FX side routines:

-Better Rendering Engine (Due to the lack of space in the ROM, they probably wrote a more basic rendering engine (probably has little optimization) to save space, but with a better one you can write a more advanced one written to push the Super FX to it's limits to get better speed, and write more optimized code to get even better speed.)

-Floor and Ceiling Textures (Self explanatory, would also need the Better rendering engine routine, and you would put your floor and ceiling textures in the new free space in the lower ROM)

-Textured automap (Would be pretty cool, since the Super FX does the automap too, it would have pretty good texture mapping, and would need the Better Rendering Engine and Floor and Ceiling Textures routines) 
    
So personally if I had the ability to do this right now, I'd be getting straight to work.

Ok, now I follow. That said, some of the suggestions you made would breed out some of the endearing idiosyncrasies of SNES Doom. I myself would prefer a better frame rate or drawing distance. As always, my main question is whether this will allow support of user-made PWADs or the ability to run outside an emulator.

[lunaark]

Job said:

Ok, now I follow. That said, some of the suggestions you made would breed out some of the endearing idiosyncrasies of SNES Doom. I myself would prefer a better frame rate or drawing distance. As always, my main question is whether this will allow support of user-made PWADs or the ability to run outside an emulator.

As for the drawing distance, I think Doom SNES uses double column rendering so everything is stretched by 1 pixel horizontally, plus the border meaning these are the main causes of severe pixellation in SNES Doom. The FPS issue can be helped by well optimized code and pushing the Super FX to always be processing at max capacity.

It might run outside an emulator.

The chances of user made levels are kind of high, as we know a bit on how SNES Doom levels work.

Also even if it does run outside an emulator, the SNES will be under heavy load and may crash/overheat. 2.68MHz is not a lot to work with.

[lazygecko]

Can you even run Super FX, or any other chip-extended ROMs on something like a flash cart? Is there some kind of software/emulation solution built into the carts for those situations?

[lunaark]

GeckoYamori said:

Can you even run Super FX, or any other chip-extended ROMs on something like a flash cart? Is there some kind of software/emulation solution built into the carts for those situations?

I don't know.

[Danfun64]

If you're going to make it 8mb, wouldn't it be better to port Jaguar Doom with certain 32x ifdef's turned on (No infighting/front facing only monsters)? It would be nice not to deal with SNES specific weirdness and play using the "real" doom engine.

[Jaxxoon R]

Except Jaguar Doom is Jaguar Doom and not a better SNES Doom like he wants to make using SNES Doom. Have fun porting from one entirely different machine to another, you might as well just base it on Linux Doom since that at least doesn't run physics calculations on the sound chip like Jaguar does.

[Danfun64]

...yeah, you're probably right. And no, I am not qualified to do such a thing myself.

...it's a nice idea though...