* Ada, games and frame rate calculation @ 2005-02-16 21:32 Luke A. Guest 2005-02-16 22:16 ` Stephen Leake 0 siblings, 1 reply; 18+ messages in thread From: Luke A. Guest @ 2005-02-16 21:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-16 21:32 Ada, games and frame rate calculation Luke A. Guest @ 2005-02-16 22:16 ` Stephen Leake 2005-02-16 23:03 ` Luke A. Guest 2005-02-17 0:06 ` Jeffrey Carter 0 siblings, 2 replies; 18+ messages in thread From: Stephen Leake @ 2005-02-16 22:16 UTC (permalink / raw) To: comp.lang.ada "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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-16 22:16 ` Stephen Leake @ 2005-02-16 23:03 ` Luke A. Guest 2005-02-17 0:55 ` Stephen Leake 2005-02-17 23:23 ` Randy Brukardt 2005-02-17 0:06 ` Jeffrey Carter 1 sibling, 2 replies; 18+ messages in thread From: Luke A. Guest @ 2005-02-16 23:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-16 23:03 ` Luke A. Guest @ 2005-02-17 0:55 ` Stephen Leake 2005-02-17 2:33 ` tmoran 2005-02-17 8:39 ` Dmitry A. Kazakov 2005-02-17 23:23 ` Randy Brukardt 1 sibling, 2 replies; 18+ messages in thread From: Stephen Leake @ 2005-02-17 0:55 UTC (permalink / raw) To: comp.lang.ada "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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-17 0:55 ` Stephen Leake @ 2005-02-17 2:33 ` tmoran 2005-02-17 8:39 ` Dmitry A. Kazakov 1 sibling, 0 replies; 18+ messages in thread From: tmoran @ 2005-02-17 2:33 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-17 0:55 ` Stephen Leake 2005-02-17 2:33 ` tmoran @ 2005-02-17 8:39 ` Dmitry A. Kazakov 1 sibling, 0 replies; 18+ messages in thread From: Dmitry A. Kazakov @ 2005-02-17 8:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-16 23:03 ` Luke A. Guest 2005-02-17 0:55 ` Stephen Leake @ 2005-02-17 23:23 ` Randy Brukardt 2005-02-19 14:48 ` Simon Wright 1 sibling, 1 reply; 18+ messages in thread From: Randy Brukardt @ 2005-02-17 23:23 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-17 23:23 ` Randy Brukardt @ 2005-02-19 14:48 ` Simon Wright 0 siblings, 0 replies; 18+ messages in thread From: Simon Wright @ 2005-02-19 14:48 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-16 22:16 ` Stephen Leake 2005-02-16 23:03 ` Luke A. Guest @ 2005-02-17 0:06 ` Jeffrey Carter 2005-02-17 2:33 ` tmoran 1 sibling, 1 reply; 18+ messages in thread From: Jeffrey Carter @ 2005-02-17 0:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-17 0:06 ` Jeffrey Carter @ 2005-02-17 2:33 ` tmoran 2005-02-17 22:08 ` Simon Wright 2005-02-18 0:06 ` Jeffrey Carter 0 siblings, 2 replies; 18+ messages in thread From: tmoran @ 2005-02-17 2:33 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-17 2:33 ` tmoran @ 2005-02-17 22:08 ` Simon Wright 2005-02-18 0:06 ` Jeffrey Carter 1 sibling, 0 replies; 18+ messages in thread From: Simon Wright @ 2005-02-17 22:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-17 2:33 ` tmoran 2005-02-17 22:08 ` Simon Wright @ 2005-02-18 0:06 ` Jeffrey Carter 2005-02-18 5:30 ` tmoran 2005-02-18 9:04 ` Adrien Plisson 1 sibling, 2 replies; 18+ messages in thread From: Jeffrey Carter @ 2005-02-18 0:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-18 0:06 ` Jeffrey Carter @ 2005-02-18 5:30 ` tmoran 2005-02-19 0:03 ` Jeffrey Carter 2005-02-18 9:04 ` Adrien Plisson 1 sibling, 1 reply; 18+ messages in thread From: tmoran @ 2005-02-18 5:30 UTC (permalink / raw) > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-18 5:30 ` tmoran @ 2005-02-19 0:03 ` Jeffrey Carter 2005-02-19 0:45 ` tmoran 0 siblings, 1 reply; 18+ messages in thread From: Jeffrey Carter @ 2005-02-19 0:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-19 0:03 ` Jeffrey Carter @ 2005-02-19 0:45 ` tmoran 2005-02-19 22:19 ` Jeffrey Carter 0 siblings, 1 reply; 18+ messages in thread From: tmoran @ 2005-02-19 0:45 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-19 0:45 ` tmoran @ 2005-02-19 22:19 ` Jeffrey Carter 0 siblings, 0 replies; 18+ messages in thread From: Jeffrey Carter @ 2005-02-19 22:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-18 0:06 ` Jeffrey Carter 2005-02-18 5:30 ` tmoran @ 2005-02-18 9:04 ` Adrien Plisson 2005-02-18 9:19 ` Vinzent 'Gadget' Hoefler 1 sibling, 1 reply; 18+ messages in thread From: Adrien Plisson @ 2005-02-18 9:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada, games and frame rate calculation 2005-02-18 9:04 ` Adrien Plisson @ 2005-02-18 9:19 ` Vinzent 'Gadget' Hoefler 0 siblings, 0 replies; 18+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2005-02-18 9:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-02-19 22:19 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-02-16 21:32 Ada, games and frame rate calculation Luke A. Guest 2005-02-16 22:16 ` Stephen Leake 2005-02-16 23:03 ` Luke A. Guest 2005-02-17 0:55 ` Stephen Leake 2005-02-17 2:33 ` tmoran 2005-02-17 8:39 ` Dmitry A. Kazakov 2005-02-17 23:23 ` Randy Brukardt 2005-02-19 14:48 ` Simon Wright 2005-02-17 0:06 ` Jeffrey Carter 2005-02-17 2:33 ` tmoran 2005-02-17 22:08 ` Simon Wright 2005-02-18 0:06 ` Jeffrey Carter 2005-02-18 5:30 ` tmoran 2005-02-19 0:03 ` Jeffrey Carter 2005-02-19 0:45 ` tmoran 2005-02-19 22:19 ` Jeffrey Carter 2005-02-18 9:04 ` Adrien Plisson 2005-02-18 9:19 ` Vinzent 'Gadget' Hoefler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox