FPS, Delta, FixedFPS, Timing, Animation Topic (almost done)

About Monkey 2 › Forums › Monkey 2 Programming Help › FPS, Delta, FixedFPS, Timing, Animation Topic (almost done)

Tagged: , , , ,

This topic contains 16 replies, has 7 voices, and was last updated by  Arjailer 2 years, 7 months ago.

Viewing 15 posts - 1 through 15 (of 17 total)
1 2
  • Author
    Posts
  • August 23, 2016 at 7:30 pm #3374

    gcmartijn
    Participant

     

    I found a class at this forum and did try it on my engine.
    It din’t work 100% oke ;(

    Then I test some things but the animation are still not 100% correct.
    And I don’t know if the timing is correct.

     

     

    And you need to unpack the animation.zip
    I can’t upload all the 16 frames here, only four uploads are allowed.

    Attachments:

    1. 2.jpg

    2. 3.jpg

    3. 4.jpg

    1. animation.zip
    August 23, 2016 at 11:22 pm #3380

    therevills
    Participant

    I havent executed your code, but looking at your logic you are basing your animations on millisecs but using the FRL update control. This may mean you could get bigger gaps with your millisecs calls.

    What I’ve done in the past is calculate the number of millisecs to frame time.

    [/crayon] [/crayon]

    Then in FrameSet you will increase the frametime by 1*delta…

    August 24, 2016 at 6:55 am #3393

    gcmartijn
    Participant

     

    Created new topic below

    August 24, 2016 at 11:44 am #3399

    gcmartijn
    Participant

    I think I have it now, but not sure because its hard to understand this part of game making 😉

    Here is a video

    There is only a problem when starting a game, you can see it in the beginning of the ‘movie’
    The movement is way to fast, and after 1 or 2 seconds the Logic FPS is oke (100)

    The first animation is 1 second
    oFS.frames.Add(New Frame(“1.jpg”,10000))
    I want to use MS each frame, but I thought 1000 MS is 1 second (not 10000)

    The second frame is moving and the animation speed is
    oFS.frames.Add(New Frame(“1.jpg”,500))

    The third frame is moving and the animation speed is
    oFS.frames.Add(New Frame(“15.jpg”,60))

    If I understand it correctly, this means
    New FixedRateLogicTimer(100.0, 20)

    Call Method OnUpdateGameLogic(_delta:Float) after every 100 frames.
    AND everything inside that method don’t have to use speed*delta movement because this will happen every 100 frames (locked)

    Inside that OnUpdateGameLogic() I call the UpdateFrameTimer() to update the current frame duration like this.

     

    Full code

    August 24, 2016 at 12:26 pm #3402

    Simon Armstrong
    Participant

    IMHO a game should run at 60 Hz or 30 Hz (SwapInterval=1 or SwapInterval=2).

    If a game doesn’t run well it is typical to allow the user to downgrade visuals or resolution.

    A lot of the code above seems to be based on the premise that it is ok to skip frames because it can be fixed with some kind of algorithm. I’m pretty sure it can’t.

    August 24, 2016 at 12:45 pm #3404

    wiebow
    Participant

    This is also very complicated code. For me anyway. I’m not sure this is the way to go. I just force 60 updates per sec and be done with it. 🙂

    August 24, 2016 at 1:41 pm #3408

    gcmartijn
    Participant

    60, 30 I don’t ‘care’ what it is haha because I don’t know what i’m doing/must do at this most important thing :S

    Are those facts true ?
    – MX is running at unlimited random frames a second.
    – I need to call every 60 screenframe OnUpdate()

    I can drop that FixedLogicFPS because I don’t know if its better than  something like below.

    I was hoping that that there was one ‘template’ script that covers it all, so every programmer can start program.

    If there was only one drawing/moving animation script that is working on the same speed on every mid-range desktop/ios/android.

    By drawing I mean:
    – animation multiple image frames, (can set the duration each frame in MS)

    By moving I mean:
    – the frame animation moving from point A to B

    – And later in the future collision will be added.

    August 24, 2016 at 7:49 pm #3424

    Simon Armstrong
    Participant

    I would start with looking at the games included in the bananas folder of monkey2.

    None use a timer and all expect OnRender to be called at 60hz as Window.SwapInterval defaults to 1 which means App.RequestRender causes subsequent OnRender to be correctly frame synced.

    August 24, 2016 at 8:20 pm #3425

    Cole Chapman
    Participant

    What integers does SwapInterval support?  If i’m not mistaken, it calls to SDL_GL_SetSwapInterval but the documentation on it says 0 for immediate and 1 for vsync.  In Monkey2 however, if you put 2 I get 30fps, 20fps with 3, etc… What’s officially supported and will putting 3 for example, give the same fps across all supported platforms?

    August 24, 2016 at 11:14 pm #3431

    peterigz
    Participant

    Also, what about the new monitors that run at 120/144hz?

    August 25, 2016 at 8:14 am #3439

    gcmartijn
    Participant

    @Simon Armstrong

    I would start with looking at the games included in the bananas folder of monkey2.

    None use a timer and all expect OnRender to be called at 60hz as Window.SwapInterval defaults to 1 which means App.RequestRender causes subsequent OnRender to be correctly frame synced.

    I will remove all the code, and see what happen.

    I know about the bananas folder, I did see it, but I thought that maybe the creators din’t care about creating it.

    But when I remove all the ‘timing’ code, I still need to use delta calculation or not ?
    Is MX2 withSwapInterval=1  do all the things so I don’t need to care of delta anymore ?

    • Why not default SwapInterval=1 inside MX2 so beginners don’t have to know/ try to learn about those things.</span>
    August 25, 2016 at 9:19 am #3441

    Arjailer
    Participant

    As peterigz says, given all the different hardware available I don’t think it’s as simple as “default SwapInterval to 1 and never have to do delta timing again”.

    Looks like SwapInterval just sets SDL_GL_SetSwapInterval(), which when set to 1 means “updates synchronized with the vertical retrace” – i.e. it enables vsync, so updates are then linked to your monitors refresh rate.

    Great if all monitors were 60hz. But monitors that runs at different frequencies will update a different number of times per seconds (e.g. 60hz, 75hz, 120hz, 144hz). So if you write fixed logic assuming 60hz and run it on a non-60hz monitor your game would run at a different speed  🙁

    Plus there are plenty of examples out there of PCs/GPUs just not honouring vsync, which again would break your game.

    I just don’t see how we can avoid delta timing – I see it as a fundamental part of ensuring your game runs properly on “every PC” and I’ve never seen anything magical that would take that burden away, and given the complexity of PCs, I doubt we ever will.

    August 25, 2016 at 10:37 am #3444

    Simon Armstrong
    Participant

    Maybe Mark will chime in.

    I assumed mojo would force 60hz for full screen mode and that typical games would simply use native resolution fullscreen mode at 60hz.

    I see that for casual /windowed games the desktop frequency is something you can’t control (or even query atm) so yes, a fixed timing strategy is not for everyone (just most of us).

    August 25, 2016 at 10:51 am #3445

    gcmartijn
    Participant

    ignore the fixed timing strategy 😉 I was searching for the ‘best’ possible solution to make my app things running at the same speed on all ios/android/desktop (full screen/windowed).

    In the weekend i’m going back to basic delta timing.

    Maybe if I publish a game in the future, I will add something like this:
    System requirements:
    – Screen device must run at 60hz and the OS must have enabled vsync.

    Just to make sure I don’t get any/(less) sad/mad customers.

    August 25, 2016 at 10:56 am #3446

    Arjailer
    Participant

    As I say, all SwapInterval does is call SDL_GL_SetSwapInterval(), which just enables vsync – it doesn’t force any particular frequency.

    So just setting SwapInterval won’t do what you want, but yes if you explicitly set a 60hz (presumably fullscreen) mode then you’re probably good to go  🙂

    Edit: that was in response to Simon  🙂

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 17 total)
1 2

You must be logged in to reply to this topic.