Game getting only 40ish FPS on other computers?

[Ralph]

Hi,

In my pretty beefy game (lots going on) i get 55-60 frames on my computer with a 60hz monitor. However, when I launch it on another computer (much more power than mine, and with a 144hz monitor) I only get 30-40 frames? Its affecting my game because the update cycle is slower than it should be. When I run a jfiddle on those computers just drawing the fps, they receive their monitors refresh rate as the fps almost perfectly. The chrome is up to date and am using auto/phaser.WEBGL mode. Suggestions?

[phreaknation]

run this in the chrome browser on both and it should help you out. Maybe that systems chrome isnt GPU accelerated or something else

chrome://gpu

 

[Ralph]

13 minutes ago, phreaknation said:

run this in the chrome browser on both and it should help you out. Maybe that systems chrome isnt GPU accelerated or something else

chrome://gpu

 

Hardware acceleration is enabled on all.

[Fatalist]

It may be due to a larger screen resolution, make sure you test in a same-size window.

Or maybe your computer is better in some way, for example, your CPU may have a better single-core performance.

[Ralph]

27 minutes ago, Fatalist said:

It may be due to a larger screen resolution, make sure you test in a same-size window.

Or maybe your computer is better in some way, for example, your CPU may have a better single-core performance.

Same screen size and I highly doubt single-core performance is the bottleneck. I'm almost positive its a bug somewhere, and not a performance issue with my game. 

[Fatalist]

Try with a canvas renderer, and test some other benchmarks, like PIXI bunnymark.

[samme]

Try 

game.forceSingleUpdate = false

 

[rgk]

Can you show the game?

I have similar issues where I get randomly different performance. It can be based off of a lot of things, maybe the other machine has more things running in the background? aka check task manager.

[Ralph]

4 hours ago, rgk said:

Can you show the game?

I have similar issues where I get randomly different performance. It can be based off of a lot of things, maybe the other machine has more things running in the background? aka check task manager.

I can send you a link if you would like, but really its not any external thing or the computers. These computers im trying the game on should be able to way more than handle the game. It was odd too because on one of the computers, it would idol at 30 and NEVER go over. While another one was pretty random from 30-40. But another between 55-60 frames. Really it couldn't be things in the background I'm certain. Its some bug with chrome or it's something I'm missing. 

[Ralph]

Actually, im starting to think its a bug with just these 2 computers. I tried it on 2 more computers, 1 worked like mine. 1 was a crappy laptop capped at its refresh rate of 50hz, and it could handle it so. Also, if someones monitor is lower/higher than 60hz will the update function be called more than 60 times a second? Or will that be capped there and just frame rate goes up? Like I just realized I have some things dependent on the 60 times a second refresh rate of the update function, so do I need to work with deltaTimes now? I question this because on the computer running at 30fps they move slower than the computers at 60fps, but the one at 120fps moves at same speed

[mattstyles]

Browsers are capped at 60fps, hence you saying the quicker monitors are displaying the same speed of movement.

The 60fps cap is based on how much the human eye can handle (actually its probably as much to do with refresh rates as anything), whilst some gamers will tell you they need higher fps every (albeit small scale and limited) scientific test into this (and yes, the entertainment industry was commissioning such research long before computers became mainstream) caps human rate of noticing fps at just over 30, not sure why browsers then whacked it up to 60, presumably its to do with monitor refresh rates. Most TV's run at 60 fps now, some can do more but they generally have to interpolate between frames to reduce the effect of motion blur (which is what most people report seeing as jarring), there is a difference between progressive and interlaced (I think) scanning for TVs that is tied to how many frames they can push, or are shot at. Higher refresh rates seem to be regarded as nothing more than a marketing ploy, with many expensive sets boasting refresh rates they don't actually hit!

7 hours ago, Ralph said:

so do I need to work with deltaTimes now?

It's up to you, its normally a good idea to keep logic independent of frame rate, but its totally dependent on what you want to achieve, its certainly often easier to tie it to FPS.

On 18/01/2017 at 5:24 AM, Fatalist said:

test some other benchmarks, like PIXI bunnymark.

@Ralph, did you try this? If the other computer does not bottom out faster than your 'lower-powered' machine then it would logically seem to be something you're doing in your code that is causing the lower frames.

Are you sure about stuff in the background? If I'm running something really GPU intensive, like max intensive, in the Chrome then I'll often notice that Atom (my editor, which is basically Chrome also) becomes very sluggish. Try to make sure nothing else is happening on the machine, which I'm sure you're already doing to test.

 

 

[Ralph]

On 1/19/2017 at 0:42 AM, mattstyles said:

Browsers are capped at 60fps, hence you saying the quicker monitors are displaying the same speed of movement.

The 60fps cap is based on how much the human eye can handle (actually its probably as much to do with refresh rates as anything), whilst some gamers will tell you they need higher fps every (albeit small scale and limited) scientific test into this (and yes, the entertainment industry was commissioning such research long before computers became mainstream) caps human rate of noticing fps at just over 30, not sure why browsers then whacked it up to 60, presumably its to do with monitor refresh rates. Most TV's run at 60 fps now, some can do more but they generally have to interpolate between frames to reduce the effect of motion blur (which is what most people report seeing as jarring), there is a difference between progressive and interlaced (I think) scanning for TVs that is tied to how many frames they can push, or are shot at. Higher refresh rates seem to be regarded as nothing more than a marketing ploy, with many expensive sets boasting refresh rates they don't actually hit!

It's up to you, its normally a good idea to keep logic independent of frame rate, but its totally dependent on what you want to achieve, its certainly often easier to tie it to FPS.

@Ralph, did you try this? If the other computer does not bottom out faster than your 'lower-powered' machine then it would logically seem to be something you're doing in your code that is causing the lower frames.

Are you sure about stuff in the background? If I'm running something really GPU intensive, like max intensive, in the Chrome then I'll often notice that Atom (my editor, which is basically Chrome also) becomes very sluggish. Try to make sure nothing else is happening on the machine, which I'm sure you're already doing to test.

 

 

As always, another great post. I only tried to the pixi test on two computers, both of which were the ones that were working to begin with. Ill have to test tomorrow. I guess ill be switching to delta times for people who cant run 60 frames. I already have movement speed capped on the server so I wasn't really worried about over. Do you happen to know of any good guides of how to do this properly? Er basically how to do this. I know the idea of changing movement speed based on the delta but not how to access it in phaser. 

Edit: I would be willing to link my game in a PM, but its a large read. Their is a lot of sprites drawn at once but nothing rapidly changing. Like it was weird because on one computer it would not pass 30 FPS at all even when standing still when all sprites are idol and nothing is working in the background of the game. 

Edit 2: Holy moly, I just realized my update function is just 15 lines lol. All it is is on a key press set a sprites velocity and update the sprites position on the server. Server handles the rest of the game. I guess I never realized how much logic I moved to the server lol, I've come a long way from asking how I should handle map data. 

[mattstyles]

This article on game loops you might find interesting although it doesn't go into the nuts and bolts of using delta to calc movement speeds etc. Most physics libraries should run off of delta, Phaser implements P2 which certainly does, maybe the Arcade physics does the same? I'm not sure of any good tutorials on the subject, I like to work this stuff out myself or just use a physics library.

It generally requires a bit of a change in how you think about your movement code. The simplest way is to move entities by a set amount, often this is implemented by moving them (e.g.) 1 unit per frame until they hit their destination. Using delta requires you to add another vector, namely time, so movement speed could be modelled by saying move 1 unit of distance in one second, you then take your delta (which is time elapsed) and use that to work out how much of a second has passed and move by that 'how much' for the elapsed time i.e. in the example above of moving 1 unit per second, if delta is 500ms then you'd move 0.5 units (delta / totalTime * distance or 500 / 1000 * 1), if a unit equals 20 pixels then you move 10 pixels for that tick. You can simplify this too usually, you might decide unit speed is a set 20 pixels per second, or 0.02 per ms, in which case movement per tick is delta * 0.02. In all of these cases positional data must be floats or you lose loads of precision, even though the renderer will display per pixel (integer).

[samme]

It seems the recommended method for fixed-step updates is

• Set game.time.forceSingleUpdate = false
• Set game.time.desiredFps (if not 60)
• Use game.time.physicsElapsed for updates

Arcade Physics (and Lifespan) use physicsElapsed. physicsElapsed is the ideal interval (1s / desiredFps), not a measured interval, but it seems to work.

Try https://github.com/samme/phaser-plugin-advanced-timing 

[WombatTurkey]

There is a HUGE difference between 60hz and 144hz with Phaser. I just got a new 144hz monitor and am testing it out now, it's nuts. Especially when moving around  

[Skeptron]

I'm pretty sure I noticed that there is no more updates at 144 than at 60fps. The render method is called twice as much but not the update function (at least that's what I remember from tests I did a while ago). That's why you saw no difference between 60 and 144 fps for your game. I think. 60 is the max.

Also, you should probably be framerate independant. It's a bad user experince doing stuff twice as slow when at 30fps (unless you're doing a card game or something very static).

Also, I always found Canvas was much more stable and performant than WebGL. Just my own experience though.

[ForgeableSum]

On 1/18/2017 at 6:09 PM, Ralph said:

Actually, im starting to think its a bug with just these 2 computers. I tried it on 2 more computers, 1 worked like mine. 1 was a crappy laptop capped at its refresh rate of 50hz, and it could handle it so. Also, if someones monitor is lower/higher than 60hz will the update function be called more than 60 times a second? Or will that be capped there and just frame rate goes up? Like I just realized I have some things dependent on the 60 times a second refresh rate of the update function, so do I need to work with deltaTimes now? I question this because on the computer running at 30fps they move slower than the computers at 60fps, but the one at 120fps moves at same speed

What i do is change my time-dependent constants based on FPS. e.g. if a constant is 5 @ 60FPS, and the FPS is 20, I will change the constant to 4 (20 divided by 5).

Re: refresh rate affecting performance. Does not surprise me in the least. I have a computer which uses a giant 32-inch LED monitor with a monster graphics card that performs poorly, while my weak mac air with a crappy integrated GPU runs like a dream. I stopped trying to predict Phaser/webgl performance based on hardware a long time ago. 

[Skeptron]

2 hours ago, feudalwars said:

What i do is change my time-dependent constants based on FPS. e.g. if a constant is 5 @ 60FPS, and the FPS is 20, I will change the constant to 4 (20 divided by 5).

Waow! I had never heard of this technique before but it seems incredibly fragile : how do you deal with FPS constantly changing, for a weak computer? Why not use time-dependant constants? For instance instead of saying vX = 5px/frame, saying const = 300px/s, so that each update you can calculate the px movement based on the dT that happened since last update? Just curious why you chose this strategy.

[ForgeableSum]

9 hours ago, Skeptron said:

Waow! I had never heard of this technique before but it seems incredibly fragile : how do you deal with FPS constantly changing, for a weak computer? Why not use time-dependant constants? For instance instead of saying vX = 5px/frame, saying const = 300px/s, so that each update you can calculate the px movement based on the dT that happened since last update? Just curious why you chose this strategy.

It's more of a dirty hack than a recommended strategy :). I use a hack for now because it would require some rewrites to abstract the logic away from game loop update speed. In my RTS game (Strike Tactics), workers collect resources and move to drop resources off in silos. Seems simple, but what if the game framerate drips to 30, the worker is now moving at half speed and is much less efficient. And since I'm increasing the amount collected on every framerate (stupid, bad coding), that works against its collection speed as well. 

I also do a lot of complicated things with game.time.desiredFPS. Basically, constantly update desired FPS based on current framerate (how well the CPU is doing currently). This complicates things as well. It's kind of a mess right now, to be honest. But the end result after a lot of hacking is that resource collection rates are pretty much independent of framerate. 

[mattstyles]

10 hours ago, feudalwars said:

Seems simple, but what if the game framerate drips to 30, the worker is now moving at half speed and is much less efficient.

This is the exact situation that a time-based approach is designed to solve, rather than effectively just speeding up your simulation as the inverse of FPS.

FPS just describes the view in to your world, the simulation should usually just chug on completely independent from framework.

So, in your situation, if the FPS drops the worker still collects resources at the same rate, you just don't see the unit move as frequently.

By differentiating simulation and render speed you vastly simplify a whole load of stuff and don't have to deal with all the pain of a variable time step in your game.

[ForgeableSum]

4 hours ago, mattstyles said:

This is the exact situation that a time-based approach is designed to solve, rather than effectively just speeding up your simulation as the inverse of FPS.

FPS just describes the view in to your world, the simulation should usually just chug on completely independent from framework.

So, in your situation, if the FPS drops the worker still collects resources at the same rate, you just don't see the unit move as frequently.

By differentiating simulation and render speed you vastly simplify a whole load of stuff and don't have to deal with all the pain of a variable time step in your game.

I realize that, which is why I qualified my post with "this is bad, don't do this." It's a dirty hack and introduces tons of problems. Believe me, I know!