|
|
|
This thread is locked; no one can reply to it.
|
| A5 - Multiple TIMERS? |
|
KeithS
Member #11,950
May 2010
|
Hello, I hope this is not something that has been discussed so often that it causes lots of eye rolling to see the question here. I have not found anything on it, in any case. Reference: Timer Tutorial Let's say I have a program that uses some real world physics formulae, using units in seconds, for example. In the program I want to raise the time resolution to a calculation update every 1/100 of a second. Naturally, I will set a timer to update every 100th of a second (eg; BPS = 100), and call my functions on each "beat", with the affected units (eg; 100 meters per second) divided by BPS. Now, the problem. I want the screen to update (FPS) every 1/60 of a second, ie; not at the same rate as the BPS used for the physics calculations. What do I do? Or better asked; what is the correct way to handle this case with A5? Note: Thanks in advance! * * * * * * * * * * * |
|
AMCerasoli
Member #11,955
May 2010
 |
That's separating the logic for the drawing, a very very very discussed topic. I did one, when I was veeeery noob. Well actually three, you have: Separating Logic from Drawing Unfortunaly they're very useless, but you would be able to grasp something. But as a conclusion, If you don't want to get complicated (using different thread) just use two timer events, this way is not explained in any of the links I gave you. Edited: This is a good one too.
|
|
Desmond Taylor
Member #11,943
May 2010
 |
you could just register two timers to the event queue and check the source when the ALLEGRO_EVENT_TIMER call is made. |
|
Evert
Member #794
November 2000
 |
Fixed timesteps are not very good for integrating realistic physical functions anyway. You're better off implementing them in such a way that you can update them from the previous time to the current time while letting the integrator adjust its internal timestep. But yes, you can use multiple timers if you want to. |
|
KeithS
Member #11,950
May 2010
|
Thank you. You solved what was turning into a mystery for me. @AMCerasoli && Desmond Taylor; Ideally, yes, I was looking to run two timers and wait for the events off each to do their respective updates. It is what I used to do on Allegro 4.2 as the walk around. However, the problem was that Code::Blocks (on Debian64) was not giving me the complete list of options in the pop up box for the ev.timer structure. I was only getting options for .count and .error, which caused me to experiment with trying to obtain which timer was throwing an event by examining this way, which did not look right to start with... 1if(ev.type == ALLEGRO_EVENT_TIMER && al_is_event_queue_empty(event_queue))
2{
3 if(ev.timer == frame_timer)
4 // Note; did not know the ".source" option even existed
5 {
6 al_clear_to_color(clear_color);
7 al_flip_display();
8 }
9}
...causing the expected compile error. I did not find anything about this in the docs. My fault, though. Maybe I should have looked in the headers. Soluton found here, third post down on the linked page; AMCerasoli said: Edited: This is a good one too.
@Evert; My interpretation of your comment. Allow the physics to be updated at the computer's own speed (and get a return of the time_step to divide the physics by) and use the timer only to update the screen(?). The problem is the al_wait_for_event(), before the program will do anything. How can I access the program outside of the wait for event? Threads? Or am I misunderstanding completely? For the moment the present solution is great, and what I was looking for. Thanks again. * * * * * * * * * * * |
|
AMCerasoli
Member #11,955
May 2010
|
You could create your own user event with ALLEGRO_USER_EVENT and wait for that event with al_wait_for_event() since you would be emitting that event with al_emit_user_event() each time you run your logic at the maximum CPU speed, you could do what Evert suggested... I'm not pretty sure about this, though.
|
|
|
