Anything that moves (player, enemies, timing of the sheep smashers) is majorly influenced by framerate. Just putting it out there: optimal routing may depend on finding an optimal framerate cap

Very interesting, have you any tests footage you can share? As the game has no FPS settings I guess this will have to be done at GPU settings instead.

I am theorized about this too. Will do some testing in the future, especially when I have a more reliable way to precisely measure splits. Also might ask Thomas^2 about it

I have a run recorded with my laptop running on battery (like 33 minutes long with no big mistakes lol). I can probably pull a few clips later to compare to other people's good runs. It hit me (that it's not global timers or something else) when I saw your comment on the 20:11.660, Zyrumi.

I mean it's a pretty common thing for indie game engines to run physics based on framerate. The most obvious indicator in the game pointing to wards this is actually the chase scene with patches before Chapter 2, imo. It just doesn't always feel the same going through there.

I'm running the game on a 144Hz screen and with 144~FPS ingame, I believe the game has an auto VSync force as there are no settings to be found ingame or in the game folders to configure it.

I would be interested in hearing from @Ofce and @CrispyGyoza about what monitor Hz and FPS they are running, as both of them can (semi-)consistently get on top of this platform at 8:03 on the timer which allows them a huge time save.

@Zyrumi I'm using 144Hz screen as well, most definitely equal to or more than 144 FPS. Might turn on fps counter for that specific part if you'd like but the thing I find weird is that I'm getting this jump in like 1 in 2, 1 in 3 cases. But if you don't nail it on your first ever jump, I feel like the platforms sync again and this jump is not possible

@Ofce Exactly, it's only if you can get on it at 8:03 that they are in sync, after that they don't go back to that timing again.

Then it seems like it might be something else causing me to never get there in time, load times or just micro-failures in the route compared to you two.

Overall, I am somewhat shocked over the extended loads for some chapters as the game is only 300MB and I have the game installed on M2 SSDs (tried both of my M2s and even some 2.5" ssds and all had the same load times)

Overall, I am somewhat shocked over the extended loads for some chapters as the game is only 300MB and I have the game installed on M2 SSDs (tried both of my M2s and even some 2.5" ssds and all had the same load times)

I adressed this topic in my first posted run, which is now obsolete. Loading times for this game are odd going by the size of assets and computation needed. It's roughly equal for all runners at this point, though I didn't analyse the newest WR runs yet. I honestly believe some timing is actually depended on micro-optimizing the run up to this point, since I've both done few runs lately myself that had the wanted sync of platforms while seeing a lot of other runners just missing a lot of micro optimization I usually do. I would need to systematically and quanitiatively review those findings tho before coming to absolute conclusions.

I also did some research into the game engine, which is most likely Construct3, at the least it's Construct, which uses a framerate based physics control.

Lastly, I also did some testing on GPU limited frame caps and came to the conclusion that the difference between 60 and 144 Frames probably isn't too big of a factor, tho anything below 60 will exponentially increase run time and screw with timings. I tried to also investigate how Construct handles frame physics simulation and what the upper cap used usually is, yet couldn't come to conclusive results. Easist solution to this whole discussion is getting in touch with Thomas Lean and getting insights into how the game is designed.

Good to hear any decent FPS should be on equal footing. C3 docs* back up your findings, Aemiliana-- the default physics speed is a fixed 30 TPS, so only microstutters or plain bad framerate should impact timings. The developer may have changed that, but I suspect there was no reason to.

Inconsistent load times are most likely out of anyone's control. C3 suffers from a lot of runtime complexity because it's all Javascript, and packed with nw.js. Neither of these are ideal for games.

* It's definitely a C3 game. package.nw has the C3 runtime in it.

Yeah, the dev said in an interview that the game engine is construct.

@Zyrumi Yeah as you said I think it's more to do with getting there until 8:03 instead of FPS and stuff. As long as I jump over the mine cart at around 6:48 I can get it most of the time. I'm on 144Hz 144FPS as well.

Thanks for confirming! I just wanted to rule out any/both of you playing on 240Hz causing tiny speed increases or something. I will just have to finetune my movement in the second part, so I can catch up to you! :D