config recommendation: tape player buttons & actions

Discussion about Rocks'n'Diamonds, Boulder Dash, Supaplex, Emerald Mine and any other BD hybrid.

Moderators: Flumminator, Zomis

Post Reply
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

config recommendation: tape player buttons & actions

Post by filbo »

I have, and recommend for other players, the following tape keys (Setup -> Key Shortcuts -> Tape Buttons):

'0' Eject Tape
'1' Warp / Single Step
'2' Stop Tape
'3' Pause / Unpause Tape
'4' Record Tape
'5' Play Tape

As well as (Setup -> Key Shortcuts -> Various Keys):

' ' (space) Start Game & Toggle Pause

Based on these, I have a number of brain macros:

A. Used from the main menu while the game is not in play; many also applicable during game play, or from a pause. I use these to review my own play and "solution tapes", and to get back to where I was after dying or leaving the game for a while:

'0:ist' Load "solution tape" provided with levelset, if available (then '55' or '551' is nice)
'5' Play tape
'55' Fast forward
'555' Fast forward, pause before end
'551' Play as fast as possible with display (FF)
'5515' Play as fast as possible with display, pause before end (FFP)
'51' Play as fast as possible without display ("warp forward") (WF)
'5155' Play as fast as possible without display, pause before end (WFP)

B. Used to interrupt playback of a tape ('3' or ' ' are equivalent here):

'34' Cut tape here, start live play (appending at the cut point)
'341' Cut tape here, start live play in single-step mode

Example:

I have solved about half a level when I need to do something else. Hit ESC to "quit" the level. At the menu, hit '0' (eject) to save the partial solution tape. Quit the game. Later I come back to finish this level. I start RnD, it comes up on the same levelset and level number. From the menu, I hit '51' to play up to the point I'd been at. After a little while the game pauses the level at the point where I'd stopped. I hit '4' to record (append) onto the in-memory tape, finish solving the level, and let it save normally (it prompts me whether I want to overwrite the existing tape, I say 'yes').

=======

Holger, what would you say to embedding those definitions in the standard game config?

=======

Besides this "full control" tape system there are two other systems which overlap with it in ways that I don't really understand.

C. There are "Quick Save Game to Tape" (F1) and "Quick Load Game from Tape" (F2). I don't use these due to problems with synchronization of the resulting tapes. I stopped using them a long time ago and do not know if those problems are now resolved.

D. The newest git code also has new single-step forward/back buttons, which I have not yet tried to integrate with my playing style. I tried these a little bit but they seemed not to be integrated with the 5-control tape system. Playing back a partial tape, if I then tried to single-step backwards it lost track of where I was.

I'm not sure if the single-step buttons have any existing key bindings or a way to bind them to keys.

=======

I've worked on this post sporadically over the last 18-24 months, just now updating it to encompass the new git code. Sorry if it's a little disjoint.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: config recommendation: tape player buttons & actions

Post by Holger »

Holger, what would you say to embedding those definitions in the standard game config?
Yes, this looks like very handy shortcut definitions. I think I will add them right away just as you described it as the new default shortcut values. (Currently, only "warp / single step" is defined by default, and is set to the "." key. I think your suggestions are better.)
C. There are "Quick Save Game to Tape" (F1) and "Quick Load Game from Tape" (F2). I don't use these due to problems with synchronization of the resulting tapes. I stopped using them a long time ago and do not know if those problems are now resolved.
These problems still exist. Unfortunately, I wasn't able to track down this problem so far, or find a way to reproduce this in a reliable way that would be suited for debugging this old bug. As far as I can see, this has something to do with random numbers (as playing levels with a lot of random stuff seem to be affected more than those with less such stuff, while levels without any random stuff (like Sokoban levels) seem to be not affected at all). I reviewed the corresponding code for creating and restoring the game system state (as used by quick save and quick load) several times, but found no hint to where the problem might be so far. :-(
D. The newest git code also has new single-step forward/back buttons, which I have not yet tried to integrate with my playing style. I tried these a little bit but they seemed not to be integrated with the 5-control tape system. Playing back a partial tape, if I then tried to single-step backwards it lost track of where I was.
Using the (still considered experimental) single-step forward/back buttons when playing tapes should now also work with tapes (so tapes can be paused now and "played backwards" (no smooth backwards playing though, but only stepping backwards step-wise using the buttons for each step). As this uses engine snapshots just like quick save/load, it suffers from the same consistency problems (plus it can quickly eat up a huge amount of RAM, which still needs some optimization by throwing away more and more snapshots when the tape grows larger -- this has been covered somewhere else in the forum, I think, with some good suggestions on how to "compress" (shrink) the list of snapshots).
I'm not sure if the single-step buttons have any existing key bindings or a way to bind them to keys.
No, currently not, but this may be added later when they leave "experimental" state.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

Holger, what would you say to embedding those definitions in the standard game config?
Yes, this looks like very handy shortcut definitions. I think I will add them right away just as you described it as the new default shortcut values. (Currently, only "warp / single step" is defined by default, and is set to the "." key. I think your suggestions are better.)
There is some problem with this, I forget exactly what -- I'm just posting now to forestall you from issuing a version with my definitions until I report back what the problem is; or 24hrs. Thanks.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

Right, so the probem is that '0' also means "toggle between 4% and 100% speed" when -DDEBUG, and -DDEBUG is turned on by default in the current Makefile. That might just be an artifact of point in development cycle, but it's what anyone using this change would see at the moment.

Since I'm not currently working at a company that wants me to icebreak through an archipelago of red tape before I can contribute to open source, I can just give you a patch! Woo!

Here. Below is what would be my verbose git commit message. I'll attach the patch itself, to preserve tabs etc.

=======================================================
Rationalize game-wide special control and debug keys:

- Alt or Control plus the following keys now work everywhere:

'-' Decrease window scaling factor
'+' Increase window scaling factor
'0' Reset window scaling to default (100%)

'1-9' Set game frame delay (speed):
'1' is double-speed (200%)
'2' is normal speed (100%)
...
'8' is fairly slow (25%)
'9' is very slow (4%)

'b' Toggle Supaplex border elements
'd' Toggle debug mode
'v' Show game engine version

- Keypad synonyms (and '=' for '+') also recognized
- Speed changes always print a message (previously it worked in both
play & main menu, but confusingly printed the message only in play)
- '0' used to toggle speed between what are now Ctrl+'2' and Ctrl+'9'
- The range of speeds is as was implied by ineffectual existing code
- This frees un-shifted '0' for use as a tape control key
=======================================================
debug-keys.patch
Rationalize game-wide special control and debug keys
(5.34 KiB) Downloaded 557 times
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

C. There are "Quick Save Game to Tape" (F1) and "Quick Load Game from Tape" (F2). I don't use these due to problems with synchronization of the resulting tapes. I stopped using them a long time ago and do not know if those problems are now resolved.
These problems still exist. Unfortunately, I wasn't able to track down this problem so far, or find a way to reproduce this in a reliable way that would be suited for debugging this old bug. As far as I can see, this has something to do with random numbers (as playing levels with a lot of random stuff seem to be affected more than those with less such stuff, while levels without any random stuff (like Sokoban levels) seem to be not affected at all). I reviewed the corresponding code for creating and restoring the game system state (as used by quick save and quick load) several times, but found no hint to where the problem might be so far. :-(
I spent some time chasing a different suspicion of mine about this bug. I've come to an "interesting" point -- no bug yet fixed, but maybe you can get me past the current hump...

I've long observed that tapes created in single-step mode differ from "normal" tapes in that they are riddled with "0" moves. Suppose I start playing and immediately hit '1' (my shortcut) to go to single-step mode; and then hit right-arrow a dozen times; and then save the tape; call it "tape A".

Then suppose I start again, don't hit '1', hold down right-arrow until I've moved the same distance; and save the tape ("B").

Comparing these tapes, A has a bunch of short move-right actions interleaved with null actions:

Code: Select all

0000: 0:00 [    |  ] - (002) [00000]
0001: 0:02 [ >  |  ] - (011) [00002]
0002: 0:00 [    |  ] - (001) [00013]
0003: 0:02 [ >  |  ] - (007) [00014]
0004: 0:00 [    |  ] - (001) [00021]
0005: 0:02 [ >  |  ] - (004) [00022]
0006: 0:00 [    |  ] - (004) [00026]
0007: 0:02 [ >  |  ] - (015) [00030]
0008: 0:00 [    |  ] - (001) [00045]
0009: 0:02 [ >  |  ] - (007) [00046]
while B has long held-down keys:

Code: Select all

0000: 0:02 [ >  |  ] - (255) [00000]
0001: 0:02 [ >  |  ] - (230) [00255]
0002: 0:00 [    |  ] - (001) [00485]
0003: 0:01 [<   |  ] - (255) [00486]
0004: 0:01 [<   |  ] - (222) [00741]
Now, perhaps I could have figured this out just by thinking about it, but in practice it took a bunch of "printf"-style debugging. What I figured out is that I can create a single-step tape which is identical to a live-action tape, if I hold each key down for a long time. Not really "a long time", just long enough for Rockford to have moved as far as he's going to.

As long as this problem has been happening (to me: I'm pretty sure it predated my discovery of RnD :) -- I've suspected it has to do with the sub-move timing, not with random numbers. I know you believe otherwise, and there's a good chance you're right, but for now I am pursuing my line of debugging...

It seems what happens is:

I hit a motion key, then release it before the resulting single-step motion is complete. Then the tape records some amount of motion in that direction, followed by "0" (no action) for some period of time. The total amount of time written into the tape for each single key is 8 frames, and I think it is true that if, on reading back the tape, the game only pays attention to actions in the 0th frame of each set of 8, it will accurately play back my actions. But I haven't found where it does that (i.e. decoding the frame-by-frame playback of the tape into 1/8 as many moves).

What if in doing that decoding, it actually acts on actions from the 2nd frame of each set of 8? Or the 3rd? Most of the time, playback would still be accurate. But once in a while I might have hit and released a key so quickly that it was recorded as only 1 frame of motion + 7 frames of nothing; then playback could be wrong.

OR, what if at some point the accounting is mistaken, so that a [key, release, wait for next move] sequence wasn't written as a full 8 frames, but only 7? Then everything would be off by 1 frame -- and that would actually play back correctly most of the time. But if that happened multiple times, once it was 2 or 3 frames off, moves that had been recorded as only a couple frames of move + 6 frames of nothing, would now be missed.

...

I guess what I need to do now is actually reproduce the problem, and examine the resulting saved tape. And the problem with that is, it's been so long since I used the quick save/load method that I don't remember how! All I have left is a reflexive avoidance of them...

======

Anyway. I'm wondering how hard it would be to have single-step mode pretend that the key I hit has been held down for an entire 8-frame move, i.e. don't pay attention to the key-release action until the move is complete? Resulting tapes would be smaller, easier to interpret by me trying to debug things, and it might just fix the problem.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

In fact I wrote a program `shrink` which smashes "nothing" frames together with the preceding motion frame (this would utterly destroy any tape with legitimate and necessary pauses, but it doesn't harm the one test tape I tried it on).

Dumping the output, I see this:

Code: Select all

0035: 0:02 [ >  |  ] - (024) [00374]
0036: 0:18 [   v|1 ] - (008) [00398]
0037: 0:02 [ >  |  ] - (024) [00406]
0038: 0:18 [   v|1 ] - (008) [00430]
0039: 0:02 [ >  |  ] - (024) [00438]
0040: 0:1a [ > v|1 ] - (003) [00462]
0041: 0:18 [   v|1 ] - (005) [00465]
0042: 0:02 [ >  |  ] - (024) [00470]
0043: 0:18 [   v|1 ] - (008) [00494]
0044: 0:02 [ >  |  ] - (008) [00502]
0045: 0:04 [  ^ |  ] - (008) [00510]
0046: 0:04 [  ^ |  ] - (008) [00518]
0047: 0:04 [  ^ |  ] - (008) [00526]
-- moves have been summarized down to single 8-frame actions, or in a few cases lumped together into e.g. 24-frame 3-moves-doing-the-same-thing. But where I've snapped -- at [00462] -- single-step mode has faithfully recorded exactly when within the move I initiated and released the snap.

Actually I don't know if that's accurate either. Notice in this case that the duration of having held down the snap key is shown as 8; it just isn't on move boundaries. This "smashed" save file has 4 instances of this (a snap recorded on non-move boundaries, but still exactly 8 frames long). It also has many other snaps which are like the ones at [00398] here: exactly 8 frames long and exactly on move boundaries.

I'm not sure what all of that means. It just seemed interesting that snaps are being recorded as exactly 1 move long, but not necessarily on an exact move boundary (yet usually so).
Anonycat
Posts: 47
Joined: Thu Mar 27, 2008 4:45 am

Re: config recommendation: tape player buttons & actions

Post by Anonycat »

That's a phenomenon I've long noticed, to the point where I hex-edited all the mid-step waiting moves out of my tapes simply to compact the file sizes.

Different branches of the game engine treat snaps differently: the BD and EM engines effectively only poll at 8-frame intervals, so anything you do--move, snap, or wait--commits to an entire 8-frame window. In SP, a snap still costs 8 frames, but can be initiated freely at any point, and waiting only costs 1: you can wait for 3 frames, then snap to use up 4-11 without being forced to wait through the next 5. Meanwhile, base RND takes up only a single frame to snap while still allowing waits in any multiple of 1--the only catch is that after a snap, you can't snap again without either moving into another square or inserting at least one frame of exactly 0x00 movement. This last one could be tricky, because single-step mode offers the ability to increment frame by repeatedly pressing the snap key by itself, but this is an input of 0x10 which isn't good enough. By default, there is no reliable way to insert a single 0x00 frame in 1-step mode, although I've edited that hotkey into my local copy of the game (which is still running on the 3.3.1.0 code)--that kind of precision is especially helpful at tasks like repeatedly flickering conveyor belts, either for hitting the "scroll right" position when it's 3 flicks away, or simply because spamming a conveyor belt can make the objects on it slide 37% faster.

Walking into a wall is another thing that can waste a frame, but some levels are coded to force an older interpretation of the RND engine (from around 2002) to be used, in which that act not only wastes the frame but locks you out of the next 7 as well. It's not just a mechanism for wasting time, though: if you're pushing a rock, the rock acts as a wall until the push delay expires. If you're dealing with a random push delay (BLEH) of, say, 8-15 frames, the relevant random number isn't actually drawn until after the 8th frame, but rolling the lower bound of 8 works as-is, while anything else gets padded all the way up to a push delay of 16 since the nominal delay expires while you're still in the recoil state from walking into the "wall" on frame 9. Modern levels are at least more sensible about this, and rolling a push delay of 10 means you can push the rock successfully on the 11th frame instead of the 17th.

Another curiosity is that you can truncate the final 7 frames off any completing tape, and it will still complete, but the game thinks it gave autonomy back to the player once tape input ran out in the middle of the final step, so after playing it back, it will ask if you want to re-save the tape (this time with the 7 blank frames re-added to the end), and regardless of what you answer, it will proceed to show the high-score screen.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

FWIW, I've been testing on levelset "emc_cosmos_mine_04" levels 033 & 034; thus using the EMC engine. Ctrl-V says "::: currently using game engine version 4000000".
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

Here is a tape which changes behavior when "smashed".

I'm not including smash.c because it's too ugggly to believe :)

Anyway, things go wrong at about 4630 on the frame counter.

I believe in actual gameplay, I had single-stepped my way up (almost) to the point where I wanted to snap-up, then fumbled the keyboard, doing a plain "snap" (left-control) as a standalone move, before moving up one more and actually doing the snap-up.

The recording there has:

Code: Select all

0094: 0:04 [  ^ |  ] - (157) [04473]
0095: 0:00 [    |  ] - (001) [04630]
0096: 0:04 [  ^ |  ] - (007) [04631]
0097: 0:10 [    |1 ] - (008) [04638]
-- and apparently that 1-frame '0' at 04630 is crucial. i.e. it is the one frame whose action matters.

How did it get recorded that way?

Could it, in any form of playback, make a similar error to what my `smash` did -- reading out a different frame's action from that 8-frame move cycle?
emc_cosmos_mine_04-015.tape
Original tape of my play
(403 Bytes) Downloaded 558 times
emc_cosmos_mine_04-015-smash.tape
Same tape after running through `smash`
(349 Bytes) Downloaded 550 times
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

Hi Holger --

I posted this 6+ years ago and you said you were going to immediately implement it. And then I said wait, no, there are conflicts.

I think the conflicts are long since resolved... so maybe this can go in?

Meanwhile, there are a bunch of other interesting things here about tape artifacts etc., which I have no idea whether they have been resolved... :)
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: config recommendation: tape player buttons & actions

Post by filbo »

Updates to the 'brain macro' tables from the original post, for two reasons: (1) the ones in the original post aren't correct for current code (I'm not sure if the code changed or I just got it wrong back then); (2) fixing terminology. 'Fast Forward (FF)' means 'play at a fast, but watchable speed'; 'Warp Forward' means 'play as fast as the game can go while displaying'; 'Nodisplay Forward' means 'play as fast as possible without displaying'.

The 'pause before end' macros are '51...' because if you do '55551' you'll often hit end-of-tape before having a chance to hit '1' for 'pause before end'. Other than that, the order doesn't matter as long as it starts with '5'. (Starting with '1' puts you in single-step mode instead...)

'brain macros':

A. Used from the main menu while the game is not in play; many also applicable during game play, or from a pause. I use these to review my own play and "solution tapes", and to get back to where I was after dying or leaving the game for a while:

'0:ist' Load "solution tape" provided with levelset, if available (then '55' or '555' is nice)
'5' Play tape
'51' Play tape, pause before end
'55' Fast forward (FF)
'515' Fast forward, pause before end (FFP)
'555' Play as fast as possible with display ("Warp Forward") (WF)
'5155' Play as fast as possible with display, pause before end (WFP)
'5555' Play as fast as possible without display ("Nodisplay Forward") (NF)
'51555' Play as fast as possible without display, pause before end (NFP)

B. Used to interrupt playback of a tape ('3' or ' ' are equivalent here):

'34' Cut tape here, start live play (appending at the cut point)
'341' Cut tape here, start live play in single-step mode
Post Reply