I'm not talking about HDTV lag, I'm talking about games that had control lag on CRTs.
The simplest explanation would be innefficient programming, but that doesn't explain how there can be several frames processed in between fetching the joypads at reacting to them.
It really depends on which game you're talking about. Lag could come from any of several sources:
- Micronics games ran at 12-20 fps, so they'd read the controller at that rate.
- A lot of games have dumb autorepeat logic that just samples the controller at the autorepeat rate instead of actually using a time held counter. I've seen this in plenty of shitty Tetris clones.
- Navigating the Action 53 menu with a Zapper is laggy. That's because reading the Zapper's position takes full attention between sprite 0 hit and photodiode hit, but drawing text in a proportional font also takes lots of CPU.
- Some games require holding down the button for a while to start moving because they map a short press to a different action.
- Some games are paranoid about switch bounce or about cheating with turbo controllers and will delay input by a frame to make sure all presses are intended.
- Some NES games using DPCM use the previous frame's data if a glitch corrupts a read, causing one additional frame of input lag. Other NES games using DPCM will reread until it settles, but race conditions with IRQ and NMI handlers open the possibility of the recently discovered 2-second TAS for Super Mario Bros. 3 that may lead to a total control exploit. More recently, Nintendo has taken games off the eShop for having total control vulnerabilities.
- Some games allow actions only on specific animation frames. This may be to increased perceived animation smoothness at the expense of responsiveness, such as allowing a jump only from certain frames in a walk cycle. Or it may be to hide the fact that movement is fixed to a tile grid, as in the way some ZX Spectrum games work around that platform's attribute clash.