I have been trying to figure it out for myself, but all tutorials online and everything I could find, does not really explain my question, so I hope someone here can help me.
I so far have only worked with C# mainly using WPF and if I want to raise an event whey a key is pressed on the keyboard, I simply use the KeyDown event. There I can easily identify the pressed key by e.Key.
Now in XNA everything I have seen is using KeyboardState state = Keyboard.GetState(); to get the state of the keyboard and constantly check in the Update()-method if e.g. state.IsKeyDown(Keys.Left); returns true of false.
And my question is: Is that not really inefficient? If for example my game uses 15 keys for input, I would get the keyboard state and check every single of those 15 keys and that 30 times a second. Is there a reason, why it seems to be so common to use this approach in XNA?
The only explanation I could think of, is to make sure everything remains in the Update-method so it will definietly be executed, such that no delayed events cause problems in the game.
A form application and a video game is two completely different beast. In a good video game, the code uses all the threads available. For this reason, having an event start a new thread while none are available is obviously a bad thing, as it could hang another critical thread. There is no loose threads in a game.
A form is reactive to your input. It does virtually nothing while you don't do something. Nobody care if pressing a button in a form take 0.2-0.5 sec of reaction time.
A game is pro-active, and keep checking for them. It update itself for every frame anyway for the AI, physic, sounds, FX, animation and so one, and what goes on screen is always linked to what the user do. The input should always be resolved when the code get to updating the player's actions. So you have to test them anyway! On top, you want the best reaction time possible to your input and the only way to do it is to constantly check them. A 0.2 sec latency to a user input can make a game unplayable. There's coders whose role is solely to reduce the input latency to a minimum.
Related
I've got a game with lots of menus. The menus have their own scripts which I don't neccessarily want to stop, just because the user can't see the menu.
This is why I currently just translate the canvases off the screen, so the user can't see them and the scripts can continue to do their thing.
Can anyone say something about the performance drain of non-visible UI? Does it cost much to have let's say 200 labels, 50 images and 50 buttons active but off screen, or is it all culled away immediately and does basically nothing performance wise?
In this context I'm also curious, if it is ok to have multiple fullscreen menus in the same canvas as I do currently, or would it be way better to give each menu it's own canvas? If non-visible UI drains a lot of performance while not visible, I would do the latter option to deactivate the canvas, but keep the script running. Would that be the way to go?
The performance is really poor. Even rendering operations are being called as long as they are active, doesn't matter how hidden of far from the camera.
It's better to have just one canvas, rather than a lot of them.
I can confirm, that there was a huge performance increase after deactivating the UI elements, that are not shown. To keep scripts on them alive, one can just write a little function, that checks if there are any scripts on a GameObject that is about to be deactivated.
This is related to my other question.
I used the OnStructureChanged event to detect that the 'Help' window popped up in the 3rd party application that my application is writing data to. I need my application to pause while the end user resolves the data issue in the 3rd party application, then I need my application to resume once the end user closes the 'Help' window. (Either I need to detect that the 'Help' window was closed or I need to display a message box and use the DialogResult to trigger my application to resume).
I've never encountered something like this before. I don't know if it's possible to do what I want to do. If it is possible, I don't know where to start.
Advice?
UPDATES:
I have only used Threading once before and I think it was a fairly "easy peasy" usage, I pulled it off without much effort, considering I'd never used Threading before. I'm playing around with Threading for this issue right now. There's a good chance I've implemented it incorrectly, but my app isn't functioning correctly anymore...I don't know if I'm even playing with the correct tool.
I had to just keep moving with the project - deadlines, you know...
I ended up using UI Automation to detect the "Help" window, then I showed a message box giving instructions to the end user. I check the MessageBox's DialogResult and continue processing based on that. It might not be the "best" way to skin the cat, but I'm a noob and I have a deadline, so I did what I needed to do to keep moving.
I'm looking for some ideas as I'm trying to wrap my head around the best way to code menu navigation with one interrupt driven device. In particular a rotary encoder knob with a push button. The question is how to manage how the interrupt routines will change depending on the context of the menu/dislay. Also, what data types should I used to keep track of the menu etc.
I'm programming an embedded device with the NetMF framework in C#. The rotary encoder know will fire an interrupt/event when it's rotated and return the direction and timestamp. Also, the push button will fire another interrupt/event and return the timestamp.
A simple outline. Device will boot up and start in some default state. Then the user can rotate the knob to change the "mode". This is simple, to me. Now, when it comes to the user controlling the settings, It would be something like press and hold the momentary for 3 seconds. After 3 seconds it will switch into settings mode. Now, the rotary encoder will rotate through different settings. Scroll/rotate to the setting you want. Forwards or backwards. Then, press the button to enable editing the setting...again, change what the rotary encoder and button do. Maybe press and hold button for exit and save all settings. Menus may be nested.
Thinking aloud:
Hardware Functions are Change-Setting-To-Edit(rotate), Enter specific Setting/forward/deeper into menu(button), Change Setting Value(rotate), Save Setting(button), Go-Back(button), Save-All and exit to Main Mode.
Each Setting "Page" or display could have a forward and back indicator that can be selected with the Rotary encoder.
Anyway it flows, I'm looking for a way to keep track of the menus and the controls of the rotary encoder and so that it's easy to extend and read.
How do I manage all of the different functions of the Interrupt Event Handlers as I change menu contexts? Is there some way to have have a set of functions for each context? How Do I keep track of them?
Thanks!
REVISED BETTER QUESTION:
How to pass native event handler for interrupt in state pattern code
What you are describing is a classic example of an event-driven state machine -- the events are handled differently depending on the current context (i.e. state). Check out QP for a framework that could suit you well. Or if that requires too much of an investment then Google for more traditional ways of implementing a state machine.
I have a strange issue that I'm not too sure on how to fix or address. I'm writing a mini text editor style application - RichTextBox editor.
I need to do some complex parsing after the selection changes - updating position, selection text and various other bits about the context of the text around the area.
As it takes a bit of processing I don't want it to fire each time the selection changes if the user is scrolling with their arrow keys. I thought of using the Application.Idle, but it fires too regularly. I tried a timer, but it may fire while the selection arrows are still moving.
What I was thinking of was a countdown timer sort of utility that will reset the timer each time the RichTextBox SelectionChanged event fires, then when the timer hits 500 ms or 1000 ms it will execute the complex processing runs.
Does this sound like a good idea?
You should probably start your processing in its own thread when it takes too long. As soon as you get new inputs you can stop the previous calculation and start with the new information again (so consider a cancel mechanism for your thread).
When your thread is done you have to check if its results are valid (the selecion did not change in the meantime). Finally, you can "synchronize" the results of the calculation to the GUI, which is hopefully quick enough :)
This does only work, when there is a certain amount of calculation that can be done without writing to the GUI ... I am not sure if you can implement it this way. It depends on the type of your calculations.
I'm programming an application consisting of three usercontrols in an main window.
In one of the usercontrols, there's a slider that needs to be controllable by keyboard input. The left arrow should decrease value, right button increase and so on. I have this work, but only when the slider has focus. If some other control has focus, I cant make it work at all.
Is it possible to define "global" hotkeys? IE keys that trigger the same event or function, no matter where the focus is? Hope I've made myself clear enough...
I have never tried this but If you have a command registered at the main window level with keys associated to it that might work. Keep in mind I have never done this but it is some thing you can try. If you are new to commands here is a blog post about it.
I have never rolled this my self but when using the built in past command I actually had to put code in to prevent it from happening in some cases.
I know this probably isn't much help but I hope it is enough to get you started.