Been playing around a bit without the pogo in Keen1, and I found a pretty neat trick: the pogo button still does something without the pogo. It's not much, but if you press the pogo key while walking, it'll completely halt your horizontal momentum. Mostly it lets you do some slightly-quicker turns, but it also works on slippery tiles so it may have some applications if you're landing on one and need to stop immediately.
Even more interesting is that it works to halt Keen's falling horizontal momentum off of ice. If you hold the opposite direction as you approach the edge, then press the pogo key right as you're falling off, Keen will turn around and fall straight down rather than the usual horizontal fall. Doubt it has major applications outside of tricky mods, but I suppose there could be a spot where falling straight down could save a second or two in, say, a no-pogo individual level challenge.
Demonstration video: https://youtu.be/Je87yYw87Aw
(un)known glitches and mechanics in keen
-
CapnClever
- Vortininja
- Posts: 62
- Joined: Mon Mar 10, 2014 1:54
-
CapnClever
- Vortininja
- Posts: 62
- Joined: Mon Mar 10, 2014 1:54
Re: (un)known glitches and mechanics in keen
One of the smallest glitches I've stumbled upon in speedrunning the later games as of late is so disjointed that I don't have a good name for it. Basically, entering and exiting the menu can sometimes cause Keen's jump height to increase by one or two pixels, which I think is the result of slightly faster vertical motion. It's more noticeable on Easy-difficulty gravity, and you have to find a point of measurement on a map to really spot the difference, but it exists.
I could make a little video on it, but it's pretty easy to boot up a game and try it for yourself. A good spot is the first level of Keen5 with normal/hard gravity: from the starting position, jump above to the gums, then use the stubby block above as a measuring stick. Enough attempts at a quick enter/exit of the menu will shockingly show Keen's jump height as increased, but it'll also remove that increase on a whim.
It's also, amusingly, the difference between making certain tricks easier or even possible. For example, you need this "menu boost" to break the Korath III Base fuse on Easy difficulty (in addition to shooting mid-air, which is another glitch that inexplicably increases Keen's fall speed that I assume is the game giving him normal-difficulty gravity). This is one of those things that I only found as the result of needing to perform very precise jumps that barely reach their destination.
I could make a little video on it, but it's pretty easy to boot up a game and try it for yourself. A good spot is the first level of Keen5 with normal/hard gravity: from the starting position, jump above to the gums, then use the stubby block above as a measuring stick. Enough attempts at a quick enter/exit of the menu will shockingly show Keen's jump height as increased, but it'll also remove that increase on a whim.
It's also, amusingly, the difference between making certain tricks easier or even possible. For example, you need this "menu boost" to break the Korath III Base fuse on Easy difficulty (in addition to shooting mid-air, which is another glitch that inexplicably increases Keen's fall speed that I assume is the game giving him normal-difficulty gravity). This is one of those things that I only found as the result of needing to perform very precise jumps that barely reach their destination.
Re: (un)known glitches and mechanics in keen
The fact that the maximum jump height can differ in Keen 4-6 (and Dreams) has to do with the way the gravity functions are implemented. Since the games are storing speed and position values in "global" units (16 global units = 1 pixel), it means the speed and position values can only increase by multiples of one sixteenth of a pixel. This limited precision is the reason why gravity and acceleration only update the speed on odd timer ticks. So, depending on whether the jump was started on an odd or an even timer tick, it may take 1 tick longer before gravity kicks in, allowing the player to keep the initial jump speed (-48 "global" units per tick with the pogo, -40 "gobal" units per tick for normal jumps) for one additional tick, causing the player to jump/pogo up to 3 pixels higher.
The game usually runs at 2 ticks per frame (35 frames per second) when the system is fast enough. But the timers are initialized to 3 when the level starts (or when a saved game was loaded), so a constant frame time of 2 ticks per frame would mean every jump starts at an odd timer tick, resulting in more or less constant jump heights.
When you open the main menu, the game will be forced to re-draw the entire screen, which takes longer than the normal adaptive refresh. Also, the time spent in the menu will get added to the timer, so you may or may not continue playing on an odd timer tick.
The secret fuse will only break when the player's falling speed was >= 48. The reduced gravity on easy makes that almost impossible, but there are ways to break it anyway. One way is to try to get a relatively long frame time during the last frame right before Keen lands. If the frame time is large enough, it allows Keen to accelerate further. For example, if 1 tick would have been enough to make keen land, but the last frame took 5 ticks, there are 4 more ticks during which the gravity code can increase the speed before the game tries to clip the movement and realizes that Keen has hit a fuse tile.
The other way is shooting. The mid-air shooting states use T_Projectile, which always uses the normal gravity function (the one Keen uses on normal and hard difficulty), even when playing on easy. So if you shoot repeatedly and manage to activate the pogo before landing, you can increase the chances of destroying the secret fuse.
There is another bug in the design of some actors (including Keen). Some states (Keen's falling states, the Mad Mushroom states) will transition into the next state after their time elapses to change the object's sprite number. If there are extra ticks left after this state transition, the code will run the object's "think" routine a second time. This will effectively cause the object to move twice as fast during that state transition. This glitch generally doesn't alter the object's jump height, it just makes the object move faster. In the case of the Mad Mushroom, for example, that means you have slightly less time to walk past it when it does the high jump.
Another side effect that might be interesting to exploit is the fact that the physics code generally doesn't allow an object to move more than 1 tile per frame. Since the maximum falling speed is 70 global units per tick and the maximum frame time is 5 ticks (6 ticks in Keen Dreams), the objects would be supposed to fall 350 units (420 units in Keen Dreams) during such an extremely long frame, but the physics code will reduce that to 255 units. This effectively reduces the falling speed and allows Keen to cross longer distances when falling for a long time while the game runs at an extremely low frame rate. You can simulate this with the "Extra VBLs" debug cheat.
The game usually runs at 2 ticks per frame (35 frames per second) when the system is fast enough. But the timers are initialized to 3 when the level starts (or when a saved game was loaded), so a constant frame time of 2 ticks per frame would mean every jump starts at an odd timer tick, resulting in more or less constant jump heights.
When you open the main menu, the game will be forced to re-draw the entire screen, which takes longer than the normal adaptive refresh. Also, the time spent in the menu will get added to the timer, so you may or may not continue playing on an odd timer tick.
The secret fuse will only break when the player's falling speed was >= 48. The reduced gravity on easy makes that almost impossible, but there are ways to break it anyway. One way is to try to get a relatively long frame time during the last frame right before Keen lands. If the frame time is large enough, it allows Keen to accelerate further. For example, if 1 tick would have been enough to make keen land, but the last frame took 5 ticks, there are 4 more ticks during which the gravity code can increase the speed before the game tries to clip the movement and realizes that Keen has hit a fuse tile.
The other way is shooting. The mid-air shooting states use T_Projectile, which always uses the normal gravity function (the one Keen uses on normal and hard difficulty), even when playing on easy. So if you shoot repeatedly and manage to activate the pogo before landing, you can increase the chances of destroying the secret fuse.
There is another bug in the design of some actors (including Keen). Some states (Keen's falling states, the Mad Mushroom states) will transition into the next state after their time elapses to change the object's sprite number. If there are extra ticks left after this state transition, the code will run the object's "think" routine a second time. This will effectively cause the object to move twice as fast during that state transition. This glitch generally doesn't alter the object's jump height, it just makes the object move faster. In the case of the Mad Mushroom, for example, that means you have slightly less time to walk past it when it does the high jump.
Another side effect that might be interesting to exploit is the fact that the physics code generally doesn't allow an object to move more than 1 tile per frame. Since the maximum falling speed is 70 global units per tick and the maximum frame time is 5 ticks (6 ticks in Keen Dreams), the objects would be supposed to fall 350 units (420 units in Keen Dreams) during such an extremely long frame, but the physics code will reduce that to 255 units. This effectively reduces the falling speed and allows Keen to cross longer distances when falling for a long time while the game runs at an extremely low frame rate. You can simulate this with the "Extra VBLs" debug cheat.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
Re: (un)known glitches and mechanics in keen
Interesting. This is exactly the kind secret mechanics/glitch I was talking about. The "usefulness" would be mostly limited to a custom level that is build to require such a move. Though I think you could also make a little micro jump in advance from the ice and turn around mid air. which would also be quite hard to perform probably, if it works.If you hold the opposite direction as you approach the edge, then press the pogo key right as you're falling off, Keen will turn around and fall straight down rather than the usual horizontal fall.
This kinda reminds me of another mechanic I noticed in keen 2. if you jump off of an upwards moving scrub without using the pogostick you jump/get launched higher than you would of the ground.
A jump with a pogostick does not give these benefits however but it is still higher than the non-pogo launch-jump.
So, this mechanic would only be usefull if you didn't have a pogostick somehow in keen 2.
-
CapnClever
- Vortininja
- Posts: 62
- Joined: Mon Mar 10, 2014 1:54
Re: (un)known glitches and mechanics in keen
That explains most of my experience, good to know the processes behind it. I generally found that reloading in a level is inconsistent with regards to jump height, so I'm not sure if loading necessarily keeps things consistent (maybe being in the menu messes with it). Also, attempting the same thing in Keen Dreams resulted in a surprisingly-consistent alternation between jump heights: perhaps in that case the menu doesn't advance the timer?K1n9_Duk3 wrote: Mon Oct 20, 2025 5:26 The fact that the maximum jump height can differ in Keen 4-6 (and Dreams) has to do with the way the gravity functions are implemented. Since the games are storing speed and position values in "global" units (16 global units = 1 pixel), it means the speed and position values can only increase by multiples of one sixteenth of a pixel. This limited precision is the reason why gravity and acceleration only update the speed on odd timer ticks. So, depending on whether the jump was started on an odd or an even timer tick, it may take 1 tick longer before gravity kicks in, allowing the player to keep the initial jump speed (-48 "global" units per tick with the pogo, -40 "gobal" units per tick for normal jumps) for one additional tick, causing the player to jump/pogo up to 3 pixels higher.
The game usually runs at 2 ticks per frame (35 frames per second) when the system is fast enough. But the timers are initialized to 3 when the level starts (or when a saved game was loaded), so a constant frame time of 2 ticks per frame would mean every jump starts at an odd timer tick, resulting in more or less constant jump heights.
When you open the main menu, the game will be forced to re-draw the entire screen, which takes longer than the normal adaptive refresh. Also, the time spent in the menu will get added to the timer, so you may or may not continue playing on an odd timer tick.
Ha, definitely noticed this with Mad Mushrooms before: I recall it mainly happening as the result of loading a save in front of them.K1n9_Duk3 wrote: Mon Oct 20, 2025 5:26 There is another bug in the design of some actors (including Keen). Some states (Keen's falling states, the Mad Mushroom states) will transition into the next state after their time elapses to change the object's sprite number. If there are extra ticks left after this state transition, the code will run the object's "think" routine a second time. This will effectively cause the object to move twice as fast during that state transition. This glitch generally doesn't alter the object's jump height, it just makes the object move faster. In the case of the Mad Mushroom, for example, that means you have slightly less time to walk past it when it does the high jump.
---
Speaking of Keen Dreams, another glitch I've noticed in only that game is something I dubbed the "rocket stomp". It requires you to move Keen to a ledge until he falls off of it, then immediately release the movement key: if done correctly, Keen instantly reaches maximum downwards velocity. I'm fairly certain it also depends on how Keen lands onto the ground with the ledge-to-fall-off-of, in that his precise position likely determines whether or not the glitch will occur. In general, Keen's velocity falling off a ledge in Keen Dreams is weird and inconsistent, and I usually avoid it in favor of jumping off, but there are a couple spots where it saves a tiny bit of time in a speedrun.
An example of the rocket stomp can be seen in an old run of mine: I was aware of the glitch back then but didn't look much into it.
Re: (un)known glitches and mechanics in keen
That "rocket stomp" is caused by Keen's falling speed not being set to 0 when he starts falling from a standing state. That means Keen starts falling with the speed he had the last time he landed on something. If you perform that move before Keen jumped in the current level, you would just get a normal falling speed starting at 0. There is another bug/quirk in the jumping code that might be the reason why the falling speed isn't set to 0 when falling from a standing state.
Keen has 3 different jump states for each of the two possible jumps (standing jump and running jump). Keen starts jumping in state 1, then transitions into state 2 when gravity kicks in, then he transitions into state 3 when he starts falling. These transitions always use the "nextstate" value assigned to the current state instead of being hard-coded to switch to states 2 and 3. This allows both jumps (standing and running) to share the same code. What causes problems is throwing a power pellet mid-air. Keen transitions into the 3rd jump state after the throwing animation is done. The problem is that the "nextstate" value of the 3rd jumping state links to Keen's standing state. If you throw a pellet before gravity kicks in or before Keen starts to fall, those conditions will cause another state transition and will cause Keen to switch into the standing state for one frame. The standing state's react function will notice that Keen isn't standing on anything and will immediately make him fall again, which means you don't actually see Keen in the standing state.
Just test this by jumping straight up and throwing before Keen reaches the highest point of his jump. If you don't want to waste ammo, you can just throw straight up. You will notice that even though you didn't press any movement keys, Keen will still move to the side after throwing. That's because falling from a standing state gives Keen a little bit of momentum for the direction he is facing. And if you have ammo, you can even hear the falling sound. If you don't have ammo, the "no ammo" sound has a higher priority and you don't hear the falling sound (unless you're playing the Android version by Super Fighter Team, which allows more than one sound effect to play at the same time).
So if Keen would reset the falling speed to 0 when he starts falling from a standing state, it would have prevented the mid-jump throwing from working at least somewhat correctly. Keen would have stopped mid-air after each of the bugged state transitions. This was fixed in Keen 4-6 by having two falling states that transition into each other instead of leading into the standing state. An easy way to fix this problem in Dreams would have been to make the third jumping states link back to themselves, thus preventing the game from switching to the standing state in the first place.
BioMenace actually has a similar bug when starting to fall from a standing state. I guess it was inherited from the Keen Dreams code. However, BioMenace does not seem to have the other bug. The 3rd jumping state still links to the standing state in BioMenace, but throwing a grenade or firing the gun mid-air transitions back into the first jumping state in BioMenace and that prevents the code from switching into the standing state.
Keen has 3 different jump states for each of the two possible jumps (standing jump and running jump). Keen starts jumping in state 1, then transitions into state 2 when gravity kicks in, then he transitions into state 3 when he starts falling. These transitions always use the "nextstate" value assigned to the current state instead of being hard-coded to switch to states 2 and 3. This allows both jumps (standing and running) to share the same code. What causes problems is throwing a power pellet mid-air. Keen transitions into the 3rd jump state after the throwing animation is done. The problem is that the "nextstate" value of the 3rd jumping state links to Keen's standing state. If you throw a pellet before gravity kicks in or before Keen starts to fall, those conditions will cause another state transition and will cause Keen to switch into the standing state for one frame. The standing state's react function will notice that Keen isn't standing on anything and will immediately make him fall again, which means you don't actually see Keen in the standing state.
Just test this by jumping straight up and throwing before Keen reaches the highest point of his jump. If you don't want to waste ammo, you can just throw straight up. You will notice that even though you didn't press any movement keys, Keen will still move to the side after throwing. That's because falling from a standing state gives Keen a little bit of momentum for the direction he is facing. And if you have ammo, you can even hear the falling sound. If you don't have ammo, the "no ammo" sound has a higher priority and you don't hear the falling sound (unless you're playing the Android version by Super Fighter Team, which allows more than one sound effect to play at the same time).
So if Keen would reset the falling speed to 0 when he starts falling from a standing state, it would have prevented the mid-jump throwing from working at least somewhat correctly. Keen would have stopped mid-air after each of the bugged state transitions. This was fixed in Keen 4-6 by having two falling states that transition into each other instead of leading into the standing state. An easy way to fix this problem in Dreams would have been to make the third jumping states link back to themselves, thus preventing the game from switching to the standing state in the first place.
BioMenace actually has a similar bug when starting to fall from a standing state. I guess it was inherited from the Keen Dreams code. However, BioMenace does not seem to have the other bug. The 3rd jumping state still links to the standing state in BioMenace, but throwing a grenade or firing the gun mid-air transitions back into the first jumping state in BioMenace and that prevents the code from switching into the standing state.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
-
CapnClever
- Vortininja
- Posts: 62
- Joined: Mon Mar 10, 2014 1:54
Re: (un)known glitches and mechanics in keen
I think this is the first time I've seen a disjointed kill against an enemy before. Anyone know what's going on there? I'm guessing it has to do with the incline, and that the Sparky's "calculated" vs "visible" positions are slightly off due to diagonal weirdness. Maybe Keen's gun has a tiny hurtbox when it fires, but it doesn't seem close enough to touch the Sparky (if it's in combination with my initial guess then maybe it'd work). Go figure this happened in a "glitchless" run, so I had to explain why I still considered the run legit.
Re: (un)known glitches and mechanics in keen
It would help if you could post screenshots of the frames in question (immediately before the Sparky got stunned and the first frame showing the stunned Sparky). The two hitboxes might have touched, but I can't be sure without some better source material.
Keen's gun itself definitely doesn't hurt the enemies, only the shot can do that.
Edit:
I think this is a tile attribute issue. The rightmost tile of the upper flat (horizontal) floor has blocking walls on the sides right where it tansitions into the slope down to the lower floor. The "mid-clipping" code used in Keen 4-6 and Keen Dreams allows the actor's hitbox to be partially inside a tile with blocking east/west walls as long as the actor is standing or walking on a tile with a non-horizontal top (north) edge.
The Sparky was moving up the slope and it must have been hit while still walking on the slope tile. The left end of the Sparky's hitbox would have been partially inside the tile with the blocking sides, and the clipping code allowed that because it was still on a slope. Then the Sparky got stunned, which changed into a state that wasn't ground-based anymore (most actors jump a bit when they get stunned, including the Sparky). That meant that as soon as the Sparky changed into the stunned state, it was no longer walking nor standing on a slope tile and the clipping routines were forced to push the actor out of the tile (to the right, in this case). This was done during the state transition to the stunned state, so you never got to see the sprite drawn at the exact position where it got hit. The Sparking moving to the left and up the slope, getting hit by the stunner shot, and the Sparky getting pushed to the right (back down the slope) could all have happened during the same frame.
Keen's gun itself definitely doesn't hurt the enemies, only the shot can do that.
Edit:
I think this is a tile attribute issue. The rightmost tile of the upper flat (horizontal) floor has blocking walls on the sides right where it tansitions into the slope down to the lower floor. The "mid-clipping" code used in Keen 4-6 and Keen Dreams allows the actor's hitbox to be partially inside a tile with blocking east/west walls as long as the actor is standing or walking on a tile with a non-horizontal top (north) edge.
The Sparky was moving up the slope and it must have been hit while still walking on the slope tile. The left end of the Sparky's hitbox would have been partially inside the tile with the blocking sides, and the clipping code allowed that because it was still on a slope. Then the Sparky got stunned, which changed into a state that wasn't ground-based anymore (most actors jump a bit when they get stunned, including the Sparky). That meant that as soon as the Sparky changed into the stunned state, it was no longer walking nor standing on a slope tile and the clipping routines were forced to push the actor out of the tile (to the right, in this case). This was done during the state transition to the stunned state, so you never got to see the sprite drawn at the exact position where it got hit. The Sparking moving to the left and up the slope, getting hit by the stunner shot, and the Sparky getting pushed to the right (back down the slope) could all have happened during the same frame.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
http://k1n9duk3.shikadi.net
-
CapnClever
- Vortininja
- Posts: 62
- Joined: Mon Mar 10, 2014 1:54
Re: (un)known glitches and mechanics in keen
Thought it might've been along those lines, but many thanks for clarifying the details. (Read this a while ago, just didn't have anything additional to post until now.)K1n9_Duk3 wrote: Wed Dec 24, 2025 13:02 Edit:
The Sparky moving to the left and up the slope, getting hit by the stunner shot, and the Sparky getting pushed to the right (back down the slope) could all have happened during the same frame.
Found another one! This involves Keen spontaneously becoming visible in places he should be obscured. It's apparently caused by Keen's ledge-grab getting cut short by the platform (around 10s in the video). After further investigation, I found that Keen stays visible regardless of the type of hidden area, but the glitch fixed itself due to a completed ledge-grab (around 42s) and would also fix itself by entering a doorway.
--
Non-glitch note, but I found myself making use of Keen's mid-air pogo state being slightly shorter than his standard mid-air state when working on collecting items in Pyramid of the Gnosticene Ancients. The chocolate bar immediately following the red door is a good example of this: while the bar appears to be lower than the dart-shooter to its left, they're seemingly at the exact same height, which means you can't grab the bar without hitting the shooter unless you can duck the shooter and still pop Keen's head up for the bar. Collection is possible with a short hop, turning on pogo before reaching the dart-shooter, and then turning off pogo after touching the right wall. Video showing it in action. I also use this to grab the Lifewater Flask on the western ledge in the same level a few minutes earlier, but the exact motions are unfortunately obscured by the scorebox: in that case, the pogo is toggled on to avoid bonking the sandstone block, which allows Keen a little extra horizontal distance, and then toggled off in time to grab the ledge.
I don't know if the above has been used for any modded-level tricks before, but I haven't seen such a technique explicitly mentioned so I thought I'd bring it up.
-
Multimania
- Vortininja
- Posts: 96
- Joined: Sat Nov 10, 2007 8:10
- Location: Hiding in a small, cramped corner of the BwB megarocket.
- Contact:
Re: (un)known glitches and mechanics in keen
This one is the pole foreground bug explained here. Interestingly it was fixed in Keen 6.CapnClever wrote: Thu Jan 15, 2026 14:18 Found another one! This involves Keen spontaneously becoming visible in places he should be obscured. It's apparently caused by Keen's ledge-grab getting cut short by the platform (around 10s in the video). After further investigation, I found that Keen stays visible regardless of the type of hidden area, but the glitch fixed itself due to a completed ledge-grab (around 42s) and would also fix itself by entering a doorway.