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.
User avatar
aa-dav
Posts: 91
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: SNES Doom Source Released! Now What?

Post by aa-dav » Mon Jul 20, 2020 1:49 am

Nikku4211 wrote:
Sun Jul 19, 2020 8:59 pm
[Linden]
Oh, thank you for correction. I was on positive emotions, so let it to fingers to write. :)
It's really cool to get in touch with such person!

User avatar
aa-dav
Posts: 91
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: SNES Doom Source Released! Now What?

Post by aa-dav » Mon Jul 20, 2020 9:30 am

New release of binaries! https://github.com/RandalLinden/ACCESS
It's ACCESS toolset and it's for Amiga.
But probably it is the moment this project can be compiled in appropriate environment...

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

Re: SNES Doom Source Released! Now What?

Post by 93143 » Mon Jul 20, 2020 4:15 pm

I mentioned the possibility of a controller+mouse scheme earlier. It has occurred to me that the automap isn't necessarily something you absolutely can't afford to reach across the controller to trigger, so the Select key could be mapped to something else.

How does this look?

Code: Select all

RUN-----          ----STRAFE     FIRE----             ----OPEN DOOR
        \        /                       \     ^     /
       __\___   /                         \  __|__  /
      /,-----'-/-----                      \/_   _\/
     /        /                            /| | | |\
    /    _   /                            / | | | | \
   |   _| |_/   _   _                    |  |_| |_|  |
   |  |_   _|  //  //-----PAUSE       <--|           |-->
   |    |_|    -   -                     |           | \
    \    |      \                        |           |  \
     \   |   ,---\---                     \         /    ----ROTATE
      `--|---     \                        \_______/
         |         \                           |
FORWARD/BACK   WEAPON SELECT                   v----UNMAPPED
Allowing remapping would cover for any problems encountered with a particular playstyle.

...the mouse seems to work in the original port, but the manual says it isn't supported. Could this be because of current draw issues? I know the multitap is globally disallowed for both Super FX and SA-1 because of current draw...

User avatar
dougeff
Posts: 2710
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: SNES Doom Source Released! Now What?

Post by dougeff » Mon Jul 20, 2020 4:48 pm

Has anyone confirmed that the mouse works? I saw a recent video, and the guy couldn't get the (Hyperkin) mouse to work.
nesdoug.com -- blog/tutorial on programming for the NES

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

Re: SNES Doom Source Released! Now What?

Post by creaothceann » Mon Jul 20, 2020 10:19 pm

I'd use the LSB as "walk" instead of "run" so that you don't have to press it all the time.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

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

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Mon Jul 20, 2020 10:42 pm

dougeff wrote:
Mon Jul 20, 2020 4:48 pm
Has anyone confirmed that the mouse works? I saw a recent video, and the guy couldn't get the (Hyperkin) mouse to work.
MVG did say that the mouse doesn't work in the PAL version. I have the PAL Doom ROM, and even though I don't have the SNES mouse, with Mesen-S, I can quickly confirm that the mouse indeed works on it, so it's likely a problem with the Hyperkin mouse itself or possibly the SNES clone he used in the video.
93143 wrote:
Mon Jul 20, 2020 4:15 pm
I mentioned the possibility of a controller+mouse scheme earlier. It has occurred to me that the automap isn't necessarily something you absolutely can't afford to reach across the controller to trigger, so the Select key could be mapped to something else.

How does this look?

[diagram]

Allowing remapping would cover for any problems encountered with a particular playstyle.

...the mouse seems to work in the original port, but the manual says it isn't supported. Could this be because of current draw issues? I know the multitap is globally disallowed for both Super FX and SA-1 because of current draw...
Right on point. That's exactly what I was thinking. Though I'm not too keen on using the mouse to open doors... Oh well, remapping would allow me to fix that.
creaothceann wrote:
Mon Jul 20, 2020 10:19 pm
I'd use the LSB as "walk" instead of "run" so that you don't have to press it all the time.
This. There doesn't seem to be that many opportunities in Doom where you would need the extra precision that walking gives you, and if you're in combat, you'll certainly want to keep running, so autorun should be the default.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

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

Re: SNES Doom Source Released! Now What?

Post by 93143 » Mon Jul 20, 2020 11:36 pm

dougeff wrote:
Mon Jul 20, 2020 4:48 pm
Has anyone confirmed that the mouse works?
I don't have a SNES mouse, but it definitely works in emulation (NTSC version). I think it has to be in Port 1. I can't seem to get the controller to do much of anything at the same time.

It's pretty bad. With nothing but the mouse, all you can do is turn left or right, run forward or back (and not continuously either - player position is mapped to mouse position), shoot, and operate doors and switches. Maybe I'm missing something in the setup...

How would the Super Scope have worked? You'd basically have to have a friend using the controller...
Nikku4211 wrote:
Mon Jul 20, 2020 10:42 pm
Right on point. That's exactly what I was thinking.
Excellent. I don't play shooters on PC, but I keep hearing how great keyboard+mouse is even compared to dual-analog, and it occurred to me that you can basically do that on SNES.
creaothceann wrote:
Mon Jul 20, 2020 10:19 pm
I'd use the LSB as "walk" instead of "run" so that you don't have to press it all the time.
Nikku4211 wrote:There doesn't seem to be that many opportunities in Doom where you would need the extra precision that walking gives you, and if you're in combat, you'll certainly want to keep running, so autorun should be the default.
I'm not carving anything in stone at the moment (in fact I'm not doing much of anything at the moment), but for authenticity's sake (and the fact that in a game with a frame rate this low, fast movement can be a problem), IMHO the default should be what it is with controller alone, and in the PC original - press a button to run. The default walk speed is brisk enough that I had no problem with it even before I realized you could press B to go even faster, and with the frame rate and input lag in this port, the precision issues are serious enough that I usually only run when I've cleared an area and am trying to get somewhere else quickly.

Certainly autorun should be a prominent option, given its history.

Perhaps running would feel better if the input lag were lower. Currently it's about 3 Super FX frames (~18-21 SNES frames) as far as I can tell, and I see no particularly ironclad reason why it couldn't be less than that. Especially if the game were reworked to boost the frame rate...

...

Perhaps the renderer could be modified slightly to allow (optional) fake lookup/lookdown; basically just drawing a vertically scrolled version of a normal frame. There wouldn't be any effect on aiming, but you'd be able to see above and below you more easily, and the mouse's Y axis would have something to do....
Last edited by 93143 on Mon Jul 20, 2020 11:50 pm, edited 1 time in total.

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

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Mon Jul 20, 2020 11:49 pm

93143 wrote:
Mon Jul 20, 2020 11:36 pm
creaothceann wrote:
Mon Jul 20, 2020 10:19 pm
I'd use the LSB as "walk" instead of "run" so that you don't have to press it all the time.
Nikku4211 wrote:There doesn't seem to be that many opportunities in Doom where you would need the extra precision that walking gives you, and if you're in combat, you'll certainly want to keep running, so autorun should be the default.
I'm not carving anything in stone at the moment (in fact I'm not doing much of anything at the moment), but for authenticity's sake (and the fact that in a game with a frame rate this low, fast movement can be a problem), IMHO the default should be what it is with controller alone, and in the PC original - press a button to run. The default walk speed is brisk enough that I had no problem with it even before I realized you could press B to go even faster, and with the frame rate and input lag in this port, the precision issues are serious enough that I usually only run when I've cleared an area and am trying to get somewhere else quickly.

Perhaps autorun would feel better if the input lag were lower. Currently it's about 3 Super FX frames (~18-21 SNES frames) as far as I can tell, and I see no particularly ironclad reason why it couldn't be less than that. Especially if the game were reworked to boost the frame rate...

...

Perhaps the renderer could be modified slightly to allow (optional) fake lookup/lookdown; basically just drawing a vertically scrolled version of a normal frame. There wouldn't be any effect on aiming, but you'd be able to see above and below you more easily, and the mouse's Y axis would have something to do....
I can see that running would be a problem with input lag this bad. My bad.

I don't think you should add Y-shearing (freelook) to the game. Even if it won't affect your aim, I don't want my frame rate to be impacted by rendering more of the top and bottom (which is how Y-shearing works), especially for something like this that the original game wasn't even designed with in mind.

I think it's better for the mouse to have novert. I don't care about authenticity at this point, I just want a good mouse control.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

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

Re: SNES Doom Source Released! Now What?

Post by 93143 » Tue Jul 21, 2020 1:06 am

Nikku4211 wrote:
Mon Jul 20, 2020 11:49 pm
I don't want my frame rate to be impacted by rendering more of the top and bottom (which is how Y-shearing works)
Don't worry. If I ever get around to doing anything with this game, I won't be doing that. I see no reason why a superfluous feature like lookup/lookdown should need a higher frame rate than the rest of the game, so it wouldn't be a matter of rendering extra scanlines - I'd just render the scene with the Y-shear already applied. No extra rendering required. (I think that's how ZDoom does it...)

...

Now, extending the framebuffer in the X-direction... I had considered that as a way to cheaply double the frame rate using the S-PPU's BG scroll ability, based on my observation that low frame rate tends to be more objectionable during rotation than during Z axis motion (forward/back). Since the extra columns would be the last part of the scene rendered, the input would be known (ideally), and thus there would be no "wasted" rendering; the game could restrict itself to rendering the columns that actually need to be displayed.

However, there are significant issues with anything other than rotating in place or while moving forward/back in an empty room. Low frame rate is also objectionable during lateral motion ("strafing"), which this technique can't help with. Circle-strafing, or even lateral motion by monsters and projectiles during player rotation, could look pretty stupid unless the game was very smart about backing off the effect. Notice that these confounding factors occur in the parts of the game that would benefit from high frame rate the most...

Also, mouselook can get pretty quick, and rendering that much extra scene could be a noticeable drain, even using low-detail rendering for the buffer extension. Maybe not enough to lose all the benefit, but more than could be considered a small delta on top of the main load...

Best to just shoot for as high a true frame rate as possible, I guess...

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

Re: SNES Doom Source Released! Now What?

Post by creaothceann » Tue Jul 21, 2020 4:10 am

Perhaps a version without textures could achieve 30 or 60 fps.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

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

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Tue Jul 21, 2020 10:00 am

creaothceann wrote:
Tue Jul 21, 2020 4:10 am
Perhaps a version without textures could achieve 30 or 60 fps.
Perhaps.

But then again, Doom was all about those textures na mean?
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

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

Re: SNES Doom Source Released! Now What?

Post by 93143 » Tue Jul 21, 2020 2:08 pm

I was going to complain that 60 fps at 8bpp is physically impossible without shrinking the display even more, even using low-detail mode with the mosaic trick to halve the size of the framebuffer. But then I remembered that VRAM DMA during HBlank is possible. I think 216x176 with a 108x144 8bpp rendered area could actually work at 60 fps, just based on raw numbers.

...

But I'm not convinced the engine can run that fast. Even assuming the renderer can pull 30 or 60 fps, you've still got the BSP and the collisions and the thinkers... I was hoping for 15 fps at best with the SNES CPU helping out as much as possible with a bunch of lookup tables and optimized speedcode. With a comfortable 15 fps (which is not exactly a hatched chicken at the moment if you know what I mean), you could fake 30 fps with the buffer extension trick, but it would look bad where it matters...

Mind you, I haven't actually looked at what's possible; maybe the whole thing can reliably get done in one or two frames on the S-CPU while the Super FX is rendering - but I kinda doubt it. The frame rate is too consistent in the existing port (which seems to run the bulk of the engine on the GSU); something other than rendering is tanking it. And even on the PC version, rendering was most, but by no means all, of the computational load - maybe 2/3 or so based on the data in the Black Book. Even the Super FX is nowhere near as powerful as a 486, and the S-CPU is in a whole other world of slow...

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

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Tue Jul 21, 2020 2:51 pm

93143 wrote:
Tue Jul 21, 2020 2:08 pm
I was going to complain that 60 fps at 8bpp is physically impossible without shrinking the display even more, even using low-detail mode with the mosaic trick to halve the size of the framebuffer. But then I remembered that VRAM DMA during HBlank is possible. I think 216x176 with a 108x144 8bpp rendered area could actually work at 60 fps, just based on raw numbers.

...

But I'm not convinced the engine can run that fast. Even assuming the renderer can pull 30 or 60 fps, you've still got the BSP and the collisions and the thinkers...
Considering how the original game ran at 35 fps, I wouldn't expect a port like this to reach 60 fps.

I wouldn't mind if it was 25 fps, I doubt most can tell the difference between 25 and 30 without a side-by-side comparison.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

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

Re: SNES Doom Source Released! Now What?

Post by 93143 » Tue Jul 21, 2020 7:41 pm

Why 25? It isn't a factor of 60. You'd be looking at a mix of 2 and 3 refreshes per frame, and it might look uneven (though to be fair, frame time isn't likely to be rock solid regardless of the nominal rate). The original was 35 fps because the monitor refresh rate was 70 Hz.

(I like the "refreshes per frame" metric because it's linear with computational load while being easier to work with than frame time in ms, and you don't have to do any math to determine whether a given rate results in an even frame pace - if it's an integer, it does. It's also easy to directly convert to fps with no averaging - each new frame can be given a frames-per-second value based simply on how long it stays on the screen.)

Right now DOOM-FX is at about 10 fps, or 6 rpf, with drops. According to my testing in bsnes, in sparse areas with nothing happening, it can sometimes hit 12 fps (5 rpf), but it doesn't take much to kick it back down, kinda like how Star Fox runs at 20 fps right at the beginning of the training level if you don't do anything.

I figure rendering tricks could save a frame or two depending on whether or not low-detail mode is used, and handing off a substantial part of the engine to the SNES CPU (with enough fast CPU-ROM to actually make it useful) could save another frame or so - the Super FX has an ideal instruction rate of at least 12 times that of the S-CPU, but it's bad at accessing memory, which is the 65c816's bread and butter. This could mean potentially 15 fps (4 rpf) in full-resolution or perhaps, maybe, 20 fps (3 rpf) in low-detail mode, subject to engine bottlenecks...

With VRAM HDMA, the bandwidth to VRAM is sufficient to sustain 20 fps in 224x192 with a 224x160 buffer (which is about as big as you can fractional-buffer in VRAM along with everything else) or 256x224 with a 128x192 buffer. 15 fps is already better than you'd typically get in a 4-player Goldeneye deathmatch and even some of the missions. I think it may be unreasonable to hope for 20, but anything higher is IMO a pipe dream, even at screen sizes low enough to actually display more than 20 fps. It would be awesome to be wrong...

...

Honestly, if I had to pick between 20 fps with untextured flats and all of the DOOM-FX engine limitations on the one hand, and 15 fps with all textures and an essentially PC-equivalent engine on the other, I'd probably go for the latter. 15 fps is way more playable than 10, and the game was sold at 10.

...what was that I said about chickens and hatching earlier?

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

Re: SNES Doom Source Released! Now What?

Post by Nikku4211 » Tue Jul 21, 2020 11:11 pm

93143 wrote:
Tue Jul 21, 2020 7:41 pm
Why 25? It isn't a factor of 60. You'd be looking at a mix of 2 and 3 refreshes per frame, and it might look uneven (though to be fair, frame time isn't likely to be rock solid regardless of the nominal rate). The original was 35 fps because the monitor refresh rate was 70 Hz.
I don't know. I guess I forgot that it was really a matter of refreshes per frame. And I was talking about in NTSC, not PAL, so this was my mistake.
93143 wrote:
Tue Jul 21, 2020 7:41 pm
I figure rendering tricks could save a frame or two depending on whether or not low-detail mode is used, and handing off a substantial part of the engine to the SNES CPU (with enough fast CPU-ROM to actually make it useful) could save another frame or so - the Super FX has an ideal instruction rate of at least 12 times that of the S-CPU, but it's bad at accessing memory, which is the 65c816's bread and butter. This could mean potentially 15 fps (4 rpf) in full-resolution or perhaps, maybe, 20 fps (3 rpf) in low-detail mode, subject to engine bottlenecks...
Yeah, good idea. How much of the game is already handled by the 65816? Because I'm sure the game logic itself could already be.
93143 wrote:
Tue Jul 21, 2020 7:41 pm
With VRAM HDMA, the bandwidth to VRAM is sufficient to sustain 20 fps in 224x192 with a 224x160 buffer (which is about as big as you can fractional-buffer in VRAM along with everything else) or 256x224 with a 128x192 buffer. 15 fps is already better than you'd typically get in a 4-player Goldeneye deathmatch and even some of the missions. I think it may be unreasonable to hope for 20, but anything higher is IMO a pipe dream, even at screen sizes low enough to actually display more than 20 fps. It would be awesome to be wrong...
Don't forget that part of that screen area will be taken up by the HUD, so you can actually subtract that since the HUD doesn't need the Super FX chip at all. Yeah, HDMA is awesome.
93143 wrote:
Tue Jul 21, 2020 7:41 pm
Honestly, if I had to pick between 20 fps with untextured flats and all of the DOOM-FX engine limitations on the one hand, and 15 fps with all textures and an essentially PC-equivalent engine on the other, I'd probably go for the latter. 15 fps is way more playable than 10, and the game was sold at 10.
I agree, 15 is already better, and I really want the flats back.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

Post Reply