It often happens that the 'm' is ineffective; so that if I were not paying attention, I would walk past some of the emeralds, having failed to 'snap' them up.

I've known about that problem for a very long time. But there was another aspect which it took me much longer to verify:

When the snap fails, a turn is consumed. Suppose now that a yamyam was following me (from the left) as I traversed this corridor:

Y__P##########
#####o##o##o##

I would expect it to stay the same distance away from me, for each 'Right'; and get one closer, for each 'm'. And this is indeed what happens; but this is so even when the 'm' didn't snap.

So now I'm walking down the corridor, I hit R,R,m,m,R,R,m,R,R,m,m -- the extra 'm's because a snap didn't 'take' -- and the yamyam is now two steps closer to me than he started out:

__________YP##
#####_##_##_##

It seems that this happens when I hit 'm' "too early" in the time window of the next step. If I had a keyboard macro facility which was able to feed into RnD, I would expect a macro of 'RRm' (jammed into the input queue as fast as possible) to always trigger the problem, while 'RR[pause]m', with a pause of the right length (some 10s of milliseconds), would never trigger it.

====

There is another similar bug (might easily be a different manifestation of the same bug) in which the TAS keys cause the player to move. This is much easier to reproduce, in fact trivial: start any level, then hit 'jjjjjjjjj' a bunch of times. You'll move left some of the time. Hit 'jkjkjkjkjkjkkjkjkjk' (hammering both keys); you'll move left/right erratically. There is some pace at which you can hit 'j[pause]j[pause]j[pause]etc' and not move; this might be 200ms per 'j' or something like that. Faster than that, and you move.

====

So these are two separate bugs, but I suspect same or closely related underlying cause (having to do with the fooling around with the input queue which with which the direction-and-snap sequence is simulated). They might be characterized in one line as:

I've also played around a bit to check your observations, but so far I'm more confused than before... I thought I would know what's going on, but apparently I have to make some more detailed tests with debug output etc.

The behaviour I would have expected would be that key presses are ignored if entered too fast (without the previously triggered move being completely executed), but then such ignored key presses should not cause the game engine to play an additional frame (as can be seen with moving objects). Strange.

Also, I think the behavior I'm used to / expecting is that the 'next move' can be typed ahead and is queued for eventual execution 'at the right time'. Not 100% certain. I mean: when I play, I play, not necessarily analyzing everything in detail. Looking back, that seems to be what I'm conditioned to expect.

I should mention these observations were all on EM levels. Are there any other settings it would help to know?

This is extremely helpful to know! In fact, I've done all my tests with the RND game engine, which behaves differently. (Sorry, I should have asked for the game engine used before doing my own tests.)

But with this information in mind, your observations make more sense to me! Because the EM engine behaves differently in this regard: While the RND engine runs asynchronously (which means than input events can be processed at any time), the EM engine runs synchronously (and processes input events every eight frames, while doing virtually nothing (only screen updates) in the remaining seven frames. This has some fundamental consequences on input event processing. Let's have a look at this in some more detail:

Input event processing in R'n'D generally works differently than, say, in a text processing application. While the latter queues all input event (key strokes) in a buffer, to be able to process all of them subsequently, R'n'D only has a look at the current state of all recognized input devices. That means, it does not buffer input events to process them later. This is especially important for key input events. Buffering key input events would result in one of the following two problems, depending on automatic key repeat being enabled or disabled: If it's enabled during the game (like it is in the R'n'D menu, or in a text processing application), holding a key pressed would result in quickly accumulating lots of key events in the buffer, causing unexpected movements of the player after releasing that key (because the key events are stored at a much higher speed than the player moves). If automatic key repeat is disabled, it wouldn't be possible anymore to hold a key pressed to let the player move several fields without interruption. Therefore, key input within the game works just like a joystick: If a direction is indicated by holding a direction key pressed at a time the player is able to move, the player moves, if not, it does not move.

With the EM engine, things work a little bit differently. As the engine is not able to immediately process direction events at any given time (because the player can only move every 8th frame), this could lead to the following behaviour when the player is not moving: Pressing and releasing a key (or moving and releasing the joystick) very quickly during those seven frames, while no key/joystick direction is pressed anymore in the eighth frame, would result in no movement at all, which would be very unexpected behaviour when the player was not moving before. To circumvent this, changes of the direction input state during these seven frames are stored and processed in the eighth frame (where it is important to differentiate that the "direction state" is stored, but no "direction events" are buffered -- that is, only one single direction "event" will potentially be processed in the eighth frame).

I understand that in single-step mode, expectations may intuitively be different, as game actions do not run continuously in this case (with the game engine reacting on optional input state changes), but are directly triggered by "input events", while everything is paused in the meantime -- just similar to the behaviour of a text processing application.

Also, I think the behavior I'm used to / expecting is that the 'next move' can be typed ahead and is queued for eventual execution 'at the right time'. Not 100% certain. I mean: when I play, I play, not necessarily analyzing everything in detail. Looking back, that seems to be what I'm conditioned to expect.

This absolutely makes sense to me, yes. And I'm quite sure that this is the "intuitive" summary of what I've written above.

So, to match "intuitive" expectations in single-step mode, it would be required to change the usual in-game behaviour described above, and buffer and process input events instead of handling the current input state when the player is able to move.

I'll have a look if such a change could be added to the state/event handling in single-step mode without too much complications...

In addition to the above post, some thoughts on the experienced misbehaviour of quickly entered TAS keys for snapping (without being able to directly test it at the moment, so it's just from thinking about it).

The first one (snap keys are ignored, but engine continues an additional game frame) seems to make sense to me with the EM engine: While the first move ("move right") is still being executed, the next move ("move right") AND the following snap input ("snap down") are both stored to be processed during the eighth EM engine frame, resulting in "right | down | snap" being stored. In the eighth frame, this input state cannot be processed (as there is no diagonal snapping), so no player action will be performed. But the engine plays another game frame nevertheless, as there _was_ some player input.

To "fix" this as described in the last post, both input actions would have to be stored and processed independently.

BTW: This could be a problem with the normal (non-TAS) keys, as "press snap key, keep it pressed, press direction key, release snap key, release direction key" would have to be stored/buffered and processed as one single input event in single-step mode. But maybe there is a solution for this. (Or maybe this case could simply be ignored, as this kind of input in single-step mode is already processed as two input events (which is the reason why there are TAS keys for snapping available now).)

The second observation (TAS snap keys causing the player to move) is currently a riddle to me, and I have to reproduce/debug this "hands on"...

Without thinking too deeply about this (because I know I am never going to achieve the same level of understanding as you have, of the input processing): single-step is essentially a different input mode. It may need a whole processing / parsing layer between it and the 'regular' game engine processing of this layer's output. It may need to accept asynchronous input and serialize it as every-8-frames output (to become input to the game engine's regular input queue). And as you describe, this parsing may include various sorts of bundling / coalescing of separately typed inputs.

I get the feeling that right now it is sort of _effectively_ a layer like that, but built over time in a more ad hoc fashion, through which shine these various imperfections...

Yes, I think you're right with how you've described it, especially regarding single-step mode being (or requiring) a different type of input mode. Single-step mode really "feels" like it could/should accept key input that way.

I'll check if it could perhaps be possible to just delay processing input events unless the last one was completely processed (meaning to not process any event while single-step operation is _not_ in paused mode). This could possibly work as expected, and would maybe be an easy solution. However, I'm not sure about handling the "snap" and "drop" keys, so I will do some tests...

Besides the oddities I described with the snap keys, there are odd behaviors with dynamite. But these odd behaviors seem intentional and more-or-less 'right'. e.g., in single-step mode (and again this is in EMC!), hitting the 'light dynamite' key for a short time only burns the fuse part way. You must hold it down for a longer period, as if allowing it to 'autorepeat' for that many small sub-frame steps. But then, when it reaches the point of the fuse actually being lit, it stops 'autorepeating' and comes to 'the end of the frame' or 'the end of the single-step movement'.

In fact the handling of that might point somehow to a model for handling other sorts of actions. Not sure.

I vaguely remember there might be other such exceptions. Certainly nothing else I encounter so consistently as the snap issues...

A simple 'typeahead' system might work. Too long of a typeahead buffer would be problematic; I suppose queue length could be a user setting (or maybe that's a bit too geeky!) There should be a 'clear typeahead' key available to be mapped, particularly if you might allow long queues.

===

Another thing that bugs me in the input system (maybe related / maybe not): changing the speed with [modifier]-[1-9] unpauses a pause, may count as a 'move'. Now it occurs to me that I always use left-ctrl-[1-9], and left-ctrl is my 'snap' key; I should experiment with e.g. alt-[1-9] to see if the same issues occur...

... and indeed they do not. Before I was doing:

[some live action motion][space-to-pause][ctrl-7 to go faster][damn! it unpaused]

and if I instead do [alt-7 to go faster], it doesn't unpause. So if I can only remember to do that, that problem is solved :)