It is currently Wed Dec 13, 2017 6:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sat Jan 14, 2017 9:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19335
Location: NE Indiana, USA (NTSC)
In this post, JRoatch wrote:
The fceux widget telling how many frames the controller was not polled since power-on.

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.?


Top
 Profile  
 
PostPosted: Sat Jan 14, 2017 9:24 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 3:25 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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).


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 6:38 am 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
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).


Care to elaborate?

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 7:04 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 8:33 am 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 445
Location: Rive nord de Montréal
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 9:53 am 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 138
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 10:46 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 10:48 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19335
Location: NE Indiana, USA (NTSC)
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.

This is essentially what you have to do on the Super NES if you're using controller autoreading.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 2:00 pm 
Online

Joined: Tue May 28, 2013 5:49 am
Posts: 923
Location: Sweden
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?


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 2:42 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 6:53 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5893
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 12:41 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 12:54 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5893
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 7:50 am 
Online

Joined: Tue May 28, 2013 5:49 am
Posts: 923
Location: Sweden
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group