South Carolina, USAGood 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.
Hate that bug. At least there's a small window to break it before it turns solid.
Can I cheer you up with a softlock?
(I hit Patches at the same time he regained invuln)
I'm tempted to advocate that replenishing abilities midair is a glitch, and might be so abusable as to make any% glitchless less fun for "laid-back" play, but it's also way too possible to do accidentally and calling it a glitch would absolutely make moderating less fun.
Every run I butcher from here on out, I promise to mash keys at the start of chapter 6 until I unlock the trick xD
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.
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
May I ask if their price is for a code-based splitter, or a simple video splitter?
This is a Construct 3 game. They pride themselves on how difficult it is to hook/mod the "compiled" code.
Huge play! The first star can be used to skip the first climbing section too ;)
I can't explain how your speed got high enough to outpace the camera in the first place, but here's what happens when you do:
- The camera reaches its maximum speed
- The object that follows your mouse isn't allowed to leave the screen
- Mario's hammer is attached to that object by a spring force
- Mario is pulled back towards that object at insane speeds
- He moves so far each frame that collision detection goes out the window
- Gravity eventually pulls Mario below the bottom of the screen to die
Is it possible to hit the flag at those speeds? Idk.
If you want to play with it more, fly mode in my trainer was so sloppily coded that you can easily find ways to fling Mario all over the place B-)
[Edit: this is just from memory, I could be kinda wrong in some ways]
None of it intended, but I'd been in all those situations before. A good launch over the top of the first gap is still faster than the low path, thankfully. At least this run shows off everything I think I know about acceleration control
Naaa, don't sweat my time. I've been telling myself all month to get a less messy run closer to my SoB but It's not really happening lol
I think the acceleration you're talking about is explainable and matches the code. It's just tough to put a finger on how to take advantage of it and I'm no math wiz. My best strat is to try to bring the hammer to/through Mario's center after a launch instead of in a big arc around him. In your demo video it looks like your gentle arc and still hand allowed it to happen. I'd guess if you kept rotating a little you would have landed where you intended.
No idea how you reversed direction midair so perfectly in your other demo, but I think that's also perfectly valid movement that could be learned.
Getting stuck on corners happens because there's no special consideration to translate lateral/rotational force to sliding on walls.
Getting stuck in blocks should be equal across all platforms, but it's been a while since I looked at the code and can't remember if it's influenced by framerate at all.
