Any pico-8 game I play (my own or downloaded) seems to have some noticeable input lag in the standalone client (a delay between when a key is pressed and when the game responds). This doesn't happen with other games on my computer, so I know it's not a video delay issue. Is this an issue that anyone else has noticed, and if so is there a fix for it?

@NMcCoy I also sometimes have the impression that input is handled with delay. I've just tested again my game with minimal overhead so it runs at 60 FPS and it feels okay. Maybe in some places there is some overhead making it drop at 30 FPS, but I'm surprised input would also be skipped and delay input handling to next frame (input and update should persist, only render should skip a frame).

Do you still have this issue, and do you have a cartridge example? I'll try to find the conditions under which I feel the lag.

This is one reason to prefer _update60() over _update(). The bare-minimum lag between pressing a button and seeing the result on-screen is effectively doubled when you use _update().

But it's also possible there's some latency involved in either zep's code or in the SDL component he uses for cross-platform compatibility. Ideally, the physical hardware shouldn't be polled until the first time the game makes a call to btn() or btnp() since the last flip, though the OS often adds some latency for its own reasons (thread scheduling, vertical blanks, asynchronous I/O with the peripheral, etc.) and I suspect SDL adds some on top of that.

To my knowledge, the vast majority of video games have 60 fps updates (as in to the game state, not to the visuals) at minimum in hopes of matching the most common refresh rate of monitors. Beyond that, there's question of how many people would even register the difference due to the human eye being a necessary part of the process for human players. However, if you're used to 60 fps, then anything less can feel laggy due to the game literally responding less quickly.

In comparison, games from before around 1995 or so (and some rts games past that) used less for various reasons, with 30 being more common. I'm guessing this is why pico-8 defaults to it.

@Felice, I can see how that might seem ideal, but I don't think that would matter. Any gains from trying to time the polling correctly would be too inconsistent, especially in an engine that's supposed to allow ignoring the hardware completely. As it is, the processing of input really shouldn't be related to the draws as that could cause a mismatch with the player's muscle memory.

That's right, I process inputs at the beginning of the frame and that may explain some lag when I drop to 30 FPS, but I still think my _update60 is done in at 60FPS and only render frames are skipped, so I shouldn't lose more that 1/60 of a second. Since I've been back to 60 FPS I didn't experience issues anyway. Maybe I could try and play with a gamepad now.