So something I've been noticing in my game is that when C2 is reporting framerates lower than 60fps, the game becomes crippled extremely quickly. Any framerate below 45fps severely hampers gameplay, and 30fps is completely unplayable.
Why the heck is this? Plenty of games pull off ~30fps completely fine, but for some reason, C2 games simply cannot cope. Is this a HTML5 thing?
I wish I could provide a more concrete example but since there's no way to manually throttle FPS in C2 I don't see a way to do it.
Am I the only one who notices this? Can anyone else with a fast-paced game confirm this?
Yeah, same here. On my PC and on my galaxy S3 (via crosswalk), when game run between 40-60fps it runs perfectly fine and smooth. But below that it's usually unplayable, it basically turn into a stop-motion animation with zero interaction from a player :/
I noticed any fps below 45 causes the dt to produce less smootth results. I have no idea why that happens. dt is just a difference between last time and this time in a usable form. I have no problem in Unity's dt or using JS or Java custom dt. But C2's just goes herky jerky. I'm wondering if the dt is linked to the browser refresh hz.
I don't have excellent examples.
I think you should be able to dynamically throttle the refresh rate by checking the fps and running a loop checking collisions x number of times, increasing x until you get to the fps you want.
Arima yeah, that could work, but by the replies on this thread it seems like it is a well-acknowledged problem. Do you get this issue in your games?
I wonder if this has any relation to the fact C2 is locked to 60 as an upper limit?
I know this issue very well.
Ashley reckon we could get a comment on this? Is this something fixable?
I haven't noticed it myself, but I don't run many benchmarks that come in under 45 FPS. I'd guess it's to do with how browsers schedule requestAnimationFrame when frames take longer than 16ms to process. Then you get in to a difficult problem of trying to synchronise frames which take, say, 22ms to process, against 16ms screen redraws. I guess in some cases the browser will do it badly and produce irregular frame updates. Regular frame updates look OK, such as 30 fps done by draw - skip - draw - skip - draw - skip. But if it falls to something irregular and it's doing something like draw - skip - draw - draw - skip - draw - skip - skip - draw, then I guess that could look really bad (since it's visually unpredictable so it's harder to follow with your eye).
This probably varies from browser to browser and could depend on the OS/underlying graphics API too. Is it the same across Chrome/Firefox/IE/Safari on Windows/Mac/Linux/mobile?
OK, so I've gone and created a test project using Arima's suggestion.
Initially I just did the collision check method as Arima said, but when I tested it I noticed that at 30fps the game was pretty much fine.
So, I tried creating lag by a different method (rendering lots of 1% opacity rectangles) and immediately the difference was super obvious. There's significant input delay when the lag is on the GPU side.
Can anyone confirm? (Capx attached)
Tested it, it's a bit jittery at beginning, but then it was fine. Btw, the game crash if it falls >layout height, I wondered why is that.
Ci7 4510u, ATI R7 M265, 8Gb ram
Tried your example... no lag, ran smoothly.
I think it depends on users hardware.
Got a custom built machine. So no issues at all.
Yes. On "GPU lag" enabled and fps=30 there's like 1-2s delay on the input. While on "CPU lag" is nice and smooth at 30fps.
Using: Win 8.1 x64, i7-3770K, 32GB Ram, Geforce 780
Develop games in your browser. Powerful, performant & highly capable.
Those who tested with no results - you have to wait a few seconds for the lag to kick in. Change the loop iterations if it doesn't kick in fast enough.
Chrome - Super Laggy and Jittery
Node Webkit - Bad button lag, but seems to run ok.
Firefox - Really bad at start, if you wait a few seconds it seems to run fine.
IE11 - Bad button lag but seems to run ok.