Zampano Posted May 23, 2017 Share Posted May 23, 2017 Hi there, I'm not exactly about phasers behaviour when the fps drop below 60 and I hope you guys can help me clarify! if the fps drop, does the game speed drop also? Will a movement or action take longer than normally or will everything behave normally with a choppier output? I'm trying to make a rhythm based game, a little bit like guitar hero and need to have my game in synch with an audio file and don't want to start fiddling on the timing stuff while I don't really understand it. What would be the best way to do that? Thank you! Simon Link to comment Share on other sites More sharing options...
Jammy Posted May 23, 2017 Share Posted May 23, 2017 Typically in game development to ensure an object moves relative to your physics rather than the CPU cycles, you use a time delta variable which corrects any variations in the run time between frames, It sounds a little complex at first but actually it's quite simple. I'm not a phaser pro but I know there's an article here discussing a case with phaser and the requirement for time delta: https://gamedev.stackexchange.com/questions/125258/does-phaser-arcade-body-velocity-include-deltatime-or-not The post isnt very clear and I've never had to document it myself so I'll struggle to explain it succinctly but basically, once you have the deltaTime you can just multiple your variables by that number and it results in smooth transitions. I use it all the time. e.g. (pseudo code) object.y += 50 * deltaTime Nesh108 1 Link to comment Share on other sites More sharing options...
Zampano Posted May 23, 2017 Author Share Posted May 23, 2017 I see. I understand the concept, thank you very much. I'm not able to really get it to work yet, though, since in this post, the calculation of deltaTime doesn't really make sense since it will always be around 1 if the framerate is roughly consistent, regardless if its for example 60 or 30 fps. I have narrowed it down to the following calculation: deltaTime = elapsedMS/(1000/desiredFPS) My problem is that phaser.time.elapsedMS doesn't seem to be very reliable and my movement becomes jittery every few frames... I'll try to do my own elapsedMS calculation for now but I'm open for suggestions Link to comment Share on other sites More sharing options...
samme Posted May 23, 2017 Share Posted May 23, 2017 It depends mostly on the value of game.forceSingleUpdate. Set that to false. But if you use tweens, I think those should run on time in any case. Phaser recommends you use time.physicsElapsed instead of time.elapsed etc. Zampano 1 Link to comment Share on other sites More sharing options...
Zampano Posted May 23, 2017 Author Share Posted May 23, 2017 But time.physicsElapsed is a fixed value: "With fixed-step updates this is normally equivalent to 1.0 / desiredFps" Which is the whole problem, how can I get rid of those fixed steps without rewriting all of the physics? "Game/logic timing can drift from real-world time if the system is unable to consistently maintain the desired FPS." I'm afraid I can't really follow your suggestions Link to comment Share on other sites More sharing options...
Zampano Posted May 23, 2017 Author Share Posted May 23, 2017 Uhm. This works: deltaTime = (nowtime-oldtime)/(1000/this.time.desiredFps); this.game.time.physicsElapsed = 1/this.time.desiredFps*deltaTime; Is there a problem with this I'm overlooking? If not, this is so much more straight forward and helpful than I would have imagined Link to comment Share on other sites More sharing options...
samme Posted May 23, 2017 Share Posted May 23, 2017 2 hours ago, Zampano said: But time.physicsElapsed is a fixed value: It's supposed to be. When forceSingleUpdate is false, Phaser tries to match the frame rate by adjusting the number of fixed-step updates, not by adjusting the size of the step. If you're using Phaser's physics, set forceSingleUpdate=false and leave everything else alone. If you have to use a delta yourself for some other calculation, use physicsElapsed. If you're using tweens, you won't have to calculate or use any deltas yourself. If you're writing your own physics, you're of course welcome to use what you want. Zampano 1 Link to comment Share on other sites More sharing options...
Zampano Posted May 24, 2017 Author Share Posted May 24, 2017 EDIT: okay. I realized that I made a mistake when trying to set forceSingleUpdate to false. Now I corrected that and it really does work! Thank you very much =) Link to comment Share on other sites More sharing options...
Zampano Posted May 26, 2017 Author Share Posted May 26, 2017 Okay, I'm back to this topic... I'm not really satisfied with the reliability of this method, It just seems like it's rubberbanding a lot. I've got a few ideas on how to fix it, the easiest and so far best is my approach from before, where I had forceSingleUpdate on true and did this: deltaTime = (nowtime-oldtime)/(1000/this.time.desiredFps); this.game.time.physicsElapsed = 1/this.time.desiredFps*deltaTime; I know it's not the way you're supposed to do it but is there an actual proper reason not to do this? It fixes all my problems at once and if this is not an absolute no-go, I don't see why I can't just do it like that. What do you guys think? Link to comment Share on other sites More sharing options...
samme Posted May 26, 2017 Share Posted May 26, 2017 That's probably fine. You may have to account for game pauses somehow in your delta. Zampano 1 Link to comment Share on other sites More sharing options...
Zampano Posted May 26, 2017 Author Share Posted May 26, 2017 Thanks for your valuation, that's great Pausing and continuing seems to work fine for now, I'll keep an eye on it. Link to comment Share on other sites More sharing options...
Recommended Posts