About schedules...
by Benjamin L. Grauer · in Torque Game Builder · 10/26/2006 (9:09 pm) · 8 replies
By the time, I became really annoyed by the way schedule behaves.
I can't be granted precisely of how many time a schedule will execute... Since it has an unknown delay to start the schedule in itself.
So, I'm asking, why not just use the internal time of the computer running the game ?
Instead of something strange that can be varying within the framerate, that is not reliable AT ALL for commercial purpose ?!
I would really want to have a time that is absolute : in fact, like in any other computer games out there,
not something that depend so highly on FPS... Is it too much to ask ? (no I don't own the pro-version, so I can't hack this myself)
I can't be granted precisely of how many time a schedule will execute... Since it has an unknown delay to start the schedule in itself.
So, I'm asking, why not just use the internal time of the computer running the game ?
Instead of something strange that can be varying within the framerate, that is not reliable AT ALL for commercial purpose ?!
I would really want to have a time that is absolute : in fact, like in any other computer games out there,
not something that depend so highly on FPS... Is it too much to ask ? (no I don't own the pro-version, so I can't hack this myself)
#2
Because of this if your frames are coming at 30 ms and you schedule something for 10 ms, the soonest you will get it is 30 ms. That is the only stipulation and you wouldn't get any better time resolution using a custom schedule manager.
Edit: Note that in the example above if you schedule something for 60 ms you would get it at exactly 60 ms.
10/27/2006 (10:50 am)
I just confirmed that schedules do work how I thought. They are added to the event process list and checked every frame. Scheduled functions are called on the first frame after the schedule time has passed.Because of this if your frames are coming at 30 ms and you schedule something for 10 ms, the soonest you will get it is 30 ms. That is the only stipulation and you wouldn't get any better time resolution using a custom schedule manager.
Edit: Note that in the example above if you schedule something for 60 ms you would get it at exactly 60 ms.
#3
10/27/2006 (11:07 am)
Try looking into the onTimer callback.
#4
Edit: Clarification.
10/27/2006 (12:33 pm)
The onTimer callback works essentially the same as a schedule. If you call setTimerOn(10) and youre getting frames every 30 ms, you would still only get one onTimer call every 30 ms.Edit: Clarification.
#5
Good to hear, it means that I must not use too little schedules (not less than 100ms if possible).
I was assuming too much from some little schedules I made (20ms). Thanks Thomas.
But unfortunately, the main problem I'm having is not resolved :
In a plateformer game, the player jump at a different hight depending on FPS.
It's done with a 300ms schedule, so if it can be that, what can be the cause ? Is it Physics ?
10/27/2006 (8:36 pm)
Understood, if schedules are longer than a certain time, it won't have any problem like the little ones.Good to hear, it means that I must not use too little schedules (not less than 100ms if possible).
I was assuming too much from some little schedules I made (20ms). Thanks Thomas.
But unfortunately, the main problem I'm having is not resolved :
In a plateformer game, the player jump at a different hight depending on FPS.
It's done with a 300ms schedule, so if it can be that, what can be the cause ? Is it Physics ?
#6
10/28/2006 (3:24 am)
Depends on how you are applying the force. The time at which the force is applied should have no effect on the height of the jump (assuming all other things are equal). If you are using setImpulseForce, consider using setVelocityY.
#7
It would make sense, since OnUpdateScene is called with each frame. So if the framerate is higher, the "SetLinearVelocityY" is called more, and the player jumps higher ? I'm right ?
10/28/2006 (4:08 am)
When the player push the button, it set "$player.jump" to true, and in the "t2dscenegraph::onUpdateScene" function it have a very simple SetLinearVelocityY until the button is up (or the schedule)...hum, wait... It would be because I'm doing it with the onupdatescene ?It would make sense, since OnUpdateScene is called with each frame. So if the framerate is higher, the "SetLinearVelocityY" is called more, and the player jumps higher ? I'm right ?
#8
10/31/2006 (2:57 pm)
That's right. The force wouldn't be greater, but the jump would be higher since the force is being reapplied (cancelling out the effect of the constant force).
Torque Owner Thomas Buscaglia
In the meantime, you don't need the pro license to create your own schedule function. You can get the sim time at any given frame, so it would be a pretty trivial task to create a schedule management class.