Count of frames with no input poll is one way to measure a game's slowdown, as TAS authors need to minimize lag to save frames. Is it a good or bad practice to skip polling input during bulk data loads? I know a Vs. System game needs to poll each frame because the coin mech presses the coin drop button for only about 3 frames if I remember correctly. But is there a reason to do so outside Vs.?In [url=https://forums.nesdev.com/viewtopic.php?p=186695#p186695]this post[/url], JRoatch wrote:The fceux widget telling how many frames the controller was not polled since power-on.
Does input need to be polled every frame?
Moderator: Moderators
Does input need to be polled every frame?
Re: Does input need to be polled every frame?
If you want to process a edge transition at the first frame after the bulk load it's probably a good idea to always poll, or at least poll on the very last frame of the load, before the first active game fame. Not polling would make those long time gaps act as a button buffer, which is actually good thing for genuine game lag.
Re: Does input need to be polled every frame?
In my game engine, I only poll input when I process the player action (or in other cases such as the menu) and do *not* do this in i.e. the VBlank NMI routine systematically. In particular if I do not use the input I do not poll it, however some games polls controller in the NMI routine. (There is several reason it's a bad idea, yet they still did it that way).
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
Re: Does input need to be polled every frame?
Care to elaborate?Bregalad wrote:In my game engine, I only poll input when I process the player action (or in other cases such as the menu) and do *not* do this in i.e. the VBlank NMI routine systematically. In particular if I do not use the input I do not poll it, however some games polls controller in the NMI routine. (There is several reason it's a bad idea, yet they still did it that way).
__________________________
http://pcedev.wordpress.com
http://pcedev.wordpress.com
Re: Does input need to be polled every frame?
Oh yeah, it's simply that in the case where the game would slow down, it's better to be safe and know the controller is read only once per logical frame (even if that frame happens to spawn across two real frames). For example when checking if, for instance, the UP button is pressed and I know the answer is no, I can assume it's not pressed on further reads of the controller variable. If the NMI updates the variable, then there's a low chance than it would update it while the program would do game logic based on it, potentially leading to crazy decision making and glitches. The chance of this happening is low, but possible.
- Jarhmander
- Formerly ~J-@D!~
- Posts: 569
- Joined: Sun Mar 12, 2006 12:36 am
- Location: Rive nord de Montréal
Re: Does input need to be polled every frame?
I know Megaman 1 doesn't read the controller prior to a boss battle i.e. when the door closes, the boss appears and its life goes full. I know because during that time, I cannot make the PowerMappers menu appear. I mention this only to talk about a known case where the controller isn't polled every frame.
((λ (x) (x x)) (λ (x) (x x)))
Re: Does input need to be polled every frame?
You could simply have a flag that says "I'm done updating for this logical frame" and only poll the controller in NMI when set, then unset the flag. In fact, you probably want to only update the graphics then anyway, so you don't end up showing a half-updated frame onscreen.
Re: Does input need to be polled every frame?
Or you could read the controller every frame in the NMI and buffer the input, and have the game engine copy that buffered state for use in the logical frame. Some frames would be skipped and never used by the engine in case of slowdown, but the controller would still be read.
Re: Does input need to be polled every frame?
This is essentially what you have to do on the Super NES if you're using controller autoreading.tokumaru wrote:Or you could read the controller every frame in the NMI and buffer the input, and have the game engine copy that buffered state for use in the logical frame.
Re: Does input need to be polled every frame?
Because autoreading starts at vblank and finishes a few cycles later (it's possible to use $4016/$4017 like on NES as well though), so the reading has to be done in NMI (or at least sometime after vblank).
But on NES it's easier to just save the readings for the logical frame, like Bregalad do, instead of bothering with buffers, isn't it?
But on NES it's easier to just save the readings for the logical frame, like Bregalad do, instead of bothering with buffers, isn't it?
Re: Does input need to be polled every frame?
I use buffers anyway, because of the way I've implemented demo playback. The playback code basically tampers with the buffered state, replacing all bits (except that of the "start" button) with recorded states. The real "start" bit is OR'd with the recorded "start" bit and the result is used to decide whether to end the demo.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Does input need to be polled every frame?
Two alternative ways of solving this:
1. Don't have lag frames. Then the problem doesn't apply.
2. Don't depend on input in a way that a missed frame will matter, e.g. a continuous fire vs fire-per-tap mechanic might obviate the difference.
These are both highly dependent on your specific application, but I think they're both a valid way to sidestep the issue, for the right situation.
1. Don't have lag frames. Then the problem doesn't apply.
2. Don't depend on input in a way that a missed frame will matter, e.g. a continuous fire vs fire-per-tap mechanic might obviate the difference.
These are both highly dependent on your specific application, but I think they're both a valid way to sidestep the issue, for the right situation.
Re: Does input need to be polled every frame?
Wow guys. I wasn't asking for a solution to that problem - that problem is unlikely to happen anyway. I was just pointing out why it's a better idea to poll the controller before you need to take decision based on it, in the local code, rather than doing it as part of the interrupt routine. That's all. What you guys are telling me is solutions if it was REQUIRED to poll the controller in the interrupt routine, and yes indeed there is a zillion of solutions, yet it is even simpler to not poll the controller in the NMI to avoid any problems.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Does input need to be polled every frame?
Am I missing context from a thread split here? I don't quite see that question in the history, bregalad... I do think it's a good question though:
There is probably a small gain in responsiveness to be had by timing an input poll as late in the frame as you can manage, but I think this is at odds with consistency. If delaying the poll introduces jitter in the actual timing, even though you might be giving the user a few more milliseconds to respond, it's probably bad if that advantage only applies sometimes.
If they have just enough time to react to something, but only on some frames and not others, that's a bad situation. They have a loss of control because they can't reliably get the result. It's hard to learn to anticipate a timing if it's not always the same.
So in general I think it is better to poll consistently than trying to poll with the least latency, at least when we're already able to poll at the display rate anyway.
There is probably a small gain in responsiveness to be had by timing an input poll as late in the frame as you can manage, but I think this is at odds with consistency. If delaying the poll introduces jitter in the actual timing, even though you might be giving the user a few more milliseconds to respond, it's probably bad if that advantage only applies sometimes.
If they have just enough time to react to something, but only on some frames and not others, that's a bad situation. They have a loss of control because they can't reliably get the result. It's hard to learn to anticipate a timing if it's not always the same.
So in general I think it is better to poll consistently than trying to poll with the least latency, at least when we're already able to poll at the display rate anyway.
Re: Does input need to be polled every frame?
I don't really get if you mean it's better to read during the NMI or the logical frame?
Also what is a "lagframe"?
My current setup is to have the NMI handler only handle graphic updates (sprites (OAM-DMA), BG, palette, PPU settings and scrolling in that order) and the sound routine, while the main program loop in the Reset handler handles reading controllers, filling the buffers for graphic updates and all logic. I put a wait for an NMI to finish at the beginning of the main loop (as I understand is the common practice to make game logic advance in a consistent frame rate). And because of that the main loop should not happen more than the NMI happens (the reverse isn't true if the main loop takes too long though). So therefore the controllers are effectivly read only ones per frame even though they are read in the main loop.
Also what is a "lagframe"?
My current setup is to have the NMI handler only handle graphic updates (sprites (OAM-DMA), BG, palette, PPU settings and scrolling in that order) and the sound routine, while the main program loop in the Reset handler handles reading controllers, filling the buffers for graphic updates and all logic. I put a wait for an NMI to finish at the beginning of the main loop (as I understand is the common practice to make game logic advance in a consistent frame rate). And because of that the main loop should not happen more than the NMI happens (the reverse isn't true if the main loop takes too long though). So therefore the controllers are effectivly read only ones per frame even though they are read in the main loop.