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:
Notice that I may not necessarily want the BPS roundly divisible by the FPS, or I would put in an alternating switch to work around the problem. By this I mean I do not want BPS = 120 and FPS = 60.

Thanks in advance!

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
Separating Logic from Drawing Part II
Separating Logic from Drawing Part III - The Resurection (This one was written by Ben Delacob and edited by Sony entertainer television)

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.

you could just register two timers to the event queue and check the source when the ALLEGRO_EVENT_TIMER call is made.

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.

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

...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;

@Evert;
Indeed, the suggestion is what I am ultimately after, but let me be sure I am understanding exactly what you mean, first.

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.

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.