Low FPS in C2 games is more crippling than it should be?

Ashley

1) GPU blacklisting is definitely not the problem. I've checked this, I'm on a new laptop with the latest drivers, and I've tried the test both on the GPU and the integrated graphics.

2) I had a look at the other browsers and the lag difference doesn't seem to be there at least on my PC. So it's a Chrome/NW problem?

3) What would C2's profiler say that would be useful? It doesn't measure GPU at all, just CPU?

I don't think anyone would propose artificially throttling FPS like that - you're making it sound like HTML5 is permanently locked to 60fps? I don't remember reading it anywhere but I guess it could be true.

The issue brought up by Aurel is a good one and I'd urge you to take a look at allowing us to cap dt at a lower value to prevent collision issues. This isn't directly related to the issue in this thread but does play off it.

The thing is C2 was done not to have a fixed 60 fps framerate, but a V-synced based framerate as far as I understand, however, I agree that lower fps that does not vary too much should not be a problem for the player (I will keep an eye on this discussion)

For collisions however, I woild think it can be possible to have a more precise way to check them, but it would be more costly (moving first the sprite to a certain distance based off it's size, then check, if no collisions, repeat until you are arrived). So it will not be really efficient, I also supporrt the idea of a fixable framerate (like every 1/30 seconds, recalculate the non trigger based logic then render on screen, but that may cause issues with triggers triggering between those simulated ticks)

Yes, it's really at v-sync rate, not just 60 FPS, but 60 Hz is by far the most common v-sync rate.

At 45 FPS dt is only 33% higher. Objects shouldn't really be travelling that much further and missing collisions just because of that. You shouldn't cut it that fine - it should be designed so collisions aren't missed even if dipping below 30 FPS. Otherwise what if their system is just slow?

I would gladly bring my "please adujst your graphic settings!" at 30 fps for the slow systems. That would be perfectly normal : )

But triggering it and losing some collisions as soon as 45FPS is quite a surprise.

It only happens on fast objects like gun bullets or spaceships with boost, but it can break the game very quickly.

(ex: if a trigger is skipped on the track because the ship is coming too fast.)

Being fast paced is the whole point of a racing game, so I really can't slow some of the game elements.

For now, I'm applying the design advices I've read on the forum and it should be ok: making GIANT triggers objects, big hitboxes everywhere I can, " *dt " where it's needed, and around 45fps I set timescale to 0.8 and show the warning message.

But I know I'll still see some bullets and ships passing trough the walls from time to time, and that's a bit scary for the game release ^^!

Ashley I agree with you, and I'm sure most games are fine with low FPS in this regard. HOWEVER, small lag spikes are common and these play havoc with dt - whenever there's a lag spike, dt is set to its lowest value and objects teleport everywhere.

I think 45 FPS is way too high a limit to require for the game to work correctly. Basically you're requiring a constant 60 FPS for the game to work correctly, but what about slow systems, or just moments of the game where suddenly it becomes extremely busy on-screen with a sudden burst of activity and it momentarily dips the framerate? You can't allow that to break the game, because it could easily happen.

Currently the maximum value of dt in the engine is 0.1. Also if it goes over 0.5, it sets it back to 0 on the assumption the game is not actually running any more and should be paused. What do you propose as new values for these?

Ashley I agree 45fps is too high a benchmark, however, as this thread has brought up, 45fps is not the same in all circumstances. Spikes, unevenness etc are the main issue. If we were able to make 30fps consistent it would be perfectly fine.

I can't propose new values for the dt caps, but I'd love to be able to play around with lower caps. 0.0167 is the ideal value, so it would be great to be able to cap it at, say, 0.02. The fact is, some games (including mine and Aurel's) have enough fast motion that it becomes problematic to remain framerate-independent at high dt values. Slowing down the game might actually be better.

Yeah, well as you mentioned the disadvantage of a cap like 0.02 is a few seconds of lower framerate will run the game in to slow-mo for a few moments, which is disorientating for the player - kind of like randomly varying the timescale during gameplay. I'm not convinced that's a better solution. I think we want to aim for a value that just cuts off the spikes.

I would gladly bring my "please adujst your graphic settings!" at 30 fps for the slow systems. That would be perfectly normal : )

But triggering it and losing some collisions as soon as 45FPS is quite a surprise.

It only happens on fast objects like gun bullets or spaceships with boost, but it can break the game very quickly.

(ex: if a trigger is skipped on the track because the ship is coming too fast.)

Being fast paced is the whole point of a racing game, so I really can't slow some of the game elements.

!

This is a logic problem in all game engines. A very simple solution is to store a "sprite last position" element so you can check for collision along the vector instead of just the point. I'm not sure how this would be implemented in C2 though.

I think box2d (or one of the common physics engines) will handle the advanced collision for you, and I believe it works along similar lines by incorporating the last known position.

skelooth Thanks for your post. Yes, I've been told about that method, all the coders around me at the office are implementing their collisions this way for their game engines. But as a C2 user and total noob in maths, I don't have any clue on how to do this, sadly : )

EDIT: oh, and about using Box2D... well, the game don't use any physics for now, so that would mean to recode all the collisions, no? If you're sure the collisions by vectors are handled by Box2D, maybe I could do that. That seems a lot of work, but maybe less than facing angry Steam users one by one... : )

Creative problem solving with C2....

Can you just make your bounding boxes bigger? Especially in the case of a bullet, you could extend the "tail" of the hitbox 5-10 pixels. Sometimes a collision might look a little wonky, but it's better than missing.

I have my solutions to this problem thought. When fps drops below lets say 55, I switch off some of the smaller details on screen. If still continues I switch off more. And if it even continues then, I'll automatically switch to low quality renderer. After few seconds I'm switching stuff back. But that depends all on game itself. I can trade some particles and other elements temporarily for better fps.

skelooth Yep, I've done that! And not only with tails of 5-10 pixels, much more to be sure : )

It doesn't have any negative effect when the projectiles come from the player, but enlarging the hitboxes for the enemies weapons makes the game much harder, of course.

megatronx Only cutscenes runs on high quality, all the "real" game runs in low quality already to max the perfs. It feels like a 720p only game, but with some "sharpen" photoshop effects on the GUI, it looks pretty ok even for graphic nazis.

That said, instead of asking to the player to change his graphic settings if the game drops under 45fps, I could autoswitch like you do, and then bring back the high settings if the game runs smoothly for a long enough time.

That's a very good idea, thank you!

Note: I feel like I'm hijacking the thread, I'll now shut up for a bit and let sqiddster and Ashley continue ; )

Curious, how would you accomplish this auto switch to a lower res?

(the game is based on a 1280x720 resolution but uses 1080p assets.

So you can set the fullscreen scaling to "low" for some parts, and to "high" for others, at the start of the layouts or depending on the FPS variable. This can be found in the System action pannel)