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

Discussion and feedback on Construct 2

Post » Mon Sep 29, 2014 1:50 pm

@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.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,699

Post » Mon Sep 29, 2014 2:08 pm

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)
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Mon Sep 29, 2014 2:15 pm

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?
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,351

Post » Mon Sep 29, 2014 2:45 pm

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 ^^!
Last edited by Aurel on Mon Sep 29, 2014 3:12 pm, edited 1 time in total.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

Post » Mon Sep 29, 2014 3:00 pm

@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.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,699

Post » Mon Sep 29, 2014 3:16 pm

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?
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,351

Post » Mon Sep 29, 2014 3:48 pm

@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.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,699

Post » Mon Sep 29, 2014 4:08 pm

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.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,351

Post » Mon Sep 29, 2014 4:19 pm

Aurel wrote: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.
Developing Surolace, the survival role playing space game.

surolace-survival-role-playing-space-game_t116953
B
14
S
4
Posts: 303
Reputation: 1,730

Post » Mon Sep 29, 2014 4:35 pm

@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... : )
Last edited by Aurel on Mon Sep 29, 2014 4:42 pm, edited 2 times in total.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 4 guests