New SNES Doom version.

[Señor Ventura]

Cacodemontube has a video: https://www.youtube.com/watch?v=7s7nXiZrBCM

In it, he claims the game hits 30 fps. In the comments he corrects himself, saying that due to SNES hardware limitations it only manages 20 fps, but hits that pretty consistently.

I don't see that. It has been said, of course, that the frame rate will be better in the final version, so maybe he's referring to that. But the 60 fps footage in beavermatic's video seems to almost never drop below four refreshes per frame (although I do think it stays there much more than the original did).

If it's hardware-limited to 20 fps, that implies a full-resolution frame. If the frame were 108x144, either with Mode 7 or the mosaic trick, 30 fps would work fine. So it seems that the full-res dither on floors and ceilings will probably remain.

It occurs to me that if the new Super FX 3 uses faster memory access, the RAM throughput bottleneck for column drawing should be reduced considerably. My clock trick, for example, drops the limit from 80 to 48 master cycles per pixel without overclocking the core, which allows the framebuffer to be filled with textured and lit wall pixels in a little over two VSync periods. Fixing the bottleneck in hardware might allow them to consistently hit the frame rate cap with a full-res frame without relying on intermediate buffering (which probably eats too much RAM on the Super FX side for this engine).

It was discussed before, right?, the super fx2 could manage more than 2MB of rom, Where is the thread with that info?.

I don't recall that being established, unless you're referring to the possibility of using a bankswitching chip. If you mean simultaneously addressable ROM, as far as I know all we have is this description from the GSU pinouts section in fullsnes, which is not terribly conclusive and which I may in any case have misinterpreted:

Code: Select all

 20 ROM./CE
 21 ?       (NC, probably /CE for 2nd ROM chip)
 22 ROM.D7

Really i don't remember clearly, and i don't know all the details, but... something like the super fx2 can manage 16 megabits, and until 48 megabits too, but for another kind of data... i couldn't say what i'd read ^^u


About frame rates... Do it still uses 64 Bytes per tile?... 108x144 are 243 tiles, so, 15.552 Bytes implies something between 20 and 24 fps, not 30fps, right?.

If somebody asks me, i would say i prefer 256x144 with 80 shutted scanlines, and a minimalistic HUD inside the action screen with near 30fps.

[Pokun]

No, I mean that if the same source makes another sound, it cuts off the first one.

In the SNES version, a monster can talk over itself, and it sounds like a bunch of monsters (especially in mono). In the PC version this can't happen.

Oh now I see what you mean. So it's a problem in the SNES version and not a feature.

[93143]

Really i don't remember clearly, and i don't know all the details, but... something like the super fx2 can manage 16 megabits, and until 48 megabits too, but for another kind of data... i couldn't say what i'd read ^^u

You may be thinking of CPU ROM.

The usual ROM in a Super FX game is called Game Pak ROM (which I like to shorten to GPROM), and it's wired to the Super FX. Normally, the Super FX and the S-CPU can't share GPROM; one or the other has to be cut off from it so the other can read it. And GPROM is thought to be limited to 2 MB by the GSU2 pinout, with the possibility of 4 MB if nocash is right about what pin 21 is for.

But it's possible to put up to 6 MB of additional ROM in parallel with the Super FX, so the S-CPU can always read it and the Super FX can never read it. Based on the official memory map labeling, I have referred to this additional ROM as CPU ROM.

This is ideal for Doom, because it's heavily memory-constrained, and while there's a lot of stuff the Super FX needs (textures, rendering lookup tables, level data, GSU code), there's also a lot of stuff it really doesn't need because all it does is go straight to VRAM or WRAM or ARAM (splash screens, music and sound effects, status bar and interface graphics, S-CPU code). The stuff the Super FX doesn't need to know about can be put in CPU ROM, and the S-CPU can handle it. However, it doesn't quite solve the problem; even with this split, the data the Super FX does need still doesn't come close to fitting in 2 MB.

As I understand it, the new enhanced version of DOOM-FX uses 1 MB of CPU ROM for the exclusive use of the S-CPU, in addition to 3 MB of conventional GPROM for the primary use of the Super FX. Assets (and apparently geometry) still had to be cut to make the game fit, but it's better than it was.

EDIT: I was wrong. It's just a chunk of GPROM that only shows up in the S-CPU's address space.

About frame rates... Do it still uses 64 Bytes per tile?... 108x144 are 243 tiles, so, 15.552 Bytes implies something between 20 and 24 fps, not 30fps, right?.

With a 32-line status bar, the active frame is 176 lines high, and on NTSC there are 262 lines total, meaning you can force blank and have 86 lines of effective VBlank (or 85 if you really need sprites on the first active line). With DMA being 165.5 bytes per scanline, that's nearly 14 KB per extended VBlank, which is more than enough to hold 30 fps with a ~15 KB framebuffer.

It's the full-resolution frame that's an issue. 216x144 is of course over 30 KB, which doesn't quite fit in two extended VBlanks even if there's nothing else happening (there is). This limits the game to three VSyncs per frame, which is 20 fps.

Oh now I see what you mean. So it's a problem in the SNES version and not a feature.

Right. It would be better to do it the way the PC version does it. It would sound better and save channels.

[Señor Ventura]

With a 32-line status bar, the active frame is 176 lines high, and on NTSC there are 262 lines total, meaning you can force blank and have 86 lines of effective VBlank (or 85 if you really need sprites on the first active line). With DMA being 165.5 bytes per scanline, that's nearly 14 KB per extended VBlank, which is more than enough to hold 30 fps with a ~15 KB framebuffer.

It's the full-resolution frame that's an issue. 216x144 is of course over 30 KB, which doesn't quite fit in two extended VBlanks even if there's nothing else happening (there is). This limits the game to three VSyncs per frame, which is 20 fps.

Maybe it would be something to consider using 4BPP tiles instead of 8BPP. Does the 8BPP color depth should make any difference in this game regarding to 4BPP?.


For me, I would sum the 32 scanlines HUD canvas to the actual 85 forced blank scanlines, and putting the HUD inside the game screen in its minimal status, like the pc version does...






...or even do an HUD with sprites with only 8 scanlines and save 24 more scanlines to force blanking...

24.326 Bytes per frame at 256x144 of effective resolution, getting the highest vertical definition, although with big ugly black bars, but at a loable performance.

-not accurate 39fps at 8BPP.
-guaranteed 60fps at 4BPP.

[Oziphantom]

due to the any wall can be any scale and presented at any angle. You can't design things to only use 16 colours per tile, you would have to put the entire game in 16 colour mode. So you would go from 256 colour on screen to 16 colours on screen and it would look horrible.
Cropping to remove the sprites which would have their own colours gives

Doom16.png

and this does have allowances in the colours for red/yellow/blue doors and for red floor and radio active floors or the sky box.

[93143]

Does the 8BPP color depth should make any difference in this game regarding to 4BPP?.

Yes, Doom really does need 8bpp. The texture and sprite art combined with the lighting just doesn't fly at 4bpp.

The PC version was capped at 35 fps anyway, never mind that nobody's computer could get anywhere near that frame rate on release, so I don't see much point in exceeding 30 fps. Even 20 fps is quite respectable and very playable. Also remember that DMA bandwidth isn't everything; you've still got to actually run and render the game, which is not happening at 60 fps on a Super FX regardless of bit depth.

Also, the DOS version had a 32-line status bar like the SNES version, only with a bit more information due to being 320 pixels wide. You could get rid of the status bar to fill the screen with the viewport, but then you'd have to keep track of your ammo by memory because there was no HUD. I don't know what this Doom II source port nonsense you've posted is...

[Señor Ventura]

I don't know what this Doom II source port nonsense you've posted is...

I've posted the reduced hud as example, not the doom 2 as intention of nothing about doom 2, google doesn't serve to you the perfect image example for every situation.

I thought this would be understatable, but i see is not...


Edit: 60fps potentially, nothing about super fx itself.

[93143]

You sounded like you were trying to sell it as being authentic to the PC version, but with a source port as an example it's not really authentic. The original "real" PC version looks pretty much like the SNES version, just higher-res.

Certainly I see what you're suggesting, but that HUD would be a loss of authenticity, as well as a loss of visible screen real estate (since the whole thing would be framebuffer, the total active area would have to be smaller, even though the framebuffer itself could be a bit bigger). There's an argument for it as an option, I suppose.

I really don't see the point in chasing 60 fps. You have to sacrifice too much to get there, and the compute hardware isn't powerful enough to run the game that fast anyway (probably. I should note that I don't actually know what they've done with the "Super FX 3", but if there's any period authenticity to it at all I don't see this happening). A cap of 30 fps in low-detail mode or 20 fps in full-res mode seems perfectly adequate.

[SNES AYE]

due to the any wall can be any scale and presented at any angle. You can't design things to only use 16 colours per tile, you would have to put the entire game in 16 colour mode. So you would go from 256 colour on screen to 16 colours on screen and it would look horrible.
Cropping to remove the sprites which would have their own colours gives
Doom16.png
and this does have allowances in the colours for red/yellow/blue doors and for red floor and radio active floors or the sky box.

Isn't the Pico-8 version of POOM running in 128x128 resolution and 16 colours, I think:

https://www.youtube.com/watch?v=WxDqsAI35iw

I don't know how the guy that pulled off POOM managed it, but it looks kind of pretty to my eyes in its own limited way.

I wonder if SNES would be able to get something like that in 4bpp mode, not that I thought you could even run SNES Doom in 4bpp. Doesn't it use Mode 7, which I just assumed was stuck in 8bpp mode, or is that Wolfenstein 3D on SNES?

Regardless, I have no idea what the best approach would be do push SNES Doom even further, especially if the "FX3" is also being considered as an option too, but I was just curious about the colours there.

[93143]

I don't know how the guy that pulled off POOM managed it, but it looks kind of pretty to my eyes in its own limited way.

"Limited" is the word. The whole game has been redesigned around that colour palette, and it still looks cramped. Very little blue and no green, as far as I can tell, and all the subtleties of the original Doom palette (which wasn't very subtle, but you know what I mean) are basically gone. It almost looks like the whole thing is on a single gray-red-orange-yellow run.

I wonder if SNES would be able to get something like that in 4bpp mode, not that I thought you could even run SNES Doom in 4bpp. Doesn't it use Mode 7, which I just assumed was stuck in 8bpp mode, or is that Wolfenstein 3D on SNES?

No, the existing SNES port uses Mode 3, and just PLOTs each pixel twice. This is how it can do full-res dither (Mode 7 doesn't support a frame size large enough) and one reason why it's so slow (Doom draws stuff in columns a lot, and PLOT doesn't handle columns well due to the nature of SNES CHR format). Wolfenstein 3D (which doesn't have a Super FX) uses Mode 7 so the S-CPU can render into the format quickly, and blows it up to 2x2 so the relatively small framebuffer can more nearly fill the screen.

Regarding 4bpp Mode 7, the fun part about Mode 7 is that you don't have to display it 1:1. This means that you could in principle use the tile-as-pixel-pair trick for this, making each tile be made out of two 4x8 (or 8x4) solid-colour blocks and setting the matrix to display each tile as two adjacent pixels. Using the whole tile pool gives you 16 colours, using the whole map gives you a max frame size of 256x128, and now you just have to render your game to the tilemap in packed-pixel 4bpp. This is of course more complicated for the programmer than either PLOTting to CHR or STBing to a linear bytemap, and thus probably slower than the latter.

Note that if you're doing tile-as-pixel-pair, whichever axis needs more than 128 pixels is the one the tiles need to be oriented in, meaning you still can't draw columns cleanly without reading and blitting (unless you're doing low-detail mode at 108x144 or something). Or you could do pseudo-256-wide like Mega Drive Wolfenstein 3D, where you just render whole bytes and they appear as pairs of 4-bit pixels, but that's ultimately an attempt to fake 8bpp via 1D dither and has no advantage versus real 8bpp.

[mannes]

I have some mixed feelings about this, why couldn't they do a 6-8mb cart in the year 2025? It looks like the logos, which do look amazing but appear to take up some valuable cart space, are getting in the way of some extra stages or textures. Also pretty sure LRG uses eeproms that are prone to failure unlike mask roms, hopefully I'm mistaken about that. Is he modding a back stock of sfx chips to run at a higher clock than the sfx2? If so why not just go all the way and make something that could handle sigil? Well neat to see an almost official re-release anyway, wish more developers did this. If only Konami would do this with Dracula X.

[93143]

I doubt the intro logos are competing for space with the levels and textures.

Remember, this game uses 3 MB for the Super FX and 1 MB of additional memory for the S-CPU. This means either CPU ROM in parallel with the Super FX (so the Super FX can't use it anyway and it doesn't take up GSU address space) or MSU1 storage (which the Super FX can't use anyway and which doesn't take up GSU address space). In either case, including something in the additional ROM doesn't take anything away from the storage available to the Super FX for levels and textures*.

EDIT: I was wrong, but the conclusion kinda stands... The way the "Super FX 3" works is apparently that there's 4 MB of GPROM, but the GSU can only access 3 MB of it; only the S-CPU can access all 4. From the sound of it, I expect this means that when the GSU is running, nothing can access that last MB...

Super FX 3 currently only exists as an FPGA implementation, on the FXPak Pro as it seems. They may go with another approach for the final production run, but ripping old Super FX chips out of games and overclocking them is unlikely; it's wasteful and expensive because you have to buy and destroy a bunch of games. I wouldn't do it for more than a couple of prototypes even if I were using a completely stock GSU2 (which I am...).

I've heard things that suggest this may not be the last attempt they make. Certainly there's more that could be done in principle. I myself have been conceptualizing a re-port from scratch that leans hard on CPU ROM plus 30 years of reverse engineering and hindsight (and the lack of tight deadlines) to allow a completely new engine with potentially much better performance. And there's still an open technical question about the GSU2 that may allow more GPROM than even this new version uses.

* unless you're operating under a total ROM size constraint where using more CPU ROM means you have to use less GPROM, which would be odd and has no technical justification.

[mannes]

Super FX 3 currently only exists as an FPGA implementation, on the FXPak Pro as it seems. They may go with another approach for the final production run, but ripping old Super FX chips out of games and overclocking them is unlikely; it's wasteful and expensive because you have to buy and destroy a bunch of games. I wouldn't do it for more than a couple of prototypes even if I were using a completely stock GSU2 (which I am...).

Dear Lord I hope not! It's already difficult to locate an old cart at a reasonable price. I can't imagine why that would be the case in a world where Famicoms out price smart phones despite smart phones being at least a thousand times more powerful. A 2015 smartphone in 1990 would sell for an easy million, funny how Nintendo manages to keep thier classic products deflation proof hopefully will stay that way.

Remember, this game uses 3 MB for the Super FX and 1 MB of additional memory for the S-CPU. This means either CPU ROM in parallel with the Super FX (so the Super FX can't use it anyway and it doesn't take up GSU address space) or MSU1 storage (which the Super FX can't use anyway and which doesn't take up GSU address space). In either case, including something in the additional ROM doesn't take anything away from the storage available to the Super FX for levels and textures*.

If the gsu2/3 is capped at 3mb, this would definitely explain the restrictions and why an extra episode was added but not other textures. I was also thinking it would explain why they are going with a "sfx3" that may just be a back stock of extra sfx chips laying around in iD's vault from 1994. That could explain why they might be clocked higher but still stuck with a 3mb gsu rom limit, although I thought the gsu could theoretically read up to 4mb as I read that 2mb was its readable limit. Although again, if gsu ram is a thing, I can't remember off hand what its specs claimed in the manuals, but if it could support enough ram I don't quite get why they don't move bank rom into gsu ram at the beginning of a stage and use that buffer to cover any extra rom space the gsu can't read. Although I guess the gsu ram is probably already tapped out.

Hopefully they can just fabricate a new chip altogether, would be nice to have a few GHz that the snes can talk to. Probably dreaming on that one though. But maybe I could finally play Crysis on the snes at 20fps in 256 colors... No, it wouldn't make a lot of sense. Yes, I would bother purchasing it just for the novelty.

Certainly there's more that could be done in principle. I myself have been conceptualizing a re-port from scratch that leans hard on CPU ROM plus 30 years of reverse engineering and hindsight (and the lack of tight deadlines) to allow a completely new engine with potentially much better performance. And there's still an open technical question about the GSU2 that may allow more GPROM than even this new version uses.

There are a lot of things I really wanted to see on the SNES and this was one of them: a full engine rebuild to do what was possible instead of what we got. I think what they did on release was great for the time, as kids often dont know better, but it's really frustrating to see Nintendo repeatedly opt for expensive special hardware that is needlessly gimped. I don't recall exactly what the sfx uses but I thought it was a MIPS r3000 just like the Playstation except at 16bits instead of 32 and a lower clock speed, so why the gsu wasn't built to access at least 16mb of memory and being confined to 2mb never made any sense. I know mapping hardware could be used to drum up whatever the gsu needs for rom, so I guess it's not a total limitation but it sure does make things difficult. Still I wanted to see this get a full re-port and hopefully find a way to include missing enemy animations from side angles, higher quality music that isn't so BRR'ed, more textures, extra features, sram saving, etc. Would be nice if they could essentially include plutonium but for the snes.

[93143]

although I thought the gsu could theoretically read up to 4mb as I read that 2mb was its readable limit.

All the official sources say 2 MB. No game exceeded that. There's an unused pin on the GSU2 that nocash thought was probably an additional chip select, which I interpret as meaning it could double the max ROM by effectively adding a bit to the address, and the fact that the 2 MB ROM appears twice (mirrored) in the SNES memory map supports this idea. However, this is unconfirmed.

A ROM limit of 3 MB is a bit weird. You could do it with a 20-bit address and three chip select pins, but why? Maybe they're just playing a little too hard into the "Super FX 3" shtick...

Although again, if gsu ram is a thing

Where do you think the Super FX puts its framebuffer and working memory? But it's capped at 128 KB for the GSU2, and is quite slow to read (not to mention it shares a bus with the PLOT circuitry), so it's not particularly useful for making up large amounts of missing GPROM.

Using RAM instead of ROM for the Super FX's ROM is certainly possible. I believe some devcarts did this. The Super FX wouldn't be able to write it (the instruction set doesn't support writing to the ROM bus), but the SNES certainly could. I've referred to this concept as "U-ROM", or Updateable ROM. In the extreme case, an MSU1 could provide all the data you could ever wish for... but it loses something in the authenticity department regardless, as megabytes of SRAM or hidden-refresh PSRAM would have been quite expensive at the time.

The original DOOM-FX used 64 KB of GPRAM, and it was so full that the framebuffer had to be rendered 1/3 at a time and transferred in between because there was no room left. This is yet another reason why running more of the engine on the S-CPU might be good if it could be pulled off, because it has 128 KB of WRAM that could take some of the load off GPRAM. It would be ideal to be able to double buffer the whole frame in Game Pak RAM.

I think what they did on release was great for the time, as kids often dont know better

It was pretty great, and not just because kids didn't know better. Development was constrained in several ways, from availability of hardware information to tight scheduling to a limited cartridge design. There are lots of ways the game could potentially have been optimized, but some of them require more hardware knowledge than anybody had back then, most of them require more memory on the cartridge, and all of them require more development time. Randy himself stated he was working on a better compression technique for textures, but he had to ship in time for Christmas.

Also keep in mind that as aeronautical engineers say, a paper airplane (i.e. a concept design, a plane that exists only on paper) always flies better than a real one. I get enthusiastic about the incredible performance and feature richness and lack of jank boasted by my hypothetical re-port, but DOOM-FX is the one that actually exists. The rubber has met the road, and we know the result. Don't count your chickens before they hatch...

I don't recall exactly what the sfx uses but I thought it was a MIPS r3000 just like the Playstation except at 16bits instead of 32 and a lower clock speed

Nope. The Super FX was a completely custom processor made by Argonaut and optimized for rendering (the MERGE instruction is pretty obviously intended for texture mapping, not to mention that the chip is basically built around the PLOT instruction). It may have been the ancestor of the ARC series, but it definitely didn't borrow a core from MIPS.

You may be thinking of the Nintendo 64, which used R4000-based cores (two generations ahead of the R3000) at much higher clock speeds than the PSX.

[mrmxy]

Sad, but 100% predictable and understandable, that XBAND support has been removed according to Randy Linden: https://x.com/RandalLinden/status/1821895677196054823 Doom is actually the best working game in the revived XBAND server. (Fun fact: the most recent SNES Doom source code release contains the XBAND toolchain for SNES, which could be used to enable support for more than just the three games working right now.)