Ogre::Timer::Pause, UnPause

What it says on the tin: a place to discuss proposed new features.
Post Reply
entelin
Greenskin
Posts: 121
Joined: Thu Oct 07, 2004 8:38 am

Ogre::Timer::Pause, UnPause

Post by entelin » Tue Nov 02, 2010 7:23 am

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.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by Klaim » Tue Nov 02, 2010 5:08 pm

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.
0 x

entelin
Greenskin
Posts: 121
Joined: Thu Oct 07, 2004 8:38 am

Re: Ogre::Timer::Pause, UnPause

Post by entelin » Tue Nov 02, 2010 10:05 pm

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.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by Klaim » Tue Nov 02, 2010 11:29 pm

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.
0 x

User avatar
ImpalerWrG
Gnoblar
Posts: 15
Joined: Sat Feb 27, 2010 7:42 am

Re: Ogre::Timer::Pause, UnPause

Post by ImpalerWrG » Wed Nov 03, 2010 10:00 am

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.
0 x
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.

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by Klaim » Wed Nov 03, 2010 3:50 pm

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.
0 x

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 3

Re: Ogre::Timer::Pause, UnPause

Post by syedhs » Wed Nov 03, 2010 7:30 pm

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.
0 x
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

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by Klaim » Wed Nov 03, 2010 9:49 pm

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...
0 x

User avatar
shadowfeign
Goblin
Posts: 213
Joined: Mon Jan 26, 2009 11:51 pm

Re: Ogre::Timer::Pause, UnPause

Post by shadowfeign » Thu Nov 04, 2010 8:40 am

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.
0 x

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by CABAListic » Thu Nov 04, 2010 8:46 am

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.
0 x

entelin
Greenskin
Posts: 121
Joined: Thu Oct 07, 2004 8:38 am

Re: Ogre::Timer::Pause, UnPause

Post by entelin » Thu Nov 04, 2010 8:58 am

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
0 x

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by CABAListic » Thu Nov 04, 2010 9:01 am

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.
0 x

User avatar
SunSailor
Gnoll
Posts: 699
Joined: Sun Jan 02, 2005 5:45 pm
Location: Velbert, Germany
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by SunSailor » Mon Nov 15, 2010 1:13 am

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.
0 x
Online-Distribution with Jade-DS, Ogre-Wrapper included.
Follow me on Twitter for updates!

User avatar
_tommo_
Gnoll
Posts: 677
Joined: Tue Sep 19, 2006 6:09 pm
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by _tommo_ » Wed Nov 17, 2010 3:40 am

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).
0 x
OverMindGames Blog
IndieVault.it: Il nuovo portale italiano su Game Dev & Indie Games

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by Klaim » Wed Nov 17, 2010 1:31 pm

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.
0 x

User avatar
_tommo_
Gnoll
Posts: 677
Joined: Tue Sep 19, 2006 6:09 pm
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by _tommo_ » Wed Nov 17, 2010 4:24 pm

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.
0 x
OverMindGames Blog
IndieVault.it: Il nuovo portale italiano su Game Dev & Indie Games

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by Klaim » Wed Nov 17, 2010 11:59 pm

That's an interesting design! If you make it available somewhere once polished, I'd be interested to read (and maybe use) it :)
0 x

User avatar
_tommo_
Gnoll
Posts: 677
Joined: Tue Sep 19, 2006 6:09 pm
Contact:

Re: Ogre::Timer::Pause, UnPause

Post by _tommo_ » Thu Nov 18, 2010 12:33 pm

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...
0 x
OverMindGames Blog
IndieVault.it: Il nuovo portale italiano su Game Dev & Indie Games

Post Reply