Re: Digital Foundry Retro Doom port comparison
Posted: Tue Oct 03, 2017 7:19 am
I wonder if the Super FX chip really is better than the SA-1 for this game. The SA-1 can do character conversion DMA.
NES Development and Strangulation Records message boards
It can also execute at nearly full speed from ROM, and has a real divider (MMIO, but it's much better than the S-CPU's divider, and it beats the Super FX's divide-by-two instruction and cumbersome lookup table access). It also supports 8 MB of ROM, vs. the Super FX's 2 MB (yeah, you can add CPU ROM, but that's only useful for stuff the Super FX doesn't need to know about).psycopathicteen wrote:I wonder if the Super FX chip really is better than the SA-1 for this game. The SA-1 can do character conversion DMA.
What? Every emulator supports the SA-1. It's not accurate, but it's there. And as for it being expensive, every game that used it appears to have used it primarily as copy protection, or possibly as aap9 wrote:Possibly. But SA-1 is expensive, and few emulators support it.
That sounds like what the Super FX does for its automatic overhead-free checkerboard dither. I've abused the dither feature to get two pixels out of a single ROM read when drawing unscaled 2D graphics. Of course, since the COLOR register is 8-bit, dither only works for 4bpp or lower...ap9 wrote:I remember a while back stepping through the Mac version of Doom in a debugger to discover a horizontal technique to render more than one pixel at a time by storing two 16 bit portions in a 32 bit register, for the low-res. mode. This method, of course, is not conceivable on a 16 bit system.
How necessary is that precision, though? If you're using a 32-bit CPU, it would seem natural to use 32-bit operations.DOOM uses a lot of 32 bit math (esp. fixed point math); a proper port of Doom to SNES would be pretty slow in software because of the 16 bit limit.
You sure about that? I was pretty sure no C compiler existed for the Super FX. Leaving aside the fact that it was something of a niche market, the chip is weird enough that it might actually be worse for C than the 6502.The engine Williams Entertainment used was maintained mostly in C, so there was plenty of room for performance improvements.
At the time I was reading up on more exotic implementations for expansion chips (e.g., non-PC emulators). I should've used the word 'fewer' in regards to the general scope… yes, all popular SNES emulators support SA-1. However, 'few' would still apply to completeness and accuracy; bsnes is the first (and still relatively new) to use low-level reverse engineering for expansion chips, whereas most emulators cannot be expected to even work with lesser known operations. SuperFX is better known.93143 wrote:What? Every emulator supports the SA-1. It's not accurate, but it's there.ap9 wrote:Possibly. But SA-1 is expensive, and few emulators support it.
While precision can be reduced without breaking the game, it wouldn't nearly be an authentic port without all the fixed-point and trig operations a game like Doom uses. Of course, some operations may only need 24 bits or less, and rendering can be scaled down considering a smaller window.On the SNES, we typically find that position can be expressed as a 24-bit fixed-point number (or a 32-bit number, for data integrity reasons) while velocity is fine with 16 bits. This sort of mixed-headroom math can speed things up considerably versus simply doing everything at 32-bit. It's also basically impossible in C...
Yes, I was referring to the S-CPU side. One of the leading people who worked on SNES Doom said the main level engine was maintained in C, and if optimized in assembly could have increased overall performance by maybe 30%.I can see the S-CPU code being C, but the GSU code would probably have to be assembly.
Okay, that's fair. I've got to say, though, I can't bring myself to care much, particularly since AFAIK nobody is planning to actually do anything about this. The scenario is either "how could SNES Doom have been better" or "how could a better SNES Doom hypothetically be made?".ap9 wrote:most emulators cannot be expected to even work with lesser known operations.
Sure, but are you really going to notice the difference between 1/256 and 1/65536 positional precision? Just the fact that the frame time is a multiple of 1/60 s instead of 1/70 s would make a bigger difference, I'd expect. And the trig would all be precomputed and tabulated.While precision can be reduced without breaking the game, it wouldn't nearly be an authentic port without all the fixed-point and trig operations a game like Doom uses.
No, it would have to be used to do the rendering as well. I'm pretty sure it draws too much current to pair with the Super FX, even if the memory arrangement were compatible, and the S-CPU is too weak to render Doom at a decent speed and resolution.The SA-1 could certainly help as a math co-processor if nothing else.
Wow. The S-CPU side was the bottleneck, then?One of the leading people who worked on SNES Doom said the main level engine was maintained in C, and if optimized in assembly could have increased overall performance by maybe 30%.
Lessee...93143 wrote:dithering on the floors (if it's still necessary to have blank floors with the additional ROM space)
Code: Select all
with R7 add Ry with R8 add Rx getc to R14 merge plot loop plot
Code: Select all
with R7 add Ry with R8 add Rx getc to R14 merge with R14 and Rmask plot loop plot
93143 wrote: ↑Fri Oct 06, 2017 7:03 pmThe idea is to be able to draw in double-wide pixels without having to draw and DMA each pixel twice. The pixels in the graphics data would alternate between line N and line N+1, and by manipulating mosaic and scroll with HDMA you turn this:
I may have been overthinking this. It seems to work fine on my SNES with no mosaic reset at all. All I have to do is shift every other line left by one pixel, and decrement the Y scroll value every two lines. I can do that with one HDMA channel, although in this specific example I didn't.