0 Favourites

FPS drop affecting speed / collisions

  • Edit 3 : Even after coming up with a bit of a hack to solve this, I'm still dealing with game breaking behavior due to spikes / lag in FPS. ;-;

    Edit 2 : My final solution >>> So I tried a few things, but nothing was working well... then it finally hit me!

    I looked at the FPS dip that was causing the problems (surprisingly started as low as 55 fps) ... and implemented a very minor time scale slowdown (0.9) when the game went below 55 fps.

    It fixed everything! While I appreciate what C2 does to try and make a game run smoothly when FPS drops, it's going to look choppy regardless, so I'd rather it be a tad slower and work well then choppy and be wonky at different frame rates. :3

    I know it's a bit of a hack, but it works well for my purposes and fits the retro nature of the game! :D

    Edit : I think I found a decent answer to my problem here : scirra.com/forum/deltatime-and-framerate_topic49729.html[/b]

    I am incredibly new and wasn't sure what to search to see if this has been brought up before.

    I'm creating an action platformer that relies on quick movements and knives that stick into walls.

    The current online demo can be found here : deviever.com

    The thing is, I have noticed that if I have a program, like bandicam or xsplit recording while I am playing the game online in browser, specifically in Fire Fox (I haven't tried other browsers yet... the sprites collisions work MUCH differently, often times falling through walls, flying through walls, etc. etc.

    The game definitely seems to be running a little more slowly with those programs on, and I'd be totally okay with that, but on top of the slow down / jerkiness is this weird collision behavior. <img src="smileys/smiley19.gif" border="0" align="middle" />

    Anyhow. Thank you advance! C2 has been an amazing inspiration for me as a budding developer, and I appreciate any words of wisdom / advice ya'll have to offer!

    <img src="smileys/smiley4.gif" border="0" align="middle" />

  • Fun game. Here's a few things to consider.

    • Most of C2 games runs on the GPU. Those screen recording tools likely run on the GPU also. So, they would affect each other.
    • Have you properly set the collision polygon? (When you double-click on a sprite, the bottom-left tool/icon allows you to do this.)
    • As you may know already, animations (like throwing knives) are not perfectly smooth. They are typically around 30 or 60 frames/images per second. For each frame, the location of the knife is calculated and sometimes it skips quite a few pixels. The moving sprite will skip more pixels the faster it is moving, and the slower the frames per second (fps) is. Sometimes, so many pixels are skipped that the knife sprite will go all the way through the wall.

    Having said all that, I think it's a good game. I wouldn't have called that a bug where the knives going inside the blocks. But, I didn't try it on a "slow" machine either.

  • Construct 3

    Buy Construct 3

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

    Buy Now Construct 3 users don't see these ads
  • Thanks for the response!

    The knives sticking in the walls are a designed part of the game. The collision polygons have all been set correctly, and I'm aware that when things are moving quickly they will simply skip a bunch of pixels (and thus will not detect collision if it's going fast enough).

    What it "feels" like is happening, is that when the recording programs are on, the game is "skipping steps"... so that where normally a knife would collide with a wall and thus triggering its speed to 0 (the way I get them to stick), it instead flies right through the wall.

    Either that, or the weird performance issues make it such that the speed of everything is increased in a way it normally wouldn't be.... if no one else is having the same issues, I'll do some debugging to get back to everyone with more concrete performance figures.

    The same thing happens with sprites that have the platformer behavior.

    For instance, if the main character is falling fast enough and the recording programs are on, thus making everything jerky (inconsistent fps?) where the character would normally collide with the ground and stop, they'll just fall straight through.

    The same thing happens with the ninja characters that are flying towards you... when you throw a knife at them (which is also going pretty fast), they would normally collide with no problem... instead they fly past each other with no hint of a collision what-so-ever.

    Maybe this is what you were saying, about the FPS affecting such things, but I was under the impression that a changing FPS would simply mean the program would run slower... not affect the physics / collision of the game.

    I hope that makes sense, and thanks again!

  • If it would help, I could record video... ha ha, after all, recording video is how I realized there is a problem!

  • I have not tried the game but, If you are using bullet behavior for the knives it uses delta time to calculate pixels moved per tick, so a lower frame rate will result it it moving more pixels each tick, if that is more than the width of the wall then it could glide right through without a collision being detected.

    You can counter this by either making the sprite hitbox larger, slowing the knives down or making the wall thicker... a combination of all three would probably be best...

  • I have not tried the game but, If you are using bullet behavior for the knives it uses delta time to calculate pixels moved per tick, so a lower frame rate will result it it moving more pixels each tick, if that is more than the width of the wall then it could glide right through without a collision being detected.

    You can counter this by either making the sprite hitbox larger, slowing the knives down or making the wall thicker... a combination of all three would probably be best...

    Thanks!

    That definitely explains part of the problem, but the main character is also being affected when they fall.

    So I'm guessing it's the same kind of calculation problem?

    Unfortunately making walls thicker / hitboxes larger is going to create more problems then they'll solve, especially since I intended on having the game contain precision based fighting / puzzle mechanics.

    Is there no way to lock in a certain FPS?

    I find it kinda odd that there'd be such a game breaking mechanic built into the engine.

    I was very excited at the prospect of having browser based games, and LP'ers these days are an important part of getting the word out about games, but if having them record a game will ultimately change the way the game behaves... well, it obviously makes for a pretty bad situation. <img src="smileys/smiley19.gif" border="0" align="middle" />

    More than anything, I want a level of consistency and reliable expectations across platforms in terms of collision behavior. I don't mind the FPS dipping down on slower setups and the game being a bit choppy, but if the game acts completely differently / becomes unplayable... well, I'm sure you can understand my concern.

  • I think I may have found a more specific answer to my problems here : scirra.com/forum/deltatime-and-framerate_topic49729.html

  • played the game, like the pixel retro look...

    The knives are very fast and small, you could make the collision box larger without increasing the size of the actual graphic, just increase the canvas size,with bounding box collision, same goes for the walls...

  • So I tried a few things, but nothing was working well... then it finally hit me!

    I looked at the FPS dip that was causing the problems (surprisingly started as low as 55 fps) ... and implemented a very minor time scale slowdown (0.9) when the game went below 55 fps.

    It fixed everything! While I appreciate what C2 does to try and make a game run smoothly when FPS drops, it's going to look choppy regardless, so I'd rather it be a tad slower and work well then choppy and be wonky at different frame rates. :3

    I know it's a bit of a hack, but it works well for my purposes and fits the retro nature of the game! :D

  • deviever your game is cool i also like the retro <img src="smileys/smiley20.gif" border="0" align="middle" />

  • deviever, thank you for posting your timescale solution. It makes sense that that would work. I'm now thinking of throwing that into my current game as well.

  • Hey, this is weird...I've just been trying to figure out a solution to this problem myself!

    What you are looking for is Framerate Independance. deviever : check out my thread and the attached capx; I ended up with a similar approach, expect that I set the timescale dynamically in relation to the fps. It works pretty good, though not as good as I'd like.

    scirra.com/forum/framerate-dependant-mode_topic84422.html

    P.S.: Game looks good, love the art! <img src="smileys/smiley20.gif" border="0" align="middle" />

  • Just wanted to revisit this topic and say I'm still having hella-trouble with FPS spikes / lag affecting things in a game breaking kinda way, even after implementing my hack. ;-;

  • Have you tried setting the hitbox to be longer than your knifes? I played your demo, it was fun and retro-cool, if you have issues with knife flying through walls etc due to their tiny hit box, just make it longer, but not fatter if you get what i mean. I won't interfere with knife hitting walls mechanic with a longer hitbox, but it will make collisions much more stable at lower FPS.

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