#include <SFML/System.hpp>
template <class TClass>
class FTTimer : public sf::Thread
{
public:
FTTimer( TClass* _class, void (TClass::*_ptr)(), int ms_ival )
{
if(_class != NULL && _ptr != NULL)
{
ptr = _ptr; ptObj = _class; ival = ms_ival; Launch(); pause = false; alive = true;
}else
{
ptr = NULL; ptObj = NULL; ival = 0; alive = false; pause = true;
}
}
~FTTimer(){ KillTimer(); }
void TooglePause(){ pause = !pause; }
void KillTimer(){ alive = false; ptr = NULL; ptObj = NULL; }
double GetDt(){ return ival/1000.0f; }
private:
virtual void Run()
{
while(alive)
{
if(!pause)
{
(*ptObj.*ptr)();
Sleep(ival);
}
}
}
void (TClass::*ptr)();
TClass* ptObj;
int ival;
int current;
bool pause;
bool alive;
};
Timer on Thread
Author
Hi, i want to know if this is good a approach:
The main idea is to create one thread per timer, if the timer is alive call the function callback, sleep the time specified and continue. This approach still has no problems at all, but all i ever wanted is to know how WxWidgets or SDL manage timers, if they use threads or what.
Thanks
One thread per timer seems extremely inefficient. Remember, on Windows, threads get 1MB of stack space by default, so if you've got 100 times, that's 100MB right there.
If you have a game loop, you don't need to use separate threads at all. Just create your own "timer" class and check each frame whether the time has expired. If it has, execute the timer. If not, keep going. You can keep all of your "timer" objects together in a list, sorted by "due" time and then just pick the first one off the queue to see whether it's time is up. This is how I do it in my game.
For example:
Of course, that's just pseudocode...
If you have a game loop, you don't need to use separate threads at all. Just create your own "timer" class and check each frame whether the time has expired. If it has, execute the timer. If not, keep going. You can keep all of your "timer" objects together in a list, sorted by "due" time and then just pick the first one off the queue to see whether it's time is up. This is how I do it in my game.
For example:
class Timer{private: float due_time_; boost::function<void ()> callback_;public: Timer(float due_time, boost::function<void ()> callback) : due_time_(due_time), callback_(callback) { } bool tick(float curr_time) { if (curr_time <= due_time_) { callback_(); return true; } else { return false; } }};...std::vector<Timer> timers; // keep this sorted by the "due_time"void game_update(){ // ... std::vector<Timer>::iterator it = timers.begin(); while (it != timers.end() && it->tick(curr_time)) { timers.erase(it); it = timers.begin(); } // ...}Of course, that's just pseudocode...
Author
Thanks for reply so fast!
I already have my own timer, it works fine, the classical approach of get
the time differential between frames, but what happens if the game loop fails,
or is paused by a large amount of time? we need some things to still going on.
This is because my game is all about of having a face looking at the camera
all the time, talking to you with lip sync, we need full synchronization, that's
why i need to force the animation to be at exact 60fps..
Maybe as you said this is unnecessary, with a solid timer and vertical sync is ok, thanks for the advice, as i though a thread is just too much for a timer.
I already have my own timer, it works fine, the classical approach of get
the time differential between frames, but what happens if the game loop fails,
or is paused by a large amount of time? we need some things to still going on.
This is because my game is all about of having a face looking at the camera
all the time, talking to you with lip sync, we need full synchronization, that's
why i need to force the animation to be at exact 60fps..
Maybe as you said this is unnecessary, with a solid timer and vertical sync is ok, thanks for the advice, as i though a thread is just too much for a timer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
