regression in emc_boulder_dash_pro

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

Moderators: Flumminator, Zomis

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

regression in emc_boulder_dash_pro

Post by filbo »

Running my regression tests on 4.2.0.5, I had 3 levels come up as last solvable on 4.2.0.3:

4.2.0.3 most recently solved emc_boulder_dash_pro level 87
4.2.0.3 most recently solved emc_boulder_dash_pro level 96
4.2.0.3 most recently solved emc_boulder_dash_pro level 97

... but then I went to play them back in 4.2.0.3 and it also failed. So then I swapped in the previous EMC levelset hierarchy, and suddenly those tapes were solvable again!

A diff of the two directories is less than a (45-line :) screen long. sounds_set is split into 2; titlescreen_1 is moved from pcx to png; and helpanim.conf has some changes I don't understand, but seem unlikely to cause an issue. Yet those three levels fail.

So, specifically:

4.2.0.3 + EMC 2.1.1 levels + my tapes, those 3 levels solve
4.2.0.5 + EMC 2.1.1 levels + my tapes, those 3 levels solve
4.2.0.3 + EMC 3.0.0 levels + my tapes, those 3 levels fail
4.2.0.5 + EMC 3.0.0 levels + my tapes, those 3 levels fail

These are 2P levels which I painstakingly solved in 2P singlestep keyboard mode (because I am insane). Something gets out of sync, one of the 2 players dies, everything goes to hell.

Ah, interesting. I see that in the shipped tapes, each of those levels, and several others, are named '%03d.tape.failed'. Yet all but one of them work for me. Again, specifically:

Level 81 tape is just bad.

Levels 86 87 95 96 97 98 99 work for me, on 4.2.0.3 or 4.2.0.5, with EMC 2.1.1 levels
Levels 86 __ 95 __ __ 98 99 still work for me, on 4.2.0.3 or 4.2.0.5, even with EMC 3.0.0 levels

So the fact that your runs fail those other 4 levels is very interesting. It seems there is some sort of timing variance which can happen due to some sort of environmental change, maybe?
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

Researching this caused me to find 2 other levels where our results differed:

emc_emerald_mine_15 level 92: another 2P single-step keyboard level, sure to be the same timing problem.

emc_crystal_caverns_3 level 3: this one succeeds for me because I patched the level itself. Changed byte #70 from 0x18 to 0x1A, thus changing the initial movement direction of a bug. Without the change, the 4 bugs in the initial room immediately reach a steady state of going nowhere, and the level is unsolvable.
Attachments
emc_crystal_caverns_3-003.good.gz
1-byte patch fixes this level
(499 Bytes) Downloaded 141 times
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

4.2.0.3 most recently solved emc_boulder_dash_pro level 87
Very strange. I tried to solve this tape with various versions of the game, but did not succeed.

The tape looks like this:

Code: Select all

aeglos@isengard:~/.rocksndiamonds/tapes/emc_boulder_dash_pro$ file 087.tape
087.tape: Rocks'n'Diamonds tape file, version 4.0.0.0, engine 4.0.0.0, date 20150929, level set "emc_boulder_dash_pro", level 87
aeglos@isengard:~/.rocksndiamonds/tapes/emc_boulder_dash_pro$ ls -al 087.tape
-rw-r--r-- 1 aeglos aeglos 4714 Okt 29  2015 087.tape
aeglos@isengard:~/.rocksndiamonds/tapes/emc_boulder_dash_pro$ 
(Side note: Strange observation I just noticed: "date 20150929" vs. "Okt 29 2015". Hmmm...)

The tape is from your "test-tapes-1.3.d" package.

For testing the tape, I used the "Emerald_Mine_Club-2.1.1" level collection, and both version 4.2.0.3 and 4.0.0.0.

Both tests resulted in "NOT SOLVED".

I also watched the tape in these versions, and the tape starts looking weird after the first diamond field was collected (which still worked fine, but afterwards things get worse).

Any idea what you might have done differently to get a successfully solved level with that tape?
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

Hah! Yes, I think I know what it is, although I have done zero experimentation to confirm this.

I think one or more of these settings is key:

- scroll delay: 3
- EM scroll delay: on
- small game graphics: on

I think some combination of different screen sizes is causing different scroll delay dragging behavior (doesn't P2 get pulled along when P1 tries to move offscreen, or P1 get blocked from moving?).

The EMC 2.1.1 levels in small game graphics have no vertical scrolling; the entire vertical space fits within the game window. In 3.1.0, there's a small range of scrolling.

My '2P' tapes are me playing P1 for a while, until it's necessary for P2 to do something; then vice versa, etc., until the level is solved. I played on small game graphics, i.e. double width & height game viewport. Actions that won't cause frame dragging in that setup definitely will on large game graphics.

... and indeed, I just tested, turning off small game graphics makes that tape utterly fail. Whereas, with the 3.1.0 level data + small game graphics, it gets much further, but still eventually fails.

...

So those 2P tapes I've submitted are more or less invalid, unless you can do something where frame dragging doesn't happen during playback (instead, up to N-1 players may be outside the viewport at any moment).
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

My reports that 4.2.0.3 was the last version to solve them were bogus. They were cached results from the previous version of the EMC Club levels. I thought I'd cleared away all old results to validly retest all the new levels, but -- on rechecking now -- I totally forgot to do that; all of my cached results are for EMC levels 2.1.1! Retesting now...
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

Levels 86 87 95 96 97 98 99 work for me [...]
OK, these tapes can be patched to work again (and other tapes that are affected by the same problem like tapes 093 and 094 from that same level set, if autotest'ed with EMC 3.1.0 activated in the last "normal" invocation, will also work again now).

The problem is just as you have described it: Generally spoken, when replaying a team mode tape with a different visual playfield size than during recording, this tape may fail as soon as a situation occurs related to players not being able to move when reaching an edge of the visual playfield due to other players staying at the opposite edge (with active default player focus that forces all players to stay within the visual playfield). This may happen with team mode tapes using either the R'n'D or EM engine.

I am sure that this problem has already been reported by someone else in this forum some time ago, but I cannot find that post at the moment.

I have added a new patch mode "screen_34x34" to patch most affected team mode tapes (which were recorded with default playfield size of 17 x 17 tiles, but "small game graphics" enabled in the setup menu). Team mode tapes which were recorded with normal 17 x 17 mode, but which are replayed with a different visual playfield size (as it is the case with all EMC team mode tapes recorded with EMC collection 2.1.1 (classic playfield size), but replayed with EMC collection 3.0.0 or 3.1.0, which has a different visual playfield size) will also work again, as 17x17 is the default now (while newly created team mode tapes with a non-standard visual playfield size store this size now in the tapes).

I've just started autofix'ing all your EMC tapes (and will go to sleep while they run) ... I'll report which tapes have been fixed tomorrow. :-)
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

> newly created team mode tapes with a non-standard visual playfield size store this size now in the tapes

Haven't checked the code, but I imagine this is a new tape chunk which specifies the size? Then shouldn't the patched tapes use that chunk, specifying 34x34, rather than a special bug flag?

I think tapes could be affected in the opposite direction. Suppose a tape was recorded with a low viewport (large graphics); and some dragging occurred. Playing that back in a large viewport, the players wouldn't be dragged.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

Haven't checked the code
Sorry, it's not in the public git repo yet.
but I imagine this is a new tape chunk which specifies the size?
Yes, exactly.
Then shouldn't the patched tapes use that chunk, specifying 34x34, rather than a special bug flag?
Yes, that's exactly how it works! (When I read your post, it sounds like you already had a look at the code! :D )
I think tapes could be affected in the opposite direction.
Definitely true! I did some tests with tapes recorded in normal 17x17 playfield viewport, played back with small game graphics (34x34 playfield viewport), as well as tapes recorded in 34x34, played back in 17x17. And also using the non-standard sized EMC playfield viewport...

(Heads up: When autotest'ing, the engine uses the playfield viewport of the level set graphics last used, so results may differ depending on the last level set.)
Suppose a tape was recorded with a low viewport (large graphics); and some dragging occurred. Playing that back in a large viewport, the players wouldn't be dragged.
Yep, exactly. That's now all handled by that new tape chunk (that only stores those two bytes for the playfield viewport width and height. Unfortunately, the already existing "HEAD" chunk only has one single byte still unused -- if it would have two bytes left, I could have used these (and interpreted by the engine if both != 0).

The new "HEAD" chunk is only used if

- the tape is a team mode tape (more than one player)
- the playfield viewport differs from the standard size (17x17)

Else, the engine assumes a 17x17 playfield viewport when replaying a tape...
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

Sorry, it's not in the public git repo yet.
OK, just pushed all that stuff to the public repo, to branch "master-next-patch-release".
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

I'll report which tapes have been fixed tomorrow.
Oh, BTW: The fixed tapes are exactly those that you already listed here:

- emc_boulder_dash_pro 086 087 095 096 097 098 099
- emc_emerald_mine_15 092

No other tapes were affected by this issue.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

> Yes, that's exactly how it works! (When I read your post, it sounds like you already had a look at the code! :D )

It's the correct solution in this context, so I pretty much knew what you were going to do :)

> (Heads up: When autotest'ing, the engine uses the playfield viewport of the level set graphics last used, so results may differ depending on the last level set.)

Last used? 'autotest' is a command line option that applies to a single levelset. Are you saying it carries over via setup.conf or something? If so, do you mean it carries over from the last interactive play, or what? Surely it cannot be that if you autotest levelset A, then B, then C, that B is tested using A's viewport, and C with B's viewport?

> Unfortunately, the already existing "HEAD" chunk only has one single byte still unused -- if it would have two bytes left, I could have used these (and interpreted by the engine if both != 0).

With 4 bits each, you could have used an enum to represent all the dimension values you can think of. But it's basically a bad idea :) New chunk with fully expressive numbers is better.

> Oh, BTW: The fixed tapes are exactly those that you already listed here:
>
> - emc_boulder_dash_pro 086 087 095 096 097 098 099
> - emc_emerald_mine_15 092

But I mentioned emc_boulder_dash_pro 086 095 098 099 as *not* having been affected!

Perhaps they were affected (differences in dragging), but the tapes ran successfully anyway? This could easily happen e.g. if the drag moved a player in a direction he was going to move anyway, so at the other end of the move he would just push against the wall a bit before turning. If there was a safe-to-push wall at the end of the linear motion...

Or, perhaps you simply mean those were all the multiplayer tapes which were created at different viewport size, so *should* be run at 34x34 even if the players were never far enough apart to make a difference.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

Last used? 'autotest' is a command line option that applies to a single levelset. Are you saying it carries over via setup.conf or something?
Yes, unfortunately. It's a command line option, but in fact, the program only suppresses window and graphical output, but else does everything it would do when fully running. Yes, that's extremely nasty. I never really thought of this, but stumpled upon it now when autotest'ing tapes that once succeeded and once failed, depending on the artwork of the set I used during the last interactive session. This Is Bad And Should Be Fixed[tm]. :oops:

It should use the default playfield viewport size of 17x17 here.
With 4 bits each, you could have used an enum to represent all the dimension values you can think of. But it's basically a bad idea :) New chunk with fully expressive numbers is better.
I also thought about this for a second or two... ;-) But this does not work, because you can simply define custom artwork that uses every visible playfield size you want -- even sizes larger than 256, if you are crazy (as the level's playfield is limited to 128x128), so you could force a case where one byte for the visible playfield width or height is not sufficient. But I decided to ignore such cases. ;-)
But I mentioned emc_boulder_dash_pro 086 095 098 099 as *not* having been affected!
Yes, but only under the conditions you listed above -- especially "small game graphics: on", which causes all levels to succeed. But if you use 17x17 (or 20x13 with the latest EMC set), the tapes fail because the two players cannot leave the visible playfield (unless player focus was explicitly changed during the game, which would be possible), and a 17x17 (or 20x13) visible playfield is too small for the recorded player movements of the above tapes.

When internally setting the visible playfield to 34x34 (as used during recording), everything works fine (even though the players are not always visible anymore when interactively replaying those tapes).
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

> It should use the default playfield viewport size of 17x17 here.

Levelsets have their own artwork, which might have a different viewport size. Shouldn't it use the levelset's inherent viewport size, just ignore any custom artwork settings?
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: regression in emc_boulder_dash_pro

Post by Holger »

Levelsets have their own artwork, which might have a different viewport size.
That's right, but you might decide to play it with a different artwork set (that might have a different viewport size). Or you might want to play it with "small game graphics" enabled (just as you did). So the viewport size when playing might differ from the level set's "original" viewport size.

Besides this, a level set's custom artwork may be subject to change -- see the EMC collection version 2.1.1 (17x17) and 3.x.0 (20x13). (The same is true for the artwork of the Supaplex collection, but there's no team mode option for these sets.)
Shouldn't it use the levelset's inherent viewport size, just ignore any custom artwork settings?
No, it should use exactly the viewport size that was used to play the level (record the tape) -- not storing and using it for replaying was the problem that caused failed tapes for team mode levels in the past.

And if there is no such chunk in the tape, the default viewport size of 17x17 will be used (as the chunk is only stored if the viewport when recording was different from this, which is the viewport size that is probably least wrong for already existing team mode tapes).
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: regression in emc_boulder_dash_pro

Post by filbo »

OK... in any case, the patch flag should not be '-screen34x34' but '-screensize 34x34' with the possibility to inject any needed dimensions.

(actually, make it '-screen%dx%d' and it remains 100% compatible with the scripts you already wrote!)
Post Reply