SNES Doom Source Released! Now What?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: SNES Doom Source Released! Now What?

Post by Pokun »

Ah that seems to match my memory with the game, especially that strafing was unhelpfully on "." and "," keys, nowhere near the other keys. I think the developers probably had 3 hands.

Well then mouse was used as an alternate way to move in the default controls. With that in mind Romero's statement that "DOOM was made for mouse input" (or whatever exact quote is his) doesn't mean much for the discussion. It certainly doesn't sound like that the mouse was used for turning only or anything that is similar to the modern WASD+mouse style of play. I guess that the makers of the game used the mouse as a crude analog joystick for fine-tuning movement when it mattered, and perhaps switched to back to keyboard when running larger distances or so (or they really had 3 hands).
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES Doom Source Released! Now What?

Post by Oziphantom »

Yep, ok, I'm wrong.
Pokun wrote: Huh? Since when did this change happen? Is this the norm with modern FPS games? Last time I played a computer FPS the mouse were used to look up/down and turn left/right. I guess it was probably the late '90s though.
In that case how do you turn left/right if the mouse is just used to turn the head/aim? Is A and D (WASD keys) no longer used for strafing?
Twin Stick - so one stick moves, and one stick looks/aims. You have a button to switch as per Doom.Normally move is "tank controls" then you switch to "fixed displacement". This way you don't run at the thing you are shooting at, you can aim to the side but keep moving forwards away from the target.
93143 wrote:I guess if your mouse responds to the wobbling of your rickety computer table, or your brother keeps poking it while you're sniping, or something like that, it would be convenient to not have to unplug it every time you want to play Doom...

Ball mice are not susceptible to desk vibrations and only detect angular momentum of the ball rotation.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: SNES Doom Source Released! Now What?

Post by calima »

If your brother keeps poking the table while you play, unplugging him every time does not seem excessive.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: SNES Doom Source Released! Now What?

Post by Pokun »

Oziphantom wrote: Mon Mar 21, 2022 9:34 pm
Pokun wrote: Huh? Since when did this change happen? Is this the norm with modern FPS games? Last time I played a computer FPS the mouse were used to look up/down and turn left/right. I guess it was probably the late '90s though.
In that case how do you turn left/right if the mouse is just used to turn the head/aim? Is A and D (WASD keys) no longer used for strafing?
Twin Stick - so one stick moves, and one stick looks/aims. You have a button to switch as per Doom.Normally move is "tank controls" then you switch to "fixed displacement". This way you don't run at the thing you are shooting at, you can aim to the side but keep moving forwards away from the target.
Oh I see, you mean when playing an FPS with a joypad. Actually I think the controls works very similarly to that when drawing a bowstring in Breath of the Wild as well, in addition to motion controls acting like an alternative to the right thumbstick which is great for fine-tuning the aim.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 »

I sure wish I had a Time Teaser. My failed attempt at Wolfenstein 3D speedcode gave me an idea, and it's a doozy...
Oziphantom wrote: Mon Mar 21, 2022 9:34 pmBall mice are not susceptible to desk vibrations and only detect angular momentum of the ball rotation.
Kinda depends on how severe the "vibrations" are. If they cause the mouse to slide even a little, you've now missed that Imp you were aiming at from across the map, or perhaps launched a rocket into a nearby pillar. Or maybe walked off a cliff, because the mouse moves you forward and backward...

Anyway, my point was that unwanted mouse input is possible in principle, even if only from accidentally bumping the mouse itself, so shutting it off in the game settings is a reasonable option.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: SNES Doom Source Released! Now What?

Post by Pokun »

I agree, besides ball mice can also be quite sensitive, enough to deactivating a screen-saver by bumping the floor near it. I also think some people perhaps overestimates the issues of ball mouse technology.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 »

...so why is the RAM requirement for PC Doom 4 MB while the IWAD is 11 MB? The only thing I can think of that doesn't need to be in RAM for a given level is the data for the other levels, but SNES Doom has most of the levels and it's only 2 MB. And the textures in the IWAD are apparently compressed. Besides, The Ultimate Doom is only about 12 MB despite including a substantial level pack, and it still only requires 4 MB of RAM despite stuff like the Cyberdemon spawning in large, complex levels while a ton of miscellaneous enemies are still around.

What's all that data for?
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 »

93143 wrote: Sat Mar 26, 2022 10:37 pm ...so why is the RAM requirement for PC Doom 4 MB while the IWAD is 11 MB? The only thing I can think of that doesn't need to be in RAM for a given level is the data for the other levels, but SNES Doom has most of the levels and it's only 2 MB.
SNES Doom doesn't have flat textures at all, which are actually stored in raw 8BPP format in the original Doom. This means every flat in DOS Doom is exactly 4096 bytes, no more and no less, since they're all 64x64.

Also SNES Doom only has front sprites for every enemy(and players in XBand multiplayer). There are no sprites for other directions in SNES Doom like there are in the original Doom.

And the HUD graphics, including face, are all converted to the SNES' own 4BPP planar format, rather than kept 8BPP.

The sound effects are all in BRR format in SNES Doom, and further downsampled from there. In DOS Doom, they're raw 8-bit audio, most of which are 11kHz.

So it's clear there were plenty of compromises that allowed Doom to fit in 2 MiB on SNES.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 »

I know all that. But none of that is level data, and it's all stuff that has to be present in RAM to run a level on PC, which means it doesn't explain the fact that the IWAD is 11 MB. Or am I wrong about that, and the game regularly hits up the hard drive for more data?

My question is: what is causing the Doom IWAD to be triple the size of its RAM footprint? The fact that the SNES version has most of the levels means it can't be level data, and the fact that pretty much everything else has to be in RAM to play a level means it can't be anything else. The music is per-level, but MIDI isn't large. The wall textures are bigger in RAM than in the IWAD, because they're assembled from patches.

I don't get it.

Any attempt at a better Doom port for SNES will have to deal with this. If Doom is 4 MB, it's easy. If Doom is 11 MB, we have a problem, because that amount of data will only fit in an EXHiLoROM configuration, which doesn't fit in a Super FX cartridge map. What is eating all that space? And can it be crunched down enough to fit in 8 MB (2 MB GPROM + 6 MB CPUROM) without harming the port?

...

...is it really the textures? Do textures get loaded in based on whether the level needs them, rather than at boot? The whole texture set for The Ultimate Doom is about 3.86 MB if I counted the pixels right, so that's quite plausible - inevitable really - but it doesn't explain the jump in WAD size, particularly since a good number of those textures were used in Episode 1, and also considering that they're compressed in the WAD.

The enemies unique to the non-shareware version are the Cacodemon, Lost Soul, Cyberdemon and Spiderdemon, which apparently total 109,959, 33,703, 351,513 and 458,630 non-transparent pixels respectively; their sizes on disk shouldn't be much more than that because the format compresses transparent runs. All told, the new enemies should take up about a megabyte.

[Apparently the Cyberdemon's graphics, if taken as rectangles and counting blank pixels, total 666,951 pixels. Hmm...]

The plasma gun and BFG9000 appear to take up 57,159 non-transparent pixels combined, including their item sprites. If I've identified their effect sprites correctly, they're an additional 26,125. Absolutely insignificant.

The sound effects are short, and 8-bit 11 kHz audio is less than 11 KB per second. One megabyte of this would be over a minute and a half.

...

I think I can compress flats to a little over half size without much damage to the rendering speed. I can probably get wall textures well below half size, but that's vs. the RAM version, not the compressed patches in the WAD. Sprites are already compressed with a form of RLE, but my wall scheme would probably be significantly better. The sound effects would be smaller by a factor of 9/16 even at full quality, but music would probably have to be bigger because it requires patch sets, which on PC would have been the sound card's problem. As for the level data, improving the game while leaving enough space in GPROM for textures and sprites would seem to require not only storing level data in CPUROM, but perhaps reconceptualizing the game engine so the S-CPU can make a useful contribution to processing, which could end up using more space because the best way to run something faster on the S-CPU is to unroll and precompute everything...

Also, some of the composite textures don't really need to be composite. I could eat the cost of drawing switches separately...

Those texture and sprite numbers do worry me. Even with my compression schemes, the walls might end up between 1 and 1.5 MB at best, and the flats nearly 300 KB. That could eat most of GPROM right there, unless I make sacrifices.

...

Say - does anyone think it would be reasonable to design a cartridge that runs an R/W line around the Super FX, and possibly forks the data lines, to allow the SNES to write to GPROM? If GPROM were actually SRAM, per-level asset loading could be managed by the S-CPU, with the Super FX treating it like ROM. The Super FX can be temporarily locked out of ROM for the transfer, but I don't know if you'd need some sort of signal-preserving switch thingy to prevent writes to GPROM from overwriting the value in the ROM buffer... or perhaps just issue a programming caution that the Super FX should be stopped and restarted when updating its data "ROM" because of ROM buffer invalidation...

This idea would probably require at least a megabyte of the ROM to be replaced with SRAM to really open things up, and that could have been expensive in 1995. If this were done, authenticity would be out the window - the FastROM Super FX clock trick would be a no-brainer, and using the MSU1 to handle up to a few extra megabytes would be on the table as an ersatz hypothetical bankswitching chip (especially since replacing some of GPROM with SRAM directly reduces the total actual storage available in the standard mapping)... I feel like I'd prefer authenticity, even if it costs some texture accuracy.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES Doom Source Released! Now What?

Post by Oziphantom »

Doom needs 8MB of RAM to run so it can't load the whole 11MB WAD into RAM. Don't they hold the entire "episode" worth of data per WAD?

None of the sprites will need 256 colours, so you could easily drop their bit depth and offset the values with proper packed palettes. You will only need one set of music and sound effects. But I think dropping frames is probably your only real path or maybe delta compression and have all entities on the screen use the same frame for either walking or attacking.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: SNES Doom Source Released! Now What?

Post by TmEE »

Doom dynamically loads assets as you progress through the stage, sounds and GFX in particular, causing hiccups on hardware where storage access is slow. It doesn't try to load everything even when RAM is available to do so.
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 »

93143 wrote: Sun Mar 27, 2022 4:06 am I know all that. But none of that is level data, and it's all stuff that has to be present in RAM to run a level on PC, which means it doesn't explain the fact that the IWAD is 11 MB. Or am I wrong about that, and the game regularly hits up the hard drive for more data?

My question is: what is causing the Doom IWAD to be triple the size of its RAM footprint? The fact that the SNES version has most of the levels means it can't be level data, and the fact that pretty much everything else has to be in RAM to play a level means it can't be anything else. The music is per-level, but MIDI isn't large. The wall textures are bigger in RAM than in the IWAD, because they're assembled from patches.

I don't get it.
Looking in SLADE, a WAD editor, all the levels combined only take just under 4 MiB.

All the sounds combined (including PC speaker sounds because I'm lazy) take just under 2 MiB.

All the textures (both patches, sprites and flats) combined take over 6 megabytes alone. And to my surprise, most of the space was taken by the compressed patches, not raw flats, though of course there's more patches than flats in the WAD anyway.

So yeah, it's the textures and sprites that take the vast majority of the IWAD's space.

Fun fact, Doom doesn't use regular MIDI, the IWAD instead uses a custom MUS format that outputs to General MIDI, so it's all even smaller than you'd expect.

Also fun fact, for levels that share the same song, instead of using the same MUS lump, they use duplicate lumps. Granted, sometimes the duplicate isn't exactly the same, but the differences typically aren't audible, and if they are, it's not noticeable to your average gamer(in-game at least).
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 »

Oziphantom wrote: Sun Mar 27, 2022 5:31 am Doom needs 8MB of RAM to run so it can't load the whole 11MB WAD into RAM.
It only needs 4 MB to run. It will use up to 8 MB if it's there.
But I think dropping frames is probably your only real path or maybe delta compression and have all entities on the screen use the same frame for either walking or attacking.
The Baron of Hell is 103,468 non-transparent pixels. The Demon is 86,559 (and the Spectre is 0, of course). The Former Human is 46,338 (or 65,875 including the unused rotations, the use of which would be a weird flex if there were textures missing). The Former Sergeant is 45,106, or 63,731 with unused frames. The Imp is 49,588, or 57,456 with unused frames. Doomguy himself is 49,169, or 87,727 with unused frames.

In other words, the entire bestiary of Episode 1 is smaller than the Spiderdemon.

Level objects (barrels, torches, etc.) seem to be 76,442 non-transparent pixels, unless there are some Doom II sprites in there besides the flaming barrels. Power-up items are 24,534, or 20,601 without the weapons. Weapon and explosion effects seem to be on the order of 50k pixels, although it's not clear how much of this is Doom II graphics, and I may have cut something important...

Gun graphics, including weapon pickup sprites, are 179,878 non-transparent pixels, or 175,947 without the pickup sprites (note the two-pixel discrepancy with my above numbers; take the precision of all these values with a grain of salt). Note that the gun graphics are optional, since in a pinch they can be reduced to 4bpp and loaded directly into VRAM from CPUROM, never touching the Super FX.

If my compression scheme works out, I should be able to fit all of the sprite graphics into less than a megabyte even with the gun graphics included. The textures are the bigger problem, as they take up well over a megabyte in the best-case scenario, and of course there needs to be room for code. But it's still far closer to working than it would be without CPUROM...

I'm assuming here that the S-CPU can preprocess the level data sufficiently that it doesn't need to stuff an entire level into GPRAM, because that's just not gonna fit. The idea is to not have to put level data in GPROM, because that would seriously crowd out any attempt at radically improving the availability of game assets vs. Randy's port.

TmEE wrote: Sun Mar 27, 2022 6:50 amDoom dynamically loads assets as you progress through the stage, sounds and GFX in particular, causing hiccups on hardware where storage access is slow. It doesn't try to load everything even when RAM is available to do so.
Interesting. I wonder if this is what's causing those brief freezes I get playing the DOS version...

I was assuming an action game wouldn't want that to happen if at all possible. I was also assuming that since it was designed to be modded, the obvious way to prevent it would be to just load everything in at once. Clearly this wasn't as important a consideration as I had assumed.

Nikku4211 wrote: Sun Mar 27, 2022 2:48 pmit's the textures and sprites that take the vast majority of the IWAD's space.
Yeah, that's starting to become evident to me.

With heavy compression and removal of unused material, it might be possible to get the texture assets down to not much more than a couple of megabytes. With one extra address pin on the Super FX, this would have been enough.
for levels that share the same song, instead of using the same MUS lump, they use duplicate lumps
I guess with a file format that compact, there was no real need to optimize storage. Still, it suggests a certain attitude toward space saving that might have positive indications for a SNES port.

Were all the textures used? Some of these don't look familiar to me even after a full playthrough. If there are Doom II textures, or textures that are only used in Episode 4, those could be removed too. Also, there seem to be a few flat textures that are just rotations of each other.

If the texturing conventions from the Doom level format were relaxed slightly, it might be possible to do away with a good number of these nearly-duplicate, strictly tiled, symmetric, or obviously patched textures, and just draw the components separately. Like I said in my previous post, I'm sure it wouldn't kill performance to draw switches separately from the walls they're attached to, as long as it doesn't become necessary to draw the part of the wall hidden by the switch... and it is a little silly to store two copies of a big 256x128 stone wall where the only difference is that one of them has blood on the bottom 10 pixels - in fact, I'm not sure a 256x128 stone wall is justified in this scenario regardless of how much blood it has on it; both halves of the texture seem to tile well with themselves...

EDIT: Looks like Randy thought so too, only he's gone even further and quartered it:

GSTONE1_PC.png
GSTONE1_PC.png (34.08 KiB) Viewed 673 times

GSTONE1_SNES.png
GSTONE1_SNES.png (16.01 KiB) Viewed 673 times

...

I've considered special-casing the Cyberdemon and Spiderdemon, since they only show up in boss battles one at a time, and even with my additional compression they'd almost certainly end up eating over a quarter of GPROM with all rotations present. The graphics could be stored in CPUROM instead, and the required cel could be DMAed into WRAM and then up to GPRAM for the Super FX to use. Rendering from a source texture in RAM would be a bit slower, but the frame rate hit would probably be modest if it's just the one monster. It might work, if we don't care about moddability...
none
Posts: 117
Joined: Thu Sep 03, 2020 1:09 am

Re: SNES Doom Source Released! Now What?

Post by none »

Randy's version seems to use run length encoding for the wall textures:

https://github.com/RandalLinden/DOOM-FX ... aww.a#L151

I don't know enough about the super fx but i guess in addition to saving rom, it might be faster than rendering an uncompressed texture (because same colored pixels do not need to be read).

Same goes for objects: https://github.com/RandalLinden/DOOM-FX ... /rldrawo.a

It is interesting that it is drawing the sprites in vertical spans, shouldn't horizontal spans be faster? Maybe there is some optimization in place for avoiding overdraw, but it's still weird...
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 »

none wrote: Mon Mar 28, 2022 4:05 pmRandy's version seems to use run length encoding for the wall textures
I know. I think I can do better.

He thought he could do better; he just ran out of time. I wonder what his idea was...
It is interesting that it is drawing the sprites in vertical spans, shouldn't horizontal spans be faster?
Yes, very much so.
Maybe there is some optimization in place for avoiding overdraw
There isn't. There can't be, unless I've grossly misunderstood the chip I'm building my game around. Every pixel pair he plots requires the entire 8-pixel sliver to be read, modified, and then written, consuming a minimum of 80 cycles due to memory bandwidth limits (8-byte RMW at 5 cycles per access).

I believe there's code that attempts to preemptively trigger a cache flush so the PLOT instruction doesn't stall, or something like that, but the most any mitigation measure could accomplish is preventing the loss of even more time. The memory bottleneck is what it is. As long as you're only drawing (effectively) one pixel per scanline in the inner loop, you're limited to no better than 80 cycles per pixel by the nature of the SNES CHR format.

...

My proposed workaround is to draw to an intermediate bytemap buffer, so the rasterization axis doesn't matter as much. After drawing the whole screen, the intermediate buffer would then be picked up and transformed in bulk to CHR format using PLOT with a far more efficient access pattern. This has the additional advantage that you can do framebuffer effects*, so all the Spectres that Randy replaced with pinkies could be made transparent again.

A further advantage could be gained through the use of a mosaic+scroll trick that allows Mode 3 to display double-wide pixels without the GSU having to actually plot each pixel twice. This improves rendering time somewhat in low-detail mode, and cuts buffer recopy and DMA times in half. It also means that the intermediate and CHR buffers combined take no more space in GPRAM than either one alone would without the trick, and a lot of VRAM is freed, potentially allowing much larger screen sizes. The source format is a bit weird, but with an intermediate buffer it doesn't matter because the renderers don't need to know about it; the only thing that cares is the buffer recopy loop. The only disadvantage is that full-resolution checkerboard dither on floors and ceilings is no longer possible, but with flat textures that doesn't matter either.

Even without an intermediate buffer, the mosaic trick could help a fair bit, since the aforementioned weird source format would allow columns to be rendered at 40 cycles per pixel instead of 80 (though it would complicate floors). But I think I can beat that with an intermediate buffer, even accounting for the recopy step, and there are other advantages.
but it's still weird...
I know why he did the walls that way (I think horizontal could actually be faster with uncompressed textures, even with fully perspective-correct texturing and Z-lighting, but with RLE you have to do the walls vertically), but the sprites...? Perhaps it's just because that's the format the sprites were in, he already had a working draw loop modelled in the wall code, and it would have taken too much time to rejigger everything. Sprites aren't often the dominant rendering load, after all.

It's also possible that re-encoding the sprites for horizontal rasterization would have taken more space. Most of them are taller than they are wide, with probably more gaps per span in the horizontal axis, and with any sort of RLE-related coding the number of runs determines the amount of overhead. DOOM-FX was very space-constrained.


*You can technically read from the CHR framebuffer with RPIX, but it's basically useless for real-time rendering. Just like vertical rasterization, RPIX is horribly expensive, particularly since for coherence reasons it forces a pixel cache flush. This does have a practical application, actually - the manual says to RPIX before calling the SNES to tell it the graphics are ready, because it's the easiest way to guarantee that the framebuffer is up to date.
Post Reply