The feeling of weight could be given to the characters with longer animations if desired. If those 4 frames of delay are present for all actions and moves in the game, it’s probably an indication of a technical limitation on the game engine and not intentional. The fact that multiple games from the same company have the same amount of frames of latency probably means those games use the same engine.
Your PC and RetroArch settings (other than runahead) don’t change anything in the game’s internal latency, which is what you’re measuring with K.
Even with the worst settings for latency, you will always measure the same 4 frames of internal latency on that game.
Yes, Capcom arcade games, at least in emulation has 3 to 4 frames in my experience.
Interesting about your points, so basically only runahead really does make the difference there. Still, with it ON and at 3, most Capcom games feel great to play.
The only downside is that once you play even official compilations such as the Genesis Collection on the Xbox SX, it’s clear when playing Shadow Dancer and basically any other fast-paced game, in the PC using Retroarch or even standalone emulators that are now incorporating runahead natively, the games are much more responsive. So it can make us a bit spoiled, specially for action oriented games.
Not only official compilations lack run-ahead support (that I know of), but they’re also typically terrible when it comes to input lag.
Most often than not those compilations use emulation with no attention paid to latency at all.
I don’t ever buy any of those compilations because of those and other issues.
If I can have a better experience playing on retroarch instead of original console, I guess I’ll go for it, I’m crazy enough to try to maximize competitiveness and fun at the same time, so, I should buy some refurbished or FPGA based consoles if I want to record some authentic gameplay, and use retroarch functions to make some really hard games less frustrating as possible.
I agree, and that’s why I said the only downside is that we can’t unnotice that. I tried it in my brothers Xbox and I told him that it was hard for me to play Shadow Dancer, a game I’m used to playing, so for him, the games were probably good enough, but since I’m more into PC emulation than he is, I’m spoiled or just a bit more aware about this difference.
About runahead, do you notice if it adds sound delay compared to the same test with it off, I’m pretty sure that some games add a bit of delay in that regard.
Absolutely, specially if you’re into shooters and action games in general, it’s that much better. Be aware that FPGA, while an interesting approach isn’t better by default just because someone said it is. It’s still emulation and it still requires good coding, or like the article from below states, any inherent input delay is from the OS and not from the code itself, but then again, I’m not an expert to really explain why that is.
Near wrote this article (archived from 2018) which explains it better than I could.
I really like both approaches, I just think this should be clarified, though.
Yeah, after one is spoiled by low-latency, going for another system with higher latency is immediately noticeable. There’s this feeling of disconnection with the actions in the game.
Not sure as I don’t use runahead myself, but you can test sound synchronization on the 240p test suit for the SNES, for example.
This. It’s very important to note that an FPGA might, or might not, beat the latency of a beefy PC. It depends.
Has anyone noticed that by overclocking, depending on the game, input lag is halved or can be even be lower? I was always fascinated by PC to console ports and I just tried the Quake II release for the PS1, the game runs fine mostly at 30FPS and looks great, specially for the hardware. I noticed that the game feels a bit heavy on the controls but what I wanted to do was to see how far I could smooth the gameplay, so I started overclocking from 200% up to 1000%, from 300% onwards, the game runs at 60FPS most of the time but I suddenly noticed the controls were much more responsive too and I measured 7 frames of delay in the stock CPU speed, 4 frames of delay at 300% OCed, 3 frames from 500%+, the sweet spot for this game is at 500~, I couldn’t notice any improvements beyond that. By activating Swanstation’s internal runahead to 1 (Core Options), I could reduce the input lag even further and the character reacts at the second frame, where 3 by the OCis already quite impressive, but I didn’t fine tuned it extensively, as the OC and the runahead together started to make the game hiccup a bit as I was pushing it too hard for my old i7-2600, still I found it very interesting to see how input lag can be inherent to the game’s own performance limitations, depending on how it was coded and how it can be basically eliminated with modern enhancements, while making the game look stunning with a tweaked shader (which still needs more time to reach that goal, by the way) and even in widescreen, very impressive stuff.
If you try this approach using other cores/games to see improvements on input lag across different systems, I’m sure the info will be useful to others as well.
Here’s a short one showing the overclocked performance:
Edit: I’ve uploaded a much better video:
I was going to say that since you’re doubling the framerate from 30 to 60 fps, you would naturally get lower latency. But the expected latency reduction should be only half a frame of 30fps (~16ms). But you got a 3 frames at 60fps (50ms) reduction.
It’s impressive how that game benefits so much from overclocking.
That makes sense, the benefits from getting less latency were unexpected, though, as I was focused in framerate performance, you’d expect the game to control better just by making it run consistently, that’s for sure.
True, I wasn’t really even thinking about going that far but the way the game is designed really benefits from this. I’ll say that even in its stock performance, if I still had a PS1 console around, the game itself is very enjoyable. I’m used to how games worked and actually find them fascinating in a way or another, I don’t recall once thinking SNES games were slow or any drops in framerate being an annoyance, as a kid and a teen, hooking a Power Base on the Mega Drive to play Master System games was fascinating, it still is, also, each hardware behaved so differently and the same games across these systems also did.
Don’t take my word for it, though, if you can test yourself and confirm the benefits from this game or others that can benefit from increased internal performance, that would be very interesting.
PS: Another improvement shown in the video above I forgot mentioning is the ability of the core/frontend to preload the CHD into memory, and the added increased CD reading speeds/seek time, I probably could go even further to eliminate loading times as the game is split into small sections that needs to load here and there.
One might say “are you still playing a PS or 'insert retro game console/game here”?
Yes, it’s still a PS1 game, the design is so good it shows how much more they can offer when enhanced, it’s like they have so much potential to be discovered and enjoyed.
There were definitely some games with lots of slowdown on the 8 and 16 bit consoles, but yeah, from my experience, framerate consistency started going down from the PS1 onwards.
Wait, this question is off-topic for my own thread but I must know this, what core are you using and this works in any PS1 game? I tried to eliminate the long loading times of Diablo (this is the only annoying downside of this port in my opinion) but I had no sucess at all.
If you use normal Bin+Cue or Isos, make sure to check 'Preload CD-ROM Image to RAM, if you use CHD, the best option is the highlighted, while preloading games into RAM doesn’t have too much to do with the read/seek speed, it can definitely help avoiding hiccups if using a normal HDD.
In Swanstation and probably in Mednafen too you can shorten load times by using the other highlighted options, be aware that depending on the game, it can hang, while others benefit a lot from the increased read/seek speeds, so if you notice a game misbehaving, try lowering the speed or default it altogether, I think Diablo won’t have issues, but you should try it to make sure.
Note that pre-cache/preload is mostly useful for unreliable storage devices (like when you have your CD images on some network device that can suddenly become very slow or completely drop-out from time to time.)
On a normal HDD (let alone an SSD) it’s not really useful. The 10x read speed option for example only requires 6MB/s from your storage device. Through a network you might not get that at all times, but from your local storage, it’s pretty much guaranteed.
Other benefits by using the caching, specially for USB external HDDs, is that it also avoids hiccups since these devices sleep in a few minutes (you can use a third party program to avoid that but this is an extra layer/step to take and the power options to keep it ON all the time in Windows never worked, it always turns off, I had a few in the past and it can be annoying. That can probably make HDDs live a bit longer too, since the games need random access like the real thing, the HDD is accessed frequently, long games and extensive play sections makes so that having it in the RAM is the better option as well.
On my Windows machine I am using RTSS scanline sync and I am pleased with the result.
Basically what you do is turn vsync off in retroarch and in your GPU control panel, then RTSS injects variable amounts of delay into the OGL/Vulkan/DX pipeline to keep the horizontal tear line in a fixed position at the top/bottom of the frame. Actually it’s hidden completely in the blanking area so you don’t even see it, and you can control the position of it manually as well with hotkeys while you’re playing the game.
The catch is the game has to have consistent render times between frames otherwise you’ll briefly see the tear line appearing before RTSS hides it away again.
I use it with Retroarch NEStopia and standalone Dolphin, GTX1070 Windows 7. Also use it for other PC games.
What is the benefit of RTSS over regular Vsync? In theory, doesn’t it increase latency, as it waits for the frame? Just like Vsync would do.
From the reading it sounds like VSync, but if the game cannot deliver the frames, then it stops being Vsync and instead shows the tearing. So no slowdown caused by syncing. I guess that is the benefit, right?
In theory I’d imagine a latency-optimised implemenation of vsync with no prerender queue would only add up to a maximum 1 frame of latency as that is the maximum time to wait until the current frame’s refresh interval is finished and it can be swapped with the next frame.
Anyway, scanline sync feels to me identical to vsyncless in terms of latency. So if you can’t feel any diff between vsync on or off, then you don’t need to bother with scanline sync.
I suppose the amount of latency added by scanline sync might be affected by how much delay scanline sync has to add to shift it to the edge and out of sight. For instance if your tear line is already near to the edge it might only need to delay it by 2ms to move it that final bit and thus out of sight.
I’ve seen the option for “GPU hard sync” in retroarch and will have a play around with that later tonight as it sounds like it might potentially be as good as scanline sync.
NVidia driver also has something called “fast vsync” which might work a similar way but I think it only works when the game is rendering fps above the refresh rate which obviously isn’t the case with emulation.
