Public Commander Keen Forum

I noticed the following quite a while ago. It's not on the KeenWiki's Keen 1 Bugs page, and forum and web searches didn't turn up relevant results, either. I'd like to know who else has been aware of this little bug.

Whenever a window is opened, the actual action is frozen. But in the case of the "God mode enabled/disabled" window in Keen 1, something is a little different. Go to a place with an ice cannon and press G O D. Wait a moment (at least the usual interval between two shots) and press G O D again. Repeat it multiple times to create a stream of icecubes. The animation below shows the result:

If it is done in user-made levels where many ice cannons are simultaneously active, such as The Ice Factory, it eventually crashes the game.

I've seen a similar bug in Keen 2 where activating God Mode alters the behaviour of rendered Scrubs, sometimes making them fall off the ceiling, and offsetting their position a bit (most noticeable in trails where multiple Scrubs that were evenly dispersed become staggered).

The Keen: Vorticons engine is a little weird when it comes to timing. The engine was supposed to adapt to different frame rates (so things move at somewhat constant "pixels per second" speeds. But some things are seriously messed up. For example, Keen's maximum jump height depends on the CPU speed.

The Cannon uses a "real time" counter for the delay between two shots. This "real time" counter is not paused when the god mode window is shown, all the other windows (help, status etc.) do pause that counter. So the cannon sees that enough time has passed since the last time it spawned a shot (which is true, just not in game-time) and keeps spawning those tons of shots in Grandy02's example.

The missing pause can also affect other enemies. Since there's no pause, the game will notice that it took quite long to compute the current frame, so it will try to adapt to that (the game thinks you are playing at a very low frame rate, which is technically true). But as I mentioned before, there are some issues with the adaptive timing. This might be what caused the weird behavior of the Scrubs that proYorp mentioned.

Ah, was not aware of the Scrub and jump height things.
Thanks for the nice explanation, K1n9_Duk3. If anyone would like to add something like that to the KeenWiki, feel free to use the GIF animation.

K1n9_Duk3 wrote: ↑Fri Nov 22, 2019 22:18 Keen's maximum jump height depends on the CPU speed.

Tell me more about this! Playing Keen1 as a kid on 7mHz 8086 I could have sworn keen jumped higher - not every time but intermittently. Then I thought it was version 1.0 being different but when I eventually transferred that exact copy of Keen1 to a modern PC the jump height was normal again. I ultimately decided this memory was just due to weakness of my mind.

K1n9_Duk3 wrote: ↑Fri Nov 22, 2019 22:18For example, Keen's maximum jump height depends on the CPU speed.

Huh, that's interesting. Do you know what speed gives the highest maximum jump height? Will changing DOSbox cycles emulate this effect?

K1n9_Duk3 wrote: ↑Fri Nov 22, 2019 22:18 Keen's maximum jump height depends on the CPU speed.

elecdude33 wrote: ↑Mon Nov 25, 2019 14:54 Will changing DOSbox cycles emulate this effect?

Most interesting! I guess that also explains this: https://youtu.be/8jhGnLED7wc?t=485
For context, NY00123 had done some experimenting with getting the impossible lollipop in Capital City, and in his experiment turned the CPU cycles in DOSbox down; he then commented that he thought it was possible that could have had an effect.

Yes, you can definitely see a difference when you turn the DOSBox cycles down to around 200 cycles or less. It helps if there are other sprites (like Yorps) visible at the same time. I strongly recommend starting the game at 3000 cycles or more and then lowering the cycles count with CTRL+F11, otherwise you would get insanely long loading times.

In my experiments, Keen can jump about 2 tiles higher than he could at normal speeds. It seems like varying frame rates may give you the highest jumps. At least I think that lowering the cycles count in DOSBox sometimes gave me bigger jump heights than simply patching the game to always run at the lowest supported frame rate (9.666... fps).

This is where the technobabble starts.

The game measures the frame time "tics" of a 145 Hz timer. The minimum is 6 tics per frame (24.1666... fps) and the maximum is 15 tics (9.666... fps). I think the problem lies in the way the game handles gravity. For every tic that passed during a frame, the game adds 3 to the yspeed AND then adds the yspeed value to the ymove value (but only for the first tics-1 iterations). After that, the game multiplies the final yspeed value by the number of tics and adds the result to the ymove value. The final ymove value is then added to Keen's y position.

Let's look at an example. Assume Keen's initial yspeed is -400 (this is the maximum value supported by the gravity function, I don't know what Keen's actual maximum jumping speed is).

If the frame time is 6 tics, then the gravity function adds -397 + -394 + -391 + -388 + -385 to the ymove value (-1955 in total). Then the game adds 6*-382 on top of that (-2292) for a grand total of -4247. During the next frame (6 tics again), the gravity function adds -379 + -376 + -373 + -370 + -367 and 6*-364 for a total of -4049. That's -8296 for 12 tics.

If the frame time is 12 tics to begin with, the gravity function adds -397 + -394 + -391 + -388 + -385 + -382 + -379 + -376 + -373 + -370 + -367 + 12*-364 for a total of -8570.

As you can see, higher frame times (and therefore lower frame rates) result in higher jumps (negative ymove values move Keen up, positive values move Keen down).

But there is another factor that limits the jump height. The engine only allows absolute xmove and ymove values of 3840 units per frame (this is the equivalent of 15 pixels), so that objects cannot pass through any solid tiles by accident.

So for the best results, you would probably want frame tics that are low enough to not lose any jump height due to that 3840 units per frame limit, but still large enough to gain as much as possible from the gravity quirks. That means: lower frame times at the beginning of the jump, that increase to the maximum as Keen moves up.

Wow. Thanks for the info! I'll need some re-readings to understand all of it. So perhaps that cornered lollipop was possible to collect on the computer Tom Hall designed and presumably play-tested his levels...

Whoa. I never knew about this at all before! Out of curiosity, I started up Keen 1 with DosBox and was playing around with the cycles, trying to see if I can get the infamous lollipop in Capital City. It took me many, many tries, but I actually got that lollipop, with cycles set at just 147! I noticed that at lower cycles, Keen will jump higher than usual, with the maximum jump height being random (sometimes he'll jump over 4 tiles, and sometimes he won't).

It's really cool that in even nearly 30 years after the original game has been released, we still make cool discoveries like this!

EDIT: I was playing around with the cycles in the ice level with ice cube shooters, and I noticed that lower frame rates affected the ice cube shooters as well!

So... maybe we should ask Tom Hall wether these lopipops were intended to be collected or not. And based on his answer to show him how it's possible to get these.

Quillax wrote: ↑Thu Dec 05, 2019 19:22 It's really cool that in even nearly 30 years after the original game has been released, we still make cool discoveries like this!

I second that. I know Keen since the mid-1990s and never even thought about the possibility that the jump height could be affected by CPU speed. Very neat.