SNES Doom Source Released! Now What?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 » Fri Jul 31, 2020 4:14 am

I've done a test of the two possible low-detail methods, using a high-resolution phone screenshot I found. I scaled it down nearest-neighbour, forced it into the Doom palette, and posterized it to 15-bit RGB, then ran it through blargg's NTSC filter (with a bit of post-processing to improve the contrast).

doom_128x192_filtered.png
doom_256x96_filtered.png

The first image is with conventional double-wide pixels. The second is with double-high pixels. In this example, it seems like a toss-up, or maybe the double-high approach looks better...

I would expect, in general, that enemies would look better with vertical doubling, while flats would look worse. The effect on wall textures would depend on the viewing angle. Edges at less than 45° from horizontal would look worse, which could be a significant issue since a lot of important geometry is typically viewed that way...

Now I'm wondering what an ultra-low-detail mode would look like... hmm...

doom_128x96_filtered.png

Very Wolfenstein 3D. Also not hard to do at all - just a modification of the mosaic trick to use a 128x96 framebuffer (256x48 internally).

Alternately, you could render it in a linear bitmap (eliminating the wall recopy step and the row interleaving) and use the result as a tilemap for Mode 7, with each tile consisting solely of the CGRAM index matching its tile index. If my calculations are correct, this barely works without tearing if you use VRAM HDMA, implying that the Super FX would have to draw the gun. On the other hand, it's easy to render and there's plenty of spare DMA bandwidth even at 30 fps... not that I expect the rest of the engine to be quick enough to hit 30 fps, even if the rendering could...

User avatar
Nikku4211
Posts: 67
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Fri Jul 31, 2020 12:23 pm

93143 wrote:
Fri Jul 31, 2020 4:14 am
I've done a test of the two possible low-detail methods, using a high-resolution phone screenshot I found. I scaled it down nearest-neighbour, forced it into the Doom palette, and posterized it to 15-bit RGB, then ran it through blargg's NTSC filter (with a bit of post-processing to improve the contrast).

The first image is with conventional double-wide pixels. The second is with double-high pixels. In this example, it seems like a toss-up, or maybe the double-high approach looks better...

I would expect, in general, that enemies would look better with vertical doubling, while flats would look worse. The effect on wall textures would depend on the viewing angle. Edges at less than 45° from horizontal would look worse, which could be a significant issue since a lot of important geometry is typically viewed that way...
Yeah, double high looks better, as Doom is all about columns. I would happily take <45 angles looking worse if the overall game runs better.

And maybe ultra-low would be tolerable as well if, again, the game runs better than low-tall.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 » Fri Jul 31, 2020 2:58 pm

Double-high might be easier to render and thus slightly more performant, because the framebuffer format is simpler, although it's the same number of pixels.

However, I'm not convinced it would look better overall. It depends on the material. Like I said, a lot of the edges in this game are at less than 45° when it's most important, and flats will pretty much always look better with more vertical resolution. Behold:

doom2_128x192_filtered.png
doom2_256x96_filtered.png

In this case, pretty much everything except the cacodemons' horns looks better in double-wide. And yes, I know this is Doom 2, but it's an illustrative example nevertheless.

If this re-port ever gets made, it may need to use a smaller font for the graphics options...

User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Re: SNES Doom Source Released! Now What?

Post by Señor Ventura » Fri Jul 31, 2020 4:37 pm

93143 wrote:
Fri Jul 31, 2020 4:14 am
On the other hand, it's easy to render and there's plenty of spare DMA bandwidth even at 30 fps... not that I expect the rest of the engine to be quick enough to hit 30 fps, even if the rendering could...
If the engine couldn't afford 30 fps, may be the best option could be to level up the graphic solution, i think (more real resolution at less fps).

A question, Why 128x96 framebuffer is lower horizontally, but higher vertically than 256x48 (internally)?.

93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 » Fri Jul 31, 2020 5:39 pm

Señor Ventura wrote:
Fri Jul 31, 2020 4:37 pm
If the engine couldn't afford 30 fps, may be the best option could be to level up the graphic solution, i think (more real resolution at less fps).
That depends on how the tasks are partitioned between the S-CPU and the Super FX.

Right now, basically everything runs on the Super FX except basic system I/O. In this model, the less time you spend rendering, the higher your frame rate. But if the render time is reduced so much that the non-rendering parts of the engine start to take a large fraction of the total compute time, further reducing rendering time has a diminished benefit, and it may be worth it to take a modest frame rate penalty in exchange for better graphics.

I do not yet know if it's feasible to run enough of the engine on the S-CPU to allow the level data to be moved from Super FX ROM to CPU ROM (effectively removing the GSU's ability to help with certain tasks). If it is, then the speed with which the S-CPU can complete its allotted tasks determines the maximum frame rate, beyond which no render time savings matter at all. In this model, the smallest and/or lowest-resolution display that can reliably keep up with the S-CPU is the limit of performance tuning, and there's no point going any further.

Obviously both of these scenarios lack hard numbers attached to them at the moment. I hope to eventually be able to get deeper into Randy's code and figure out exactly how intensive the calculations are and how fast the S-CPU could reasonably do some of them...
A question, Why 128x96 framebuffer is lower horizontally, but higher vertically than 256x48 (internally)?.
Because of how the mosaic trick works. The original idea was for 2x1, or double-wide, pixels, and the way it worked was that it took a single 8x1 tile sliver in VRAM:



and converted it into two double-wide 4x1 slivers stacked on top of one another in the video output:

▄▄▄▄▄▄▄▄
▀▀▀▀▀▀▀▀

The modified version would simply use a different scroll HDMA pattern to also double the pixels in the vertical direction, resulting in:

████████
████████

So basically, when using either variant of the mosaic trick, the input framebuffer has twice as many pixels horizontally and half as many vertically as the output.

Using linescroll for double-high pixels is much simpler and doesn't use mosaic:



In this case, the display height is doubled, but the number of "pixels" in the x and y axes remains the same.

User avatar
Nikku4211
Posts: 67
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Fri Jul 31, 2020 7:14 pm

93143 wrote:
Fri Jul 31, 2020 2:58 pm
Double-high might be easier to render and thus slightly more performant, because the framebuffer format is simpler, although it's the same number of pixels.

However, I'm not convinced it would look better overall. It depends on the material. Like I said, a lot of the edges in this game are at less than 45° when it's most important, and flats will pretty much always look better with more vertical resolution.
Still, I'd take performance over graphics, seeing as how along with graphics, the performance of the original SNES version is one big area where the game was criticised, if we can't mitigate both, we might as well have bad graphics with tolerable performance over good graphics with bad performance.

Gameplay > graphics.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 » Fri Jul 31, 2020 9:57 pm

Emphasis on "slightly". It is the same number of pixels, after all. Gameplay over graphics is all very well to a point, but would you trade 1080p Ultra at 30 fps for 144p Low at 31 fps (even with GSync)? Best not to make any snap judgments before the numbers are in...

I wonder how much of a pain it would be to code all these different rendering modes? I was thinking you could have multiple screen sizes, like the PC does but not as many, and at least two detail levels, perhaps all four. As I've said, I believe it is possible to write a wall renderer to be faster at full resolution than the existing port's wall renderer is at half resolution, and I'm hoping that using the S-CPU as a coprocessor will turn out to be feasible and save a significant amount of time on top of that. Depending on exactly what has to go in VRAM, it looks mildly likely that 224x192 with a full-resolution 224x160 viewport could work without tearing at up to 20 fps by using VRAM HDMA (again, that's DMA-wise and VRAM-wise; I make no claims about the frame being ready that fast).

So the options might (in the extreme case) look like:

Resolution:
- Low - 216x176
- Med - 224x192
- High - 240x208 (low-detail only)
- Max - 256x224 (low-detail only)
Detail Level:
- high-detail (1x1)
- low-detail (2x1)
- low-detail (alt) (1x2)
- ultra-low-detail (2x2)

The obvious default would be Medium size with high-detail mode, but that also happens to be the one most likely to have performance issues...

Obviously this is all predicated on achieving a sufficient performance improvement over the existing port. Higher resolution and larger frame size are useless if you're getting 6 fps in an empty room...

User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Re: SNES Doom Source Released! Now What?

Post by Señor Ventura » Sat Aug 01, 2020 8:47 am

Do wolfenstein 3D use 2x2 pixels of detail level?, i wonder if it admits any improvement.

What about to intercalate null scanlines instead of doubling pixels horizontally or vertically?. It could get some perfomance improved, and a better aspect visually.

And is left to know if the PPU1 multiplicators are used too.

creaothceann
Posts: 230
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: SNES Doom Source Released! Now What?

Post by creaothceann » Sat Aug 01, 2020 11:06 am

Señor Ventura wrote:
Sat Aug 01, 2020 8:47 am
What about to intercalateinterlacing null scanlines instead of doubling pixels horizontally or vertically?
I'm pretty sure vertical doubling is easy to accomplish, perhaps easier than blanking every other line.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SNES Doom Source Released! Now What?

Post by tepples » Sat Aug 01, 2020 11:39 am

93143 wrote:
Fri Jul 31, 2020 2:58 pm
and flats will pretty much always look better with more vertical resolution.
Flats in Doom for Super NES are actually flat. Do the PC ports have an option to turn off textured flats?

The other option is to render only even scanlines or only odd scanlines, alternating from one frame to the next. (The poor man's bob interlace.)

User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Re: SNES Doom Source Released! Now What?

Post by Señor Ventura » Sat Aug 01, 2020 12:38 pm

creaothceann wrote:
Sat Aug 01, 2020 11:06 am
Señor Ventura wrote:
Sat Aug 01, 2020 8:47 am
What about to intercalateinterlacing null scanlines instead of doubling pixels horizontally or vertically?
I'm pretty sure vertical doubling is easy to accomplish, perhaps easier than blanking every other line.
But you can get a lot of bandwidth, and may be the image turns more definited than doubling pixels vertically.

93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 » Sat Aug 01, 2020 3:21 pm

Señor Ventura wrote:
Sat Aug 01, 2020 8:47 am
Do wolfenstein 3D use 2x2 pixels of detail level?, i wonder if it admits any improvement.
Maybe. It's Mode 7 for a reason - there's no Super FX chip, so the S-CPU has to do everything, and Mode 7 is the only one with packed-pixel data. And there's not a whole lot more room in Mode 7 for higher resolution.

But I looked into it, and it seems like it's being rendered into tile data rather than the tilemap. That's the obvious way to do it, of course, but as I suggested earlier, using the tilemap as a linear bitmap framebuffer, with the actual tiles as pixel colours, might be even easier.

On the other hand, the DMA to VRAM would inevitably waste some time unless the framebuffer was exactly 128 pixels across (it's 112 in the existing port), and that would cut into the benefit from not having to draw into tiles. I wonder if the game could sustain its frame rate if it went to 128x96 (using VRAM HDMA) with tilemap drawing...

I'm sure there's a bunch of stuff that could be improved in Wolfenstein 3D (starting with the audio engine). Apparently Id subcontracted the port, but the subcontractor didn't accomplish anything, and once this was discovered Id basically had three weeks to port it from scratch...
What about to intercalate null scanlines instead of doubling pixels horizontally or vertically?. It could get some perfomance improved, and a better aspect visually.
You mean like this? (Click to view.)

doom2_256x96odd_filtered.png

(I boosted the colours to make up for the darkening effect of blanking half the screen.)
And is left to know if the PPU1 multiplicators are used too.
You're really obsessed with the PPU multiplier for some reason, aren't you?

That's a good point, though; Mode 7 should probably be avoided for Doom if the S-CPU is expected to do fast signed multiplications...
tepples wrote:
Sat Aug 01, 2020 11:39 am
The other option is to render only even scanlines or only odd scanlines, alternating from one frame to the next. (The poor man's bob interlace.)
You mean like this? (Click to view; it's animated.)

doom2_256x192i.gif

Or perhaps like this:

doom2_256x96pi.gif

Keep in mind that the field rate is likely to be no better than 15 fps. Even real 480i can look bad at 60 if it's not filtered... and then there's the fact that you can't look for jumpy pixels to identify enemies if every pixel is jumpy...
Señor Ventura wrote:
Sat Aug 01, 2020 12:38 pm
But you can get a lot of bandwidth, and may be the image turns more definited than doubling pixels vertically.
That's a hilarious way of getting extra bandwidth, especially since you don't really need it at this resolution. Note that at least some Super FX rendering would be necessary to draw the gun, since it can't be done entirely with BG2 due to muzzle flash, and if you blank a scanline, sprites won't render on the following line because OAM scan wasn't done.

User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Re: SNES Doom Source Released! Now What?

Post by Señor Ventura » Sat Aug 01, 2020 5:06 pm

93143 wrote:
Sat Aug 01, 2020 3:21 pm
I wonder if the game could sustain its frame rate if it went to 128x96 (using VRAM HDMA) with tilemap drawing...

I'm sure there's a bunch of stuff that could be improved in Wolfenstein 3D (starting with the audio engine). Apparently Id subcontracted the port, but the subcontractor didn't accomplish anything, and once this was discovered Id basically had three weeks to port it from scratch...
About "tile data" I interpret that the cpu has to calculate and render 10.752 tiles at a resolution of 112x96

And for "linear bitmap framebuffer" i think about 96 simple lines copied twice with 112 doubled pixels.

I don't know if it is easier, but sounds faster.
93143 wrote:
Sat Aug 01, 2020 3:21 pm
You're really obsessed with the PPU multiplier for some reason, aren't you?
It is lately in my thoughts, yes xD

In this case is not so useful since wolf3D is using mode 7 already, but i don't know if doom could benefits more of it.
93143 wrote:
Sat Aug 01, 2020 3:21 pm
That's a hilarious way of getting extra bandwidth, especially since you don't really need it at this resolution. Note that at least some Super FX rendering would be necessary to draw the gun, since it can't be done entirely with BG2 due to muzzle flash, and if you blank a scanline, sprites won't render on the following line because OAM scan wasn't done.
Sorry, i meant this for wolf3D.

With 1x2 of detail the perfomance decreases (224x96 or 256x96), but with null scanlines the image turns like 1x1 of definition, and you recover cpu time (plus doubling the bandwidth).

The only odd thing of this result, is an image with notorious scanlines, but the rest should look great.

93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES Doom Source Released! Now What?

Post by 93143 » Sat Aug 01, 2020 10:10 pm

Señor Ventura wrote:
Sat Aug 01, 2020 5:06 pm
About "tile data" I interpret that the cpu has to calculate and render 10.752 tiles at a resolution of 112x96

And for "linear bitmap framebuffer" i think about 96 simple lines copied twice with 112 doubled pixels.

I don't know if it is easier, but sounds faster.
Tile format in Mode 7 just means that the pixels are in rows of 8, which are then stacked in columns of 8. It means extra calculations to figure out where in WRAM to put a pixel when rendering. Linear framebuffer should be easier, because it's just a single giant stack of 128 rows of 128 pixels each. And it turns out it's pretty easy to trick the PPU into rendering the Mode 7 tilemap as if it were a bitmap (by using 256 different solid-colour tiles and zooming out).

Interleaved bitplane format, used for Modes 0-6, is WAY more complicated and cannot be considered for texture mapping on an unassisted SNES.
Sorry, i meant this for wolf3D.

With 1x2 of detail the perfomance decreases (224x96 or 256x96), but with null scanlines the image turns like 1x1 of definition, and you recover cpu time (plus doubling the bandwidth).
You can't do a framebuffer that large in Wolfenstein 3D.

It doesn't have a Super FX, so you need to use Mode 7 because it's the only one with a data format the S-CPU can render into at a decent speed. And Mode 7 only gives you 256 tiles and a 128x128-tile map, so any way you slice it you can only do ~16K pixels at most.

Also, those scanlines are pretty darn "notorious"...

...

You could do 4bpp graphics by splitting each tile into two colours and packing two pixels into every tilemap entry, like Mega Drive format. This allows you to double the resolution in one axis or the other. But Wolfenstein 3D is a 256-colour game, like Doom, so this would seriously hurt the game's style.

I was thinking that since the Mega Drive version looks decent, 4bpp with doubled resolution might be a feasible approach, since Wolf3D doesn't use its palette nearly as well as Doom does. But it turns out that the Mega Drive version has to use horrible-looking column dither to approximate the palette depth of the game (and speed up rendering, I guess, since you can write two pixels in one shot), so you're not really any further ahead this way...

...

I wonder if Doom could run at a playable frame rate on an unassisted SNES... You'd probably have to use the Mode 7 tilemap as a framebuffer, so the most you could do would be 128x96. Double-digit frame rates would probably be out of reach at any decent resolution, considering how badly the Mega Drive runs Doom (to be fair, he says he's made some improvements)...
Last edited by 93143 on Sun Aug 02, 2020 12:04 am, edited 3 times in total.

Oziphantom
Posts: 861
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES Doom Source Released! Now What?

Post by Oziphantom » Sat Aug 01, 2020 11:34 pm

On a PAL SNES, using Mode7 in colour per Tile mode works pretty well for 3D rendering. You might be able to pair the tiles down to colour combinations in something like DOOM so you could say cut the actual number of bytes you need to DMA in half for NTSC.

Post Reply