Page 5 of 5 FirstFirst ... 345
Results 41 to 43 of 43

Thread: Library recommendation?

  1. #41
    Good game loop :
    Yes, But:
    If you do too much stuff it may not cost much immediately but get cached in the command buffer instead and lead to swap stretching over the frame limit and wait until the end of the next frame (BAD!).
    So you have to monitor for such accidents and decrease the amount of "do stuff" accordingly if that stuff includes uploading hi-res LODs in the background.


    I learned this the hard way and I (maybe, wrong) "do stuff" *before* issuing rendering commands and just let this homeostatic system of waiting swap and my auto-balancer system stabilize FPS for me. I even have an alternate mode when v-sync is disabled and the auto-balancer simply keeps increasing load until FPS drops to about 80. Leads to funny cases like rendering an empty scene in 6k FBO before downsampling to back buffer, cooling fans roaring like wild beasts and so on.

    In short, it is up to you

  2. #42
    P.S. I am thinking of switching to a hybrid system where xxxSwapInterval(1) is called once per N frames (I think, 5 or 10) while the rest of the time the loop tries to adhere to the timing using micro-sleeps (hello, TimeBeginPeriod(1), you ugly freak) and can measure SwapBuffers()+glFinish() duration freely, thus getting real results not contaminated with v-sync wait times.

  3. #43
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    It shouldn't be the case that you need to call xxxSwapInterval more than once for each context but clearly it works for you. The overhead is likely negligible but it might be worth timing how long that call takes just in case you need to manage it.

    I totally agree and I believe you're quite right as far as what I personally know goes - handling v-sync in this way requires that you know how long your operations take, how long they could take etc

    But dropping a frame isn't the end of the world - the nice thing is that if it looks like you're going to miss your window? you can skip over all of the rendering and then use all the time to catch up for the next window - or even better, start rendering the frame after the one you're about to drop - if the scene is very complex and you're only going to get 30 FPS anyway - then implementing it like this automatically gives you an optimal solution for when the refresh rate of the display can't be matched.

    Don't think of a loop that runs 60 times a second - instead think of it like a WW1 bi-plane gun firing through the spinning propeller - its not in sync with the insane spinning - it just fires whenever both the gun is ready and the propeller is ready - it's firing as fast as possible regardless of how fast the propeller is spinning (refresh rate) or the rate of fire of the gun (frame rate)

    You don't want this to happen a lot or you may get perceptibly visible stutters in the output - but by calculating a safe 'overhead' over the lifetime of your scene - while you miss out on time you could of used - you can basically turn such potential frame dropping into an initialization process.

    Yeah - it's not simple and the more time you want to save, the more likely you are to drop a frame - 50 explosions and thousands of particles suddenly bursting into existence isn't the kind of thing you can predict or that you want to increase your overhead to manage - I guess no matter how hard you try - dropping frames is a possibility.

    But given that the approach covers both the best case scenario (60fps, never miss a window, silky smooth graphics) and lesser cases (eg 30fps, miss every other window, minimal stutter) then I personally feel it's a good choice

    It is important however that such an approach covers very poor performance - let's say we can only manage 10fps - assuming we will get 60fps and then skipping a window when it looks like we won't? may not lead to efficient management of the time available. I believe it is prudent to have some form of mechanism that says :

    "ok, we're definitely going to miss the next 5 windows, so instead of trying to hit each one and then giving up, let's just use all the time to ensure we hit the 6th"

    So I guess variables that keep track of 'desired frame rate', 'predicted frame rate', 'actual frame rate' and then logic that acts accordingly. We've not touched on LOD schemes but for anybody reading? it goes without saying that being able to manage the level of detail in each frame dynamically lends itself very well to such a design. You don't want everything to collapse to cubes when a hundred explosions go off just to keep your framerate - but you want something along those lines. Quality settings should be a thing of the past, instead we should have a desired frame rate and the quality is the best it can be while still meeting your demand. (In fact I distinctly remember an old DOS nascar style game where you did exactly this - can't remember what it was but clearly they were ahead of their time)

    (EDIT : it was "NASCAR Racing" - so I didn't forget the title - it just basically didn't have a title )
    Last edited by phibermon; 09-02-2018 at 04:13 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

Page 5 of 5 FirstFirst ... 345

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
  •