Page 1 of 1

Ogre::Timer::Pause, UnPause

Posted: Tue Nov 02, 2010 7:23 am
by entelin
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Tue Nov 02, 2010 5:08 pm
by Klaim
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Tue Nov 02, 2010 10:05 pm
by entelin
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Tue Nov 02, 2010 11:29 pm
by Klaim
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 03, 2010 10:00 am
by ImpalerWrG
Klaim wrote: Ogre::Timer is meant to provide a reliable source of real time value. No more, no less.
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 03, 2010 3:50 pm
by Klaim
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 03, 2010 7:30 pm
by syedhs
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 03, 2010 9:49 pm
by Klaim
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...

Re: Ogre::Timer::Pause, UnPause

Posted: Thu Nov 04, 2010 8:40 am
by shadowfeign
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Thu Nov 04, 2010 8:46 am
by CABAListic
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Thu Nov 04, 2010 8:58 am
by entelin
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)
Ogre::Timer is defined to only give (hardware) real time passed, and nothing more
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.
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.
Works for me, I'd rather keep the devs happy lol

Re: Ogre::Timer::Pause, UnPause

Posted: Thu Nov 04, 2010 9:01 am
by CABAListic
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Mon Nov 15, 2010 1:13 am
by SunSailor
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 17, 2010 3:40 am
by _tommo_
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.
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.
Just using two different TimeZones (i prefer it over TimeProvider :D ) 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).

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 17, 2010 1:31 pm
by Klaim
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.
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.
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).
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 17, 2010 4:24 pm
by _tommo_
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 just misunderstood the use of your TimeProvider by its name then!
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.

Re: Ogre::Timer::Pause, UnPause

Posted: Wed Nov 17, 2010 11:59 pm
by Klaim
That's an interesting design! If you make it available somewhere once polished, I'd be interested to read (and maybe use) it :)

Re: Ogre::Timer::Pause, UnPause

Posted: Thu Nov 18, 2010 12:33 pm
by _tommo_
Klaim wrote:That's an interesting design! If you make it available somewhere once polished, I'd be interested to read (and maybe use) it :)
I was thinking about releasing my whole IOS engine, but it's a long way from polished :D
Also the timer thing is mostly at a "design" stage, so there isn't much to share :roll:
Maybe sometimes i will up this thread...