Ogre::Timer::Pause, UnPause
-
- Greenskin
- Posts: 121
- Joined: Thu Oct 07, 2004 8:38 am
Ogre::Timer::Pause, UnPause
I was talking with a friend of mine about how much I liked the Timer class, and he asked if it had a pause function. The idea hadn't really crossed my mind until that point, however it would actually be a useful addition and trivial to add.
pause (); // accumulated time is stored in separate variable
unsigned long getMilliseconds (const bool& pause = false); // this could be another way of doing it
continue (); // same as reset(), but without resetting the accumulated time variable
and thats about it, a useful but simple shortcut when using the same timer to sum up different blocks of time.
pause (); // accumulated time is stored in separate variable
unsigned long getMilliseconds (const bool& pause = false); // this could be another way of doing it
continue (); // same as reset(), but without resetting the accumulated time variable
and thats about it, a useful but simple shortcut when using the same timer to sum up different blocks of time.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Ogre::Timer::Pause, UnPause
You shouldn't use this class as anything other than a "real" time information source. In "reality", there is no pause.
So a better idea is to create some kind of "virtual" clock that get the real time passed info from anywhere else-- for example, Ogre::Timer -- and then will provide a time that can be paused or event accelerated or slow down (by using a time flow factor to each time update).
I'm doing this and it works great. You can see an old version of my code there, just to get the global idea :
- gcore::ClockManager header cpp
- gcore::Clock header cpp
- gcore::TimeProvider header << this one is the base class for an implementation that might use Ogre::Timer -- in fact that's what i use in my game.
There are other ways to implement this (and it's a bit old code). Be critic and curious.
Hope it helps.
So a better idea is to create some kind of "virtual" clock that get the real time passed info from anywhere else-- for example, Ogre::Timer -- and then will provide a time that can be paused or event accelerated or slow down (by using a time flow factor to each time update).
I'm doing this and it works great. You can see an old version of my code there, just to get the global idea :
- gcore::ClockManager header cpp
- gcore::Clock header cpp
- gcore::TimeProvider header << this one is the base class for an implementation that might use Ogre::Timer -- in fact that's what i use in my game.
There are other ways to implement this (and it's a bit old code). Be critic and curious.
Hope it helps.
-
- Greenskin
- Posts: 121
- Joined: Thu Oct 07, 2004 8:38 am
Re: Ogre::Timer::Pause, UnPause
well my main thought wasn't about turning Timer into a big class with lots of features that tend to be program specific. Rather to provide for a common task that deals with stuff that it already does, but just makes it easier to use in a number of cases. One common example is profiling functions, if the timer can do the summing for you, you don't need to store an additional variable outside the timer.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Ogre::Timer::Pause, UnPause
What you want is to break the Separation of Concern and it's a bad thing.
Ogre::Timer is meant to provide a reliable source of real time value. No more, no less.
Then if you want to add any functionallity, simple or not, if it's not to provide real time value, then you need to build something else (a class or a system or a function, whatever) that will rely on this one. Dont change this one juste to make it what you want, you can already take it and use it as a part of implementation of what you need.
By the way, I also implemented a "very simple" profiler by using the same technique.
Ogre::Timer is meant to provide a reliable source of real time value. No more, no less.
Then if you want to add any functionallity, simple or not, if it's not to provide real time value, then you need to build something else (a class or a system or a function, whatever) that will rely on this one. Dont change this one juste to make it what you want, you can already take it and use it as a part of implementation of what you need.
By the way, I also implemented a "very simple" profiler by using the same technique.
- ImpalerWrG
- Gnoblar
- Posts: 15
- Joined: Sat Feb 27, 2010 7:42 am
Re: Ogre::Timer::Pause, UnPause
If this is the case then the class should have been called Ogre::Clock, when a class is named Timer people are going to expect it to do things like pause, reset and generally have a stop-watch like functionality. Providing two classes, a read-only Clock and a stop-watch like Timer would probably be the best solution.Klaim wrote: Ogre::Timer is meant to provide a reliable source of real time value. No more, no less.
Companions the creator seeks, not corpses, not herds and believers. Fellow creators, the creator seeks - those who write new values on new tablets. Companions the creator seeks, and fellow harvesters; for everything about him is ripe for the harvest.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Ogre::Timer::Pause, UnPause
If it's only the name that bother you then it's not a real problem as you have to use the convention of the tools you're using. Here Timer is simply providing real time (that can't be stoped or changed). In my own tools, I use "Clock" as the name of objects giving "virtual" time, that can be stopped and other things. It could have been names differently.
In a lot of library, Timer isn't even a kind of time provider but more like an object that trigger some event once some (real or virtual) time passed.
So the name have nothing to do with the fact that the role of Ogre::Timer is defined to only give (hardware) real time passed, and nothing more.
Now, in Ogre, there is no need for pausing time. It's not a general library, it's a rendering library. If you want to make your animation pause or change speed, then simply provide different delta when updating them. To do this, you'll have to implement your own virtual time system (like mine). If you want to have events once some time is passed, you'll have to use something else or build a tool to do this over Ogre::Timer.
Don't forget that Ogre is not a general library, it's only for graphic rendering.
In a lot of library, Timer isn't even a kind of time provider but more like an object that trigger some event once some (real or virtual) time passed.
So the name have nothing to do with the fact that the role of Ogre::Timer is defined to only give (hardware) real time passed, and nothing more.
Now, in Ogre, there is no need for pausing time. It's not a general library, it's a rendering library. If you want to make your animation pause or change speed, then simply provide different delta when updating them. To do this, you'll have to implement your own virtual time system (like mine). If you want to have events once some time is passed, you'll have to use something else or build a tool to do this over Ogre::Timer.
Don't forget that Ogre is not a general library, it's only for graphic rendering.
- syedhs
- Silver Sponsor
- Posts: 2703
- Joined: Mon Aug 29, 2005 3:24 pm
- Location: Kuala Lumpur, Malaysia
- x 51
Re: Ogre::Timer::Pause, UnPause
I think pause feature should be application code. Right, I agree with Klaim: Ogre::Timer should just report the time elapsed not more not less. And pause feature is not that hard to implement.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Ogre::Timer::Pause, UnPause
I even gave you a simple example. It looks like complex because it manage several clocks and there is a lot of comments but in the end it's really simple...
- shadowfeign
- Goblin
- Posts: 213
- Joined: Mon Jan 26, 2009 11:51 pm
- x 15
Re: Ogre::Timer::Pause, UnPause
If Timers job is just to provide time, then its already expanded too far, as it has a reset function. Pause/Unpause adds no more or less extra than that. So if you want to maintain that logic, should we remove the reset functionality as well, or just go with making it something more than a half assed stop watch and add pause/unpause? My two cents. I'd rather have something that does the basics, which includes pausing if needed, as time is relative to the task we want to accomplish, which isn't always in a single block.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Ogre::Timer::Pause, UnPause
Pause/Unpause requires additional logic and therefore more operations to perform all of Timer's functions. Even though that may not be much, Timers usually run often and every frame within Ogre; if the functionality is not needed by Ogre then I'd rather not do it.
-
- Greenskin
- Posts: 121
- Joined: Thu Oct 07, 2004 8:38 am
Re: Ogre::Timer::Pause, UnPause
First I should point out I don't really care one way or another, a friend asked me the question, my initial reaction was the same as yours. However after thinking a bit more I thought it was a useful and appropriate idea because it really is simple and not outside the limited scope of the class. (imo)
Here Timer is simply providing real time (that can't be stoped or changed)
By that logic you wouldn't have reset(), or getMilliseconds(). After all the real system time perpetually increments until it overflows it doesn't give you elapsed time between two arbitrary points, and getMilliseconds triggers a divide op which you might not want. A pause is pretty much on the same footing, though it would require one if to implement.Ogre::Timer is defined to only give (hardware) real time passed, and nothing more
Works for me, I'd rather keep the devs happy lolPause/Unpause requires additional logic and therefore more operations to perform all of Timer's functions. Even though that may not be much, Timers usually run often and every frame within Ogre; if the functionality is not needed by Ogre then I'd rather not do it.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Ogre::Timer::Pause, UnPause
The thing is this:
Timer stores one timestamp, the time when it was started (or reset). Measuring time means taking another timestamp and returning the difference between the two, optionally scaled by the required unit of time.
You cannot implement a pause/unpause functionality with this setup, so you would have to rewrite the entire class. This is not going to happen unless there is a really good reason to.
Timer stores one timestamp, the time when it was started (or reset). Measuring time means taking another timestamp and returning the difference between the two, optionally scaled by the required unit of time.
You cannot implement a pause/unpause functionality with this setup, so you would have to rewrite the entire class. This is not going to happen unless there is a really good reason to.
- SunSailor
- Gnoll
- Posts: 699
- Joined: Sun Jan 02, 2005 5:45 pm
- Location: Velbert, Germany
- x 2
- Contact:
Re: Ogre::Timer::Pause, UnPause
In my opinion, pause and unpause are a matter of the game state management, not of a core class. In a practical case, you mostly want to stop and resume some of your events, but most likely not all of them, or you want to fade them by switching between states.
- _tommo_
- Gnoll
- Posts: 677
- Joined: Tue Sep 19, 2006 6:09 pm
- x 5
- Contact:
Re: Ogre::Timer::Pause, UnPause
I think that this will be the design i will adopt in my next games... it is much more powerful and versatile than a "pause/unpause" function because allows coupling between time speed, game state and time consumers.Klaim wrote:You shouldn't use this class as anything other than a "real" time information source. In "reality", there is no pause.
So a better idea is to create some kind of "virtual" clock that get the real time passed info from anywhere else-- for example, Ogre::Timer -- and then will provide a time that can be paused or event accelerated or slow down (by using a time flow factor to each time update).
I'm doing this and it works great. You can see an old version of my code there, just to get the global idea :
- gcore::ClockManager header cpp
- gcore::Clock header cpp
- gcore::TimeProvider header << this one is the base class for an implementation that might use Ogre::Timer -- in fact that's what i use in my game.
There are other ways to implement this (and it's a bit old code). Be critic and curious.
Hope it helps.
Just using two different TimeZones (i prefer it over TimeProvider ) you can have objects that animate or lose their health at different rates, for example if the player freezed the game.
In my design i also use timers as "update callbacks", more like Ogre's framelisteners, but tied to a fixed timestep (alterated by the time step multiplier).
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Ogre::Timer::Pause, UnPause
Not sure I understood what you said here but in my system TimeProvider provide the real precise time for the whole system, and if you need different time flows then you need different Clocks. Each clock get updated when the ClockManager get updated but they go at Clock-specific timeflow.Just using two different TimeZones (i prefer it over TimeProvider ) you can have objects that animate or lose their health at different rates, for example if the player freezed the game.
I added a "Timer" system over my Clock system but didn't use it in the end because I need to predict exactly when the time passed will be checked.In my design i also use timers as "update callbacks", more like Ogre's framelisteners, but tied to a fixed timestep (alterated by the time step multiplier).
- _tommo_
- Gnoll
- Posts: 677
- Joined: Tue Sep 19, 2006 6:09 pm
- x 5
- Contact:
Re: Ogre::Timer::Pause, UnPause
I just misunderstood the use of your TimeProvider by its name then!Klaim wrote:Not sure I understood what you said here but in my system TimeProvider provide the real precise time for the whole system, and if you need different time flows then you need different Clocks. Each clock get updated when the ClockManager get updated but they go at Clock-specific timeflow.
I am using Timer as your Clock, so as a "time consumer", and TimeZones as ClockManager + TimeProvider.
So, a Timer has a scaling factor that it applies to the time fetched from the TimeZone it was created from.
A TimeZone creates the Timers for you, and has an additional scaling factor that influences any of its child Timers.
For example, GameState inherits by default a TimeZone for the frame-by-frame game object updates.
In this design i tried to avoid having timers that need to be updated by their parent; for their primary task of providing read-only time values they just fetch their TimeZone when needed; this because you can have as much as one timer per GameObject.
The timer is updated each frame only if you register one or more scheduled callbacks to it.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Ogre::Timer::Pause, UnPause
That's an interesting design! If you make it available somewhere once polished, I'd be interested to read (and maybe use) it
- _tommo_
- Gnoll
- Posts: 677
- Joined: Tue Sep 19, 2006 6:09 pm
- x 5
- Contact:
Re: Ogre::Timer::Pause, UnPause
I was thinking about releasing my whole IOS engine, but it's a long way from polishedKlaim wrote:That's an interesting design! If you make it available somewhere once polished, I'd be interested to read (and maybe use) it
Also the timer thing is mostly at a "design" stage, so there isn't much to share
Maybe sometimes i will up this thread...