Time control
by bentgarney · in Torque Game Builder · 03/20/2005 (9:38 am) · 18 replies
#2
As a bonus, $timeScale can also be used for slow motion, fast forward, etc. :)
03/20/2005 (9:39 am)
I seem to recall a pause function somewhere while reading through the T2D code, but I could be mistaken. An alternative:$timeScale = 0;
As a bonus, $timeScale can also be used for slow motion, fast forward, etc. :)
#3
03/20/2005 (9:47 am)
$timescale is great... David Grace mentioned a good Slow Motion $timeScale at 0.2
#4
This doesn't affect anything else you may having running such as game logic that might be using schedules or sounds that are currently playing etc. You need to ensure you control all that.
I removed the ability to scale the scenetime in the alpha version. It's not hard to add but there are critical things that need to be taken into account when doing such modifications.
You can see this in action by pressing the "P" key in the shooter demo.
- Melv.
03/20/2005 (9:49 am)
You can use "fxSceneGraph2D::setScenePause()" which will pause the updating of the scene you select (see ref doco). If you're using T2D scenes for GUIs (probably best to use GUI system though), then you should use seperate scenes so that you can independantly control them.This doesn't affect anything else you may having running such as game logic that might be using schedules or sounds that are currently playing etc. You need to ensure you control all that.
I removed the ability to scale the scenetime in the alpha version. It's not hard to add but there are critical things that need to be taken into account when doing such modifications.
You can see this in action by pressing the "P" key in the shooter demo.
- Melv.
#5
I don't suppose you'd be willing to explain the issues that might arise with timescaling? (Sorry, just curious about it :)
03/20/2005 (10:04 am)
Melv, when you say alpha version, would that be the next update? Or did you mean you removed $timescale and then re-added it for the EA release?I don't suppose you'd be willing to explain the issues that might arise with timescaling? (Sorry, just curious about it :)
#6
03/20/2005 (10:19 am)
I'd be interested in hearing this too.. If $timeScale affects both physics and schedules, it'd be pretty much golden :) (Not sure of what it actually does yet, haven't had a chance to mess with it)
#7
03/20/2005 (10:50 am)
I don't know for sure if it scales schedules, but from what I can tell from testing, it doesn't break the physics.
#8
03/21/2005 (12:14 am)
@Robert: Probably not, because it seems like pause would only affect the scenegraph it's called on. I hope I'm wrong. :)
#9
What Melv is talking about is particular to T2D -- that pauses the T2D scene graph. I'm not sure if it also pauses schedules that are owned by objects under that scene graph, however, but that behavior makes sense.
You can scale sim time right now by using $timescale, but I am sure what Melv is referring to is the ability to scale the fxscenegraph2D's timescale -- without affecting anything else running in the sim universe.
03/21/2005 (12:50 am)
$timescale has nothing to do with Torque 2D. It's an overall Torque sim time scale. So, if you set it to 0.5, then the entire sim runs at half speed. In laymen terms, this means anything but the GUI (and the sound system, though an interprising coder could modify it to pitch bend currently playing sounds). Sim-based schedules and such will stop if $timescale is set to zero.What Melv is talking about is particular to T2D -- that pauses the T2D scene graph. I'm not sure if it also pauses schedules that are owned by objects under that scene graph, however, but that behavior makes sense.
You can scale sim time right now by using $timescale, but I am sure what Melv is referring to is the ability to scale the fxscenegraph2D's timescale -- without affecting anything else running in the sim universe.
#10
David is spot on.
Alpha is the initial release (long time ago), we've been through that and the beta releases (to associates) and you've now got an EA release version.
The time-scale was causing certain problems so I temporarily removed the call. You can see its effect in one of the T2D demo videos. It allowed you to scale the time in any scene both slower and faster. We'll be adding this back in but not until we've done some other work. This sounds like a nice feature but we've got lots of other stuff to deal with over here like the impact on networking which is extremely important!
Changing of $timescale is not a supported activity and should only be done with the supervision of a consenting adult. :)
- Melv.
03/21/2005 (1:27 am)
Come on guys!Quote:You can use "fxSceneGraph2D::setScenePause()" which will pause the updating of the scene you select (see ref doco). This doesn't affect anything else you may having running such as game logic that might be using schedules or sounds that are currently playing etc. You need to ensure you control all that.No ambiguity there. ;)
David is spot on.
Alpha is the initial release (long time ago), we've been through that and the beta releases (to associates) and you've now got an EA release version.
The time-scale was causing certain problems so I temporarily removed the call. You can see its effect in one of the T2D demo videos. It allowed you to scale the time in any scene both slower and faster. We'll be adding this back in but not until we've done some other work. This sounds like a nice feature but we've got lots of other stuff to deal with over here like the impact on networking which is extremely important!
Changing of $timescale is not a supported activity and should only be done with the supervision of a consenting adult. :)
- Melv.
#11
03/21/2005 (4:23 am)
Checking the state of the game before schedules wouldn't be so bad if it were organized well. For instance, you could write a simple function which would return 1 on paused and 0 on not, and then simply have a conditional to execute the scheduled code based on the result of that function. I guess technically, this is 'messier' than NOT having it, but its still a relatively trivial quirk, for now.
#12
03/21/2005 (9:23 am)
You could avoid doing any sort of schedule voodoo at all by overriding setScenePause() to read something like this:package PauseHelper
{
function fxSceneGraph2D::setScenePause( %this, %pause )
{
Parent::setScenePause( %this, %pause );
$timeScale = %pause ? 0 : 1;
}
};
ActivatePackage(PauseHelper);I haven't tested it too heavily, but doing that would pause all the schedules automatically. The only drawback I can see is that it would also pause any non-T2D related schedules you have running.
#13
03/21/2005 (3:33 pm)
Well, it depends on the implementation of the menu. Straight up GUI stuff should work just fine. If the menu is built on T2D itself or otherwise relies on the passage of time, then you're definitely right: freezing the entire simulation wouldn't be so hot an idea =)
#14
$timescale will do what you want -- pause all scheduled tasks, including the T2D scenegraph -- but keep in mind $timescale and multiplayer do not mix. Now, if your game is singleplayer, that's fine and dandy. (Which is why I used it in Cloudburst.) But changing timescale causes problems with clients and servers in a network situation.
So, reliance upon $timescale could lead to further complications down the road. (But then again, if it's a networked game, why would you want a client pause it anyway?)
03/21/2005 (5:42 pm)
Listen to Melv, for Melv is all-wise and all-knowning.$timescale will do what you want -- pause all scheduled tasks, including the T2D scenegraph -- but keep in mind $timescale and multiplayer do not mix. Now, if your game is singleplayer, that's fine and dandy. (Which is why I used it in Cloudburst.) But changing timescale causes problems with clients and servers in a network situation.
So, reliance upon $timescale could lead to further complications down the road. (But then again, if it's a networked game, why would you want a client pause it anyway?)
#15
Look forward to seeing some demos of what you get though ! :)
03/21/2005 (5:52 pm)
@Robert: look forward to seeing them... though then again this comes down to genre, design, and wanted approach... for certain games, very concise orderly menus (maybe with some vibrancy) are best, while other games need more of a vibrant active menu system... so for the later I definately would agree another scengraph would work well, though I do suggest not to underestimate the Torque GUI system, its quite powerful, and keep in mind you can use them in conjuction with eachother :) Look forward to seeing some demos of what you get though ! :)
#16
So you gonna' give us some details of your project or what? We won't tell and I'm sure nobody is watching. :)
- Melv.
03/22/2005 (3:38 am)
I look forward to seeing some screenies of your project Rob. I would say that you should definately not base your project timescales on us doing networking though. I'm not saying we're not going to be working on it, it's just that we've got several key steps to get through first.So you gonna' give us some details of your project or what? We won't tell and I'm sure nobody is watching. :)
- Melv.
#17
I've got a number of objects on screen that move according to schedules that are constantly being reset. Pausing the game causes the schedules to expire and the objects jump about when I unpause.
Setting the timescale seems to be the best solution as it will pause the schedules as well. Is this still the best way to go for a single player game using Alpha 2?
01/06/2006 (11:42 am)
* bump for an old post *I've got a number of objects on screen that move according to schedules that are constantly being reset. Pausing the game causes the schedules to expire and the objects jump about when I unpause.
Setting the timescale seems to be the best solution as it will pause the schedules as well. Is this still the best way to go for a single player game using Alpha 2?
#18
Thanks,
Aaron
01/16/2008 (3:47 pm)
What is the current best practice for pausing a t2d scene? Including sound effects/music, and scheduled events (using schedule()).Thanks,
Aaron
Torque Owner Greg Lincoln