Update 1:- Added 3 new levels- Capped the delta time to prevent cheating- Added a few new types of crates- You will now be able to continue from the round you reached- Rewrote the storyline to be somewhat like a Bastion-esque narration (at least it sounds like the Bastion narrator in my head when I'm reading it )

I like the game, but for a game that requires lightning reflexes, the variable input lag is somewhat killing it. Sometimes when I hit the spacebar, I immediately jump, while on other occasions it waits for like '10px' (whatever that is in millis), meaning that I cannot physically make the next jump. Sometimes the input lag is so bad that I start jumping after respawning

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Thanks for playing guys. About the lag, I'm not entirely sure how to resolve that because in LibGDX you can handle input either via their Polling mechanism or using Event Handling. Crates uses event handling because the LibGDX wiki says polling might produce missed events. http://code.google.com/p/libgdx/wiki/InputPolling

Thanks for playing guys. About the lag, I'm not entirely sure how to resolve that because in LibGDX you can handle input either via their Polling mechanism or using Event Handling. Crates uses event handling because the LibGDX wiki says polling might produce missed events. http://code.google.com/p/libgdx/wiki/InputPolling

quoting libgdx:

Quote

Caution: If you rely on polling, you might miss events, e.g. a fast paced key down/key up. If you need to make sure a specific sequence of input action was completed, use event handling instead.

I don't think you'll miss an event, only if the guy presses and releases a key in less then 1000/fps milliseconds (I think that's what the caution is about). If you're running at 60FPS, I think it's physically impossible to a human to press and release a key faster than that.

And, from my own experience (I'm writing a libgdx game right now), I've never experienced a key polling miss.

Events are best used for stuff like text input where you don't want to miss anything, however for real time input (e.g. jumping) polling should be fine.

I'm guessing though that the reason for the delay in input is a sudden drop in frames giving a large delta time value (causing the sprite to move forward faster and hence delay the jump). One solution is to cap the delta time value to something like 20-50ms to avoid these jump delays have too much of an effect on gameplay.

btw noticed that in your appletloader html code you use the al_bgcolor and al_fgcolor parameters, these do not work with the AppletLoader anymore and you should instead use the boxbgcolor and boxfgcolor parameters. You'll probably want the following as it'll match your logo

Events are best used for stuff like text input where you don't want to miss anything but can afford a little input lag, however for real time jumping polling should be used.

btw noticed that in your appletloader html code you use the al_bgcolor and al_fgcolor parameters, these do not work with the AppletLoader anymore and you should instead use the boxbgcolor and boxfgcolor parameters.

Ohh I see, I'll definitely switch to polling then. Thanks, I didn't know those params had changed. I'll push a new update tonight.

It doesn't work. I get the following error message:"An error has occurred while loading the applet. Please contact the support to resolve this issue. This occurred while 'switching applet'".

I use Firefox 14 under Mageia Linux 2, OpenJDK 1.7 update 3, Icedtea-web 1.2, ATI Radeon X1950 Pro (Gallium 0.4 driver). Minecraft demo shows me a similar message, I assume it has something to do with this bug (from Icedtea-web or LWJGL) preventing LWJGL applets from working with Icedtea-web. Xerxes uses a more recent version of Icedtea-web, he wrote that it doesn't reproduce this problem with the provided examples on the official website of LWJGL.

@gouessejIf this was a commercial application, I wonder if looking into this would even be worth it. I mean, how big of a userbase are we losing? Why don't you update to the same version of Iced-Tea as Xerxes?

I'm guessing though that the reason for the delay in input is a sudden drop in frames giving a large delta time value (causing the sprite to move forward faster and hence delay the jump). One solution is to cap the delta time value to something like 20-50ms to avoid these jump delays have too much of an effect on gameplay.

Unfortunately I don't know enough about LibGDX to answer that, so hopefully some of the other members here will be able to answer that but basically the time value you use to move your sprites every frame should be capped.

For maximum polish, you'll probably only want to process jumps that were queued within X amount of time before hitting the ground, where X is some fractional-second value that's smaller than the length of an entire jump. Otherwise it's annoying if you accidentally bounce the button and queue jumps you didn't want to.

For maximum polish, you'll probably only want to process jumps that were queued within X amount of time before hitting the ground, where X is some fractional-second value that's smaller than the length of an entire jump. Otherwise it's annoying if you accidentally bounce the button and queue jumps you didn't want to.

Before you start implementing that 'convenient' feature, think about how that takes all skill out of the equation. The entire point of this game is to have lightning speed reflexes, and by doing 'action queueing' they don't matter as much, only the timing of the first jump would be important.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

That's why you don't let people queue jumps at any time, just a small fraction before they hit the ground. It's basically adding a little bit of tolerance to the mix, and it's pretty much a requirement to compensate for any input lag. Obviously removing input lag is better, but even then it still provides a smooth experience without taking away too much difficulty.

Before you start implementing that 'convenient' feature, think about how that takes all skill out of the equation. The entire point of this game is to have lightning speed reflexes, and by doing 'action queueing' they don't matter as much, only the timing of the first jump would be important.

Quote

That's why you don't let people queue jumps at any time, just a small fraction before they hit the ground. It's basically adding a little bit of tolerance to the mix, and it's pretty much a requirement to compensate for any input lag. Obviously removing input lag is better, but even then it still provides a smooth experience without taking away too much difficulty.

The main reason I'd look at doing something like this would be for an 'easy mode', because people tend to curse alot while playing this game

It is not a easy mode, just a human factor consideration. We queue actions everytime on our brain, even when walking.

It is hard to find the exact tick when you are able to jump again. It is just asking someone to have a near 0ms reaction time.Of course the levels can be beaten without it, but if you add it, you can create even harder levels, which would need near perfect timing