Updating game while windows is inactive
by Chris Kim · in Torque X 2D · 04/26/2007 (11:44 am) · 10 replies
I'm developing a network game.
It works but I'm testing it on a single machine and need to see updates on both instances of the game.
Right now, if the window is inactive, it won't update. "UpdateAnimation" and "ProcessTick", as such, are not being called.
It doesn't seem obvious how to make them update regardless of window state.
One caveat is that I still want to make the input active/inactive according to the window state so that I control single player at one time.
Thanks for your help.
It works but I'm testing it on a single machine and need to see updates on both instances of the game.
Right now, if the window is inactive, it won't update. "UpdateAnimation" and "ProcessTick", as such, are not being called.
It doesn't seem obvious how to make them update regardless of window state.
One caveat is that I still want to make the input active/inactive according to the window state so that I control single player at one time.
Thanks for your help.
About the author
#2
I can perhaps work around if GG is kind enough and they provide us the source to "Update" and wherever it's related.
No?
Otherwise, I'll have to get two machines setup.. :(
04/26/2007 (12:53 pm)
It seems to me that it's a bug.I can perhaps work around if GG is kind enough and they provide us the source to "Update" and wherever it's related.
No?
Otherwise, I'll have to get two machines setup.. :(
#3
Being as no GG employee has officially said 'Yes, this sucks and we'll fix it" I'd say we wont see it fixed any time soon.
04/26/2007 (2:00 pm)
The latest word from GG is that they thought it was an XNA thing, which it PARTIALLY is. XNA slows way down when the game looses focus, but still does have ticks, just really slow ones. TX appears to take this even further and actually stop the update calls all together (or slows them down way more than I'm willing to sit and test).Being as no GG employee has officially said 'Yes, this sucks and we'll fix it" I'd say we wont see it fixed any time soon.
#4
First in the main game class I set the inactiveSleepTime to 0.
depending on whether you have access to TX source or not, you might be able to fix the other half of the issue: TX stopping it's update when the window isn't active.
04/26/2007 (11:07 pm)
I'm working on a networked game and haven't had any issues testing on the same machine.First in the main game class I set the inactiveSleepTime to 0.
public Game() {
_myGame = this;
this.InactiveSleepTime = new TimeSpan(0);
. . . .depending on whether you have access to TX source or not, you might be able to fix the other half of the issue: TX stopping it's update when the window isn't active.
#5
I think it's also an issue to start throtling the ticks while inactive. As the Ticks drive the game progress you should always "get constant amount of ticks per GameTimeSpan" (while constant ticks are enabled). If you want to conserve resources and keep the application responsive, it would be better to throttle the renders as it's IMO less important.
04/27/2007 (3:40 am)
@Alex: What do you mean by "no issues"? You get Tick-updates in your program (by setting the InActiveSleepTime), or that you don't need the Tick-updates for testing? For me it's also a big problem that Ticks stop when the program becomes inActive.I think it's also an issue to start throtling the ticks while inactive. As the Ticks drive the game progress you should always "get constant amount of ticks per GameTimeSpan" (while constant ticks are enabled). If you want to conserve resources and keep the application responsive, it would be better to throttle the renders as it's IMO less important.
#6
04/27/2007 (7:33 am)
One thing to note semi-related is that even with ticks supposedly being the same length 'varlengthticks' or some such property, they still do not tick the same depending on machine. I have Simian running on a beefy desktop and on an average laptop. The laptop runs a lot faster (ticks happen faster) than my desktop for some reason even tho variabletickrate or whatever it is is set to true. Was going to get actual time stamping logged and then submit the bug report, but haven't had time to yet.
#7
1) Your ticks/millisecond value is wrong, which implies that the clock reporting speed is not showing up properly to Torque X.
2) You have a bug in your drivers for an AMD dual core (known issue with AMD DC configurations). There is a driver update you can download to help with this. IIRC, it has to do with dual core AMD's improperly reporting their performance.
04/27/2007 (11:08 am)
@Jonathon: The only reason I can think of for this issue is one of two things:1) Your ticks/millisecond value is wrong, which implies that the clock reporting speed is not showing up properly to Torque X.
2) You have a bug in your drivers for an AMD dual core (known issue with AMD DC configurations). There is a driver update you can download to help with this. IIRC, it has to do with dual core AMD's improperly reporting their performance.
#8
As for the throttling ticks when inactive, I imagine that's a TX feature. I haven't really done any hardcore testing of ticks to measure if this is going on or not. A GG employee would be better qualified to answer that. I guess fortunately for me, all my game critical objects that require consistent updates don't use TX's tick-updating (ProcessTick()) but just the standard XNA update(GameTime time) method, due to custom-written collision and physics outside of TX. I'm also using delta timing so inconsistent passages of time shouldn't be a huge issue for me, because I needed to do some particular things with network latency in the first place (which is inconsistent passage of time already).
So in testing, I can have both windows open and get decent enough performance on both instances to be able to test basic networking functionality, tick-throttling or not. I don't look for 'smoothness' when testing on the same machine, as running two instances is already resource heavy. I tend focus performance testing when running the game across multiple machines.
05/01/2007 (6:38 am)
@Matias: Well, setting the inactiveSleepTime to 0 is an XNA setting and that stopped the application from stuttering when it lost focus due to it sleeping. Editing TX to keep updating when it wasn't active allowed it to keep doing tick-updates when it lost focus.As for the throttling ticks when inactive, I imagine that's a TX feature. I haven't really done any hardcore testing of ticks to measure if this is going on or not. A GG employee would be better qualified to answer that. I guess fortunately for me, all my game critical objects that require consistent updates don't use TX's tick-updating (ProcessTick()) but just the standard XNA update(GameTime time) method, due to custom-written collision and physics outside of TX. I'm also using delta timing so inconsistent passages of time shouldn't be a huge issue for me, because I needed to do some particular things with network latency in the first place (which is inconsistent passage of time already).
So in testing, I can have both windows open and get decent enough performance on both instances to be able to test basic networking functionality, tick-throttling or not. I don't look for 'smoothness' when testing on the same machine, as running two instances is already resource heavy. I tend focus performance testing when running the game across multiple machines.
#9
Since we're in the topic, do you have any experiences, comments or opinions you'd like to share about "constant vs. variable time updating" with respect to network development? The reason I'm asking is that it's something I've been pondering myself. I'm currently working with constant time ticks and synchronize everything based on that. It has it's benefits and disadvantages, and it would be nice to hear if you have some insight on the topic :)
Matias
05/03/2007 (12:19 am)
Thanks for the info Alex. Since we're in the topic, do you have any experiences, comments or opinions you'd like to share about "constant vs. variable time updating" with respect to network development? The reason I'm asking is that it's something I've been pondering myself. I'm currently working with constant time ticks and synchronize everything based on that. It has it's benefits and disadvantages, and it would be nice to hear if you have some insight on the topic :)
Matias
#10
This is only my 2nd fully networked game, so my experience is a little limited. But if I understood your question correctly, then I would think that constant vs variable time updating shouldn't matter on the networking side if created carefully. I've used constant time updating mostly, but whenever I send something over the wire I try to make as little assumptions as possible. The client on the other end could end up not receiving the message for a full 5 seconds or more so even though I'm using 'constant time updating' on the clients I code things to work in variable [passage of?] time as much as possible when it does arrive.
05/06/2007 (8:51 pm)
Heya Matias,This is only my 2nd fully networked game, so my experience is a little limited. But if I understood your question correctly, then I would think that constant vs variable time updating shouldn't matter on the networking side if created carefully. I've used constant time updating mostly, but whenever I send something over the wire I try to make as little assumptions as possible. The client on the other end could end up not receiving the message for a full 5 seconds or more so even though I'm using 'constant time updating' on the clients I code things to work in variable [passage of?] time as much as possible when it does arrive.
Torque Owner Matias Kiviniemi
Matias