🔒 Locked

DXTimer vs. Loops

Started by Lumin Oct 4, 2001 at 3:51 PM 5 replies 1.2k views

Original Post

Oct 4, 2001 at 3:51 PM

Greetings, I just want to know what each one of you have experienced using either loops or the DXTimer component. I made a little test today to check if the DXTimer was as fast as my loop. My loop turned out to give a steady 85 fps on a 640x480 windowed mode screen. I then proceeded to use a DXTimer and it ran at about 85 fps (sometimes it dodged down to 83 for a few sec) I used only 2 moving sprites (The two sprites was a set 5 pictures each in an animation sequence.) Also I had a background picture. Now what I wonder is if Im gona feel it later on if I make my game using the timer or if it is equaly as good as a loop (that ofcourse depends on how well the loop is made, but lets say I do it medium to good

) what I have experienced sofar using loops is that getting key imputs and using the timer to other things is difficult as the loop consumes much of the programs time (I have managed to find a good way of getting the keyboard part but I still strugle with the timer, and it would be nice to have it instead trying to incorperate thsoe parts in the loop). The fact is that the game will not be graphic intensive (3d and special effects) it will be realy just a bunch of animated sprites (around 64 or so at the same time) and ofcourse some background sprites. So anyone got any good Advices ? -Lumin

Sly

Oct 4, 2001 at 6:47 PM

Commercial games generally use the message loop similar to this...


while not Finished do
begin
  while PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE) do
  begin
    if GetMessage(Msg, 0, 0, 0) then
    begin
      TranslateMessage();
      DispatchMessage();
    end
    else
    begin
      Finished := True;
    end;
  end;
  GameUpdate();
  GameDraw();
end;

This is easily simulated using the Application.OnIdle event in the following manner...


procedure TForm1.AppIdle(Sender: TObject; var Done: Boolean);
begin
  Game_Update();
  Game_Draw();
  Done := False;
end;

Setting the DXTimer interval to zero also closely simulates this behaviour.

Steve ''Sly'' Williams Monkey Wrangler Krome Studios

Lifepower

Oct 5, 2001 at 9:03 AM

DXTimer.Interval = 0 -> same as OnIdle loop.
And if you''re so anxious about dual CPU systems (which are not very popular though) - create more threads, but still render on your idle loop (Video card has only one CPU, if it has any) if you don''t want to block your poor M$ Windoze system...

Gunner55

Oct 5, 2001 at 10:41 AM

Hi,

Just a note,
For your 85 fps benchmark vs 83 fps, there might just of been a Hard disk access when you tested the timer.
Also, those figures reflect your refresh rate and not the true framerate, that''s why they''ll always roof at 85.

Try and run your simulations with v-sync off, this will give you a better approximation of the true framerate

Hope this helps.

Best regards,

Gunner

turbo

Oct 6, 2001 at 10:01 AM

I like Hori''s DXTimer because it includes "LagCount" and "FrameRate" functionality. It makes things pretty easy to lock into a specific FPS. Here''s a good way to user it...


procedure TLaunchForm.DXTimer(Sender: TObject; LagCount: Integer);
begin
  // this procedure does all our gameplay/input/calculations
  EngineTick(nil);
  // exit if DXDraw is busy
  if not DXDraw.CanDraw then Exit;
  // exit if we''re lagging (i.e. FrameSkip)
  if LagCount > 1 then Exit;
  // this does all the drawing to DXDraw
  EngineDisplay(nil);
  // this ajusts our framerate to our target
  if DXTimer.Framerate > TargetFrameRate inc(DXTimer.Interval)
  if DXTimer.Framerate < TargetFrameRate dec(DXTimer.Interval)
end;

Now all you do is put gameplay code in EngineTick and display code in EngineDisplay and now you have a Timer that constantly pushes toward a framerate specified in TargetFrameRate.

[ Michael Wilson | turbo sys-op | turbo.gamedev.net ]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.