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

[ccexplore]

I can't think of any advantage of using the cursor to scroll the screen, the cursor seems to be unaffected by lag frames and doesn't seem to cause them.

I noticed that using the cursor to scroll the screen one tiny amount can sometimes avoid causing a lag frame, compare to A+left/right, which scroll the screen by a much larger amount at once but almost always cause a lag frame.  So the idea is that maybe with some sequence of cursor-scrolls and A+left/right-scrolls, where all the cursor-scrolls cause no lag frame and there are enough of those, maybe you could potentially end up scrolling the same/larger distance while using slightly less lag frames.  But so far I'm not sure I'm getting enough of those no-lag cursor-scrolls to gain any advantage.

With your script however it doesn't seem to be working with TAStudio savestates which is what I use when working on solutions (this is after creating a new project with the new script).

Hmm, I haven't used TAStudio at all yet, will have to play around with it and see.  Unfortunately there may not be a good (or at least easy) way to deal with this, as I only see one thing in the reference documentations that allows me to save supplementary data to a savestate, which has no mention that it doesn't work with TAStudio savestates.

[Gronkling]

hmm interesting, it depends if you can scroll fast enough as scrolling 1 pixel at a time on certain frames will be much slower + the cursor will also have to be moved if it's needed away from the edge of the screen, but it could be used in some situations later I'm sure... I will definitely keep it in mind. Using A+S scrolling at the start of the level almost never makes lag frames so that's the best method as of yet.

TAStudio allows for more precise/easy jumping around, though it's not a huge bother if the script doesn't work with it because it's perfectly useful as it is



Fun 17 in 1270 Frames (~26s)
https://youtu.be/kEIG0eUZcIg
Only paying attention to the first two groups seem to cause the best result. Some hectic bashing through the two right pillars, and then a steel glitch to reduce the amount of floaters needed so that the time can be spent bashing the stairs next to the exit to reduce time due to jumping.

[ccexplore]

TAStudio allows for more precise/easy jumping around, though it's not a huge bother if the script doesn't work with it because it's perfectly useful as it is

I looked into it.  It might still be possible to support TAStudio despite its savestates not able to carry the script's data, but will probably require some hacks to make it work.  The hack is that TAStudio movies have per-branch markers list, and it looks like you can associate any frame of a movie with a marker (which is just some arbitrary text).  Normally markers are used by the user to annotate points of interest in the movie, but can certainly be repurposed by the script to store its tracking data in a per-branch fashion, given that some frames in the movie are almost never going to be annotated by user (eg. the first few frames after power on are not interesting and therefore prime candidates for script-inserted markers).

Essentially we use markers as a poor-man's method of allowing the script to "savestate" its tracking data to the branch.  While you are messing around within the same branch, the marker will always be updated by the script after each frame to reflect the most current state of the branch:  jumping backwards any # of frames => roll back all lag frames seen by script after the target frame you jumped backward to; advancing forward in time works as usual.  If you switched branch in between frame updates, it restores the state (which would include the markers, ie. the script's own savestate) of the branch at the time you created it or last updated the branch, effectively working like you load a normal savestate.  Saving the TAStudio project itself takes the current state (including markers) and save that, so reloading the project would restore to that state, similar to the branch switching case.

At least that's the theory.  Having to cram the script's data into text and back on each frame could end up tricky performance-wise, will have to do some tests and see.  This endeavor will definitely be more complex than adding support for normal savestates (which was already somewhat hacky and technically tricky in parts).  Don't expect progress anytime soon.

===========

Fun 17 in 1270 Frames (~26s)

I'm wondering if there's a good reason to assign the floaters so last-second?  You don't really need to optimize those lemmings--it's the last few to exit for save requirement that needs optimizing.  In any case, just like in "We All Fall Down", I believe you should dig down exactly multiples-of-3 times before stopping the digger (it currently does 4).  This will save 3 frames (ie. one physics update cycle aka "PUC") over non-multiples-of-3, assuming no changes in resulting lag frames.

Bashing the stairs next to the exit like you currently do, would turn a 4-pixel step into a 3-pixel step, which saves 3 frames (ie. one PUC) per change, though I don't know if the bashing itself may introduce lag frames that would slightly offset the advantage occasionally.  With a digger+basher possibly lowering the 3-pixel step further into a 2-pixel step, you can save another 3 frames (1 PUC) each by not having the lemming do a jumper transition to go up the step, but again dependent on whether/how the additional skill usages may introduce lag frames.

[ccexplore]

Manage to remove 6 more lag frames from Fun 11 (so down to 1660F with 12 lag frames).  It seems that having less lemmings in the compressed crowd can help reduce lag frames during the fade-out.  I first did a quick test of that idea by first manipulating the memory to artificially remove some of the lemmings in the crowd, and found that removing 4 from the crowd seems able to get down to just 1 lag frame during fade-out, while removing more doesn't seem to help.  Granted, that test is obviously not the same as an actual solution, but at least with this actual solution (which reduces the crowd size by sending more climbers up during the beginning), it did work out to getting just 1 lag frame during fade-out as the test suggested.

I did determine that a no-scrolling solution is probably not optimal, even if you avoid using the bomber.  Probably due to the one-way wall animations, it seems that once enough lemmings have entered the level and are on-screen, merely walking will still generate lag frames.  Scrolling also seems to require 1 lag frame per movement in this level even with no lemmings around (again, probably the one-way walls to blame).  So it seems like there's probably a minimum of around 10 frames required from just scrolling the left side offscreen.

[Gronkling]

Don't expect progress anytime soon.

Yeah don't worry about it!

Using your suggestions for fun 17, I saved a further 4 frames making new solution 1266F. The stair bashing at the end definitely saves frames.

Thanks for the new fun 11 improvement!



And Fun 18 in 2562 Frames (~52s)
https://youtu.be/-961ZucnrWM
Just bombing at strategic points and scrolling to try to remove lag frames caused by large numbers of lemmings.

[ccexplore]

Took a stab at lag frames reduction on Fun 18.  Now down from 166 lag frames to 58, so 2454 frames.

"Fun" fact:  you'd notice when I scroll back to the left, I continue to held down A+Left for a bit of time even after the screen already cannot be scrolled further left.  That apparently somehow makes a difference with lag frames, believe it or not.   If I release the buttons immediately after the screen has reached the leftmost position, I can wind up with up to 3 more lag frames.

[Gronkling]

Oh wow, that's a very odd fact, quite "Taxing"... so seemingly useless inputs can affect lag frames too hmm these things keep getting more and more mysterious. I'll assume that it only happens on very lag sensitive levels such as that one.. but I guess for now its just something to trial-and-error

Good job on getting the lag frames out there too!



Fun 19 in 3994 frames (~1m 20s)

https://youtu.be/_BJBjvizQdI

One of those levels where there's no choice but to do a very normal solution that takes a while. Lots of anti-lag-frame scrolling though, and I even manage to get a cosmetic scroll at the end for no cost.

Also it seems youtube suddenly want to upload my videos in 144p despite not changing any options, so sorry that these videos have been all blurry

[Gronkling]

and another one...

Fun 20 in 1764 frames (~35s)
https://youtu.be/i4NT_OYMWpw

A pretty interesting one. Two builders get over the first gap as soon as they can, and then bash to start walking again, also keeping there being no fall distance to the top of the steps. Miners are then used to shave off the corners to reduce falling times (this surprisingly doesn't cause many lag frames). The thin pipes are bashed through as you'd expect.

The last gap is the tricky one, a regular builder goes over the top to let the last few lemmings needed get over quickly. It's stopped with a basher as soon as possible. The ones that fall down create a basher staircase to the exit. It's constructed in such a way that it won't cause anyone going through the normal bridge route to fall down and step up. There's also a blocker to turn around a couple of stragglers from the basher staircase.



EDIT:
Let's get this one out the way
Fun 21 in 3819F (~1m 17s)

https://youtu.be/0gm-Aj2IQKA

Not the marble one of the same name which will be much more interesting. This is another one where there's no choice in what to do. Screen scrolls to reduce lag frames. The release rate had to be figured out by trial-and-error, there are probably better RR changes out there.

[ccexplore]

Nice job on Fun 20!

I was able to reduce 3 more frames out of Fun 11 (so 1657F), by using those climbers I sent up to smooth out some of the steps on top of the wall.  Doing so unsurprisingly adds a bunch of lag frames (precisely, 6 more), but still apparently add up to a small overall savings of frames.

==========

For Fun 19, here are a bunch of ideas to think about:

- By using a blocker at the starting area, you can alter the timing of the crowd with finer control such that you may be able to send them up a little sooner.  This is not the only way to alter timing, but likely the one method that gives you the most control over timing of crowd release.  Setting the blocker in the mining tunnel could also work, though it'll likely scatter the crowd slightly if some lemmings overtake the miner before it breaks through.

- The miner can start mining up to 5 pixels further to the right than where you're currently mining (ie. at the landing spot from the build bridge) without hitting steel.  This allows the miner to break through in 11 strokes instead of 13, which might again help allow you to release the crowd sooner.  (I think somewhere around 180 non-lag frames sooner.)

- If you don't use the blocker, you can instead send another climber ahead such that he overtakes the builder after the bridge is long enough but before the builder finishes.  (It can also be made to work if this second worker ends up behind the builder, but less efficient time-wise.) Have this second worker explode at exactly 5 pixels away from the leftmost column of pixels of the steel wall.  Then have the first worker start mining at the leftmost pixel of the lowest part of the bomb pit.  (So basically this setup is the lowest and furthest to the right you can get with a bomb pit, that still allows you to start mining without steel interference.)  This allows the miner to break through in 7 strokes, which might allow you to release the crowd sooner (though now you can't afford the blocker to help with timing, so I don't know).

[Gronkling]

Using the bomber suggestion, I saved 320 frames! (~6.5 seconds), record now 3674F (~1m 14s) The timing was very, very precise so I un-marked the solution as trivial. I ended up having to use the blocker too, to slightly delay the one to be a miner whilst the bomber exploded. That steel area does not give much room.

Fun 22 is annoying as expected

[Gronkling]

Fun 22 in 2958 Frames (~59s)

https://youtu.be/ccCVp3cxz4A

Eeek a beast of a level to optimise definitely! This takes the prize away from fun 7 for most tedious level so far... The main feature is the big basher staircase below the exit, this has to be recalibrated every time a small change is made to the method of getting through the trees due to different lag frames and lemmings distributions. There are almost certainly improvements that can be made here. It even takes a long time to load...

[ccexplore]

I finally figured out and fixed one of my major pet peeves with my lag frames counting script:  that it keeps getting disabled after things like reloading a movie, core reset, etc., forcing you to reload it manually. Now it no longer does that!   Once you opened the script in the lua console, it will remain active throughout the entire emulator session.

No other changes have been made in this script update.  Everything should behave just like it does today, except you no longer need to keep reloading the script whenever you replay a movie, load a different movie, core reset, etc.

[Gronkling]

Aah thanks!

Fun 23 in 2414 frames (~49s)

https://youtu.be/41boqO8wg2A

Quite fun but not much to explain, basically just a lot of fall distance/step reduction. Levels are starting to take longer now though, mostly taking over 2000 frames recently.


EDIT

Fun 24 in 1318 frames (~27s)

https://youtu.be/VJe1jmYUf5k

Mining through terrain as normal. A small step is built to shorten a fall.

[ccexplore]

For Fun 24 seems like fall-shortening can be applied to other falls as well?  In fact because all the other fall distances are not multiples of 3, you should already get a saving by reducing them down to nearest multiple of 3 with just 1 or 2 build steps.  Falling from first to second platform is 25 pixels, and the final fall to exit platform is 31 pixels.  The fall from entrance I think is 19 pixels (at least it should be on DOS Lemmings, so hopefully same in Genesis). [edit: still haven't tested, but since the fall from entrance do not involve a walker -> faller transition, resulting subtle differences in fall distance tracking might mean you need to use 2 build steps instead of 1 to actually effect a saving there.  Again, you need to test]

One other possible trick:  in DOS Lemmings anyway, fallers can't exit until on the frame where they land, but floaters (once they started the transition to floating, which can happen immediately after assignment if the lemming already fell for 16 or so pixels) can even before landing.  So depending on how exactly the exit trigger is set up in Genesis, it might be possible that if you set up the fall to happen directly over the exit trigger, you may be able to make exiting happen slightly earlier by assigning the lemming floater just one or two physics updates before it would've normally started landing and exiting, if it's able to trigger exiting before actually landing.  It is not a guaranteed savings though since I think the faller -> floater transition itself always eats up one physics update with no falling (again, based on DOS anyway), so it may well wind up that you save just as much time or more merely by shortening the final fall to 30 pixels instead.  You need to test especially since I don't know if the physics details in Genesis match DOS exactly here.  If float-exiting does help, the difference is small enough that you should only need to assign the floater to the last lemming that needs to exit for save requirement.

[ccexplore]

It is not a guaranteed savings though since I think the faller -> floater transition itself always eats up one physics update with no falling (again, based on DOS anyway)

This turns out to be not true in Genesis based on a quick test I was able to sneak in right now.  In DOS Lemmings (or at least Lemmix, but I'd be really surprise if it's not the same in actual DOS Lemmings, since the game disassembly from DOS I just looked at leads to the same conclusions), if the fall is long enough to matter (more than 16 or so pixels), assigning the floater during the fall will always eat up one physics update cycle ("PUC") during which the lemming doesn't move (ie. the faller -> floater transition).  It is especially clear if you have another lemming following closely behind (eg. RR 99) that isn't assigned floater, or better yet, if you can achieve a setup where both lemmings are at the exact same position--after even a last minute floater assignment during the fall (as oppose to one that happened upon landing, which granted are two cases hard to tell apart), they should end up separated by one pixel.

In Genesis however, based on my testing, things behave more normally--the transition does not skip the falling during that PUC like it does in DOS.

What that means is that there is no waste of time in Genesis from the floater assignment itself, so there's a slightly better chance that float-exiting would help, unless of course there are other differences to offset this (eg. differences in positioning of trigger areas, or the ordering in which trigger checking is done relative to other updates, etc.; heck, I don't even know if floaters do bypass in Genesis the landing check for exit that normally applies to fallers).  Again, you just have to test in Fun 24 and find out the optimal time to assign the floater and see how/if it affects the timing.