Oh damn! I'll have to buy a mouse and see whether it is compatible. Meanwhile my route planning has descended into chaos, since I found myself finishing a level way quicker despite a lower IGT, seemingly due to scrolling all the lemmings off screen during builds. Looks like I'll have to retime all my level comparisons with real time and go from there, though I had already started to prioritise lag reduction.
Sure you aren’t just using pause more often? That could result in longer rta’s and shorter igt’s.
Yep, the relevant level 8 features no pausing at all. I'll do some basic research into numbers, try to get a handle on it, then make a little video once I'm done that shows the difference. The basic tldr seems to be that with a certain number of lemmings on screen, animation slows down significantly, and it looks like I'm going to have to start scrolling everything off and back on screen in such levels many times.
So here are the first numbers about this stuff. I checked a couple of levels where there is no slowdown at all. Running the IGT from 5:00 to 2:40 took 2m30 of real time, with a ratio of IGT:RT of 14:15.
In my WR vid, Level 8 takes 3:24 real time to elapse 2:16 IGT. This gives a ratio of roughly 14:22, which shows what a mammoth loss I had.
I just did the same level with screen scrolling and elapsed 2:20 IGT in 2:45 RTA. That is to say, that simply by proper screen scrolling in one level, I saved FORTY SECONDS.
My initial findings suggest that slowdown begins around 14 lemmings appearing on screen and is worse as you go on. Once 20 were out, I lost 120 frames over the usual time to build one bridge, even with scrolling, and 240 frames by leaving them on screen.
This is an absolutely massive headache because it puts all my current strategies into question and also means I have to consider immediately killing numbers of superfluous lemmings. It may be that there are some levels where it works out best to keep a low RR so that as the first lemmings enter the home, some more come on screen, to keep the total below 14 at all times. I have asked on LemmingForum for help because this whole thing could turn into a real bitch. I wouldn't want to end up separating runs into lowest IGT and lowest RTA separately, but at the same time I have this horrible image of a bunch of interested runners coming to Lemmings, seeing some absolute TAS-like screen manip and RR manip fest, and being immediately put off running the game altogether. It's certainly a valid skill to lower the RTA but do you think it would be viable to split IGT and RTA if these delays persist all throughout the runs?
Another thought is that allowing IGT to count on its own might actually change the whole game because with that much extra thinking/reaction time, a player would have far less problem in rectifying mistakes since the effective speed of the game is slower even if the game thinks its still running at 60fps :/
I hand't run the game yet so I really don't have an specific opinion.
In any case, by my experience in other games, I think you should stick to RTA or IGT depending on which one is more comfortable and fun to play with. Then in the future is there's a good amount of runners that want the other method, a new category can be implemented for that (considering they'll be super different and not fair to compare against).
Hmm, that is interesting. On all the various ports, usually the developers changed things, for instance, the max number of lemmings appearing on the screen. In general, this was done to match the limitations of the hardware the game was being ported to. Looks like SMS is set to limit max lemmings at 20, like the ZX Spectrum does, so that's pretty crazy it starts to lag once more than 14 lemmings are on the board. Given that those sort of gaps would wildly change your strategy depending on what the best sort of time is, I'd be willing to separate IGT/RTA times on the leaderboards for ports where something like that would make a difference. I can only imagine trying to RTA the game where you'd constantly have to be trying to keep less than 14 lemmings on screen during the level, on each level, and also scrolling as often as possible to reduce lag when lemmings are actually on the screen.
I mainly split IGT/RTA up for full game/individual level runs to help better account for small differences in the DOS port as far as certain pauses and glitches go, but the juggling the number of visible lemmings on screen at any given moment really adds a whole different level to the mix.
Indeed, my first thought would be to switch to IGT total for 30-level blocks, but before I lower any of my existing times I need to get a way better handle on just how much delay is involved in these runs as a whole. I wonder would it be restrictive or confusing, to attempt to set an upper limit on the permitted RTA delay in a run? So that runners are not punished for the game's limitations, but equally are aware that they cannot sit idly while the game animates everything at 50% speed and coast to a wr time. This is a problem from the future but solving now makes life easier.
EDITED: Since we have the exact IGT to RTA ratio, I looked through my Fun WR (which has some scrolling but not lots) and collated the total amount of the times which were down to lag/slowdown. I'll take the worst few levels for it, and practice them until I get a decent optimisation of the rta, and see where the realistic lower bound lies, and report back on any subsequent difficulties in gameplay that arise.
Fourteen(!) levels had lag which totalled nearly SEVEN minutes. And that's just on the Fun segment. It will be an interesting project to see how much I can lower this in those levels.
Initial tests are very positive for lag reduction being quite easy where I have control of RR etc. Very first attempt at Fun 21, my RTA went down from 2:17 to 1:53 (which would be lower if I did it right) just from a few easy tweaks. Same success in Fun 20. So it looks like the Fun levels WR can not only be easily optimised, but isn't going to have a problem presuming almost all the levels are editable like this. I might do a side by side comparison of these levels in a youtube video to highlight the difference as it's quite visually shocking.
Totals for Tricky are slightly higher as one would expect. Twenty-six levels have lag, which totals around nine minutes.
The worst problem was Level 8, because you need four blockers and twelve to rescue, so you can't get below the 14 limit I discussed, but I was able to cut lag down to 15 seconds from over 40.
Sega Three had 49 seconds lag. I've already knocked my RTA down from 3:56 to 2:26 where lag is confirmed not to exist at all.
Menacing! had 42 seconds lag/delay, some of which was from bashing unnecessarily through the brick at the start. RTA has gone from 3:26 down to 2:44, with just 9 seconds of lag because of a high save % requirement.
There's a Lot of Them About is quite hard to optimise because you can't kill any lemmings. I can cut the lag though down to about 11 seconds, and get my RTA from 2:20 down to 1:58. Interestingly, in this level the IGT remained the same across the WR and the new run.
The general overview therefore is that a lot of the lag can be dealt with even in the smelliest levels, it will simply take a lot of strategy and working out to optimise. So I would advise dropping the IGT as a criterion/marker on runs straight away, in order that newcomers will easily understand that RTA and lag are just as much to be optimised as the actual route. It does mean I may have to spend quite a while re-formulating all the strategies in laggy levels, but it means I should be able to drastically lower both my records in the near future, especially with little things such as my Attic hack.
Here's my optimisation for Tricky 20 as an example - this one takes 1:44 rta where the former took 2:10. www.youtube.com/watch?v=XTrfrh-pi5o
www.youtube.com/watch?v=lC1kv1FL2Lg&t=04
Now it just gets silly. My friend who made Emulicious, and teaches Z80, told me that the game is written such that only the first 192 lines contain the game screen. NTSC uses 262 lines, PAL uses 342. And that because of this, he thinks PAL would have far less lag because there is more time for the game to do its work each frame.
So now I'm going to have to seriously investigate THAT, and check whether it's true. If so, PAL runs could be accepted as a separate category if anyone has trouble managing their lag strategies, that might be an ideal compromise to stop people being put off the game. Fortunately for my sanity, of course, if we remove all the lag from the optimal run, NTSC will still be faster and there's no debate about that being the method of choice.
"So I would advise dropping the IGT as a criterion/marker on runs straight away, in order that newcomers will easily understand that RTA and lag are just as much to be optimised as the actual route."
I can do this, but it would involve me erasing the IGT's from your run. If you are cool with that, I can do it it and make IGT invisible from the Full-Game Run perspective.
Presumably the PAL version would lag less, but you'd be running at 5/6th's the speed. Very unlikely that there is that much lag that could be reduced to offset the lower frame rate. That being said, PAL at 50 fps might be useful for IL runs, since it shouldn't really have any effect on IGT.
I think he meant there might be a lower proportion of lag which means it might affect IGT in terms of having a wider time window to complete critical actions. Probably we can say to new players 'if this looks daunting, feel free to run on PAL for now' once I test it out.
Please feel free to erase the IGT's and make it invisible on full game runs yeah ^^ I've started posting new optimals based on RTA to my Youtube. In some levels only so much can be done, but I had a surprising result in Lost Something?
Ignore the 85% mistake, I was testing various methods of optimising the level. This method came out ahead of creating a playpen at the very start of the level, where I made it so small that the lemmings bunched up into 1-2 sprites width total. I guess because in both cases I scroll them off screen, it's affecting the game the same either way and so it's better to put them closer to the exit.
Done. And wow that lag is bad. You can literally see the lemmings slow down as more come on the screen. I honestly don't think I've seen I've seen that much lag in a game on any console.
Mm, I'm making very good progress in not only smashing all the level times but drastically reducing lag too. Taking as a group the 14 Tricky levels I have videoed improvements to, I have knocked off a total of 6:55 from the existing record. Total improvement of around 15 minutes down to a sub 1h15 is highly plausible since some of the remaining improvement levels are the heaviest in lag. There will probably be just as much carnage within Fun because learning from one set of levels feeds into the other. Once I get the times down for both of these, to the point where it would require a lot of grinding to improve, I'll move over to looking at Taxing; probably in the next couple of months or so.
Here is a playlist of my progress so far, up to 19 levels at -7:39. Enjoy! Please feel free to point out stupid errors.
https://www.youtube.com/playlist?list=PLOTsjhPmEfJeElqnBUB6wPCj2k98ds9H8
As a bookend to the recent work I did on lag, I performed my friend's theory experiment with NTSC and PAL.
NTSC the game runs at 14 seconds of game clock takes 15 seconds real time; so that 2:20 game takes 2:30 real. In PAL the rate was 2:20 game to 3:00 real, or 6/5, as you expect.
But lag is different. Loading the same savestate to run 2:20 of game time through the clock with a screen full of 20 lemmings, NTSC took just over 4:20. PAL took just 4:28.
The implication of this is that for beginning speedrunners, the only punitive effect of using PAL is a slower time overall because of frame rate. This is compensated for because any extra lag they pick up will often be cancelled out by their having 1/6 extra reaction time in sticky situations. So if anyone out there is interested in taking up speedrunning SMS Lemmings but is nervous of all the work to do, start with the PAL speed to practice your strategies.
I have asked said friend whether it is possible to create a tool in an emulator, which can measure in real time, the dy/dx rate of change of lag tied to the game clock. You cannot just measure with lag frames because the game still runs at 60fps - it's only the animation cycles that slow down. My idea is that if such a tool is possible, it would be immensely useful to have during practice runs, since you would be able to see precisely what actions spike or lower lag, and specific areas to improve within complex levels. This would probably be essential in order to make any sort of dent in the Taxing levels. I found the RAM address that takes care of this so it seems as though it should be relatively simple to make such a monitor - if one is made I will append it to the resources section.
We did it!
www.youtube.com/watch?v=BLGrBL1DAGU
And you thought speedrunning wasn't as complicated as emergency medical technology xD
1ad4 in main rom is the animation cycle - lucked into that find! If I set the plotter to display ($dad4)*8, I end up with a nice seismograph style effect which is clear to understand. The game usually animates lemmings every fourth frame. This includes builders and likely also bashing. The best thing about this discovery is that you could just watch this value in any emulator and probably some very skilled person could map a lua script to overlay a HUD on the screen to indicate slowdown.
Slowdown begins to occur with the ELEVENTH lemming. Cycle goes from 1/4 to oscillating between 1/4 and 1/5. So it's no wonder I had no perception of slowdown since it's only 1 frame in 9 at this point. This can be reversed by scrolling to any point where a max of 10 lemmings are being animated.
Fifteen lemmings, and it becomes 1/6, scrolling will reduce it to 1/5.
At first when eighteen pops out, and permanently when nineteen are out, that goes to 1/7. Scrolling will still reduce this to 1/5, so already that's a bigger difference than I had ever thought.
I am looking at making a lua script which will count these superfluous frames, looks relatively simple to do so and would make a nice tool. I'm a beginner but it shouldn't take ages, and would work well with recording emulators like Bizhawk.
Research on lag continues but encouragingly it appears to be related to horizontal positioning on screen. Example: 20 lemmings on screen walking on a level platform will cause immense slowdown at 2 frames in 7. 20 lemmings on screen walking on a big bridge will cause barely any slowdown at all. The same applies for undulating territory.
I've started applying lag minimising concepts to the Fun levels now. I'm making a new playlist to showcase these improvements. I already found a way to gain 15 in Level 16 alone. The big banana so far is Level 17, which is technically interesting for its lack of floaters. In my last wr run it took 75 seconds. But now I can get it down in 53:
Albeit one cannot compare apples and oranges (nor 8 and 16 bit machines), Garbi's 41:32 is now well within sight if things continue apace. Ultimately I want to have the fastest time in both Fun AND Tricky excepting the insane nes run - it may take me a few months but I am determined. And frankly if I ever get bored I might try to come and steal a few of you guys' runs on other consoles, so keep improving yourselves ;)
I'm not sure I understand. Why would walking on a bridge in the level as opposed to the ground in general cause less slowdown?
I don't quite understand either, but I have video and photo proof that appears to corroborate what I say, ie I took a screenshot with 18 lemmings on screen but no slowdown (ie $1ad4 was only cycling between 1-5 not 1-7). I can make a video comparison of two states if you'd like, I can understand it seems berzerk but I think the reason is to do with the way the lemmings are drawn in - excess lemmings means the game switches between animating half on one frame and half on another. Calindro is still looking into what drives the $1ad4 byte but given that going off screen mitigates the effect it seems a logical conclusion that it's to do with horizontal positioning.
I have now padded my playlist of improvements to Fun, to 11 levels, including some massive saves out of nowhere. The total improvement from these is 7524 frames, or 2:05.4. The implication is that a sub-40 minutes time may be eminently possible if I hook up perfectly, and therefore the idea of besting Garbi's SNES time is absolutely doable. Some of these strategies are hair trigger though in terms of cursor movement, but I tend to play aggressively anyways so it shouldn't take many full runs to achieve it and there's far less faffing about in general with Fun levels.
