Page 7 of 7 FirstFirst ... 567
Results 61 to 67 of 67

Thread: PyroGineび「 Game Engine

  1. #61

    Re: PyroGineび「 Game Engine

    Hi,

    It only gets called once per frame as do any OnUpdate and OnRender methods. The problem your having is because aElapsedTime does not represent the value that you're expecting. The TPGTimer class in PGE uses frame-based timing. If you call TPGTimer.Init(35.05, 2), this tells the timer that you want your simulation to run at 35 fps and to try and maintain this rate if the rate drops by two times. So then what does aElapsedTime represent? If the current frame is running at 17.5 fps, in order to keep the simulation running at 35 fps, aElapsedTime would be a value of 1.5 so when you multiply your object speed by aElapsedTime then it will speed the objects up to keep the overall simulation at 35 fps. If the frame rate go to 60+ fps then aElapsedTime would be around 0.5. It will continue to try to do this if the frame drops/increases by two frames.

    The TPTimer class (PG.Timer) already has methods to help you with the timing your trying to do. You can use the TPTimer.FrameSpeed method. You use it like this:

    [code=delphi]var
    timer: Single;
    ...
    timer := 0;
    ...
    // return TRUE if 30 fps has elapsed
    if PG.FrameSpeed(timer, 30.0) then
    begin
    ...
    end;
    [/code]

    The timer variable is used so that you track different timing speeds if needed. So, when doing your timing, keep in mind that aElapsedTime will return a value to represents a quantity that will keep objects in your simulation running at the specified desired simulation rate. By default TPTimer will set to 35 fps. This is a historical value that I've used the past 8+ years. In general I've found that optimal and silky smooth animation is better if your simulation rate is multiple of your monitors refresh rate. 60Hhz is a standard refresh rate for all monitors and it tends to be the default. So running at slightly above half this rate has proven to produce good results. You can of coarse change the simulation timing to what ever value you choose, but keep in mind the things I've outlined here.

    So in this case your simulation is running a 35 fps. What you should do is this:

    [code=delphi]var
    FTimeCount: Single;
    FSecs: Integer;
    ...
    // update counter
    FTimeCount := FTimeCount + (1.0 * aElapsedTime);

    // check if a second has passed
    if FTimeCount >= PG.Timer.GetDesiredFPS then
    begin
    FTimeCount := FTimeCount - PG.Timer.GetDesiredFPS;
    Inc(FSecs);
    end
    [/code]
    Jarrod Davis
    Technical Director @ Piradyne Games

  2. #62

    Re: PyroGineび「 Game Engine

    Hi Jarrod, thanks for the quick reply!

    So you are saying that PG.DesiredFPS is equivalent to 1 second in sumulation time then?

    So if I wanted something to trigger at 1/2 second for example, I would use PG.DesiredFPS / 2?

    cool, I will give it a go..thanks dude

    cheers,
    Paul

  3. #63

    Re: PyroGineび「 Game Engine

    Im saying that PG.Timer.DesiredFPS is the value that you set when PG.Timer.Init was called. Since aElapsedTime will always be a quantity associated with DesiredFPS then if you multiple aElapsedTime by 1.0 it will normalize it one second in this case. When the accumulated value become greater than PG.Timer.DesiredFPS (35) then one second of time has passed. If you wanted to check for 1/2 second then yes it would be 1/2 that (17.5).
    Jarrod Davis
    Technical Director @ Piradyne Games

  4. #64

    Re: PyroGineび「 Game Engine

    Quote Originally Posted by PyroGine Development
    Im saying that PG.Timer.DesiredFPS is the value that you set when PG.Timer.Init was called. Since aElapsedTime will always be a quantity associated with DesiredFPS then if you multiple aElapsedTime by 1.0 it will normalize it one second in this case. When the accumulated value become greater than PG.Timer.DesiredFPS (35) then one second of time has passed. If you wanted to check for 1/2 second then yes it would be 1/2 that (17.5).
    Ok, I think I understand

    Expanding on this, I have a bunch of other objects in my game that I want to control using the elapsed frame time in seconds (or fractions thereof) by passing in this time into their .Update() method...

    To pass in the number of seconds into these methods, do I do this kind of thing?

    [pascal]
    var
    TimeSlice: Single;
    begin
    TimeSlice := 1.0 * aElapsedTime / PG.Timer.DesiredFPS;

    ...
    MyObject.Update(TimeSlice);[/pascal]

    I'm hoping this will pass in a time I can then compare to, let's say 1 = 1 second, 0.010 for 10ms?

    EDIT: just so you know, the fix for my global game time now works lovely thanks to you

    [pascal] FTimeCount := FTimeCount + (1.0 * aElapsedTime);
    if FTimeCount >= PG.Timer.GetDesiredFPS then begin
    FTimeCount := 0;
    Inc(FTime.Seconds);

    if FTime.Seconds >= 60 then begin
    FTime.Seconds := 0;
    Inc(FTime.Minutes);

    if FTime.Minutes >= 60 then begin
    FTime.Minutes := 0;
    Inc(FTime.Hours);
    end;
    end;
    end;
    [/pascal]

    cheers,
    Paul

  5. #65

    Re: PyroGineび「 Game Engine

    Ok, this seems to work for me just fine, yay!

    [pascal]var
    TimeSlice: Single;
    begin
    TimeSlice := 1.0 * aElapsedTime / PG.Timer.DesiredFPS;

    ...
    MyObject.Update(TimeSlice);[/pascal]

    cheers,
    Paul

  6. #66

    Re: PyroGineび「 Game Engine

    All you objects should be updated based on aElapsedTime. The overall effect is that your simulation will be be updated at a know and predictable rate while the game loop can update as fast as the host machine can process the loop. If you you need to do timing based on a specific fps independent of the current simulation rate then just use TPGTimer.FrameSpeed which allows you to specify a specific fps independent of the simulation rate. What your doing is decoupling rendering from physics. The extra cycle per frame on faster machines will have no notable effects on your simulation while generating smoother graphics and more cycle can be devoted to AI and other processing. On slower machines, if you keep simulation a magnitude lower than the refresh rate of your monitor, then the frame can drop without any noticeable effects.

    Any way if what your trying to do is working then keep going, but keep in mind what I've outlined as the proper way of using frame-based timing in PGE.

    Jarrod Davis
    Technical Director @ Piradyne Games

  7. #67

    Re: PyroGineび「 Game Engine

    Thanks chief

    cheers,
    Paul

Page 7 of 7 FirstFirst ... 567

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL