Post subject: Player Input Delay - Status and Future
Player (37)
Joined: 2/16/2012
Posts: 282
A long while back, I thought one of the major BizHawk revisions announced significant changes to the rendering pipeline - with a side effect that user input from gamepad or keyboard now had an additional several frames of delay globally. I haven't been able to find any mentions of this in the Release Notes - does anybody recall what version this change was made, or if I'm simply misremembering things? On the other side of things, I'd like to start a discussion about what it would take for having options within BizHawk to lower this delay, even if at the loss or interference with other features. I get a lot of value from developing and testing with BizHawk, but as a player it leaves a lot to be desired when actually practicing, or just playing casually. I actually keep quite a few very old versions of BizHawk around to get a compromise between tools and real-time playability - but ideally I would like to stick with modern versions for all the other improvements they bring to the table. So I'm interested in: 1) What is the last version of BizHawk before the major change that enforced additional input delay? 2) Is it feasible/realistic to create modern versions or options that reduce input delay for real-time players?
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Interesting, how do you measure something like this? Do you know how BizHawk compares to other emulators that RTA people use for practice?
Patashu
He/Him
Joined: 10/2/2005
Posts: 4045
One way to measure it is to put both the emulator and an input viewer in OBS and make a recording. When an input is registered, frame advance until the game moves as well - that's the input latency. This is the technique used in https://youtu.be/mjAoH_iCCq4
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Player (37)
Joined: 2/16/2012
Posts: 282
I haven't thought of a precise way to measure this - it's largely based on the "feel" of the responsiveness. Another example is shown here: https://www.youtube.com/watch?v=A-xZXSa3zck There are plenty of other minor discussions on this scattered around the net, but most seem content to say "yeah, BizHawk has a lot of input delay, but RetroArch/snes9x/other feel pretty good. Use those instead." That's part of the reason I wanted to bring this up - I swear there was a note or comment on one of the BizHawk releases that due to a change in how rendering was handled, there was added delay between user input and registered input. My memory says it was at the 2.0 release, but I haven't been able to find any comments or notes confirming that. Knowing where the cutoff is can at least point folks to something a bit more playable. There are other mechanisms that some emulators try that reduce this further - RetroArch has a sort of read-ahead mode that calculates future frames and applies the input there - but I think there are probably some tweaks that can have an impact on playability in BizHawk without going to that level of complexity.
Joined: 2/25/2006
Posts: 407
If you 1) Switch to Direct 3D. 2) Disable Vsync. 3) On the "Window" tab disable the Enable Windows Fullscreen Hacks option. then you should get the fastest input response possible. You may also need to 1) Right-Click the programs EXE file. 2) Click Properties. 3) Click Compatibility tab. 4) Then tick "Disable Fullscreen Optimizations".
Ryzen 3700X, ASUS Crosshair VIII Hero (WiFi) Motherboard, 32GB 3600MHz RAM, MSI Geforce 1070Ti 8GB, Windows 10 Pro x64 http://tasvideos.org/Nach/FranpaAlert.html
Player (37)
Joined: 2/16/2012
Posts: 282
I don't think it's quite so simple as fidgeting with the currently-available video options. I ran an experiment today, recording AVIs from both snes9x 1.57 and BizHawk 2.4.0. I had both accepting background input and loaded Super Mario World. BizHawk was using the snes9x core, and full-screen hacks were turned off with Direct3D rendering. BizHawk had focus during recording. I entered Yoshi's Island 2 and then walked forward to hit the shell, and jumped once. Using the "Mario Start!" text as a synchronization point and comparing the video files afterward, the video from snes9x with default settings had actions occur 2-3 frames before BizHawk. I ran a second test with "Reduce Input Lag" selected in snes9x - counter to its claim, it actually slowed down input processing and made it run even with BizHawk. This is a case of a very similar core responding slower between different implementations - unless the core used within BizHawk is compiled with whatever the "Reduce Input Lag" feature is by default. I can try with a few other cores for other systems, but just wanted to report that here first in case I don't get to it this weekend.