4.0.1.0 playback problems

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

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

4.0.1.0 playback problems

Post by filbo » Wed Sep 20, 2017 4:59 am

Previous binary I was playing called itself 4.0.0.2 and was built 2017-04-11, most recent commit ad543757bee23838b7f1a58bd1eca6192a37af5e.
New one is 4.0.1.0, 2017-09-16, most recent commit 25c22434b11938e230719d6f73df4ed7813570be.

Today I am playing a level, finishing it, playing back the tape, and dying. 4.0.0.2 and probably a couple years' worth of builds before that have not had this problem, though long ago it was common.

The level in question is "$RO_GAME_DIR/levels/Emerald Mine Club/emc_down_under_mine_15/65" (for what it's worth).

Oh! Actually that _is_ helpful -- it turns out that the tape, which I created with 4.0.1.0 and which fails to play back correctly with 4.0.1.0, *does* play back with 4.0.0.2. So I upload it!
Attachments
4010-tape-playback.7z
plays back w/ 4.0.0.2, not 4.0.1.0
(1.04 KiB) Downloaded 10 times

filbo
Posts: 211
Joined: Fri Jun 20, 2014 10:06 am

Re: 4.0.1.0 playback problems

Post by filbo » Wed Sep 20, 2017 6:22 am

Hmmm. Here's an archive of two tapes from the same levelset -- one is the same as before.

Tape ................................ 046.tape .. 065.tape
Created under ................. 4.0.1.0 .... 4.0.1.0
Playback under 4.0.0.2 ... Fails ........ Works
Playback under 4.0.1.0 ... Works ..... Fails

Suggest: you should have a regression test which plays back a huge library of old tapes, insisting that a new version not fail to play back some tapes which previously worked.

If the library is too big to do a comprehensive run on, do continuous statistical sampling...
Attachments
4010-tape-playback-2.7z
(2.77 KiB) Downloaded 10 times

User avatar
Holger
Site Admin
Posts: 2752
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: 4.0.1.0 playback problems

Post by Holger » Wed Sep 20, 2017 8:53 am

(Small note to prevent confusion for those only using regular R'n'D release versions: There's no official release version 4.0.1.0 yet; this is the current version number of the R'n'D source code available from Git, and will probably be the version of the next release version of R'n'D.)
it turns out that the tape, which I created with 4.0.1.0 and which fails to play back correctly with 4.0.1.0, *does* play back with 4.0.0.2.
This is indeed very interesting, and most probably very helpful!

I haven't checked this issue yet, and currently have no idea what might cause this misbehavior, but I'm sure that this tape will help me a lot to track it down.
Here's an archive of two tapes from the same levelset -- one is the same as before.
This is also interesting, but even though I haven't tested it "hands on" yet, the case of "046.tape" would usually be fine, as there is no guarantee that tapes recorded with a newer version can be successfully played back with an older version. However, in the very context of this case, it might indeed be helpful nevertheless to find out what's going on.
Suggest: you should have a regression test which plays back a huge library of old tapes, insisting that a new version not fail to play back some tapes which previously worked.
Indeed, that's exactly what I use regularly (well, sort of), especially before creating a new release version. But I have to admit that I did not run it before I checked in those changes to fix that TAS snap keys bug. The main reason is that I simply forget to do it this time ;-) , even though I should really run it after all code changes related to any of the game engines. Another reason is that this unit/regression test contains so many solution tapes that it runs for several hours on my desktop system (so I usually run it over night), but unfortunately still does not contain any tapes for the EM/EMC engine (I think), which is something that I really have to change. But in this case it probably wouldn't have helped that much, because by intention I did not add compatibility code for this bugfix, so old tapes using this buggy behavior would have failed anyway -- but yes, maybe I should change this to not break old EM/EMC tapes that used TAS snap keys.

But there was another engine-related change closely after the TAS snap key bugfix (to be able to use both the snap and drop key in the EM/EMC engine for both snapping and dropping -- this time with compatibility code), which could also have caused the bug you encountered.

I will check your tapes and debug the whole thing, then report what I found out here -- please stand by! :-)

filbo
Posts: 211
Joined: Fri Jun 20, 2014 10:06 am

Re: 4.0.1.0 playback problems

Post by filbo » Thu Sep 21, 2017 5:05 am

BTW, I just thought to check whether the other TAS bug was fixed, and it was not: that quickly typing a TAS key followed by another action, the TAS key is often missed; 0-key rollover as it were... I don't expect you had intended the current work to fix that, but just in case you did, it isn't...

User avatar
Holger
Site Admin
Posts: 2752
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: 4.0.1.0 playback problems

Post by Holger » Fri Sep 22, 2017 12:47 pm

Just a quick note that I found the (totally hair-raising) bug (introduced shortly after the TAS snap key bugfix) that caused these tape inconsistencies -- I must have been drunk when implementing it. :-O

(The intention of the change was being able to use either button (snap or drop) for either snapping or dropping, so playing EM/EMC levels with a one-button joystick (or using just one joystick button) will be posslible, just like on the Amiga. Unfortunately, I totally messed it up, making it highly probable to create tapes that cannot be correctly replayed.)

I am currently thinking about an alternative solution (other than completely rolling back that change)...

While tearing my hair over this bug, I stumbled upon similar (even though less serious) potential issues with single-step mode and slightly different behavior when recording and replaying a tape. Even though I am relatively sure that these issues usually do not cause similar problems, I will review this code again, too, to find a better solution.

Thanks a lot for pointing me at these disastrous problems with tape recording/replaying, so I am able to clean up that mess before releasing the next version... :-/

Post Reply