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.
Related
I want to run a certain method every x milliseconds when a form is visible (so as to change the contents of a picturebox within that form, so that an animation is displayed, to be precise) without obviously blocking events. I cannot load a .gif since I will be using spritesheets and atlas files. I believe this approach steps outside of the event-driven programming language paradigm that comes with .net/c#. I am not sure of the correct way to face this problem - maybe using a thread, but that sounds a bit overkill - any suggestions?
You can use a timer which will fire an event at regular intervals. As to only doing that while the form is visible, you can disable the timer when the form is minimized or hidden, and re-enable it when it's shown again.
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.
I have a program which uses many hidden GUI components. For example, all the menu items, and the printer dialogs/components (which take up at least 50ms alone). In total, I'm guessing around 300ms (or 40%) of the startup of the whole program is thanks to all the hidden stuff.
What I would love to do is create these after the main immediately visible GUI is drawn (similar advice was mentioned in this thread). However, the Visual Studio editor will obviously revert it back to 'normal' after I add/change elements in the GUI designer, and keep creation of all the GUI widgets back together again in the InitializeComponent() function.
Is it possible to achieve what I want, perhaps by cordoning off particular GUI widgets which Visual Studio isn't allowed to 'touch', whilst leaving the rest for VS to play with? This way, I'd get full performance without sacrificing the convenience of the GUI designer. Or maybe there's a better way?
You'd probably be better off taking the controls you don't need immediately, and moving them out onto one or more UserControls.
You'll have to do a bit of work to move your codebehind to the new classes, but you would have had to do some work anyway to deal with some of the fields being null until you finished loading.
I have a small web application I am working on that is basically a radio player that plays live radio. On the player we have the schedule and what's playing now etc. I used a asp timer and update panel to update various content on the player mainly the 'what's playing now' bit.
Last time we tried to use the asp timer and update panel on our website it crashed the webserver in minutes because the cpu went to 100% and it could not handle that many postbacks. I am wondering what the best way of optimizing this radio player is so that it does not crash?
I have thought I could load all the content in on page load in hidden fields then use jquery? Sounds a bit messy but open to ideas?
Creating some Javascript that updates the update panel on certain timestamps isn't that much work. Send the expected end-time to the browser and let it update once the song ends.
You can even send a list of queued songs to the browser so it only has to update the data once in a while. (depending on play list style)
Make sure the update panel server side uses as much as possible cached output so it does not have to find the currently playing song. IIRC an update panel has quite some overhead, calling a clean JSON request to only retrieve the currently playing song might be much cleaner.
check view state is not enabled - this will quickly eat up memory.
You could use JQuery to fill in a portion of your page (or several portions) after the initial PageLoad. I have learnt how to do this recently and it feels better than the timer and update panels. See this post for how I achieved it - the answer from jwiscarson has the detail.
I want to create an alarm app for myself. On certain conditions (i need to poll websites) i want my app to inform me and make it HARD TO MISS. So i can take appropriate action or ignore it if i need to do something else.
I wrote a test app and using a BalloonTip (ShowBalloonTip with notifyIcon) isnt great. One of my previous apps brings the window in front of you and does a MessageBox however that doesnt always work or work well (if i somehow miss it or accidentally forget to click ok no futher messages will occur).
What are your suggestions?
You could also make it a system tray application and change the icon out if there is something which requires attention, a la a messenger application. That may not be "hard to miss" but I am trained (for better or worse) to look down at the icon tray when I see something blinking.
Where I work, we have a TimeTracker application (built in house) with which developers are supposed to log what we worked on and when. I am notorious for not using it. So, I wrote my own (Windows Forms) version for my own use which, every hour opens up and takes over my screen:
It is a frameless dialog which consumes the entire screen.
TopMost = True.
On resize, it sets WindowsState = Normal and resizes to fill the screen.
While it is open, it polls for taskmgr.exe and procexp.exe and kills them if found.
It disables the start menu to prevent cmd.exe commands from the menu in Windows 7.
The only way to close it is to enter a log, only then is the OK button shown!
So far, it's working out well - no one has been able to break it!
My less drastic suggestion would be to have a notification which pops up momentarily above the system tray. After a second or two, fade it out. Keep showing the notification every 30 seconds or so until it is dismissed.
Always-on-top window in the corner of the screen?
You could always set your window to be a top most window, make it full screen, and activate it. It would be very, very hard to miss...
Granted, it would also be very annoying, and not something I'd do to other users...
My "real" suggestion would be to use sound along with standard notification methods if this is going to be used by other people, as that's an easy way to grab attention without necessarily killing their workflow. A modeless window that appears in a corner of the screen, especially if combined with sound and color, can be very effective to grab attention.
The industry has been adopting these ambient orb devices and variations of it when such a hard-to-miss notification is required. It is used for tracking the stock-market and for broken-daily-builds.
http://www.ambientdevices.com/cat/orb/MAN_Ambient%20Orb_3-23-03.pdf
Regards