Super DOOM - Chocolate DOOM on Super NES

[93143]

Okay, so it seems if you edit your message that already has a quote from me in it, I get the notification for the new edit to your old message even if the new edit doesn't add a new quote from me.

Good to know. [EDIT439: How many notifications did you get for this one?]

replacing the ammo word with a picture of the ammo

Ammo sprite would probably make it more obvious that some guns share ammo like piston and chaingun sharing bullets, and plasma and BFG sharing cells.

The issue I have with that is that the reason I wanted a picture in the first place was to alert the player to the identity of the weapon he's switching to, before it comes up onscreen and he hastily puts a rocket into the pinky eating his face instead of blasting it with the plasma gun as he'd intended. When weapon switching is just mashing a single button to cycle through your entire arsenal, this is a real risk.

Now, a picture of the ammo does actually solve that specific scenario if the player is paying enough attention. But what it does not solve is getting stuck trying to plink that pinky with the pistol instead of filling it full of lead with the chaingun, or wasting 40 cells on a room-clearing BFG shot in a nearly empty room (and getting chomped while waiting for the gun to fire) instead of taking the monster down with a measured plasma burst.

A picture of the weapon would serve my purpose better, I think, and would probably also fit better in the space below the ammo count if momentarily losing the ammo count itself is unacceptable.

I suppose you could also flash the temporary picture up in the playfield somewhere rather than down in the corner. It'd be easier to see, but it might block important information if it's in a highly visible spot.

Technically you could just extend the status bar to the full width of the screen, but it wouldn't look as nice, and it would emphasize the smallness of the playfield window...

[Nikku4211]

Good to know. [EDIT439: How many notifications did you get for this one?]

Just one. If you actually did edit your message four-hundred-and-thirty-nine times(if so, wow), I guess the notifications are smart enough to only notify me once for any edits I didn't see to a message that already mentioned me.

A picture of the weapon would serve my purpose better, I think, and would probably also fit better in the space below the ammo count if momentarily losing the ammo count itself is unacceptable.

Honestly, if you don't really need to momentarily lose the ammo count because you can already fit the weapon sprite in the 'ammo' text, I don't see why you'd prefer not to try doing so. Unless you're specifically talking about a resized or redrawn weapon sprite that would take an extra effort (and a bit more ROM space) to either downscale in build-time or take even more time to redraw it to make the most out of the smaller resolution of the area the HUD weapon has to work with.

Even without the 'ammo' text, the number being above the weapon is still very obviously whatever ammo is used by that weapon. If you're using ammo and you're playing on a 10" CRT through NTSC composite like I'd prefer to, you'd probably want to read the bigger font even if you can technically read the smaller font through the glasses you might need to wear anyway like me. I don't expect this port to run particularly fast, but if I ever find myself playing a level that gets hectic in a high difficulty setting, I'm probably not going to want to have the ammo digits disappear momentarily even for just a split-second.
I should know, after all, because I play Chocolate Doom and other Doom source ports on PC very often. I'm sure having the 'ammo' text disappear (momentarily or not) would be more acceptable to me on gamepad than having the ammo digits disappear momentarily.

Technically you could just extend the status bar to the full width of the screen, but it wouldn't look as nice, and it would emphasize the smallness of the playfield window...

If your game is bordered anyway, you should probably expect people to play it on some 60hz CRT TVs that might have a smaller safe area than some later 60hz CRT TVs. My CRT SDTV I'm sure has a very big safe area that 256x224 alone will neatly fit in without being cut off, but I know it's a CRT from the mid-2000s, so it's a good bit more advanced than whatever much-older CRTs some people might end up finding in their homes or in Craigslist or some similar website where you arrange physical meet-ups to buy something.

Though if there are any menu/intermission screens that don't need to be bordered, you can probably expect to fill the whole screen, but in that case it'd still make sense to still keep important things within the same title-safe area but allow much less important things to fill the screen outside of the title-safe area.

[93143]

Just one. If you actually did edit your message four-hundred-and-thirty-nine times(if so, wow), I guess the notifications are smart enough to only notify me once for any edits I didn't see to a message that already mentioned me.

No, I edited it several times (as I often do), but not that many.

Thanks for the info. Lots of useful data here...

Honestly, if you don't really need to momentarily lose the ammo count because you can already fit the weapon sprite in the 'ammo' text, I don't see why you'd prefer not to try doing so.

I was trying to think of a way to get it closer to the player's line of sight and make it more obvious. But it's probably good enough underneath the number.

I've noticed that I basically never read the red text that appears at the top of the viewport. It's too far from where I'm looking when I'm playing the game. Similar to TIE Fighter, in which I rarely notice text alerts because the text output is at the bottom of the screen, but unlike X-Wing vs. TIE Fighter and X-Wing Alliance that put the text in the middle of the screen. If I were porting TIE Fighter to SNES, I'd try to put the text in the middle of the screen.

extra effort

Remember, I'm the one who was arguing with Espozo that the graphics for Metal Slug should be rescaled for SNES resolution in the case of a port, rather than just left as is with the effective viewable area being smaller. I was actually willing to try it myself. I'm the sort of person who sees possibilities rather than difficulties.

Rescaling a few small pictures of weapons is nothing compared to the effort of doing the port in the first place. I rescaled the pistol and Doomguy's head (both with substantial manual touch-up, plus re-quantizing the pistol to 4bpp) just for the mockup I posted earlier.

I don't expect this port to run particularly fast

Which port? The one in the thread is on a pretty powerful modern coprocessor and can be expected to be DMA-limited.

A real Super FX re-port from scratch might not be as fast as either OP's work or Randy's Special Edition with its cheaty "Super FX 3", but it could be pretty snappy with a 108x144 viewport (even if there are other options) because when using Mode 7 with the slant-matrix method there's no bitplane conversion required, and the pixel count is low.

A port on the S-CPU could use the slant-matrix method as well, but in that case the game would likely be pretty sluggish...

[creaothceann]

Honestly, if you don't really need to momentarily lose the ammo count because you can already fit the weapon sprite in the 'ammo' text, I don't see why you'd prefer not to try doing so.

I was trying to think of a way to get it closer to the player's line of sight and make it more obvious. But it's probably good enough underneath the number.

I've noticed that I basically never read the red text that appears at the top of the viewport. It's too far from where I'm looking when I'm playing the game. Similar to TIE Fighter, in which I rarely notice text alerts because the text output is at the bottom of the screen, but unlike X-Wing vs. TIE Fighter and X-Wing Alliance that put the text in the middle of the screen. If I were porting TIE Fighter to SNES, I'd try to put the text in the middle of the screen.

iirc Half-Life 2 and the HL2 episodes put the player's health into the left part of the reticle, and the ammo count into the right part.

[Nikku4211]

I've noticed that I basically never read the red text that appears at the top of the viewport. It's too far from where I'm looking when I'm playing the game. Similar to TIE Fighter, in which I rarely notice text alerts because the text output is at the bottom of the screen, but unlike X-Wing vs. TIE Fighter and X-Wing Alliance that put the text in the middle of the screen. If I were porting TIE Fighter to SNES, I'd try to put the text in the middle of the screen.

Having red text at the very top of the viewport is probably not good anyway for a port to a console meant to output to a 60hz standard definition TV due to overscan, but yeah it's probably also good to centre the text for other reasons too. Some PC Doom source ports let you do that I think.

Remember, I'm the one who was arguing with Espozo that the graphics for Metal Slug should be rescaled for SNES resolution in the case of a port, rather than just left as is with the effective viewable area being smaller. I was actually willing to try it myself. I'm the sort of person who sees possibilities rather than difficulties.

I actually don't remember if I've even been on that thread. If I have, that must be a long time ago because I certainly don't remember it.

For a 2D pixel art game like Metal Slug, I think the graphics would need to be heavily retouched if scaled down horizontally. Every graphic is developed specifically for the 320px resolution of the Neo Geo and a good amount of it probably wasn't expected to be scaled down like some sprites often are in other Neo Geo games or like the sprites and textures of first person shooters like Doom.

Rescaling a few small pictures of weapons is nothing compared to the effort of doing the port in the first place. I rescaled the pistol and Doomguy's head (both with substantial manual touch-up, plus re-quantizing the pistol to 4bpp) just for the mockup I posted earlier.

Rescaling a few small pictures of weapons and redrawing them to be readable in the smaller resolution is probably still nothing compared to the effort of doing the port (or demake) in the first place, at least for a somewhat-seasoned pixel artist.

Which port? The one in the thread is on a pretty powerful modern coprocessor and can be expected to be DMA-limited.

A real Super FX re-port from scratch might not be as fast as either OP's work or Randy's Special Edition with its cheaty "Super FX 3", but it could be pretty snappy with a 108x144 viewport (even if there are other options) because when using Mode 7 with the slant-matrix method there's no bitplane conversion required, and the pixel count is low.

A port on the S-CPU could use the slant-matrix method as well, but in that case the game would likely be pretty sluggish...

I mainly mean both a potential Super FX 2 port and a potential fully native S-CPU port as well. The original 1995 SNES Doom on Super FX 2 was infamously sluggish, in addition to flat out having completely different physics due to being made from scratch based on inaccurate reverse engineered information from years before the 1997 Linux Doom source release.

[stan423321]

The other console port developers had access to the original source code. I kinda doubt id would intentionally keep it away from SNES version. More likely it was expected to be of little use because of how the platform was unfriendly towards pointer and struct happy C code.

[93143]

Remember, I'm the one who was arguing with Espozo that the graphics for Metal Slug should be rescaled for SNES resolution in the case of a port, rather than just left as is with the effective viewable area being smaller. I was actually willing to try it myself. I'm the sort of person who sees possibilities rather than difficulties.

I actually don't remember if I've even been on that thread. If I have, that must be a long time ago because I certainly don't remember it.

Yeah, I guess I was being a bit pretentious there. The last post in the thread was before you joined the forum.

For a 2D pixel art game like Metal Slug, I think the graphics would need to be heavily retouched if scaled down horizontally.

Yeah, that was the issue. Just running them through a scaler wouldn't have nice results (though there are tricks that get you the majority of the way there, and a dedicated tool could do even better), and a background layer converted that way certainly wouldn't slot nicely into an attribute grid. Lots of hand touch-up would be required, and Metal Slug has a lot of graphics.

I mainly mean both a potential Super FX 2 port and a potential fully native S-CPU port as well. The original 1995 SNES Doom on Super FX 2 was infamously sluggish, in addition to flat out having completely different physics

Okay, that wasn't clear to me. Theoretically the thread is supposed to be about the cortex-accelerator version.

I do have some potential methods in mind that might get an S-CPU version to a playable speed. The original port suffered from having to draw columns in SNES bitplane format, which is so intensely suboptimal that the result really isn't representative of the speed of the Super FX compared to the S-CPU. (There are possible workarounds, but no one had thought of any of them yet, and all but one would have required a more expensive cartridge.)

A new from-scratch Super FX version with an improved cartridge could offer larger framebuffers and higher resolutions using the mosaic trick and/or intermediate buffering, though a pure Mode 7 linear framebuffer method could be significantly faster. An S-CPU version would be impractical without a Mode 7 linear framebuffer method, so it would be stuck at 108x144 at best for the viewport (that's 216x176 for the whole display, same as DOOM-FX).

The other console port developers had access to the original source code. I kinda doubt id would intentionally keep it away from SNES version. More likely it was expected to be of little use because of how the platform was unfriendly towards pointer and struct happy C code.

Did they? Or did they have access to the Jaguar port's code? It was actually id that developed the Jaguar version, so obviously they had access to the PC version's source code. But in any case it would certainly be helpful to have the source code; when porting between platforms this old you wouldn't ever really care about how the program does things, only about what it does. And the source code is the gold standard for that.

(Also, I'm pretty sure there's never been a C compiler for Super FX, so whether it uses pointers and structs a lot is somewhat beside the point...)

I think what happened was that Randy reverse engineered it on his own, and presented a working demo to id as a fait accompli. Then he (understandably) kept working on that instead of starting over with the Jaguar source. Also remember that the PC version's visplane data alone uses more RAM than the SNES Doom cartridge has installed...

[Nikku4211]

I think what happened was that Randy reverse engineered it on his own,

Gamasutra claims he also used the Unofficial Doom Specs:

To retrieve the assets, he was able to leverage the "Unofficial Doom Specs" by Matthew Fell which explained the .wad lump layout in detail. The sprites, textures, music, sound effects and maps were extracted from DOOM.WAD. The engine was an entirely different story.

Though it seems the specs didn't talk about Doom physics so he had to fill out the rest with either more reverse engineering or pure imagination.
Or Gamasutra just got it all wrong.

[tepples]

And in case of a Wayback Machine outage, "Inside the work to get Doom on the Super Nintendo" by Fabien Sanglard is still on Game Developer (formerly Gamasutra).