0 Favourites

Fixed framerate problem/bug?

This forum is currently in read-only mode.
  • So i've been using fixed framerate mode for one of my games (i want it pixel perfect: don't go all timedelta on my arse ) and it's working well except for a small problem... When the framerate drops the game slows down as expected, but then once the lag stops, the game appears to run faster in an attempt to "catch up" to the point it would have been if the slowdown had not occurred(which often results in player death due to a massive game speed boost). Is this how fixed framerate is supposed to work, or is it a bug?

  • Excuse the double post, but i would very much like an answer to this, it's been on my mind for some time now.

  • I'm sorry Davio, I would answer if I knew the answer

  • I think it's a bug, can you add it to the tracker?

  • sure thing Ash.

  • uploaded a cap to demonstrate problem.

    http://dl.getdropbox.com/u/1010927/Fixe ... ateBUG.cap

    also placed this cap on the tracker, in the report i made.

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • Set your mode to VSync, then set "Minimum FPS" to 60 and keep the "Override TimeDelta" box checked and the problem goes away. It has the same effect you're looking for (game slows down for pixel precision) but the speed-up at the end of the lag goes away.

    Plus, I think VSync is supposed to be the right way to do games or something because of tearing and stuff, but I'm not entirely sure that's a problem if you're manually overriding timedelta. Anyway, it doesn't look like it works with fixed, so there's a way to fix your fixed and make it act fixed even though fixed isn't fixed yet.

  • Thanks deadeye, I didn't think about the minimum fps with override timedelta still checked approach. I'm just wondering how it will play on different computers. Plus, since i dont use timedelta in my code (because its for a fixed rate), i'm wondering how the game will play on pc's with a higher rate than 60.

  • Hmm, not sure. I didn't think about that

  • lol oops, posted my on brothers account. So yea the whole point of fixed framerate is that you have pixel perfect precision which runs at the same speed on every pc.

  • That's what TimeDelta is for... you can code near-enough pixel perfect games with timedelta and vsync. I never really intended anyone to use fixed framerate for games. Having all your graphics shredded by display tearing seems a high price to pay for this alleged pixel perfection, too. I don't think any modern commercial games are written with fixed framerate engines.

    Also, the concept of fixed framerate games running the same speed on all computers is a myth. It will slow down if the computer can't reach the fixed framerate. Not so with timedelta games.

  • the keyword is "near enough". I need my game to move the objects in increments of exactly 1. I'm very aware that fixed framerate runs slower during lag, but i'm ready to live with that. The game requires pixel precision and the chance of slowdown is minimal. I'm pretty sure that all super nintendo games use a fixed rate engine. The only reason i'm using it is so that the game runs at the same speed on faster displays.

  • I've had to use the minimum framerate approach for tonks in order to keep the physics from falling apart on slower machines. Deadeye helped me test it out, and now physics works uniform on any framerate, whereas before on lower FPS machines, it would do weird stuff.

    I'm thinking his method would do exactly what you are looking to achieve.

    Also, if you want to find out what it will do ona faster machine, send me your CAP, and ill turn fram limit off and run it on mine... FRAPS it, and return the results.

    ~Sol

  • Out of curiosity, why does your game require moving objects in exact units of 1? There are ways to get a timedelta'd game to do this too.

  • fixed framerate with frameskip, doesn't slow down nor speed up, at least not if the slowdown is caused by rendering. Calculates logic for each passed game tick, sometimes more than one in a row (cause that's what frameskip is).

    Notice the choppyness. Do some interpolation to get rid of it. Your graphics will always be between 1 and 0 logic ticks ahead of your game logic.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)