Aum 80

Dear friends,

The new magazine is ready: Aum80

Have a nice day.
George

Thanks George!

Thanks! You're the best!

Thank you George. Excellent content as per usual.

Drac.

added to AUM Online.

Here you can find the online version of this and all previous issues.

AUM Search has now 887 indexed pages.

Great work nfs42 !

Drac.

Thank You, guys.
Nfs42, you are my hero!

thank you george!
great magazine! i love it!

if u want u can use my contribution for the next aum

take a look at this link 2.5D Spacegame

greetings
marcel

Thanks a bunch for the great effort George
Aum is always a pleasure to read

Cheers

Frazzle

Thank you for the kind words, guys.
Maslone1: sure, I will include your contribution.

Always grateful for your efforts, George.

George, I noticed you used this method to count up seconds (Questions from the forum)

time_passed += time_step / 16;

rather than

wait(-1);
time_passed += 1;

Is there a difference? I've been struggling with an accurate timing code in my game. Does time_step equal a time duration of 16 seconds?

The manual says time_step is used for movement and frame rate compensation. Boy am I confused...but that's my normal state.

Quoting JazzDude.

@256?
According to some data, the following is an approximation (with faults):
time_step is the duration between frames in ticks.
one tick = 1/16 of second.
seconds = time_step / 16 or time_step * 0.0625 (1/16).
(precision considerations: division OR multiplication is preferred here?)
Usage (above) MAY produce more precise results than wait(-t)!?
Perhaps, if (+1) eval code is used with dependencies and no carry over (int), results may vary with timing hits?

precision (var 10-22): over extended period of time, fast / slow machines may be out of sync?

Certainly, George can provide better answers / replies.

So, a framerate of 10 fps would have 160 ticks per second.
but a framerate of 100 fps would have 1600 ticks per second.

If that's the case, time duration based on time_step would be totally dependent on cpu or graphics muscle. Or so it appears to me.

I must be missing something, because on my computer both methods give the same result regardless of frame rate.

Possibly somethings wrong with your math
one tick = 1/16 of second.
that means one second = 16 ticks.
So, a framerate of 10 fps would have 16 ticks per second.
and a framerate of 100 fps would have 16 ticks per second.

We've got 16 ticks per second regardless of the frame rate.
My "while(1)" loop method allows you to stop the process immediately using a break instruction. If I would use something like this

wait(-1);
time_passed += 1;

I would have to wait until the entire second passes; I can't interrupt the process earlier if I need to.

On the other hand, "time_passed += time_step / 16;" adds 1 to time_passed each second. A loop that runs until time_passed is greater than or equal to 3 will run for 3 seconds, and so on.

I hope that this explains what's happening; let me know if you need more info.

I'm still asking, "Is time_step a measure of time duration", and if I am understanding this, it is.

If it is, one second contains 16 ticks.

from the manual:


Now, I can't reconcile those two things.

Anyway, no need to belabor the point in this thread. Maybe it'll get thru to me after a while. I'll work on it. Thanks.

time_step is the length of the LAST frame, not of the running frame. So if there is a very long frame and then a very short one, objects will "jump" in that short frame. AFAIK you can prevent that with time_smooth.

time_step changes its value from one frame to the other. You can use Windows' api to build a high precision timer.

hey, thanks George.

btw. when will there be some informations about the new competition?

Thanks George,
Awesome as always.

@Fear411 in aum81 i guess.

Quadraxas is right; the new contest will be announced in the following magazine.

Thankyou George, Your AUM's are and always will be a valuable asset.