Collision bug using Chrome

Hello Scirra team!

I have a game published on Steam, and I received a report from a user with a bug where the character could cross the colliders (solid tilemaps, and sometimes just triggers) in some situations.

After testing on several computers, with suspected performance or updates, I was unable to reproduce the problem. So, I exported it in HTML5 form and asked the user to test it in different ways.

It was seen that through the Google Chrome browser, the bug persisted. While the same did not happen with Microsoft Edge.

The user has more updated Chrome, compared to my own version.

In a curious event, the player noticed that the bug did not happen in Chrome after opening the Valorant game in the background.

What can I do to find the problem? Why can this be happening?

We already checked if the browser ran webgl2.

The only thing I didn't do was ask the user to clear the browser's cache.

It is a very strange problem to require such action in a game that will be released shortly ... Any solution?

---

You can play and test the Demo version of the game by yourself:

store.steampowered.com/app/1389120/Dojoran

It's virtually impossible to help unless you can follow the bug report guidelines (i.e. reproduce the problem in a minimal project and provide steps to reproduce).

Given the fact we are running pretty much identical code in all browsers, it seems very unlikely it's actually anything to do with the browser version, and that is just a red herring that you've falsely correlated with this. If that's the case, then we have nothing to go on at all - hence the need to follow our guidelines for issues.

Hello Ashley

I had two more feedbacks from people with the same bug. The way they play is clear, they force the character on the wall during a walljump.

Even so, I couldn't represent on any of my 3 computers with different performances (a good one, a medium one and a terrible one).

After MANY tests with one of the people who had the problem, this started to happen only through FireFox. As you said that the browser would theoretically have no difference, I made some more adjustments to the advanced engine settings.

Apparently, the only setting that "fixed" the problem, was to change the "Use worker" option to "No", and "Framerate mode" to "Unlimited".

I tried the separate settings and were unsuccessful.

What can that mean? That the computer is skipping collision frames?

The character clearly teleports from one side of the wall to the other. It appears that the program tests the player's collision only when it is already inside the solid object.

I am not accusing a bug in Construct, but trying to understand what may be happening, or where.

Jase00 You are completely correct.

I was making some changes to the code today, and everything indicates that it has to do with dropping frames along with platform behavior and overlapping events.

Since Framerate Mode Fullframes requires the computer to process all frames, this ended up solving the problem. But I don't know how much it can affect performance.

It is also difficult to test, as I depend on something working very poorly, such as low FPS monitor, video card or even processing. This explains why there were changes according to the browser.

Btw, Framerate Mode explains, but I did not understand the function of the Use worker.

I never thought I could have done that kind of movement with LOS. Is the raycast made in proportion to the character to detect walls?

So what solution do you use for Platform Behavior? All programing by "X+10*dt"? I almost sure the platform behavior works the same way...

What I did on my project, and soon I find out if it worked, is not to let the character simulate the movement to the side of the wall for a short time after the wall jump.

Theoretically, I didn't need to, because there is a wall on his side anyway, and he shouldn't go through.

But at the same time, if it happened on average computers, I sometimes imagine with the computer practically locked.

I have seen a lot of talk about different fall speed on 144hz monitors, and now I see that this is due to the Framerate Mode V-Sync. Perhaps this mode is no longer the best option today.

At the same time, more complex games may not be well accepted by Fullframe.

I had already set a limit of 60FPS by the command line "--limit-fps=60"

How do I limit the minimum?

To limit the minimum fps in C3, I think it's only a "System" event right now, not a project property (unless I'm missing this). You can read about it here too: construct.net/en/make-games/manuals/construct-3/system-reference/system-actions

Personally I don't use any behaviours at all and do everything in events - I do this because I want ALL the control lol. You can specify your collisions exactly the way you want by doing it this way, although this can get extremely fiddly and complicated and likely has a performance overhead, but to me it's worth the hassle to get the game feeling perfect. I aim to use LOS as I know there's a major performance gain compared to the event-only way of raycasting where you "Make a sprite, increase it's width by 1 until it hits a wall". It gets tricky though as a ray is only 1px wide.

Perhaps LOS could be used in conjunction with the platform behaviour, but the more I think about this, I'm not sure this would work too well for your case, as it's a ray; a 1px wide line, so it's not going to account for the whole width or height of the player. Perhaps you could make a system where if the fps is lower than 30fps, then a make-shift sprite-based ray that is the same width/height as the player, that increases it's width/height by 1px in a loop (this is taxing for performance so this may be terrible advice) or maybe utilising the "On overlap at offset" for the player... OR MAYBE the system "Set minimum FPS" would suffice in this case to avoid over-complicating things!

Yeah the whole 144hz monitor stuff (they have 240hz monitors now, would you believe? Must be butter smooth), I try to wrap my mind around this as I like the idea of making precision platformers, but I'm aware that when your fps is changing a lot, it can make your jump heights change just a little, but enough to ruin a precision jump and either miss it or overshoot it.

Thank you Jase00 !

I limited the FPS to 25.

But on second thought, I think it would hardly matter if I put a minimum FPS limit of 50 for example.

If the game was fixed and ran normally when placing Fullframes, it means that computers could run much more FPS than they showed. Something specific about each browser limited the game's performance.

This may have to do with WEBGL or any feature that browsers use to run, or improve the performance of the browser. Probably placing a minimum FPS limit on all games should make the browser obligatorily transmit the use of performance to the game, rather than slowing it down (except on extremely bad computers).

After all, what made me confused, is that the game is simple enough to run on almost any computer at 60 FPS.

Wall climbing?

If so that's not a regular part to the Platformer behavior.

Best bet would be to make an example with the code you're using and post it.

Otherwise the rule of thumb is that if the player speed(pps) is greater than the size of the obstacle, then skipping is going to happen eventually.

Platform behavior have an event to check "Is by wall", so you can just set the fall speed to 0.

But I'm pretty sure this works same as overllaping.

Anyway, I've solved with other simple solutions mentioned