Super DOOM - Chocolate DOOM on Super NES

[tepples]

With forced blanking, you could get 261 - 200 = 61 lines, which at 165.5 bytes per line equals 10095 bytes (ideally; real throughput would be less because of interrupt overhead). This transmits a 256x200x4bpp image (25600 bytes) in three vblanks.

Cut it down to Star Fox size (224x192x4bpp) and you have 65 lines or 10757 bytes of blanking time, which is almost exactly twice the frame buffer at that size (21504 bytes). I seem to remember Star Fox cutting off the bottom 2 scanlines (or thereabouts) of the picture to account for interrupt overhead.

Now try 128x112x8bpp = 14336 bytes, and stretch it horizontally by 2 and vertically by 1.5 to get 168 lines. This gives 261 - 168 = 93 lines or 15391 bytes of blanking time. This allows for two fakery techniques: interlacing to make 1.5 stretch look less bad (alternate lines become 1 or 2 output lines on alternate fields), and filling the left and right halves of each texel with different color values for dithering or Dread engine-style fake detail in the textures.

[93143]

Interesting. Is there documentation about how to do it?

I'd have to write it, unless someone else has picked up my work that I don't know about.

Basically, it all started with a quote from byuu:

I've never once seen a CGRAM write fail. It's just that the PPU can override the address when it is fetching its own pixels, so your writes won't go where you expect them to.

This inspired me to start messing around, and I found that it is indeed practical (for a certain definition of "practical") to trick the SNES into loading colours into CGRAM during an active scanline. You can even do it without the colours showing up onscreen, because (1) DMA to CGRAM seems to reliably coincide with either main screen or subscreen fetches depending on boot alignment (which also means that said boot alignment is detectable by software), (2) it's possible to display either the main screen or the subscreen alone without the other having any visible effect, and (3) the CGRAM fetches happen for both half-dots regardless of whether they're actually needed or not.

The first application was a port of the Fantom Bitmap concept to the SNES:
viewtopic.php?p=164248#p164248
viewtopic.php?p=165303#p165303

Obviously this could easily be made into a fullscreen 60 fps 15-bit RGB video mode - but it would be stuck with quadruple-wide pixels, which is below the threshold of watchability. On the other hand, since (unlike the Mega Drive version) this trick doesn't force the screen blank, there are a few possible ways to use it to create a video mode with a higher horizontal resolution.

1) The one tepples suggested, with a full-resolution 2bpp subtractive mask, resulting in a full-res 4:1:1 video mode. This requires the method above to be modified significantly, because the use of a subtractive mask precludes the hidden-pickup-layer trick, so the colours would just have to go in live (with DRAM refresh coverage preloaded during HBlank). This in turn means that since DMA doesn't align perfectly with the scanline length (it can't - even with a fresh DMA every line, it auto-aligns to a multiple of 8 master cycles since boot), even with timed code instead of an IRQ there's no way to avoid every other line being offset by one dot, and the encoder would have to take that into account.

Projected capability (NTSC):
- 256x224 60 fps quasi-15-bit RGB video with a heavy-duty lossy compressor
- 224x384i (maybe/barely, might have to trim a scanline or two) 60 fps quasi-15-bit RGB video with a fairly simple real-time encoder

Downsides:
- low [pseudo-]chroma resolution (4:1:1) and low luminance mask bit depth (4 levels per 8x8 tile with 8 subpalettes), resulting in artifacting
- DMA timing behaviour results in unavoidable line-alternating chroma layer jiggle
- per the above, stored video encoded with this jiggle pattern in mind would have to be started at the correct moment to not look stupid
- if the frame is too large to transfer the whole luminance mask, you have to use duplicate/stale tiles, making the video lossier and harder to encode
- stored video requires twice as much memory because CPU/PPU half-dot alignment is random at boot on some hardware revisions, meaning whether DMA to CGRAM targets main or sub screen cannot be predicted beforehand, and subtraction isn't commutative so you need two versions of the video


2) The one I and others have referred to as "Super Color" (as a riff on "Mega Color"). The idea is to use a multipalette 4bpp image, and replace up to four full 4bpp subpalettes every scanline. These updates are fully double buffered, being input to a hidden 8bpp layer that uses none of the colours appearing in the display layer on that scanline. The display layer is toggled between two tilemaps every scanline to make the palette buffering work.

I've been unable to find out precisely how Mega Color works, which hampers my ability to design an equivalent scheme on SNES, but I suspect I'm close.

Projected capability (NTSC):
- 232x192 30 fps 4x4bpp per scanline plus 32 kHz stereo BRR streaming, using fancy tricks (if my calculations are correct; I haven't actually tried it)
- 224x192 30 fps 4x4bpp per scanline using otherwise conventional methods

Downsides:
- capped at 30 fps, can't do interlace (unless you want to try a 2bpp version...)
- large data size considering it's technically 4bpp
- encoding is tricky because of the attribute grid


There's also a ~6bpp version of the above that I invented for the Super Game Boy Color (if somebody decides to make one, I want in). It uses a 4bpp invisible pickup layer and an 8bpp display layer, updated at 6bpp. I haven't considered making a generic video mode out of it, because it seems broadly similar in capability to the "Super Color" idea but with more tile data required for a given screen area.

...

Anyway, there are potential methods for doing colour-expansion video modes on SNES. I'm not convinced it's worth it for Doom, but it could be interesting to see somebody try to implement one of these. I hope to try them myself someday once I'm free of the real-life situation that's sucking up all my mental energy, which should happen sooner rather than later, but I wouldn't mind if somebody else did; they've been on my back burner long enough...

Keep in mind that I'm not sure the underlying assumption (CGRAM DMA reliably targeting either main or sub screen after boot) has been tested on every extant model of SNES, so I guess it's still possible it could fail on some version of the hardware...

[93143]

Even if you only display 256x200 8BPP and aim for 30fps, you can't get that speed for 256x200 at 8BPP because the SNES can only copy less than 6kiB per frame

As tepples has pointed out, that's only true if the screen is full height. You can trim scanlines with forced blank and get more time.

However, it is true that 256x200 8bpp is impossible at 30 fps, on either NTSC or PAL. It's also impossible at any frame rate without tearing, because VRAM is too small.

...

Actually, you're not necessarily limited to ~6K per frame even if the screen is full height. If there are no sprites onscreen (and in this application I expect there aren't), you can write to VRAM during HBlank. It requires a multi-channel DMA or HDMA approach. Right at the beginning of HBlank, you force blank, stopping sprite rendering in its tracks and opening VRAM up for writes. The next channel(s) write(s) data to VRAM. Then a final channel turns the screen back on, just in time for BG rendering to start.

According to my tests, you should be able to safely transfer the full possible amount of 24 bytes per scanline with HDMA if nothing else needs HDMA (though you have to watch out for the HDMA bug that can cause DMA failure if you trip it; the workaround is to either use the last HDMA channel for something else (limiting you to 20 bytes per line) or use a word write to $FF to turn the screen on, so as to avoid leaving the B bus address of the last channel at $00. Using regular DMA in an IRQ (or a massive full-screen timed loop) is a much bigger pain and only gets you a few extra bytes vs. HDMA, maybe 29 at most if your timing is very good, which is difficult and expensive if you're using an H-IRQ and the S-CPU is doing anything else at all.

So assuming VRAM HDMA at 24 bytes per line, you could manage 5376 bytes per frame on top of the ~6K you get in an ordinary VBlank. At 20 bytes per line, you'd still get 4480 extra bytes per frame. Trimming the screen reduces the bonus from VRAM HDMA, but increases regular DMA bandwidth much faster. Obviously you have to make sure you're transferring data for a part of the screen that hasn't been displayed yet, or for a part of the next frame that's already been displayed of the current frame...


Some quick calculations suggest that with VRAM HDMA, 216x184 8bpp fits in VRAM if you use scroll instead of BGnSC to switch maps, as long as you don't need to update CGRAM for the new frame (216x182 works if you do), and it's a very comfortable 20 fps on NTSC. The largest ~4:3 frame (on NTSC) with a multiple-of-8 width that can do 30 fps with VRAM HDMA is 200x171, but of course shorter, wider frames will tend to do better because VBlank DMA is still king. On PAL, the sky's the limit - 224x192 8bpp works at 30 fps, including a full CGRAM update, and fits in VRAM.

It's hard to mix this with methods that use DMA to refresh the palette during active display, since if you're within about 12 pixels (I think) of the end of the line when the CGRAM DMA ends, any attempt to run HDMA can cause a rev.1 CPU to lock up. If you watch your cycle budget, you can set up additional channels of regular DMA instead to blank the screen and transfer a bit of VRAM data.

However, VRAM HDMA does play well with the mosaic trick (although you do lose a channel because the mosaic trick needs one). Back when I was trying to figure out how hard you could push a Doom re-port with a better/more expensive Super FX cartridge and no schedule pressure, I calculated that you could comfortably manage 20 fps on NTSC (DMA-wise, not necessarily performance-wise) with a fullscreen display - a screen-spanning low-detail 128x192 viewport above a 256x32 status bar. And I'm pretty sure you could still do 20 fps if you had to update a full 128x224 8bpp display.

EDIT: I was tired last night and forgot that carefully timed DMA between scanlines can be significantly more effective if the screen width is narrowed. But it remains significantly more of a pain to use than HDMA.

[Señor Ventura]

What about an sram clocked to 3,58mhz?.

[Nikku4211]

Anyway, there are potential methods for doing colour-expansion video modes on SNES. I'm not convinced it's worth it for Doom, but it could be interesting to see somebody try to implement one of these. I hope to try them myself someday once I'm free of the real-life situation that's sucking up all my mental energy, which should happen sooner rather than later, but I wouldn't mind if somebody else did; they've been on my back burner long enough...

Keep in mind that I'm not sure the underlying assumption (CGRAM DMA reliably targeting either main or sub screen after boot) has been tested on every extant model of SNES, so I guess it's still possible it could fail on some version of the hardware...

Yeah this definitely sounds like the type of thing that several different SNES models can make or break. If you ever find the time to be able to make a test ROM, I would love to test it on my 3CHIP US SNES.

If anyone else wants to test, if you have an FXPak Pro, it has a system information menu where you can see which revisions your SNES is.
So you don't need to acquire a copy of The Lion King and input a secret code in the options menu (it was BARRY, Barry!) just to see your SNES revision.

As tepples has pointed out, that's only true if the screen is full height. You can trim scanlines with forced blank and get more time.

However, it is true that 256x200 8bpp is impossible at 30 fps, on either NTSC or PAL. It's also impossible at any frame rate without tearing, because VRAM is too small.

...

Actually, you're not necessarily limited to ~6K per frame even if the screen is full height. If there are no sprites onscreen (and in this application I expect there aren't), you can write to VRAM during HBlank.

Actually I don't expect to need to render 200 lines because I think it might be acceptable to not support HUD-less screen size (or source port fullscreen HUDs).
With the 64-pixel-high Doom HUD, you only need to render 136 lines for the 3D view, so the HUD might not even need to be rendered the same way or even need the same background video mode. I don't know if sprites will need to be used there, even for the Doom guy's face.

And I'm still okay with that being 200 lines total including both HUD and gameplay lines. Doom's HUD wasn't made for overscan anyway, so I'd rather have a letterbox where nothing is cut off on a 90s 60hz CRT SDTV than fill more of the whole screen at a higher vertical resolution than vanilla but the game runs worse.
The HUD will have to be redesigned for the lower horizontal resolution (so much of VRAM would probably be taken up anyway that it might not be enough for mode 5 shenanigans) and not be cut off by 90s CRT SDTV overscan either.

Plus if I were making this, I'd still target for 30 FPS as it's closer to vanilla's 35 FPS capped framerate and it'd be impressive enough to not need the more gimped graphics 60 FPS requires.

It requires a multi-channel DMA or HDMA approach. Right at the beginning of HBlank, you force blank, stopping sprite rendering in its tracks and opening VRAM up for writes. The next channel(s) write(s) data to VRAM. Then a final channel turns the screen back on, just in time for BG rendering to start.

According to my tests, you should be able to safely transfer the full possible amount of 24 bytes per scanline with HDMA if nothing else needs HDMA (though you have to watch out for the HDMA bug that can cause DMA failure if you trip it; the workaround is to either use the last HDMA channel for something else (limiting you to 20 bytes per line) or use a word write to $FF to turn the screen on, so as to avoid leaving the B bus address of the last channel at $00. Using regular DMA in an IRQ (or a massive full-screen timed loop) is a much bigger pain and only gets you a few extra bytes vs. HDMA, maybe 29 at most if your timing is very good, which is difficult and expensive if you're using an H-IRQ and the S-CPU is doing anything else at all.

So assuming VRAM HDMA at 24 bytes per line, you could manage 5376 bytes per frame on top of the ~6K you get in an ordinary VBlank. At 20 bytes per line, you'd still get 4480 extra bytes per frame. Trimming the screen reduces the bonus from VRAM HDMA, but increases regular DMA bandwidth much faster. Obviously you have to make sure you're transferring data for a part of the screen that hasn't been displayed yet, or for a part of the next frame that's already been displayed of the current frame...


Some quick calculations suggest that with VRAM HDMA, 216x184 8bpp fits in VRAM if you use scroll instead of BGnSC to switch maps, as long as you don't need to update CGRAM for the new frame (216x182 works if you do), and it's a very comfortable 20 fps on NTSC. The largest ~4:3 frame (on NTSC) with a multiple-of-8 width that can do 30 fps with VRAM HDMA is 200x171, but of course shorter, wider frames will tend to do better because VBlank DMA is still king. On PAL, the sky's the limit - 224x192 8bpp works at 30 fps, including a full CGRAM update, and fits in VRAM.

It's hard to mix this with methods that use DMA to refresh the palette during active display, since if you're within about 12 pixels (I think) of the end of the line when the CGRAM DMA ends, any attempt to run HDMA can cause a rev.1 CPU to lock up. If you watch your cycle budget, you can set up additional channels of regular DMA instead to blank the screen and transfer a bit of VRAM data.

However, VRAM HDMA does play well with the mosaic trick (although you do lose a channel because the mosaic trick needs one). Back when I was trying to figure out how hard you could push a Doom re-port with a better/more expensive Super FX cartridge and no schedule pressure, I calculated that you could comfortably manage 20 fps on NTSC (DMA-wise, not necessarily performance-wise) with a fullscreen display - a screen-spanning low-detail 128x192 viewport above a 256x32 status bar. And I'm pretty sure you could still do 20 fps if you had to update a full 128x224 8bpp display.

EDIT: I was tired last night and forgot that carefully timed DMA between scanlines can be significantly more effective if the screen width is narrowed. But it remains significantly more of a pain to use than HDMA.

Hm, this sounds like a very involve-- OVER 5 KIB MORE WITH HDMA??!?!??!

Okay, how many HDMA/DMA channels does it need?

[93143]

Yeah this definitely sounds like the type of thing that several different SNES models can make or break. If you ever find the time to be able to make a test ROM, I would love to test it on my 3CHIP US SNES.

Huh? This was tested years ago by multiple people, just not (I think) on every single model. The first linked post had the ROM attached.

It's not strictly a test ROM for the described assumption, but it relies on it so heavily that I think it's safe to say that if it works reliably on your SNES through several power cycles, the assumption is correct for your SNES.

Anybody with a 1CHIP/SNES Jr. can hit me up with some results any time...

With the 64-pixel-high Doom HUD

wat

Doom's status bar is 32 pixels high, my dude. Always has been.

I don't know if sprites will need to be used there, even for the Doom guy's face.

I came up with a scheme to run Doom in Mode 7 (using a display method invented by tepples to be able to just dump a linear bytemap into VRAM with no conversion step) at the same frame size and effective resolution as the existing port. Making the double buffering work requires just a touch of VRAM HDMA, and since the guns and onscreen text are sprites it can only really happen during the status bar. I seem to recall satisfying myself that a 100% BG status bar was feasible.

The HUD will have to be redesigned for the lower horizontal resolution

There's already precedent for that...

Hm, this sounds like a very involve-- OVER 5 KIB MORE WITH HDMA??!?!??!

Okay, how many HDMA/DMA channels does it need?

HDMA? All that you can spare. You need three to accomplish anything at all, because you need to turn the screen off and then on again every time. But since each channel is limited to four bytes, the cap is 24 bytes per frame using all 6 remaining channels, with nothing left for anything else that needs HDMA. I usually plan on 20 at most because my daydreams game concepts usually involve HDMA audio streaming.

Regular DMA? Three channels, manually updated, H-position-aligned, and triggered every single scanline for what is probably a prohibitive CPU cost in most circumstances. You can get substantially more additional bandwidth this way if the screen is pillarboxed, because you can start earlier and keep going later.

Oh, and every HBlank you do this on has to be followed by a line with no sprites on it. I can't even guarantee that the sprite layer will vanish; it might actually just glitch, in which case it would have to be windowed or turned off entirely. (I suspect it will vanish, depending on when the line buffer gets cleared.) Getting the full ~5K means no sprites anywhere - which is usually fine for an FMV...

What about an sram clocked to 3,58mhz?.

Why? None of what we've been discussing uses the SNES' internal RAM for anything.

[Señor Ventura]

Why? None of what we've been discussing uses the SNES' internal RAM for anything.

For 6 cycles per Byte transferred. Could be?.

[93143]

Why? None of what we've been discussing uses the SNES' internal RAM for anything.

For 6 cycles per Byte transferred. Could be?.

No, the DMA unit does not work that way. It's locked to 8 master cycles per byte regardless of source memory speed. Very unfortunate.

[regiscaelus]

Why? None of what we've been discussing uses the SNES' internal RAM for anything.

For 6 cycles per Byte transferred. Could be?.

No, the DMA unit does not work that way. It's locked to 8 master cycles per byte regardless of source memory speed. Very unfortunate.

Yes, this is really unfortunate. When I was doing the CPU reverse engineering I was hoping to find something to switch DMA to run faster but it is just not there. The DMA block runs it's own clock at Mclk/8 no matter what.

[Señor Ventura]

What a disapointment, i see why... so, the last opportunity is the snes pal...

[Nikku4211]

Huh? This was tested years ago by multiple people, just not (I think) on every single model. The first linked post had the ROM attached.

It's not strictly a test ROM for the described assumption, but it relies on it so heavily that I think it's safe to say that if it works reliably on your SNES through several power cycles, the assumption is correct for your SNES.

Anybody with a 1CHIP/SNES Jr. can hit me up with some results any time...

If that's the missing model, I unfortunately do not have that.

wat

Doom's status bar is 32 pixels high, my dude. Always has been.

I just misremembered, then. Still, it means that if fullscreen HUD-less and fullscreen HUD isn't supported, we won't have to render a full 256x200 3D view. Instead it'll be 256x168 or something even smaller.

I came up with a scheme to run Doom in Mode 7 (using a display method invented by tepples to be able to just dump a linear bytemap into VRAM with no conversion step) at the same frame size and effective resolution as the existing port. Making the double buffering work requires just a touch of VRAM HDMA, and since the guns and onscreen text are sprites it can only really happen during the status bar. I seem to recall satisfying myself that a 100% BG status bar was feasible.

Tepples invented that display method? I dump linear bytemaps to VRAM with no conversion step myself as well, and I think Jurassic Park on SNES' FPS sections also did the same back in 1993.

Wolfenstein 3D from what I've heard, doesn't do that in its SNES port released the following year(according to Wikipedia).

100% BG status bar probably is feasible, it's just a shame 8BPP backgrounds share colours with 4BPP backgrounds and sprite palettes.
You might need to cram just enough CGRAM mid-screen changes for the Doomguy face and HUD background in order for them to stay not needing 8BPP just to use the right colours that might not already be arranged neatly for 4BPP(not sure how important it is to keep PLAYPAL colour order the same between SNES and DOS vanilla).

The HUD will have to be redesigned for the lower horizontal resolution

There's already precedent for that...

I guess there's two. SNES Doom HUD and PS1 Doom HUD, though SNES Doom is horizontally bordered so its HUD has even less space.

I just hope we'll get a PS1 Doom HUD layout on SNES since PS1 Doom runs in 256px mode anyway.

Hm, this sounds like a very involve-- OVER 5 KIB MORE WITH HDMA??!?!??!

Okay, how many HDMA/DMA channels does it need?

HDMA? All that you can spare. You need three to accomplish anything at all, because you need to turn the screen off and then on again every time. But since each channel is limited to four bytes, the cap is 24 bytes per frame using all 6 remaining channels, with nothing left for anything else that needs HDMA. I usually plan on 20 at most because my daydreams game concepts usually involve HDMA audio streaming.

Regular DMA? Three channels, manually updated, H-position-aligned, and triggered every single scanline for what is probably a prohibitive CPU cost in most circumstances. You can get substantially more additional bandwidth this way if the screen is pillarboxed, because you can start earlier and keep going later.

Oh, and every HBlank you do this on has to be followed by a line with no sprites on it. I can't even guarantee that the sprite layer will vanish; it might actually just glitch, in which case it would have to be windowed or turned off entirely. (I suspect it will vanish, depending on when the line buffer gets cleared.) Getting the full ~5K means no sprites anywhere - which is usually fine for an FMV...

Oh, three channels. That's probably not too bad.

Doom's sampled sound effects are streams of samples with no sequencing, so it makes sense for SNES Doom to stream sampled audio(even if converted to the compressed BRR format the SNES' audio hardware natively expects, which I think would be more worth it to save ROM space anyway).
The channels you'd probably have to worry about then won't just be (H)DMA channels, but S-DSP channels, as it only has 8, some of which will have to be shared with the music.

Doom is a game all about atmosphere, after all. You need to rely on being able to hear all the enemies around you in a first person shooter where you can't see all the enemies around you at once if you're not specifically looking at them.
It's going to be a real gameplay disadvantage if we have to play in mono due to this.

So do we need to choose between HDMA and DMA versions, or do we need to use both for this trick you are talking about? If the former, then I think HDMA might be more worth it than all the weird limitations you'd have to face doing it with generic DMA.

[93143]

Huh? This was tested years ago by multiple people, just not (I think) on every single model. The first linked post had the ROM attached.

It's not strictly a test ROM for the described assumption, but it relies on it so heavily that I think it's safe to say that if it works reliably on your SNES through several power cycles, the assumption is correct for your SNES.

Anybody with a 1CHIP/SNES Jr. can hit me up with some results any time...

If that's the missing model, I unfortunately do not have that.

Go ahead and try it anyway. The more positive results, the better. And if somebody finally runs across a failure, maybe we can diagnose it and figure out a way around it, or alternately conclude that it isn't reliable (the biggest threat right now is the 1CHIP/SNES Jr., unless someone tried it and I forgot, but I expect it'll probably work even on that).

Tepples invented that display method? I dump linear bytemaps to VRAM with no conversion step myself as well, and I think Jurassic Park on SNES' FPS sections also did the same back in 1993.

Not like this, I think. You're probably talking about the tilemap-as-bitmap method, which has issues with this particular application.

Wolfenstein 3D from what I've heard, doesn't do that in its SNES port released the following year(according to Wikipedia).

It uses a different method. Technically there's a conversion step, but it's handled by the VRAM port's address translation and thus doesn't take any CPU time. The only issue is that you have to restart the DMA after every column unless the buffer is 128 pixels high (an issue the tilemap method shares).

But I wasn't referring to either of those methods. Specifically, tepples invented what I call the slant-matrix method, whereby the size of the minor axis doesn't have to be a multiple of 8 and the DMA transfer can be done in one shot even if the major axis isn't 128 pixels. In this case (Doom at 108x144) the major axis has to be over 128 pixels, which is a significant issue for both of the other methods, but with slant-matrix I think it should work fine.

At least, I've been too lazy to try it, but it seems like it should work...

not sure how important it is to keep PLAYPAL colour order the same between SNES and DOS vanilla

Not at all. That's the beauty of the colourmap concept - you can rejigger it to work with literally any palette order. DOOM-FX did this to collect colours for the sprite-based guns and status bar elements.

In fact, you could exploit the slightly lower RGB bit depth of the SNES by consolidating palette entries that end up identical when converted to 15-bit RGB, saving palette space which could then be used to fill in gaps like the too-abrupt pink-beige transition, and/or add non-darkening colours like in Quake, or even just to alleviate colour distribution difficulties with 4bpp elements. You could retain the detail of the original 18-bit textures by setting up the colourmap so that adjacent 18-bit colours that would translate to the same 15-bit colour still behave differently under light level variation (EDIT: though this doesn't work well with the non-darkening colours idea). (Okay, I'm getting too into this. My job does not involve re-porting Doom.)

I don't see why 8bpp shouldn't be used, at least for Doomguy's face, if there's enough VRAM left for it (in my Mode 7 scheme, there was).

The HUD will have to be redesigned for the lower horizontal resolution

There's already precedent for that...

I guess there's two. SNES Doom HUD and PS1 Doom HUD, though SNES Doom is horizontally bordered so its HUD has even less space.

The only part I really miss in practice is the comprehensive ammo display. That could be fixed, though, if you're willing to lose the 'current weapon' icon. That feature is only useful because you push a button to cycle weapons instead of selecting one explicitly like on the PC version, but I don't think it's strictly necessary - I've been playing the PC version with a SNES controller through JoyToKey for a while now, and the only time I mess up is when I reload a save and my selected weapon is out of sync with the keypress cycle. If there was a way to tell JoyToKey which weapon the saved game had loaded, this wouldn't be an issue, and obviously it wouldn't be an issue in a native SNES game.

Here, have a mockup:

super_doom_e1m1.png

...Also, it's not a HUD, because you have to look down to use it.

Also, yes, if you're wondering, I did implicitly posit three offset versions of every red numeral in VRAM, because it looked a bit silly to line them all up on the same 16-pixel grid...

I suppose theoretically you could replace the word "AMMO" with a picture of the weapon, if you really felt it was necessary. It does make it easier to see what you're about to start firing if you're not well practiced...

EDIT2: Or you could temporarily replace the digits of the current weapon's ammo display with a picture of the weapon. You don't need this picture for very long, because the weapon itself is about to show up in the middle of the playfield. And with the comprehensive ammo display on the other end of the sidebar, you don't absolutely need the current weapon's ammo display to show up instantly.

Oh, three channels. That's probably not too bad.

Three channels of HDMA only gets you four bytes per line. You need all eight channels to get maximum bandwidth (24 bytes per line).

With regular DMA you only need three no matter what, because the transfer length is customizable.

My plan for this Doom render mode involved using seven channels (leaving one for audio) for 20 bytes per line, only on the 32 lines of the status bar. According to my calculations, that extra 640 bytes was just barely enough to make the fractional buffering scheme work. Switching from Mode 7 to Mode 3 for the status bar would have had to be done using an IRQ.

The channels you'd probably have to worry about then won't just be (H)DMA channels, but S-DSP channels, as it only has 8, some of which will have to be shared with the music.

That's why if I were doing a fresh port of Doom, I'd want to have the MSU1 as an option for music. Go full throttle making the S-DSP arrangements sound awesome, but give the player the choice of reserving all 8 channels for sound effects if he's not in the mood for S-DSP music appreciation (unless he doesn't own an MSU1, in the hypothetical scenario where it's a 32X-like add-on).

Doom is a game all about atmosphere, after all. You need to rely on being able to hear all the enemies around you in a first person shooter where you can't see all the enemies around you at once if you're not specifically looking at them.
It's going to be a real gameplay disadvantage if we have to play in mono due to this.

I have no idea why DOOM-FX had mono sound effects, but it wasn't due to channel limitations. Each of those 8 channels has separate left and right volume controls, and the values are 8-bit signed. This means each channel can individually pan in Dolby Surround.

The sound was a mess in that port. Poor timing on the music, horrendous timing on sound effects, multiple vocalizations from the same monster all stepping on each other (and on music channels, which often didn't come back right away)... The chaingun and chainsaw were laughable. I think the audio driver was outsourced, like the one in the PC version, and I guess there were issues...?

One thing I've noticed is that in the PC version, a specific monster can only make one vocal sound at a time. The sound of an enemy dying is super distinctive, and the fact that the monster isn't making any other noises that could steal the channel means it tends to sound cleanly. This makes it way easier to tell when you've killed something, especially when it's far away in poor lighting conditions...

So do we need to choose between HDMA and DMA versions, or do we need to use both for this trick you are talking about? If the former, then I think HDMA might be more worth it than all the weird limitations you'd have to face doing it with generic DMA.

Mixing DMA and HDMA with close timing is generally a bad idea because it can trigger the 1/1/1 CPU lockup bug. In this case, I'm not sure how it would help; if what you can do with HDMA isn't enough, just turn it off and use DMA for everything.

[DrAcOFoto]

This is a port of Chocolate DOOM running on the Super NES:

This port is based on Graham Sandersons port for the RP2040: https://github.com/kilograham/rp2040-doom

On a PAL console (because that is what I have at hand), the port is running at 256x200 pixel resolution at about 16 fps. It does not implement double buffering (yet), so there are tears in the screen as it is transfered over 3 frames. There is no scaling of graphics. To fit them, I just crop the frame buffer to the target size.

If I used the original SNES DOOM resolution of 216x144, the game would run at 30 fps on NTSC consoles and 25 fps PAL consoles, needing 2 transfers to VRAM while in forced blanking.

After making a new revision of the cortex-accelerator hardware, DOOM2 now runs on Super NES:
cortex-accelerator - New revision running DOOM2 on Super NES

This is seriously impressive. All news will be exclusively here when they happen, or is there a Discord I can check to read about your progress?

[elseyf]

Thanks. If there are updates, they will most likely be posted here. Although since getting DOOM2 to run on SNES, I have not worked on the project. I still wanted to improve framerate and eliminate tearing. Sound is also missing, but should be possible to get working.