TGB: tickcount different in levelbuilder and "Built" projects?
by Dan MacDonald · in Torque Game Builder · 10/23/2006 (12:56 am) · 16 replies
So, I'm observing this really odd behavior. I've got a little prototype where I can move a block around a single screen. It's very basic, but it has a few timing things where it checks duration since the last keypress (using simGetTime()) and it also has a "schedule" call in it. It runs great in the TGB game builder IDE, however when I build the project and run the built executable it seems that miliseconds are suddenly 3x longer then they were when running in the editor.
Where my schedule call with a time of 250 competed in a 1/4 second in the editor, it now takes closer to a full second before the scheduled method is called when run from a "Built" project.
Does anyone have any idea why?
Where my schedule call with a time of 250 competed in a 1/4 second in the editor, it now takes closer to a full second before the scheduled method is called when run from a "Built" project.
Does anyone have any idea why?
#2
It's not just schedule however, the onUpdateScene just seems to be being called less in "built" versions of the game.
10/25/2006 (12:45 am)
Right.. optimizing for the build version makes running it in the level builder not work correctly, but running it properly in the level builder means that you may experience very different results when you build it.It's not just schedule however, the onUpdateScene just seems to be being called less in "built" versions of the game.
#3
10/25/2006 (8:25 am)
Both schedule and onUpdateScene are not reliable for consistent timing in terms of exactly when they are called. OnUpdateScene is called just after each frame renders which means it is highly framerate dependent. You can get different results in a single session on the same machine from one minute to the next based on what your machine is doing in the background and how that affects framerate. As for schedule, don't think of a 25ms schedule as happening 25ms from now. Think of it as happening a minimum of 25ms from now. In other words it could happen any time after 25ms from now depending on the load of your app and the speed of your system.
#4
It's like a 250 miliseconds (quarter second) delay when running in the game builder, becomes a 1500 miliseconds when it's running stand alone.
10/25/2006 (9:16 am)
I understand that, but this is an order of magnitude difference. I read the doc's on schedule, it attempts to make the scheduled call on a paticular interval, if it can't make it during one of those intervals then it will call it twice the next time. (If it was a recurring schedule). Something else is afoot here, framerate didn't appear to be any slower in the built version, and if framerate is being more then halved in built versions it's still an issue.It's like a 250 miliseconds (quarter second) delay when running in the game builder, becomes a 1500 miliseconds when it's running stand alone.
#5
10/25/2006 (12:38 pm)
It would be interesting to get some hard numbers on your scheduling difference. Try logging (or output to console) some times from calling schedule until the very beginning of the scheduled function.
#6
In other games, WAIT commands stay the same from one computer to another, so why not in TGB ?
How can we resolve this issue ?
10/25/2006 (4:08 pm)
Should we report this as a bug ? I mean, how can we create precise timings if nothing can be precise ? In other games, WAIT commands stay the same from one computer to another, so why not in TGB ?
How can we resolve this issue ?
#7
Solution above all :)
Since i've already meet this but don't remember the TGB version it was.
12/13/2006 (4:20 pm)
I would like more informations on this please.Solution above all :)
Since i've already meet this but don't remember the TGB version it was.
#8
Edit: I can't spell today.
12/13/2006 (4:27 pm)
The other possible reason for this (besides schedules not being reliable within 32ms or so) is that you might be using onUpdateScene on a class name. That issue is discussed and solved in this thread.Edit: I can't spell today.
#9
12/13/2006 (4:51 pm)
Uh.. i was doing that actually :) Maybe that's the problem... I'll go read the thread. Thanks for the follow up.
#10
I can't make test to see if it's the same on different machine though.
12/14/2006 (3:25 am)
Ho i was already do that, i didn't know we were talking about that scenegraph naming problem.I can't make test to see if it's the same on different machine though.
#11
I have this issue too, my game runs at the speed the users CPU can take :(
I am pretty sure i do it correctly, and use a named sceneObject as it tells me too in the thread you are linking too.
Example of my code:
This should be correct, right? But my game still runs at different speed depending on the CPU.
I have placed my, NOT very nice code here :) if anybody could take alook at see where i made a mistake.
laumania.net/downloads/ParachuteSrc.rar
Please tell me what im doing wrong if anyone can...Im now to Torque, so it could very well be me who made a mistake, but actually it look right to me...
12/18/2006 (1:45 pm)
Tom:I have this issue too, my game runs at the speed the users CPU can take :(
I am pretty sure i do it correctly, and use a named sceneObject as it tells me too in the thread you are linking too.
Example of my code:
function ParachuteSceneGraph::onUpdateScene(%this)
{
//Some code
}This should be correct, right? But my game still runs at different speed depending on the CPU.
I have placed my, NOT very nice code here :) if anybody could take alook at see where i made a mistake.
laumania.net/downloads/ParachuteSrc.rar
Please tell me what im doing wrong if anyone can...Im now to Torque, so it could very well be me who made a mistake, but actually it look right to me...
#12
There are lots of ways to fix this, but a really easy one (though not entirely bullet-proof) is to simply move all your update calls from onUpdateScene to a timer function (or a schedule, but this is just the sort of thing timers are for). Timers are in the docs, but it's really easy - you just call setTimer (maybe called something else) or something and pass in a duration and then that object (the scenegraph in your case) would get the onTimer callback and you can update everything in there. That way, if you give it something like 50 ms between ticks, you could update everything there and no one would notive the difference - and both computers would get that callback consistently.
Hope that made sense ;)
12/18/2006 (2:31 pm)
The reason your game is framerate dependent is because you are changing movement values (the sort of thing that should be time dependent instead of frame dependent) in your update functions. In your player tank update function (called from the scenegraph's update) you add to the currentspeed and then apply that velocity (you do this with the turret angle too). This means that on a computer that can render more frames and get a higher fps count, there will be times that the speed is increased.There are lots of ways to fix this, but a really easy one (though not entirely bullet-proof) is to simply move all your update calls from onUpdateScene to a timer function (or a schedule, but this is just the sort of thing timers are for). Timers are in the docs, but it's really easy - you just call setTimer (maybe called something else) or something and pass in a duration and then that object (the scenegraph in your case) would get the onTimer callback and you can update everything in there. That way, if you give it something like 50 ms between ticks, you could update everything there and no one would notive the difference - and both computers would get that callback consistently.
Hope that made sense ;)
#13
But ok, ill try it out with a timer :)
12/19/2006 (12:09 pm)
Ok great, i can see that now, i just thought that there was a build-in "timer" in the core of TGB, because they do it like this in the TankBuster code. (The one i have looked at to get inspired :) )But ok, ill try it out with a timer :)
#14
This is really a frustrating problem for me that the game doesn't run even on all computers. I have looked at the source code from the TankBuster game, and that game runs fine, just doesn't work for me...
Any body? please help me :)
01/16/2007 (1:27 pm)
The timer doesn't work.... you cant call setTimerOn(25); on a t2dSceneGraph.... any other ideas?This is really a frustrating problem for me that the game doesn't run even on all computers. I have looked at the source code from the TankBuster game, and that game runs fine, just doesn't work for me...
Any body? please help me :)
#15
Hope that made sense ;)
01/16/2007 (1:32 pm)
I wouldn't put it on the scenegraph here - it would probably be better to make a sceneObject or scriptObject (though I don't remember if scriptObjects can have timers - they probably can) and then have that update everything. That way, you could make multiple update objects so that not everything is updated as frequently as everything else.Hope that made sense ;)
#16
But maybe if works if you see my code, it ugly as it is my first project, but hope you'll get an idea of what im trying to do:
laumania.net/downloads/Parachute.zip
01/16/2007 (1:51 pm)
Hmm, i don't understand exactly. Im new to this engine, so i don't have a great knowledge of how things are put together.But maybe if works if you see my code, it ugly as it is my first project, but hope you'll get an idea of what im trying to do:
laumania.net/downloads/Parachute.zip
Torque Owner Benjamin L. Grauer
It seems like schedule is not that reliable for precise timing or maybe it's the physics that don't have the same speed due to difference of framerates. Either one of the other, it's not cool... :/