TheYetzi
Someone said that might be because if the game operates faster the inputs get detected differently.
As for the slow game someone else noted it might come from the water fall breaking framerate.
yep that was me. as a wannabe game dev I make educated guesses about games based on my own experiences in making stuff. I'm fairly confident in them.
the waterfall utilizes an interesting system for it's generation, not sure if it's a particle effect that has had a raster graphic attached to it, or if he really set spawner objects to load copies of the multiple waterfall drop objects in a specific order, but it's definitely a whole bunch of different objects on screen at once, we are talking hundreds of objects all with a specific set of animation frame and movement cycle. so thats what's sapping the speed out of it.
it really is an interesting concept. but.. it's only for closeup stuff and should probably be offloaded from memory when not in view. it seems as though it is already offloaded from memory when not in view, we call that process Occlusion. but yeah, he'll eventually need to limit it to alot less objects/particles to accomplish that same effect. I suggest doing Rows of the various water droplets as a single object with a single polygon, he can use repeating textures for the drops themselves to span the width of the waterfall, and a stencil image with alpha transparency wherever he does not want a water droplet. this way instead of hundreds of objects, it'll take it down to like 20. it will however make it less dynamic, but it'll loop.
The HOP instead of jump when the frame rate is maxed is more easily explained as a "frame skip" being applied to the engine to achieve faster speeds, but when skipping frames you are also skipping actualization of code and physics force/and linear velocity based on input sensors (like a key being pressed or held).
so even if the input sensors are set to fire once per frame if you skip a frame or 2 then that's a frame or 2 that the input sensor is not being detected this causes a break in the consistency of the application of the force and linear velocity of the jump, which causes it to fail as a mere hop.
fixing that will be more difficult. I honestly can't think of a clear fix without having a different amount of force and linear velocity applied per frame when frame skipping is active, than when it's not active. but the problem being inertia, once you stop applying force to something it usually becomes harder to continue the motion you intended requiring alot more force, sometimes way too much, to achieve the same output as if you never stopped applying the force.
.. it /may/ be able to be fixed by applying a negative input sensor for the same key and having that be nesessary to disable the jump physics' actualization, but at the same time, if because of frame skip the engine is seeing a frame gap where the key was not pressed, then this method will not work.
