PS1 Hardware Input Latency

[tnc]

On the PS1 hardware, if there is no external reasons like lcd monitor or controller, how much latency are you supposed to get playing Zanac X Zanac? I'm guessing no lag, like 0 frames? Because without Retroarch's runahead enabled, I get 3 frames of lag playing Zanax X Zanac and 6 frames of lag playing Ridge Racer Type 4. So does that mean that playing RR4 on the original hardware, you're supposed to get 3 frames of lag?

[thebigcheese]

I can't speak for that specific game, but I know SotN has a few frames of lag on original hardware. I was curious how the PS4 port compared and found that it's basically identical, which is to say 3-4 frames of lag. Probably varies from game to game, though.

[orange808]

I am not familiar with the hardware specifically, but there should be very little inherent input latency from the hardware itself.

The controller itself probably adds a millisecond or two to send the input up the wire.

At the console, there are two possiblities: direct asynchronous polling of controller registers or there may be periodically updated buffered memory locations that hold the state of the controllers. Either way, it should be less than a frame and probably just a few milliseconds.

What you want to know is probably here:
http://hitmen.c02.at/html/psx_faq.html#basicssyscall

Bottom line: PS1 latency should be the result of software design choices and it will vary.

[tnc]

Yeah, it clearly changes from game to game. I wouldn't think Zanac would have any built-in input lag, but I wish there was some place I could check.

[rama]

Latency is probably going to be however fast the game loop polls the controller state, plus the delay for the video output buffering.
The game loop is probably causing 33ms to 50ms and the video buffer would be 16.6ms I suppose.

[ZellSF]

https://docs.libretro.com/guides/runahead/

You can use RetroArch and count frames and you should get the correct result, assuming no errors in emulation.

[orange808]

https://docs.libretro.com/guides/runahead/

You can use RetroArch and count frames and you should get the correct result, assuming no errors in emulation.

You would need an application with known behaviors to get a proper answer to OP's question.

It might be worthwhile to inquire about the PSX 240p Test Suite to get specifics regarding its controller input handling. Or, you could view the source and figure out the behavior of the application yourself. That would provide the necessary information to use Retroarch and discover inherent hardware latency.

Once again, I don't know if the PS1 exposes direct asynchronous controller polling. There may be a specific timed cadence to periodically update a buffered memory location--and that would only expose the delayed buffered input state to devs.

You will also need to fully understand Retroarch's controller polling method, the specific emulator core, your specific controller, and your own computer (OS and hardware polling method/cadence) to use Retroarch properly. That gets messy fast.

The best solution here is real hardware, a homebrew application with known behavior, a controller with a LED light, a display with known lag, and a high speed camera.

[ZellSF]

https://docs.libretro.com/guides/runahead/

You can use RetroArch and count frames and you should get the correct result, assuming no errors in emulation.

You would need an application with known behaviors to get a proper answer to OP's question.

Um, counting the frames get you the application's behavior.

You will also need to fully understand Retroarch's controller polling method, the specific emulator core, your specific controller, and your own computer (OS and hardware polling method/cadence) to use Retroarch properly. That gets messy fast.

Frame by frame analysis to determine the application's behavior doesn't need to factor in any of that. You can press the button seconds before and after advancing the frame.

Granted that only gets you the application behavior, you still have to measure the behavior of PSX hardware, but:

1) if Zanac X Zanac on real hardware has 0 frames of lag like OP believes then you'll figure that out using the RetroArch method. This probably isn't the case

2) Having figured out what part of the lag is the application, it should be much easier to measure the hardware.

[orange808]

Frame by frame analysis to determine the application's behavior doesn't need to factor in any of that. You can press the button seconds before and after advancing the frame.

Maybe. Maybe not.

Does your specific PC input device work in an identical manner to the PS1 controller? It's probably USB input from keyboard, mouse, or some controller. On top of that, we have an OS layer. The OS does not directly poll the status of a keyboard, mouse, or controller. There is a buffered memory location.

On top of all that, I have no idea how the emulator core works. Does it truly emulate the hardware accurately?

Sorry, if this upsets you, but you're making a ton of assumptions. For accuracy, we must have a general understanding of the entire input event and we must understand it "all the way to the bottom". I'm uncomfortable with assuming I can just plug in any old input method to Retroarch, run any core, and trust that it's working the same way as real hardware.

Granted that only gets you the application behavior, you still have to measure the behavior of PSX hardware, but:

1) if Zanac X Zanac on real hardware has 0 frames of lag like OP believes then you'll figure that out using the RetroArch method. This probably isn't the case

2) Having figured out what part of the lag is the application, it should be much easier to measure the hardware.

That's precisely why I suggested using an open source homebrew application to test. The inherent latency introduced by the software can be discovered.

The easiest way to know is a test with a camera and real hardware. Without a ton of additional documentation and citation, a Retroarch latency test on your specific rig is nothing more than a: Retroarch test on your specific rig.

[ZellSF]

Frame by frame analysis to determine the application's behavior doesn't need to factor in any of that. You can press the button seconds before and after advancing the frame.

Maybe. Maybe not.

Does your specific PC input device work in an identical manner to the PS1 controller? It's probably USB input from keyboard, mouse, or some controller. On top of that, we have an OS layer. The OS does not directly poll the status of a keyboard, mouse, or controller. There is a buffered memory location.

The timing of the anything on the host is irrelevant, you advance a frame, you press a button, wait several seconds then advance another frame.

It's irrelevant to the application that you had to wait 8ms for USB polling on the start of a several second frame where the application was paused.

The easiest way to know is a test with a camera and real hardware. Without a ton of additional documentation and citation, a Retroarch latency test on your specific rig is nothing more than a: Retroarch test on your specific rig.

There's nothing rig specific about the measuring I was suggesting.

On top of all that, I have no idea how the emulator core works. Does it truly emulate the hardware accurately?

I did specify the caveat that the emulation must be error free. Though I really don't see why emulation would add latency when given several seconds to process every frame.

[tnc]

https://docs.libretro.com/guides/runahead/

You can use RetroArch and count frames and you should get the correct result, assuming no errors in emulation.

That is how I learned that on my computer and with my setup I'm getting 3 frames of lag with Zanac and 6 frames of lag with RR4. But that doesn't mean that's how it is on the real hardware or on someone elses PC. You might get more or less lag depending on your monitor, controller, OS, Retroarch settings etc.

[ZellSF]

https://docs.libretro.com/guides/runahead/

You can use RetroArch and count frames and you should get the correct result, assuming no errors in emulation.

That is how I learned that on my computer and with my setup I'm getting 3 frames of lag with Zanac and 6 frames of lag with RR4. But that doesn't mean that's how it is on the real hardware or on someone elses PC. You might get more or less lag depending on your monitor, controller, OS, Retroarch settings etc.

If you follow the instructions under "How many frames to Run Ahead?" then nothing on the host side is relevant.

That tells you the latency of the software + potentially major emulation bugs. That's all. Your monitor, controller, OS and RetroArch settings (other than runahead obviously) doesn't factor in.

[Xyga]

@orange: the best test for emulators would be a particular plugin + motion sensor, kinda derived from our current lag testers, but that doesn't exist (yet).

Anyway, counting frames in RA to set run-head deserves a decade's award for "stupidiest shit witnessed in the emu scene".

[ZellSF]

Anyway, counting frames in RA to set run-head deserves a decade's award for "stupidiest shit witnessed in the emu scene".

Only way to (realistically) do it = stupid?

[fernan1234]

Anyway, counting frames in RA to set run-head deserves a decade's award for "stupidiest shit witnessed in the emu scene".

Please say more. I never bothered to look too much into this because on a first and lazy glance it seemed to be aimed at reducing lag even below what is inherent to the original software on real hardware, which didn't sound particularly appealing.

[ZellSF]

Anyway, counting frames in RA to set run-head deserves a decade's award for "stupidiest shit witnessed in the emu scene".

Please say more. I never bothered to look too much into this because on a first and lazy glance it seemed to be aimed at reducing lag even below what is inherent to the original software on real hardware, which didn't sound particularly appealing.

That's not the intent (though it is possible). The intent is to reduce latency on the software side, to compensate for the latency introduced by the host hardware/software.

So for example, you have a TV with three frames of lag, you set runahead to three frames and now you've eliminated the TV's lag.

Obviously that only works if the software has three frames of lag internally and so people measure software to figure out how much host hardware/software latency they can compensate for.

[orange808]

Frame by frame analysis to determine the application's behavior doesn't need to factor in any of that. You can press the button seconds before and after advancing the frame.

Maybe. Maybe not.

Does your specific PC input device work in an identical manner to the PS1 controller? It's probably USB input from keyboard, mouse, or some controller. On top of that, we have an OS layer. The OS does not directly poll the status of a keyboard, mouse, or controller. There is a buffered memory location.

The timing of the anything on the host is irrelevant, you advance a frame, you press a button, wait several seconds then advance another frame.

It's irrelevant to the application that you had to wait 8ms for USB polling on the start of a several second frame where the application was paused.

The easiest way to know is a test with a camera and real hardware. Without a ton of additional documentation and citation, a Retroarch latency test on your specific rig is nothing more than a: Retroarch test on your specific rig.

There's nothing rig specific about the measuring I was suggesting.

On top of all that, I have no idea how the emulator core works. Does it truly emulate the hardware accurately?

I did specify the caveat that the emulation must be error free. Though I really don't see why emulation would add latency when given several seconds to process every frame.

I like turtles.

[tnc]

If you follow the instructions under "How many frames to Run Ahead?" then nothing on the host side is relevant.

That tells you the latency of the software + potentially major emulation bugs. That's all. Your monitor, controller, OS and RetroArch settings (other than runahead obviously) doesn't factor in.

But how do we know that it only tells us the latency of the software+potentially major emulation bugs? Is this mentioned anywhere?

Btw I forgot "the amount of time you pushed "K" minus 1" so it's 2 frames for Zanac and 5 frames for RR4.

[tnc]

Anyway, counting frames in RA to set run-head deserves a decade's award for "stupidiest shit witnessed in the emu scene".

Could you elaborate? So you're saying this method isn't accurate at telling how many frames of input delay we're getting?

[Xyga]

Could you elaborate? So you're saying this method isn't accurate at telling how many frames of input delay we're getting?

I'd rather not. Not here.

[ZellSF]

If you follow the instructions under "How many frames to Run Ahead?" then nothing on the host side is relevant.

That tells you the latency of the software + potentially major emulation bugs. That's all. Your monitor, controller, OS and RetroArch settings (other than runahead obviously) doesn't factor in.

But how do we know that it only tells us the latency of the software+potentially major emulation bugs? Is this mentioned anywhere?

Logical reasoning is how we know. What else would it be measuring and how?