[Genesis] Lemmings (Genesis Port) TAS (WIP)

[ccexplore]

Here are a couple other random things off top of my head that may be different in Genesis compared to DOS:

- I know that in Amiga, the basher's stroke reaches one pixel further horizontally compared to DOS's, and the "backstroke" (the amount of terrain removed "behind" the basher) is a bit more than DOS's as well.  The former is most apparent with a level like "I have a cunning plan", where in Amiga the two bashers given is just enough to get through the pillar, whereas you'd be one short in DOS.  I don't remember which behavior Genesis has for bashers, I'd suspect Amiga's but should be tested.

- I also recall some subtle differences with climbers that affected the maximum-save solution for "From the Boundary Line", but that is much less likely to affect a solution.

- I remember that "Don't Follow Me" cannot be solved in DOS without fiddling with the RR--if you try, the final miner will splat in a fall that walkers can survive, while in Genesis the exact same moves appear to be survivable.  Again, not that likely to affect a solution in general, but a possible difference nonetheless.

- Finally in DOS, the trigger area of a one-way-wall ("OWW") object is actually offset 4 pixels above the object's visual boundaries.  This leads to cases like "Tribute to M.C. Escher" where there is actually a gap between the steel areas and the bottom of the OWW triggers, a gap that can be bashed through.  I don't know if this glitch exists in Genesis or not (heck, I don't even know what happens in Amiga off top of my head).

On that note, that glitch in DOS where you can't mine OWW even in the correct direction (for one of the directions of OWW, I forgot which), I don't think that carries over to Amiga, so probably not in Genesis either but not sure.

[Simon]

For reference this is what happens when using the last moment to start the next bash.
[picture]

Awesome research, with great explanations and a detailed picture. This is quality research, well presented, very enjoyable to follow. Looking forward to what's coming up.

Level 5 (basher level): In the video, on the exit platform, you don't make a perfectly smooth path across the platform. Instead, the crowd walks over a little hump left over. Why isn't this a problem for overall time?

-- Simon

[Gronkling]

A behaviour I have just noticed in this version of lemmings is that scrolling the screen can delay lemmings by a few frames... I'm not yet sure if this happens every time the screen scrolls or just under certain conditions, this means another thing I'm going to have to keep in mind is how much I scroll the screen during levels, and also that Fun 2, 4 and 5 will probably be able to be optimised by a further few frames, as I used more scrolling than needed to show things happening on screen. This is something I'm going to look into.

EDIT: This doesn't seem to be entirely the case... there seems to be something happening though which I'm looking into. Removing a cosmetic screen scroll has both sped up a solution, slowed down a solution and left some solutions unaffected.  Individual lemming's x-values are unaffected. Maybe it's something to do with object trigger areas being scrolled a bit oddly, or vertical movement, but whatever it is it's quite interesting. I haven't been able to get any sort of consistent result.
Fun 2 seems unaffected by any sort of screen scroll.
Fun 4 was improved by 5 frames when I removed the screen scroll (making the new result 1844)
(I'm not going to try fun 5 until I properly understand this due to how finicky it is)

Level 5 (basher level): In the video, on the exit platform, you don't make a perfectly smooth path across the platform. Instead, the crowd walks over a little hump left over. Why isn't this a problem for overall time?

Thank you! I left the \ on the left of the second grate unbashed as it seemed to save some frames HOWEVER due to the effects of the screen-scroll lag I describe above I am not currently sure if this is the case, this level will have to be partly re-done after more research on the effect is done.

[ccexplore]

A behaviour I have just noticed in this version of lemmings is that scrolling the screen can delay lemmings by a few frames...

Yikes, as if the TAS isn't annoying enough as-is.   It seems to suggest that game-state updates on Genesis are not locked to a strictly constant number of frame updates, and furthermore scrolling can sometimes apparently affect exactly how many frames need to happen before the next update to the game-state (ie. where lemmings' actions and their effects are processed).

Normally I would suggest trying out the solution in Lemmix (with the Genesis version of the level of course), but since the basher is involved and there might be physics differences as I noted previously, this may not be feasible here.  Maybe we should create a modified build of Lemmix that uses Genesis version's bashing masks......

====

Anyway, regarding Fun 5, in addition to testing the difference noted by Simon, it may also be worth testing the path where you don't bother bashing the first hump at all, instead start bashing at the first valley after having walked up and past the first hump.  You'd end up using 7 bashers instead of 8.  There are too many effects at play, but I do note that Clam uses that exact path in his speedrun for Lemmix, which would suggest it probably helps, and if nothing else is at least worth testing.  My main worry with that path is whether it's more proned to lemmings overtaking the basher and escaping the intended path entirely, but looking at Clam's speedrun that appears to be a non-issue.

[Gronkling]

Yeah, I originally skipped the first hump, but it ended up being a few more frames. I'm not going to work more on fun 5 until I understand this scroll thing better though, as it's the only level so far that requires a scroll, and the difference between different bashing routes are all different by only a few frames, making it even more vulnerable to scroll mix ups.

Scrolling the screen seems to delay sprite cycles and connected movement by one frame... sometimes. Other times it just doesn't change. It might be something to do with the amount of stuff on screen, I haven't been able to cause any frame delays on Fun 2. In general, as of yet screen scrolls should be avoided.

One of the other things I've noticed is that climbing is not constant y-change rather its more of a cycle.
It takes 15 frames to move 1 upwards once, then it takes 3 frames to move 1 upwards 3 times. This means the frame difference between moving 1 pixel upwards is this sequence:
15, 3, 3, 3, 15, 3, 3, 3, 15, 3, 3, 3...
This might be used to save some frames later on.

Walking however just moves 1 across every 3 frames. I'm going to try and map every skill out like this now.
EDIT:

Climber
y   1 ,1,1,1,1 ,1,1,1,1
f   15,3,3,3,15,3,3,3,15

Walker
x   1,1,1,1,1,1,1,1,1
f   3,3,3,3,3,3,3,3,3

Faller
y   -3,-3,-3,-3,-3
f   3 ,3 ,3 ,3 ,3

Floater
y   -2,-2,-2,-2,-2,-2,-2,-2,-2
f   3 ,3 ,3 ,3 ,3 ,3 ,3 ,3 ,3

Digger
y   -1,-1,-1,-1
f   24,24,24,24

Basher
x   1 ,1,1,1,1,1 ,1,1,1,1,1
f   36,3,3,3,3,36,3,3,3,3,36

Miner
x   2 ,0 ,2 ,2 ,0 ,2
y   0 ,-1,-1,0 ,-1,-1
f   36,27,9 ,36,27,9

Builder
x   2 ,2 ,2 ,2
y   1 ,1 ,1 ,1
f   48,48,48,48

[ccexplore]

Ok, so without the scrolling-induced delays, it looks like it's 1 game update every 3 frames.  The movements more or less match DOS's (yes, the climber is not constant y-change in DOS either).

I'm still a little thrown off by your report that in some cases removing the scrolling actually slows a solution down.  I think I'd like to see the two movies for this case (ie. the original faster version with more scrolling against the slower version with less scrolling).  In fact, maybe the original movie in the emulator's formats (basically anything where no intra-frame compressions are applied that may affect any frame-by-frame comparisons, so definitely not something like MP4).

Fun 4 does have those constantly animated, relatively large acid objects in addition to the usual tiny exit top.  That would be my current suspicion as far as why there's no delay in Fun 2 while there is in Fun 4.

[Gronkling]

Yes, I noticed this whilst working on a solution for Fun 6, I've attached 2 bizhawk movies (they're played with the bizhawk emulator with Lemmings Genesis European ROM loaded). The version with the cosmetic screen scroll at the end saves 4 frames. (The actual solution isn't perfect as I got sidetracked by this) For quick reference here's two pictures, the frame count is at the point where 20% are saved in the upper left corner. Objects are also pointed out and counted. (EDIT: I added a 3rd picture)

(Pictures under spoiler)

Spoiler (click to show/hide)

without screen scroll


With screen scroll (to the right)


EDIT:
Highest frame save I could find just by scrolling the screen at the end, saving an actually quite large amount of 25, almost a whole second

Notes: There's less lava shown on the slower solution. Fire blower is shown on both. Exit is shown on faster solution but entrance isn't. Again less lemmings shown on slower solution.
If the screen is scrolled all the way to right a further 3 frames are saved.
Scrolled all the way to the left and it's still slower but is 1 frame faster than no screen scroll.
Excessive screen scrolling just causes delays though.

Frames are still lost during the scroll (on certain levels?), but afterwards there is some kind of trade off that reduces lag, what that is is still a mystery.

[ccexplore]

It looks like things first diverged on frame #1691, but the funny thing is, at that particular moment it's actually the 1992F movie that got ahead of the 1988F movie at that point.

The movies however, did confirm one thing: even without any scrolling, the # of frames per game update is not strictly constant.  Or to put it differently, there must be other factors that can cause deviations from a strict 3-frames-per-physics-update cadence.  For example, observe that on frames 1507-1511, it took 4 frames rather than the normal 3 for the next game update to happen (ie. the lemmings move forward), even though there is no scrolling or even any cursor movements whatsoever.  I don't know if that's actually the first frame that broke the 3-frames-per-update cadence.  I did note that after that point, it starts fluctuating with unclear pattern between 3 and 4.

Perhaps it's not just objects, but all sprites that are onscreen?  That would also include things like lemmings, the explosion countdown numbers, explosion particles, etc.  Basically anything besides terrain and steel.  But then I'm not quite sure how that would translate to an irregular 3-4 fluctuations though (you would've expect it to just become a constant 4, since the number of sprites clearly isn't decreasing at that point in time).

[Gronkling]

Yeah, from what I've observed it is only 3 or 4, I haven't seen any 5 frame updates (and I hope I don't ), it's just finding any rhyme or reason about it, screen scrolling itself definitely tends to set it to 4 for some levels, but what else affects is still a mystery
1507-1511 is the first time I see a 4-cycle rather than a 3 too, so this is going to be what I focus on
The thing that happens on this frame is the 50th and last lemming out's sprite is drawn (or the 49th still shown on screen)
A picture of frame 1511 is shown, with sprites (excluding the cursor) counted

Spoiler (click to show/hide)

I'm going to try and reduce the RR part way through the level and see if this causes less delays
EDIT: Yes this has stopped the 1507-1511 4-cycle, 20% saved is now at frame 1949 saving 43 frames (with no screen scrolls at the end), in fact doing this has removed all 4-cycles in the level, so it's definitely something to do with either sprites or keeping track of lemmings. (Scrolling still causes 4-cycles at the end though)

EDIT2: Decreasing the release rate on Fun 3 (Blockers) didn't save any frames despite having the same number of lemmings, it has less object sprites so I'm going to assume that's why.

EDIT3: There are some 4-cycles in Fun 1 when a lot of digging is going on, not sure what's causing these or if there's anything that can be done about them. I have a feeling it's the particles from the digging, scrolling the screen left at the end saved 1 frame. Some more frames may be saved if I scroll the screen as left as possible at all times. (Due to a lack of objects or lemmings or sprites screen-scrolling doesn't seem to delay this level)
EDIT3.1: No more frames were saved that way.

I attached my current memory watch list to this post too which makes things a lot easier to see (it has each lemmings x-position etc)

[Gronkling]

Well taking a break from weird cpu cycle lag scroll stuff... here's an actual new level solution

Fun 6 - A Task for Blockers and Bombers in 1111 frames (~23s)
https://youtu.be/QjT0MakayRY

First a bomber is set to get through the first floor as to the right as possible. Right below that a blocker is set so no lemmings go the wrong way. Another blocker is set to keep lemmings grouped temporarily, letting two go on. Very temporarily in fact because that blocker was set to be a bomber earlier, so it will be a blocker as short as possible before exploding and releasing the others.
Meanwhile the second of the two loose lemmings is turned into a bomber and the first one blocks just before the thin pillar on the right, pushing the bomber through just as it explodes so there is no period of oh-no-ing time wasting, the resulting explosion removing the wall and freeing the blocker.
The release rate is also decreased due to the recently discussed cpu lagging, the same reason the screen isn't scrolled at the end.

[Apjjm]

This is really interesting and looking forward to seeing where this goes - I hope you get to the bottom of the frame loss with objects & scrolling, i like reading about the technical stuff like that which goes into a tas.

[ccexplore]

I'm at work and don't have the computer with the emulator with me, but I wonder if the emulator may have some sort of "sprite counter" or similar that could be helpful for the lag thing, just like it has a counter for frames.

[edit: extra stuff moved to another post]

[Gronkling]

The emulator doesn't have a sprite counter that I know of, though I found earlier you can remove the terrain layer leaving just the sprites. There may also be a memory value somewhere in the games code that tracks that.
(Genesis -> Settings -> Disable bg layer B)
It looks like this

Spoiler (click to show/hide)

(Particles and lemmings are on their own layer)

[ccexplore]

Incidentally, it would be good to attach the .bk2 movies for all non-trivial solutions, for obvious reasons.

For Fun 6, I wonder if it's worth testing having an exploding faller free the 2nd blocker (ie. the "temporary" one), instead of having that blocker itself explode.  This has two effects: 1) you may be able to free that blocker sooner (and have him exit in lieu of the faller you exploded), though it's unclear whether that would have any effect on the last lemming to exit; 2) it may be possible to have a slightly shallower explosion pit.  This saves 1 frame by avoiding a 3-pixel stepping-up in the explosion pit that a walker would have to jump for one frame to get up to [2-pixels is the max to avoid triggering jumping], and possibly a little more if it also reduces the amount of falling into that explosion pit.

The technique of blocker-pushing the lemming through the thin wall to explode without oh-no is interesting, but its benefits are somewhat less clear since there seems to be so much time between that explosion and the final-lemming-to-exit getting there.  I'm sure I probably overlooked something, but I'd expect the main benefits there to be related to some minor reduction (if any) in time spent falling there?

[Gronkling]

Here's all the solutions as .bk2 files

I did experiment with falling bombers, but I couldn't save any frames with it, it still may be an option however. The limiting factor here is the final few lemmings coming from the entrance and walking as fast as possible to the exit. A shallower pit has some hope of reducing this time I feel.

The blocker push isn't actually needed in this solution, I just left it there as it didn't make the solution worse and is accommodating to possible later frame reductions (e.g. experiments with falling bombers often require this to happen) if no other frame reductions are found that require it I'll most likely remove it