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

Doom SNES Hacking Guide/Documentation

Recommended Posts

I'm no SNES hacker, and I assume Erick already knows a lot of SNES hacking stuff, but maybe this NHL '94 game forums topic can be of help?

This article by The Cutting Room Floor is much more detailed in that regard, along with several recommended tools.

Edited by InDOOMnesia

Share this post


Link to post
14 hours ago, Erick194 said:

 

Hello, I'm playing a bit with the Doom SNES data, and I just found this section in another thread of yours, it compares to the code I wrote yesterday for the decompression of textures, what else do you know about this.

i don't really know that much to be frank, and anything i have learned i've since forgotten as it's been like 4 years. however, i recommend you look into RLE compression as i vaguely recall it's a fairly standard implementation, and is common on old hardware as it is a relatively effective and very efficient compression algorithm.

 

here's an example off wikipedia that generally summarizes it pretty well.

For example, consider a screen containing plain black text on a solid white background. There will be many long runs of white pixels in the blank space, and many short runs of black pixels within the text. A hypothetical scan line, with B representing a black pixel and W representing white, might read as follows:

WWWWWWWWWWWWBWWWWWWWWWWWWBBBWWWWWWWWWWWWWWWWWWWWWWWWBWWWWWWWWWWWWWW
With a run-length encoding (RLE) data compression algorithm applied to the above hypothetical scan line, it can be rendered as follows:

12W1B12W3B24W1B14W

so, i presume the encoding will be (length of single color run) (palette index) or something along those lines, meaning every run of pixels of a certain color is 2 bytes. RLE is the only compression used, afaik. also, afaik the graphics that aren't compressed are out of a need to quickly access column data, for example, the skybox, as it has to do alot of column manipulation to get the correct perspective.

 

although, i'm no expert on the subject so take this with a grain of salt

Share this post


Link to post
Just now, lunaark said:

i don't really know that much to be frank, and anything i have learned i've since forgotten as it's been like 4 years. however, i recommend you look into RLE compression as i vaguely recall it's a fairly standard implementation, and is common on old hardware as it is a relatively effective and very efficient compression algorithm.

 

here's an example off wikipedia that generally summarizes it pretty well.


For example, consider a screen containing plain black text on a solid white background. There will be many long runs of white pixels in the blank space, and many short runs of black pixels within the text. A hypothetical scan line, with B representing a black pixel and W representing white, might read as follows:

WWWWWWWWWWWWBWWWWWWWWWWWWBBBWWWWWWWWWWWWWWWWWWWWWWWWBWWWWWWWWWWWWWW
With a run-length encoding (RLE) data compression algorithm applied to the above hypothetical scan line, it can be rendered as follows:

12W1B12W3B24W1B14W

so, i presume the encoding will be (length of single color run) (palette index) or something along those lines, meaning every run of pixels of a certain color is 2 bytes. RLE is the only compression used, afaik. also, afaik the graphics that aren't compressed are out of a need to quickly access column data, for example, the skybox, as it has to do alot of column manipulation to get the correct perspective.

 

although, i'm no expert on the subject so take this with a grain of salt

nearly forgot, the texture compression is why those random colored dots appear on certain emulators.

Share this post


Link to post
On 4/26/2020 at 6:19 PM, InDOOMnesia said:

CacodemonTube aka. TubeWave, who is currently preparing for the interview podcast with Randy Linden. Mopoz90 hasn't been active for a long while.

Has there been any developments on this? I heard this might be occurring this week, as well as whispers of tools. 

Share this post


Link to post
1 hour ago, Job said:

Has there been any developments on this? I heard this might be occurring this week, as well as whispers of tools. 

CacodemonTube postponed the interview video into around next week. He is still preparing his video so that it will look better.

As for Randy Linden, there still has yet to be another thing from him, at least not about the source code.

Share this post


Link to post

Hey everyone!

 

It's my first post here! Thank you guys for the comments on the whole progress and the interview I did last week.

 

Just wanted to share some WIP screenshots of Map03 - The Gantlet from Doom 2 (sorta) running in SNES Doom.

The last picture on here was taken at the same moment as when the game just crashed. :/

I removed some of the windows in the back to prevent too much from loading at the same time but it's still not enough...

 

Edit #1: Thanks for telling me about that common mistake people make in the name. I’ve corrected it. :)

 

 

 

 

1.PNG

2.PNG

3.PNG

5.PNG

Edited by CacodemonTube : Typo fix

Share this post


Link to post
3 hours ago, CacodemonTube said:

Just wanted to share some WIP screenshots of Map03 - Gauntlet from Doom 2 (sorta) running in SNES Doom.

You mean Gantlet? :P (To be fair, it's an archaic spelling of the same - blame Sandy Petersen, apparently).

 

Does look good though! Of course Doom II in SNES Doom "for real" is a bit of a stretch unless some solutions can be found on the ROM cart size...

Share this post


Link to post

@CacodemonTube Welcome (or technically, welcome back)!

Everybody has waited for more from you. Hopefully we all can discuss and cooperate about further SNES DOOM hacking!

Share this post


Link to post

i've thought long and hard about this, but i believe the game has an extremely poor implementation of BSP, and i believe we can incorporate changes to the engine to gain performance, but sacrifices will have to be made.

 

i believe the simplest way to gain storage space is to use the jaguar levels, and then further simplify some geometry, and then cut unused data. to be honest, the jaguar levels are probably the best bet in terms of playability anyways, as they're easier to navigate with suboptimal control. 

 

however, this brings me to my main point.

 

i've been watching alot of doom snes corruptions lately, and i notice something quite.. odd. the rendering engine fucks up quite often, as to be expected, but quite often, you can see things that you really shouldn't be able to see. for example, you can see the lights in the computer room of e1m1, from the room with the armor and columns, or you can see areas behind doors. this leads me to believe a few possibilities.

 

i believe the most likely answer is that doors are not factored into bsp visibility checks, and that it doesn't take into consideration height variation, simply checking visibility on a 2d plane (this might be why doors aren't considered, so far as the engine cares it just sees a sector, not a wall.)

 

this would explain why you could see the lights from the armor room, as looking on a 2 dimensional plane, you would clearly see from the armor, to the courtyard through the window, through the lowering wall in the computer room.

 

while this obviously sounds like a naive approach, it makes sense given the limited capability of the hardware. however, i don't believe that's the issue here.

 

randy didn't have access to the source code, nor did he really have much information about BSP, which is also why i believe REJECT and BLOCKMAP are omitted, in addition to space.

 

he basically completely wrote the game based off the unofficial doom specs, which wasn't really great and didn't delve into BSP. remember, that was written when people were making levels with fuckin hex editors.

 

i dont think it does a check on the players angle either, it just does visibility checks on a 2d plane from the players position, which explains why looking directly at a wall even with no geometry behind it at all still yields the same framerate.

 

i believe one of the most problematic parts is also the column rendering. randy did a really fucking good job with the column renderer, but it still has throughput issues.

 

in the doom engine black book, randy said he got pixel blitting to 1 cycle/pixel, by taking advantage of the GSU's internal cache to quickly write across the desired location, this is great. floors and ceilings aren't rendered, so the amount of columns is very easily controllable by lowering level geometry.

 

however, given that assuming my model of randy's bsp implementation is correct, there isn't much you can do. when the source code releases, i hope someone proficient in GSU assembly can fix it up, if i have the time and motivation i might even try to learn GSU asm.

 

all in all, i believe the game can be brought to a surprisingly playable framerate by fixing up the BSP algorithm on the source code's release. i'd expect it to net between a 30-200% framerate increase depending on the area, and assuming an average framerate of 10, that's 13-30 fps. not bad at all. 30 fps sounds like a high figure, but think of it like this.

 

assuming the example of the armor room, in the old implementation of BSP, you would render *every* surface of the start room, armor room, outdoor section of armor room, courtyard, some of the entrance to computer room, and some of the zig zag room. fuckin bonkers

 

however, in this new implementation, you'd render some of the start room and some of the armor room.

 

the game could even get up to 60 frames while looking in a small room.

 

this could push the envelope to get single column rendering on a stock GSU-2, maybe even at better framerates than the original.

 

however, the framerate would *wildly* fluctuate, so additional assembly would have to be written for keeping the controls just as responsive, by scaling input by the current factor of the target framerate, so assuming 30 fps target, times input by 2 at 15 fps, and by 0.5 at 60 fps.

 

speaking of controls, i have quite a few ideas to greatly improve control.

 

this port has a really high angle resolution. in one of cacodemontube's corruptions, you can see the player turning very slowly, but extremely smoothly and fluidly. it looks like the same turning resolution as PC doom, which uses 16.16 fixed points.

 

if you were to have logarithmic turning, you could start turning very slow, but speed up as you hold the button, to an upper cap. this is what rebecca heineman did on the 3do port of doom, which actually controls quite nicely, especially given the poor framerate.

 

also, i heard something interesting. you know that input lag when you shoot? the game does a bunch of line of sight and damage calculations, and when those finish, *then* it plays the animations. the animations on the demons you shoot also get delayed, as it asserts that a collision was made.

 

another thing i would be interested in is better sound mixing. because only 1 weapon sound can play at a time, the chaingun and chainsaw sound quite bad. sound mixing is notoriously hard on older consoles, but i believe it to be feasible.

 

you know jaguar doom? it doesn't have music because the DSP chip is too busy doing collisions. however, someone got music, sounds, and collision working at full speed. im not quite sure the technical details, but i have a theory as to how.

 

in an early demo of it, the sounds were extremely stuttery, so maybe they were streaming samples bit by bit during hblank? no idea.

 

however, this method does work. in the sega genesis version of toy story, jon burton wrote an amiga MOD player for the title screen, that used double buffering, pitch tables, basic math, and hblank to quickly stream audio to the z80, which would then be played by the ym2612. of course, this is very intensive, and you couldn't run a game while doing this on the cpu. 

 

about that however, the 65816 really doesnt do much. open doom in a snes debugger and step both the super fx and the 65816. the 65816 really just sits there most of the time. i believe you can run the 65816 and GSU in parallel, and the 65816 is what controls and sends/receives data from the APU. i wonder if you could add the sounds to a buffer, just adding each sample to each other then dividing the value by the number of overlapped samples, then stream it over one of the APU registers to the weapon channel, something along those lines.

 

sorry for the long post, but i've been thinking alot and i want to put my thoughts out there.

Share this post


Link to post
1 hour ago, lunaark said:

also, i heard something interesting. you know that input lag when you shoot? the game does a bunch of line of sight and damage calculations, and when those finish, *then* it plays the animations. the animations on the demons you shoot also get delayed, as it asserts that a collision was made.

 

That's right. While playing on nightmare, you can blast a rocket at a fast-moving monster (like imp) and, after the calculations are made, it manages to run like 5 meters away from the explosion and then dies. 

Share this post


Link to post
7 minutes ago, Dimon12321 said:

 

That's right. While playing on nightmare, you can blast a rocket at a fast-moving monster (like imp) and, after the calculations are made, it manages to run like 5 meters away from the explosion and then dies. 

 

i wonder what causes the lag, maybe it traverses every thing in the level and does a lengthy line of sight and distance calculation? i seriously doubt randy would do something that hacky, but i really wonder why there's such a huge delay

Share this post


Link to post
9 minutes ago, lunaark said:

i wonder what causes the lag, maybe it traverses every thing in the level and does a lengthy line of sight and distance calculation? i seriously doubt randy would do something that hacky, but i really wonder why there's such a huge delay

 

No, it doesn't care about the distance between you and the target. On the other hand, it's a real mystery how the rocket blast range is calculated. Check this out. These rocket blasts are really odd. Especially the pre-last one where I kill a demon which was further away from the explosion than me.

Share this post


Link to post
1 minute ago, Dimon12321 said:

 

No, it doesn't care about the distance between you and the target. On the other hand, it's a real mystery how the rocket blast range is calculated. Check this out. These rocket blasts are really odd. Especially the pre-last one where I kill a demon which was as far away from the explosion as me.

 

that's really strange, i really can't wait to see this source code. i heard the game uses cylindrical collision (??) but im not too sure about that, i have no clue why they would use such a method, but that would explain the lag, as it's harder to calculate collisions with cylinders, especially mutliple cylinders and overlapping cylinders, than coordinates on a box.

Share this post


Link to post
11 minutes ago, lunaark said:

that's really strange, i really can't wait to see this source code. i heard the game uses cylindrical collision (??) but im not too sure about that, i have no clue why they would use such a method, but that would explain the lag, as it's harder to calculate collisions with cylinders, especially mutliple cylinders and overlapping cylinders, than coordinates on a box.

 

It is cylindrical. For example, try to run between the wall and that barrel on E1M5. You can "touch" the barrel from many different angles while on PC you like run against the square wall.

Spoiler

image.png.0c633448889b0d50f693e140187e31de.png

 

Share this post


Link to post

 

Just a note to keep expectations at the door, guys. I see stuff like this...

3 hours ago, lunaark said:

all in all, i believe the game can be brought to a surprisingly playable framerate by fixing up the BSP algorithm on the source code's release. i'd expect it to net between a 30-200% framerate increase depending on the area, and assuming an average framerate of 10, that's 13-30 fps. not bad at all. 30 fps sounds like a high figure, but think of it like this.

...and I go "Whoa whoa whoa."

 

The SuperFX2 chip definitely can do some great things for the hardware, but I'd be really surprised if this game ran at 30 FPS. While it's a bit of a poor comparison admittedly, no other SuperFX games came even close to that kind of rendering speed. Of course, this doesn't account for optimizing the rendering - important caveat; if the renderer can be made several times faster, then obviously higher framerates become more possible.

 

Starfox, for example (which is the game Randy hacked up to develop SNES Doom, don't forget) ran at 15 FPS, and its timing was definitely made to have that target in mind (since if you overclock it in an emulator, the game begins getting wacky in minor ways - scenes ending before music tracks finish, for example, or in very rare cases, sound effects getting cut off before playing fully). Here's a good example video, using Starfox, with side-by-side comparisons, using a 21.5 MHz SuperFX on the left, and a 27 MHz SuperFX2 (in a hacked-up Doom cartridge!) on the right.

 

 

In short, a nearly 1/3x clock boost definitely made the game faster, but getting it to 30 FPS? That I'd doubt unless that rendering routine was HELLA optimized. As in, multiple-times-faster optimized, the SuperFX was overclocked (which would make it not really feasible on actual hardware without a physical cartridge mod), or both. 

 

Here's another video from the same guy, who actually did that to SNES Doom. However, he noted a few problems: He did overclock the SuperFX2's crystal (to 30 MHz), but anything over 30 MHz caused the game to freeze, so there's definitely at least some code that won't play nice if the chip is running too fast. Pay careful attention as well and you will see the game timings are clearly not made to deal with high framerates - doors, for example, open too quickly (more like blazing doors than normal doors).

 

 

Now, it's definitely possible that with tighter timing and optimized rendering, a modded version of the game running on the hardware could go faster. 30 FPS fast? That I'd doubt (and to be fair, @lunaark did say that's a high figure). PSX Doom is probably a decent benchmark example - the game tries to run at 30, most maps are in the 20s, some dip down to about 10-15 in worst-case scenarios, and the AI/Thinkers/etc. are at 15 Hz no matter what.

 

If that can be managed, it will be quite a playable port (it was good enough for PSX Doom, after all). Once you add in circlestrafing, anyway, because not having that is just... UGH.

 

Now I'll turn my attention to this little snippet:

3 hours ago, lunaark said:

another thing i would be interested in is better sound mixing. because only 1 weapon sound can play at a time, the chaingun and chainsaw sound quite bad. sound mixing is notoriously hard on older consoles, but i believe it to be feasible.

In short, this is the game running up against limitations of the SPC700 sound chip.

 

The SPC700 has eight hardware sound channels. How these are used is up to the developer, and most games don't use all eight for music - F-Zero, for example, reserves the last three channels for every music track besides the title screen, I believe. This way, you've got your music playing, the whine of your car's engine, some extra channels for smashing into cars/the track/etc. and it all plays on just fine without missing a beat.

 

Now here's the problem: Doom uses all eight channels for the music. The music is so lauded because, simply put, it makes more use out of the SPC's channels for music than most games do. This comes at a cost, however - when there needs to be nine sounds playing, the sound effects must play on one of those eight channels - and it will clobber whatever was playing there until it plays a new note.

 

Not every song uses all eight channels, for example - E1M1 seemingly uses only seven channels (at least, nothing played on Channel 8 when I checked it, but admittedly I didn't run the whole song through). But many songs do actually make use of all these channels (in my quick look, E1M2 and E1M3 certainly do), and there isn't necessarily a rhyme or reason as to how all these channels are used (i.e; drums aren't always on the same channel across songs!) So what Doom does here is basically allow the sound effects to clobber whatever channel sound effects are allowed to play in (presumably channel 1 or 8), which leads to music notes getting cut off until the next time it's supposed to play a note. In turn, that means they try to keep it so only one sound effect is playing at a time - because otherwise the music would get clobbered even worse than it already does.

 

In short, to fix the problem, you'd need to either reserve more channels for sound effects (in turn, reducing music richness), somehow combine multiple sound channels into one channel so as to have room for reserved sound effects (which would probably entail a lot of on-the-fly instrument switching), somehow create a software mixer for sound effects that would leave the hardware part alone, stuff like that.

Edited by Dark Pulse

Share this post


Link to post
34 minutes ago, Dark Pulse said:

 

Just a note to keep expectations at the door, guys. I see stuff like this...

...and I go "Whoa whoa whoa."

 

The SuperFX2 chip definitely can do some great things for the hardware, but I'd be really surprised if this game ran at 30 FPS. While it's a bit of a poor comparison admittedly, no other SuperFX games came even close to that kind of rendering speed. Of course, this doesn't account for optimizing the rendering - important caveat; if the renderer can be made several times faster, then obviously higher framerates become more possible.

 

Starfox, for example (which is the game Randy hacked up to develop SNES Doom, don't forget) ran at 15 FPS, and its timing was definitely made to have that target in mind (since if you overclock it in an emulator, the game begins getting wacky in minor ways - scenes ending before music tracks finish, for example, or in very rare cases, sound effects getting cut off before playing fully). Here's a good example video, using Starfox, with side-by-side comparisons, using a 21.5 MHz SuperFX on the left, and a 27 MHz SuperFX2 (in a hacked-up Doom cartridge!) on the right.

 

 

In short, a nearly 1/3x clock boost definitely made the game faster, but getting it to 30 FPS? That I'd doubt unless that rendering routine was HELLA optimized. As in, multiple-times-faster optimized, the SuperFX was overclocked (which would make it not really feasible on actual hardware without a physical cartridge mod), or both. 

 

Here's another video from the same guy, who actually did that to SNES Doom. However, he noted a few problems: He did overclock the SuperFX2's crystal (to 30 MHz), but anything over 30 MHz caused the game to freeze, so there's definitely at least some code that won't play nice if the chip is running too fast. Pay careful attention as well and you will see the game timings are clearly not made to deal with high framerates - doors, for example, open too quickly (more like blazing doors than normal doors).

 

 

Now, it's definitely possible that with tighter timing and optimized rendering, a modded version of the game running on the hardware could go faster. 30 FPS fast? That I'd doubt (and to be fair, @lunaark did say that's a high figure). PSX Doom is probably a decent benchmark example - the game tries to run at 30, most maps are in the 20s, some dip down to about 10-15 in worst-case scenarios, and the AI/Thinkers/etc. are at 15 Hz no matter what.

 

If that can be managed, it will be quite a playable port (it was good enough for PSX Doom, after all). Once you add in circlestrafing, anyway, because not having that is just... UGH.

 

Now I'll turn my attention to this little snippet:

In short, this is the game running up against limitations of the SPC700 sound chip.

 

The SPC700 has eight hardware sound channels. How these are used is up to the developer, and most games don't use all eight for music - F-Zero, for example, reserves the last three channels for every music track besides the title screen, I believe. This way, you've got your music playing, the whine of your car's engine, some extra channels for smashing into cars/the track/etc. and it all plays on just fine without missing a beat.

 

Now here's the problem: Doom uses all eight channels for the music. The music is so lauded because, simply put, it makes more use out of the SPC's channels for music than most games do. This comes at a cost, however - when there needs to be nine sounds playing, the sound effects must play on one of those eight channels - and it will clobber whatever was playing there until it plays a new note.

 

Not every song uses all eight channels, for example - E1M1 seemingly uses only seven channels (at least, nothing played on Channel 8 when I checked it, but admittedly I didn't run the whole song through). But many songs do actually make use of all these channels (in my quick look, E1M2 and E1M3 certainly do), and there isn't necessarily a rhyme or reason as to how all these channels are used (i.e; drums aren't always on the same channel across songs!) So what Doom does here is basically allow the sound effects to clobber whatever channel sound effects are allowed to play in (presumably channel 1 or 8), which leads to music notes getting cut off until the next time it's supposed to play a note. In turn, that means they try to keep it so only one sound effect is playing at a time - because otherwise the music would get clobbered even worse than it already does.

 

In short, to fix the problem, you'd need to either reserve more channels for sound effects (in turn, reducing music richness), somehow combine multiple sound channels into one channel so as to have room for reserved sound effects (which would probably entail a lot of on-the-fly instrument switching), somehow create a software mixer for sound effects that would leave the hardware part alone, stuff like that.

 

very good points, but let me break down my reasoning.

 

to make this simple on myself, im gonna simplify this a little bit.

 

i'm gonna draw how i believe the bsp system works. assuming you are standing in the sector highlighted yellow, the sectors highlighted in red are what you're gonna see.

 

now, we know that textures in snes doom are around 64x64, and when rendered as double width, have an effective resolution of about 32x64. let's assume all columns are rendered 16 pixels tall. e1m1 has 486 linedefs, and around 66% of them are drawn. let's assume a very conservative estimate of 128 units wide per linedef, which is the width of a door, but with 64 actual columns per wall, as the game renders double width.

 

(486*0.66)*64=20,528 columns drawn, and with 16 pixels tall that is about 324,448 pixels drawn, and given randy's pixel renderer pushes 1 pixel per cycle, you're looking at 324,448 cycles to just draw the frame. this sounds like alot, and it probably is, but keep in mind that the screen resolution is 108x144, which is 15,552 pixels directly on screen, so given the massive excess of geometry being rendered vs what is visible, i feel this number is plausible, despite my admittedly shoddy methodology. alright, so we know that 324,448 cycles are taken just to draw the game per frame, how much is that actually for the super fx? well, it runs at 21.447mhz, so let's convert that to hz, and we get 21,447,000 cycles. yikes.

 

so, we know the game runs about 10 fps average, so that 324,448 cycles per frame comes out to 3,244,480 cycles per second used to draw the game, which means ~15.1% of the super fx is dedicated to just drawing the screen alone, however, the actual number of pixels drawn could vary wildly, from a hundred thousand to over double my initial statement, especially on larger levels, which could mean up to 30% of the super fx is used just *drawing* the screen, leaving you with around 70% to actually run the game.

 

then when you factor in the omission of blockmap and reject to speed up line of sight and collision calculations, which both involve heavy trigonometry, math, and BSP fuckery, the weird ass cylindrical collision, demon AI, and literally an entire game, it adds up quite quickly. given the simplicity of the approach i presume randy to have used for bsp, i feel it's relatively inconsequential on performance.

 

please take this all with a fat ass grain of salt, but this is my reasoning.

e1m1_over.png

Share this post


Link to post

to test my theory, im gonna make a level with a shitload of sectors, but with very few columns, so basically a really subdivided room.

Share this post


Link to post

Yeah, I get your points just fine. If there's optimizations to be had, it's definitely in stuff like Reject or more proper BSP trees.

 

I do remember that in SNES Doom, all monsters are effectively deaf/ambush, and more than that, at a certain distance away from them they won't even move if they haven't been woken up (I specifically remember picking off a group of enemies at the start of E2M3, which is Deimos Lab in that version, right after going through the teleporter at the start). Reject may actually be pointless in that case, if monster AI is simply disabled at a certain distance unless awoken anyway.

 

Another thing to keep in mind is that the game doesn't actually run at "full" resolution. The lowest the SNES can render as a resolution is IIRC 256x224 (8:7), and pretty much every SuperFX game actually renders at less than that (something like 224x192?), I believe for memory bandwidth or DMA reasons. That should reduce the drawing some.

 

Lastly, any sort of actual expansion to the game is going to require one pretty key thing to be resolved: The 2 MB/16 MBit program ROM limit. We can certainly free up some space by removing extraneous stuff (the XBAND is long dead and there's no real way to ever do that anymore, for example, and it's probably not much point in keeping the Super Scope support which the game apparently also has), but properly fitting in more maps (especially if you want to expand to Ultimate Doom) would definitely need at least a good couple hundred kilobytes to a few more MB free.

 

Oh, I dug this up. It might help you if you're serious about learning SuperFX programming. https://en.wikibooks.org/wiki/Super_NES_Programming/Super_FX_tutorial

Edited by Dark Pulse

Share this post


Link to post

With all this talk of the inherent limitations of SNES Doom's game architecture, I'm left wondering if we're trying to modify a ROM, if we're trying to "export" the game and create a sourceport for it (which would obviously create a lot more flexibility at the expense of authenticity)? In my mind, that's the end goal, but I'm curious if that's even being realistic. 

Share this post


Link to post
1 hour ago, Job said:

With all this talk of the inherent limitations of SNES Doom's game architecture, I'm left wondering if we're trying to modify a ROM, if we're trying to "export" the game and create a sourceport for it (which would obviously create a lot more flexibility at the expense of authenticity)? In my mind, that's the end goal, but I'm curious if that's even being realistic. 

Theoretically it'd be harder than usual to make a port for this, since it's not Doom engine at all. That would probably be amazing but it'd be basically doing a somewhat strange "kinda-Doom" port, given that if we were going to be accurate, we'd be needing to keep it to more or less how the original SNES version is minus the obvious benefits such as higher resolutions and so on. A solution would definitely have to come up with how to give the port its graphics and stuff as well - presumably some sort of program where you feed it an official Doom I/Ultimate Doom IWAD and it spits out the proper crunched stuff the port needs, or an actual game ROM like was done for Doom 64 EX.

 

Expanding the ROM is going to be arguably an even harder task than making a port would be, mainly because the SuperFX2 can only address up to 2 MB of program ROM. The SNES can do more than that - the biggest games ever released were 48 Mbit/6 MB, and the SNES can theoretically handle up to 128 Mbit/16 MB (really 117.5 Mbit/14.6875 MB for techical reasons though), but the SuperFX2 is limited in that sense. There's also technicalities of what's called FastROM vs. SlowROM, and so on that would also play a part. However, to fit all of Doom/Ultimate Doom (or even Doom II) onto a cartridge, it really shouldn't need more than about 16 MB of ROM - Ultimate Doom's IWAD is 11.8 MB, and Doom II is 13.9 MB. Even with some ROM space dedicated for code, music samples, etc., these should all fit nicely into 16 MB, and that's not factoring in that compression and reduced-rez versions of the assets will definitely be smaller than that.

 

Basically to expand the game ROM, some kind of bankswitching would be needed for the ROM the SuperFX2 can access, or the SuperFX2 itself would have to be "expanded" somehow so that it can read more ROM. The former would mean additional programming logic would be necessary to handle the bankswitching; the latter would basically mean there's no chance it can play on real hardware unless some sort of in-cart FPGA could be made or something like that (since obviously no physical chips exist, just like the MSU-1), as well as emulators and such would need to gain support for this new virtual chip.

Edited by Dark Pulse

Share this post


Link to post

Using a noclip cheat, messing with the NODES data, and comparing it to the PC version etc, as well as information from CacodemonTube, I think I can confirm that the SNES port has a proper BSP implementation, and factoring in information from Randy himself I really don't think there's much to optimize. I'm kind of baffled that the game is truly done this well, especially given the lack of information around the Doom engine, BSP rendering, etc.

Share this post


Link to post

Alright, I forwarded a question to Randy through CacodemonTube, and I'm really excited. It was a long question, so it's gonna take him a while to answer.

 

Anyways, he said that the game does in fact have a proper BSP implementation, but it is implied that there is a bunch of trickery going on. I asked about potential optimizations, how the renderer works, pathfinding, etc.

 

To consolidate the information I already have, I do believe that further optimization *is* possible through large community efforts, but the game appears to use the Super FX insanely well, using many optimizations and cache etc. The game manages to push around 7-12 MIPS, and 21 is the theoretical limit of the GSU-2. However, I do believe that more is to be done, especially considering the very small amount of RAM left over, only like 16 bytes. Machine code can get decently big over a long period of time, and quite often longer code that is more efficient is better than smaller code that is less efficient.

 

Also, I do believe there is quite a significant chunk of space to reclaim. As far as I can tell, more or less all of the relevant PC data is in the ROM, and quite a bit is uncompressed as far as I can tell. I believe all sprites are in the game, all textures (excluding flats), all sounds, etc. 

 

I will post an update when Randy finds the time to type out his response.

Share this post


Link to post

@lunaark So does that mean there will be a second interview video with him?

What's more, is if this will also make the source code release much closer than we're expecting it to be. Of course, he still has to take care of copyright stuff before doing so, but I'm crossing my fingers in this case.

Share this post


Link to post
1 hour ago, InDOOMnesia said:

@lunaark So does that mean there will be a second interview video with him?

What's more, is if this will also make the source code release much closer than we're expecting it to be. Of course, he still has to take care of copyright stuff before doing so, but I'm crossing my fingers in this case.

Copyright can mostly be alleviated by following the Doom 64 EX route - the engine is abstracted from the data, and an appropriate file would need to be generated from a game ROM, which would produce an IWAD that the engine would use to run.

 

Of course, this is assuming a native PC implementation. An actual ROM hack would be an entirely different story; we'd be needing to basically create a patched ROM and create an IPS or BPS patch from that to apply to a source ROM. We distribute the patch and thus stay in the legal clear, since all a patch file is, is a file that tells a patching program "change this byte to that byte." The patch isn't the complete game, and thus we skirt any legality issues.

 

In practice the odds of anyone coming after the project are next to none either way, but better safe than sorry. (It's certainly how I'll advocate Erick to do PSX Master Edition and any eventual Doom 64 hack he may do, once it's all finished.)

Edited by Dark Pulse

Share this post


Link to post

Randy has responded, and here's what he has to say.

 

Quote

 

The SNES/FX code does indeed use a BSP and it is first stage of many when generating the 3D view of the world. Visibility determination also uses two-dimensional clipping against the view frustum to exclude (or included) complete nodes and their children. The optimizations I would focus on are improved compression for the code, graphics and data to allow more levels. The graphics and data take up the majority of the cartridge space, so that would be the first place to explore. The code is pretty good and compact, but there's always room for improvement and any speed improvement would be nice.

 

Although maybe not anything definitive, this is still a good pointer and confirms my hypotheses.

Given his wording and the explanation of the rendering engine, it seems the game has really robust optimizations, and it seems that while further optimization in terms of code is possible, it may not net the major gains I was hoping for. Given that the game runs at an average of 9.5 MIPS, it takes 950,000 cycles to draw one frame on average, which is quite large but seems it could be improved, I feel maybe a 10% performance increase at most, which is like, 1 more fps.

 

However, one thing that is extremely possible is getting more consistent framerates and responsiveness. Time will tell, but I'm not too hopeful for any major leaps in performance. Again, the game can still be greatly improved with hindsight, optimizations, general tweaks, and community feedback.

Share this post


Link to post
2 hours ago, InDOOMnesia said:

@lunaark So does that mean there will be a second interview video with him?

What's more, is if this will also make the source code release much closer than we're expecting it to be. Of course, he still has to take care of copyright stuff before doing so, but I'm crossing my fingers in this case.

 

Also, this doesn't mean much, sorry. CacoTube simply still has Randy added, and just forwarded my question. However, Randy did mention that it is coming soon enough.

Share this post


Link to post
2 minutes ago, lunaark said:

Also, this doesn't mean much, sorry. CacoTube simply still has Randy added, and just forwarded my question. However, Randy did mention that it is coming soon enough.

It's okay. Glad to get to know some more stuff about the SNES port from the programmer himself. And I sure still hope he delivers when that time comes.

Share this post


Link to post

A bit of interesting legalese from the back of the US SNES Doom box in the bottom right hand corner states:

 

Quote

For this particular version of Doom was developed by Sculptured Software Inc. which owns the copyright to such Software Program but not to any Audio-Visual elements or Images or Screen Displays generated by the program.

 

In other words Sculptured Software owned the copyright to the game engine but to nothing Doom related that the engine generates. Sculptured Software was bought out by Acclaim right after the release of SNES Doom in the fall of 1995, and Acclaim themselves went bust in 2004 liquidating all their assets after bankruptcy. I only hope that Randy doesn't need to cut through too much red tape to get the engine out, although it sounds like he has everything sorted out if he's saying the release is coming soon.

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

×