State of the Game?

#1 It is intentional. Considering the number of TGB devs who have begged GG to auto-pause the sim timer when the window loses focus, I think this is appropriate. This is actually something that comes down from XNA itself. When your game loses focus, XNA stops sending update events. It's quite possible, even likely, that Microsoft has made this configurable somewhere in the bowels of XNA. Do post back here if you decide to pursue it and find a solution.

#2 Aye. Just to reiterate Ben's answer, it's an XNA thing.

#3 @Trevor - Do you know of a way to config that bit of XNA so it wont stop sending update events?

#4 Here is a post from Mitch Walker from Microsoft:

forums.microsoft.com/MSDN/ShowPost.aspx?PostID=670758&SiteID=1&mode=1.

Quote:
We provide Activated and Deactivated events and a IsActive property that you can use to determine when your game is active or in the background. We also automatically throttle the tick rate when the game is not active so that it cooperates with other applications.

I don't know how current this information is, but it's probably worth checking out :)

Edit: can't seem to get that GGE badge in here :p

#5 Thanks for the info, have to look into it more.

use: [gge_use r=Your Name] without the space between use and r.

#6 Just wanted to give an update on this. I'm posting in the XNA forums over at microsoft and I'm getting the impression from the MS employees that this isn't an XNA thing and that it should be sending update events. I'm going to dig more into it this weekend and figure out where it's deciding to stop sending the update event.

#7 Thanks for the tip!

And good luck on your posts at the XNA forums. This is indeed an interesting topic to keep an eye on!

#8 The initial reaction from both the community there and MS was "huh? what's not firing when you loose focus?" which is why I'm gonna dig into it. Any tips on where exactly XNA is doing the check for focus would help GG =)

#9 I found the fix for this bug.

To verify the bug:
-Create a new StarterGame from File|New Project.
-Put a breakpoint in the ProcessTick method of MovementComponent.
-Add an override of the Update method to Game and set a breakpoint in it.

You can see that Game.Update is still getting called when the app loses focus, but ProcessTick is not. That pretty much points the finger at TorqueX ;)

I don't think anyone outside GG can fix it without overriding half of the engine.

The first line of TorqueEngineComponent.Update short circuits the method if false == this.IsActive, so the _timeEvent isn't being fired. TorqueEngineComponent.IsActive simply returns the IsActive property of its Game object, which returns false when the window loses focus.

It looks like the only other place TorqueEngineComponent.IsActive gets checked is OnEndDraw(), maybe it's not needed there either?

#10 I was about to update this thread actually! I talked with the XNA guys at GDC and they said basically when XNA looses focus, it drastically slows the calls to update, but they still exist. So TX is the culprit. Possibly we could get a torquesettings option to set this or not?

#11 Yeah, I agree. It needs to be configurable, since there's no single setting that will make everyone happy. That said, I think this is still a bug. Both the TorqueX code the raw XNA code should behave the same way, and right now TorqueX comes to a schreeching halt while XNA is still running.

#12 Hi,

Any updates/workarounds on this? It kind of became a headache when I started to to work on the client/server-approach and would like to have both of them running in the same computer. You can get the network communication working by hooking the message handling to Game.Update/.Draw that still work. But what you can't do (and really need) is to have the simulation running in both :(

So Jonathon and Paul are definitely right about this being a bug that should be fixed. Configurability is probably the right way, but as a short term solution it would be much better to keep things running and leave it to the Game to handle .IsActive.

As for throttling the ticks, it seems a bit dubious thing to do. I assume it would mean temporarily increasing .TickMS (so that ProcessTick / elapsed increases), but I think it should be configurable behavior. If you want to preserve system responsiveness during multitasking, it would better to skip frames, i.e. throttle Game.Draw (as it takes most of time and is not that critical for a background application). But again, configurability sounds like a good thing (e.g. InactiveTickPercentage=0.5f, InactiveDrawPercentage=0.5f).

Matias