Ada, games and frame rate calculation

Ada, games and frame rate calculation

[Luke A. Guest]

Hi,

I'm currently designing a game engine in Ada and was wondering about using
the Ada.Real_Time facilities (especially the timing).

Now, normally you get the current time calculate how much time has passed
since the last time it was called. These values are used to implement
frame rate (FPS) display and to animated models. So ultimately, I need to
get access to the internals (I think).

So, as an example, I have my Ada.Real_Time.Time type which is my FPS, I
now have to display this on screen, so I need to determine the actual text
from the value. How do I do this?

Thanks,
Luke.

Re: Ada, games and frame rate calculation

[Stephen Leake]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:

> Hi,
> 
> I'm currently designing a game engine in Ada and was wondering about using
> the Ada.Real_Time facilities (especially the timing).

If you are using GNAT on Windows, there is no difference between
Ada.Real_Time and Ada.Calendar. On other compilers and operating
systems, there may be a difference.

> Now, normally you get the current time calculate how much time has
> passed since the last time it was called. These values are used to
> implement frame rate (FPS) display and to animated models. 

I'm a little confused by this. A typical loop should be:

declare
   use Ada.Real_Time; -- or Calendar
   Next_Time  : Time; 
   Frame_Time : Time_Span := To_Time_Span (0.0333); 
begin
   loop
      Next_Time := Next_Time + Frame_Time;
      delay until Next_Time;
      --  do stuff here
   end loop;
end;

> So ultimately, I need to get access to the internals (I think).

No, that should never be necessary.

> So, as an example, I have my Ada.Real_Time.Time type which is my
> FPS, I now have to display this on screen, so I need to determine
> the actual text from the value. How do I do this?

Use Split and To_Duration:

declare
    seconds : seconds_Count;
    fraction : time_span;
begin
    split (Next_time, seconds, fraction);
    put_Line (seconds_count'image (Seconds) & "." & duration'image
      (to_duration (fraction)));
end;

That's not a very clean format, but you get the idea.

-- 
-- Stephe

Re: Ada, games and frame rate calculation

[Luke A. Guest]

On Wed, 16 Feb 2005 17:16:06 -0500, Stephen Leake wrote:

> "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:
> 
>> Hi,
>> 
>> I'm currently designing a game engine in Ada and was wondering about using
>> the Ada.Real_Time facilities (especially the timing).
> 
> If you are using GNAT on Windows, there is no difference between
> Ada.Real_Time and Ada.Calendar. On other compilers and operating
> systems, there may be a difference.

It's portable, so yeah there will be a windaz build. My main development
platform is Linux. I'm surprised that the win32 is identical to Calendar,
well not that surprised ;-) just as long as I can get milliseconds from it
then that'll be fine. Although, I would've thought they'd have used the
performance counters for the Ada.Real_Time package!

>> Now, normally you get the current time calculate how much time has
>> passed since the last time it was called. These values are used to
>> implement frame rate (FPS) display and to animated models. 
> 
> I'm a little confused by this. A typical loop should be:
> 
> declare
>    use Ada.Real_Time; -- or Calendar
>    Next_Time  : Time; 
>    Frame_Time : Time_Span := To_Time_Span (0.0333); 
> begin
>    loop
>       Next_Time := Next_Time + Frame_Time;
>       delay until Next_Time;
>       --  do stuff here
>    end loop;
> end;

You don't have to delay...what's confusing? It's a game engine, you want
it to run as fast as possible, but by utilising certain Ada language
features, you get some extra nice functionality that's portable.
 
>> So ultimately, I need to get access to the internals (I think).
> 
> No, that should never be necessary.

Well, not at the bit level no ;-) I have been told and I've verified it,
that I can use Duration and use that to get the string value to display.

>> So, as an example, I have my Ada.Real_Time.Time type which is my FPS, I
>> now have to display this on screen, so I need to determine the actual
>> text from the value. How do I do this?
> 
> Use Split and To_Duration:
> 
> declare
>     seconds : seconds_Count;
>     fraction : time_span;
> begin
>     split (Next_time, seconds, fraction); put_Line (seconds_count'image
>     (Seconds) & "." & duration'image
>       (to_duration (fraction)));
> end;
> 
> That's not a very clean format, but you get the idea.

Well, here's my current FPS calculation:


  procedure CalculateFPS is

    CurrentTime         : Float := Float(SDL.Timer.GetTicks) / 1000.0;
    ElapsedTime         : Float := CurrentTime - LastElapsedTime;
    FramesPerSecond     : String(1 .. 10);
    MillisecondPerFrame : String(1 .. 10);

    package Float_InOut is new Text_IO.Float_IO(Float);
    use Float_InOut;

  begin

    FrameCount := FrameCount + 1;

    if ElapsedTime > 1.0 then

      FPS := Float(FrameCount) / ElapsedTime;

      Put(FramesPerSecond, FPS, Aft => 2, Exp => 0);
      Put(MillisecondPerFrame, 1000.0 / FPS, Aft => 2, Exp => 0);

      SDL.Video.WM_Set_Caption_Title(Example.GetTitle & "  " & FramesPerSecond
& " fps  " & MillisecondPerFrame & " ms/frame");

      LastElapsedTime := CurrentTime;
      FrameCount      := 0;

    end if;

  end CalculateFPS;

Now that uses SDL, but ultimately that's not portable and I won't be using
SDL in the long run and cannot depend on it.

Luke.

Re: Ada, games and frame rate calculation

[Jeffrey Carter]

Stephen Leake wrote:

>    Frame_Time : Time_Span := To_Time_Span (0.0333); 

Only 3 sig digits? I'd do something like

Frame_Length : constant := 1.0 / 30.0; -- Maximal precision

Frame_Time : constant Time_Span := To_Time_Span (Frame_Length);

GNAT, IIRC, has an accuracy of 1 ns, so 0.0333 is going to be a lot 
different than 1.0 / 30.0.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08

Re: Ada, games and frame rate calculation

[Stephen Leake]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:

> On Wed, 16 Feb 2005 17:16:06 -0500, Stephen Leake wrote:
> 
> > "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:
> > 
> >> Hi,
> >> 
> >> I'm currently designing a game engine in Ada and was wondering about using
> >> the Ada.Real_Time facilities (especially the timing).
> > 
> > If you are using GNAT on Windows, there is no difference between
> > Ada.Real_Time and Ada.Calendar. On other compilers and operating
> > systems, there may be a difference.
> 
> It's portable, so yeah there will be a windaz build. My main development
> platform is Linux. I'm surprised that the win32 is identical to Calendar,
> well not that surprised ;-) just as long as I can get milliseconds from it
> then that'll be fine. 

You can read the clock with microsecond precision (on Windows and some
other platforms); you can only delay with an accuracy of about 10
milliseconds (again on Windows).

> Although, I would've thought they'd have used the performance
> counters for the Ada.Real_Time package!

I'm not sure what clock they are reading.
 
> You don't have to delay...what's confusing? It's a game engine, you want
> it to run as fast as possible, but by utilising certain Ada language
> features, you get some extra nice functionality that's portable.

Ah. You are just measureing your frame rate; I thought you were trying
to set it to some known value.

-- 
-- Stephe

Re: Ada, games and frame rate calculation

[tmoran]

> GNAT, IIRC, has an accuracy of 1 ns, so 0.0333 is going to be a lot
  Type Duration has a small 'small, but the Windows Performance Counter
only ticks (approximately) every 1/nth of a microsecond, where n = 3 on
the machine I'm using now.  So two successive clock reads, if they don't
give the same value, will differ at least by 300 or so nanoseconds.
  You may want to look up "Time the Clock" on AdaPower.

Re: Ada, games and frame rate calculation

[tmoran]

> You can read the clock with microsecond precision (on Windows and some
> other platforms); you can only delay with an accuracy of about 10
> milliseconds (again on Windows).
   That depends on how you delay.  There are Windows calls for delays, but
you can also have a spin delay whose accuracy is limited by the clock
tick, clock reading time, and maximum delay caused by other tasks.
  e.g.
   Go_Time := Ada.Calendar.Clock+0.000_058;  -- delay 58.0 microseconds
   while Ada.Calendar.Clock < Go_Time loop delay 0.0;end loop;
(But note this can fail on some motherboards where the clock jumps forward
several seconds if you re-read it too fast.)  Most, but IIRC not all,
compilers' run-times will do a "delay 0.0;" very fast if nothing else
needs to run.
  I believe the Janus system calls Windows for long delays but does its
own task management for short delays.

Re: Ada, games and frame rate calculation

[Dmitry A. Kazakov]

On 16 Feb 2005 19:55:02 -0500, Stephen Leake wrote:

> "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:
> 
>> It's portable, so yeah there will be a windaz build. My main development
>> platform is Linux. I'm surprised that the win32 is identical to Calendar,
>> well not that surprised ;-) just as long as I can get milliseconds from it
>> then that'll be fine. 
> 
> You can read the clock with microsecond precision (on Windows and some
> other platforms); you can only delay with an accuracy of about 10
> milliseconds (again on Windows).

This is a tunable parameter which default setting depends on the windows
version. It is 10ms under NT. I am not sure about XP, but it seems to be
about 1ms there.

Anyway, an application can screw it up to 1ms. The corresponding Win32 API
is timeBegPeriod. (It is a system-wide setting, BTW! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada, games and frame rate calculation

[Simon Wright]

tmoran@acm.org writes:

> > GNAT, IIRC, has an accuracy of 1 ns, so 0.0333 is going to be a lot
>   Type Duration has a small 'small, but the Windows Performance Counter
> only ticks (approximately) every 1/nth of a microsecond, where n = 3 on
> the machine I'm using now.  So two successive clock reads, if they don't
> give the same value, will differ at least by 300 or so nanoseconds.
>   You may want to look up "Time the Clock" on AdaPower.

The Booch Components (http://www.pushface.org/components/bc/) contain
an i86 high-res clock. On i86 the resolution is the timestamp counter,
ie basically the clock rate; I have a PowerPC implementation (but I
don't own the copyright), using the timebase, which has a coarser
resolution -- but 40 ns ain't bad!

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada, games and frame rate calculation

[Randy Brukardt]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote
in message
news:pan.2005.02.16.23.03.19.256588@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.
uk...
...
> Although, I would've thought they'd have used the
> performance counters for the Ada.Real_Time package!

Both GNAT and Janus/Ada use the performance counters for Calendar; thus
there is no need for Real_Time to be different. (I don't know about other
Ada compilers for sure.) Without using the performance counters, Calendar is
too coarse to be usable for delays on Windows.

                       Randy Brukardt.

Re: Ada, games and frame rate calculation

[Jeffrey Carter]

tmoran@acm.org wrote:

>>GNAT, IIRC, has an accuracy of 1 ns, so 0.0333 is going to be a lot
> 
>   Type Duration has a small 'small, but the Windows Performance Counter
> only ticks (approximately) every 1/nth of a microsecond, where n = 3 on
> the machine I'm using now.  So two successive clock reads, if they don't
> give the same value, will differ at least by 300 or so nanoseconds.

Right. I was talking about the accuracy of the representation, not the 
precision of the clock.

How does one read the HW clocks under Windows? I've heard that there is 
quantum randomness in the circuits that divide the oscillator to create 
the different clocks. Using a slower clock to decide when to read a 
faster clock, and keeping the LS bit of the faster clock's reading, 
results in a truly random string of bits. I'd like to play with it, but 
have yet to find anything on how it's done.

If it works well, I'd make it available under the GMGPL.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Ada, games and frame rate calculation

[tmoran]

> How does one read the HW clocks under Windows?
  I think of Windows as a super-CISC (virtual) machine.  Things like
interesting Pentium instructions, such as IO, are not available on that
machine (at least unless you write "device drivers").  :(

> I've heard that there is quantum randomness in the circuits that divide
> the oscillator to create
    Isn't there a single base clock source for the system and all other
clocks are just base/N for some N and thus synchronous?

Re: Ada, games and frame rate calculation

[Adrien Plisson]

Jeffrey Carter wrote:
> How does one read the HW clocks under Windows? 

there are two functions available: QueryPerformanceCounter together 
with QueryPerformanceFrequency.

it seems (though i'm not totally sure) to read the hardware clock: the 
resolution of the counter depends of the hardware you are running on.

i just tested: on my 3GHz pentium, QueryPerformanceFrequency returns 
2.99 GHz, which should make a counter resolution of 0.33 nanosecond. 
well, the problem is that MS does not give any indication of the 
precision of the counter. does it really count each clock tick or does 
it update every xxx tick ?

anyway, it is still the higher resolution timer available under Windows.

-- 
rien

Re: Ada, games and frame rate calculation

[Vinzent 'Gadget' Hoefler]

Adrien Plisson wrote:

> i just tested: on my 3GHz pentium, QueryPerformanceFrequency returns
> 2.99 GHz, which should make a counter resolution of 0.33 nanosecond.
> well, the problem is that MS does not give any indication of the
> precision of the counter. does it really count each clock tick

Yes, on modern x86 (Pentium and above) which have the RDTSC (Read Time
Stamp Counter) instruction it does. On older ones it probably uses the
timer ticks (which - in theory - should give a resolution of something
around one microsecond), but I don't know for sure.

Well, because we're talking about game programming it might be a valid
assumption that the usual gamer owns an up to date machine... ;-)


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: Ada, games and frame rate calculation

[Jeffrey Carter]

tmoran@acm.org wrote:

>>I've heard that there is quantum randomness in the circuits that divide
>>the oscillator to create
> 
>     Isn't there a single base clock source for the system and all other
> clocks are just base/N for some N and thus synchronous?

Read the part you quoted again. There's one source (oscillator), but the 
circuits that divide it introduce noise.

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

Re: Ada, games and frame rate calculation

[tmoran]

>Read the part you quoted again. There's one source (oscillator), but the
>circuits that divide it introduce noise.
  I still don't understand.  If the base clock sends
- - - - - - - - - - - - - - - - -    and a divided by 3 clock then sends
---   ---   ---   ---   ---   ---    (where "---" is actually a solid line)
the only opportunity I see for noise is when the slower clock's transition
slightly lags the other. But that lag is less than one tick of the fast
clock, and thus could only be noticed if you had a measuring instrument
with a resolution faster than the base clock - which is supposed to be
the fastest clock in the system.

Re: Ada, games and frame rate calculation

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Both GNAT and Janus/Ada use the performance counters for Calendar;
> thus there is no need for Real_Time to be different. (I don't know
> about other Ada compilers for sure.) Without using the performance
> counters, Calendar is too coarse to be usable for delays on Windows.

Only true if the external time can never change; if it can, then
D.8(32) isn't met.

  A clock jump is the difference between two successive distinct
  values of the clock (as observed by calling the Clock
  function). There shall be no backward clock jumps.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada, games and frame rate calculation

[Jeffrey Carter]

tmoran@acm.org wrote:

>   I still don't understand.  If the base clock sends
> - - - - - - - - - - - - - - - - -    and a divided by 3 clock then sends
> ---   ---   ---   ---   ---   ---    (where "---" is actually a solid line)
> the only opportunity I see for noise is when the slower clock's transition
> slightly lags the other. But that lag is less than one tick of the fast
> clock, and thus could only be noticed if you had a measuring instrument
> with a resolution faster than the base clock - which is supposed to be
> the fastest clock in the system.

I can't claim to really understand, either. I'm just repeating what I've 
read. See

http://comscire.com/Products/PCQNG20/

I would think an open-source implementation of this concept would be 
desirable.

-- 
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69