Asynchronous user input

Started by
0 comments, last by Drigovas 16 years, 11 months ago
Hi, I'm currently making a game with menus in which users can select a menu item using keyboard. It's something like this: MENU TITLE 1. Selection 1 2. Selection 2 <-- Selector 3. Selection 3 Should I make the menu selector move up/down only when during one frame cycle, or should I make it able to move up/down regardless of the frame cycle (i.e. event-triggered)? I need some opinions on this (tradeoffs between those two techniques, which technique is commonly used, and when should I use a specific technique). If the answer is the first one, what FPS value would be good for doing that? Additionally, I also would like to know the commonly used FPS value for games nowadays. Thanks in advance, - dadads-
Advertisement
If nothing is going on in the background, then updating the frame only when there is a change is perfectly acceptable. Matter of a fact, the only difference the end-user will see from updating only when a change is made, and rendering the exact same perfectly still frame over and over, is a difference in the load it puts on ths system. In most cases though, renderers are often just generalized so that they do not have to know if nothing is currently changing, and just render the frame all over again anyway [regardless of change].

In short, it's up to you.

For frames per second counts, higher is better up to a certain upper bound. Your monitor [or for that matter, any monitor, anywhere] run at a fixed refresh rate [a number that can be found by you from within your program using a few different methods, depending on what you're using]. Idealy, you will run your game at this rate. Any slower will yeild consecutive frames that are the same [since you missed a refresh], and any faster will be a waste [since they won't show anyway]

This topic is closed to new replies.

Advertisement