Just for future reference, there was some talk on Twitter a while ago (can't find it right now), that a Japanese RTA player managed to get the scroll glitch in 4-2, which caused the dropping platform at the end to be displaced so Mario could fall straight down, saving a bit of time.
Although the glitch is very rare and lag-dependent, it may be possible to do it in a new TAS.
A while ago, TiKevin83 resynced and also console-verified the current normal mode TAS here.
Since I had previously proven that the normal mode TAS can still be improved, I looked into implementing the improvement in the resynced bk2 movie file.
I don't know how TiKevin83 managed to resync the normal mode run VBM because I had to add idle frames after every level and didn't get the same bonus game as in my "known improvement" VBM. After adding a "Pause, nothing, nothing, Unpause" input after 3-3's scoring finished, I managed to get a fireflower bonus game anyway.
It didn't save 7 frames like anticipated, but actually 20 frames over the resynced bk2.
The resynced bk2 kills the 1-3 boss and fades white from the bonus screen on frame 8496.
The new bk2 which does not kill the boss fades white from the bonus screen on frame 8476.
There are also these facts which played a role into getting more improvements:
- I managed to find a 3 frame improvement in 1-3 by optimizing the pyramid section in the middle
- For now, due to observations I made with the frame rules, I will assume that omitting the boss is faster than killing him.
- I found that selecting a different color pattern during boot-up changes bonus game luck. So I went through world 1 without inserting any idle frames and then got a fireflower by pressing Down+B at frame 12 during boot-up.
This made the bonus game fade-out at 8470, therefore saving 26 frames.
- I still have to optimize world 1 for points before I can continue.
- With the current movie, the Down+B input is the only color pattern that will give a flower in 1-3 bonus game.
- If you use different button combinations during boot-up, one after the other, then it will give the result as if you had only pressed the last one. Sometimes it will give a start screen that is delayed by 1Frame so the movie desyncs. Therefore, selecting a color pattern multiple times will not give more control over the bonus game luck.
-----
Press on frame 12: Outcome:
< A Ladder-2up (2, f, 3, 1)
^ A Ladder-flower
> A (late start screen)
v A Ladder-2up
< B 1up
^ B 2up
> B 1up
v B Flower (Success!)
< 2up (3, 1, 2, f)
^ (undesired outcome not noted)
> Ladder-2up (2, f, 3, 1)
v (undesired outcome not noted)
press nothing (undesired outcome not noted)
-----
Press on frame 12: <A
Press on frame 14: >B
Outcome: 1up
Press on frame 12: ^A
Press on frame 14: vB
Outcome: (late start screen)
Press on frame 12: <
Press on frame 14: vB
Outcome: (late start screen)
Press on frame 12: vB
Press on frame 14: <
Outcome: 2up
Press on frame 12: ^a
Press on frame 14: >
Outcome: Ladder-2up
Press on frame 12: <
Press on frame 14: >
Press on frame 16: va
Outcome: Ladder-2up
Found another 2 frame improvement, by taking mush and fireflower in 1-1 instead of 1-2. Maybe the obtaining of mush or fireflower in 1-2 was suboptimal.
Getting Flower in 1-1 is better for getting points.
Unfortunately, with the 2 frame improvement, I had to find a new suitable color pattern but there was no color pattern that gave a bonus game with fireflower.
So I will have to insert an idle frame or two.
EDiT: It seems the 2 frame improvement got defeated by the frame rule in 1-3.
So I didn't save any more time, but this is good anyway. I found points improvements and there are possibly more color patterns that will get fireflower in 1-3 and maybe in world 2.
Ambassador, Moderator, Site Developer, Player
(158)
Joined: 3/17/2018
Posts: 359
Location: Holland, MI
It was less of a resync and more a rewrite, yeah the lag was completely different everywhere and it threw off the bonus games. The bk2s for 1.0 and 1.1 should still be in userfiles.
To make sure, you're using console mode GBA?
I'm using mode GBC mode. Oh, that might explain why there was such a time gap between the two movies.
The boot-up on GBA takes a bit longer.
Should the GBC mode be used because it is fastest?
Or should the GBA mode be used to be able to play it back on console?
Ambassador, Moderator, Site Developer, Player
(158)
Joined: 3/17/2018
Posts: 359
Location: Holland, MI
Yeah I won't be able to verify any further improvement unless console mode is GBA since the BIOS is slightly different
- feel free to use whichever is fastest, there's no hard requirement to use a version that verifies and my verification was never submittable since it had no gameplay improvements
I'm using mode GBC mode. Oh, that might explain why there was such a time gap between the two movies.
The boot-up on GBA takes a bit longer.
Should the GBC mode be used because it is fastest?
Or should the GBA mode be used to be able to play it back on console?
Using one console or the other for purely for a faster boot time is not considered a gameplay improvement here. You wouldn't be penalized for using GBA mode. Up to you for which mode you want to use.
Ok. For now I will continue working on a new run, but I'm not promising anything here...
I will decide which mode to use. I guess it is possible to switch between the two (GBA and GBC) easily and the bonus luck can be adjusted quickly. At least until we get to 2-3's bonus game. So it doesn't matter for now.
(All movie files use ROM version 1.0 and Bizhawk 2.7-Gambatte core.)
*8281 is possible, but the bonus game couldn't be manipulated.
**8295 is possible, but the bonus game couldn't be manipulated.
It looks like the 26 frame gap didn't come from any mode difference. I compared my GBC mode run to your movie file set to GBC.
Todo: Try idle frames in other places.
Just for future reference, there was some talk on Twitter a while ago (can't find it right now), that a Japanese RTA player managed to get the scroll glitch in 4-2, which caused the dropping platform at the end to be displaced so Mario could fall straight down, saving a bit of time.
Although the glitch is very rare and lag-dependent, it may be possible to do it in a new TAS.
Got an odd scroll bug while TASing.
There was not a single lag frame during the level.
The text is shifted to the left one row so it looks like it's related to the previously known scroll bug - which omits a vertical row during the level but here, the vertical row is omitted right at the end of the level.
It's not looking to be a timesaver. I changed the level to make the scrollbug not happen and the bonus game would still start at the same framecount.
I'm going to need to understand scroll bug better, in order to attempt it in the later levels.
After I discovered my visualisation luascript doesn't run correctly due to syntax errors that have somehow slipped into that post, I tried to fix the script but now it will output information that's different from before (when compared to the screenshot I had posted).
When running the "seemingly fixed" script, I noticed the information output is different between v1.0 and v1.1 of the game.
V1.0 (Every few frames of running right)
V1.1 (Every few frames of running right)
Not sure what to make of this. Unfortunately, I'm not very good at this. Help on this would be very appreciated.
My goal is a luascript that will do one or more of these things:
- Detect when the scroll bug has occured
- Visualize with a red vertical line which row has been omitted
- For non-bug frames with writes to $FFEA, should show information like how many cycles have passed in that frame and how many cycles it should have been to make the bug frame occur (if that makes sense)
Here is the script with syntax errors "seemingly fixed".
Here is a movie file with the scroll bug happening.
After I discovered my visualisation luascript doesn't run correctly due to syntax errors that have somehow slipped into that post…
Here is the script with syntax errors "seemingly fixed".
Language: diff
-for n=1,table.getn(addressList) do
+for n=1,#addressList do
I don't think it was a syntax error, exactly. It's just that the old script used the table.getn function, which was deprecated in Lua 5.1 and removed in Lua 5.2. BizHawk currently uses Lua 5.4. You fixed it correctly by changing it to use the # operator.
MUGG wrote:
I tried to fix the script but now it will output information that's different from before (when compared to the screenshot I had posted).
When running the "seemingly fixed" script, I noticed the information output is different between v1.0 and v1.1 of the game.
V1.0 (Every few frames of running right)
V1.1 (Every few frames of running right)
If I understand you right, there are two problems:
After you made changes to the script, it produces different output than it used to, for the same version of the game.
The updated script produces different output for v1.0 and v1.1.
On point (1), I'm not sure what the cause could be. I looked at the differences between the old and new script in Post #462326 and https://pastebin.com/qjMjp6ZP. The only significant change seems to be that, in addition to an onmemoryexecute handler, the script installs onmemoryread and onmemorywrite handlers for each address in addressList.
On point (2), the script is looking for the execution of specific addresses, and it would not be surprising for code addresses to be different in different versions of the game. You'll need a separate table of addresses for each different version.
From a quick check, judging by the text labels in addressList, it looks like the current table is tuned for the 1.1 version. For example, the "READ FFEA" and "READ FFE9" entries:
I don't think it was a syntax error, exactly. It's just that the old script used the table.getn function, which was deprecated in Lua 5.1 and removed in Lua 5.2. BizHawk currently uses Lua 5.4. You fixed it correctly by changing it to use the # operator.
I was talking about lines like
if MouseX>280 and MouseX<290>130 and MouseY<138 then
that I had to correct to
if MouseX>280 and MouseX<290 and MouseY>130 and MouseY<138 then
and the code for the arrowUp clickable button was missing altogether.
I added onmemoryread and onmemorywrite for no particular reason. Now that I think about it, I'm sure the original script only checked for executed bytes, not reads or writes.
On point (2), the script is looking for the execution of specific addresses, and it would not be surprising for code addresses to be different in different versions of the game. You'll need a separate table of addresses for each different version.
Yes, you are right. I will try to make a new script soon. Thank you.
My new hard mode run is currently in 3-2. Theoretically, the scroll bug could save time in some of the later levels, e.g.
in 3-3 - if one of the vertical walls could be removed and
in 4-2 - if one of the vertical breakable walls could be removed to move on quicker, but regardless of where it happens in the level, it would allow to skip the falling platform at the end of the level.
New script, unfinished but it's functional. It can be used with both game versions.
https://pastebin.com/63CdSW6w
It will show how many cycles have passed since the beginning of a frame, for any instance where $FFEA is written to with 0x00, 0x01, 0x02 or 0x03.
I will finish it and research the scroll bug with it, hopefully leading to some information.
Improved script
https://pastebin.com/55Leqbrp
It will visually show on the screen when a bug frame has occured.
The script will print information to the console if PRINT_INFO is set to true in line 5.
The script recognized a scroll bug mid level in 4-1 and the one I got at the end of 1-3 and there have been no false alarms.
The 4-1 one (bk2)
I'm not going to try it in 3-3 because I don't have fireflower before the vertical wall section and there is no lag. Unless I bring fireflower beforehand, the bug is probably not possible. So if anything I'm trying it in 4-2.
Since it took quite some time to get the bug just once in testing with tons of lag in 4-1, I think the chances of getting it in the TAS are too slim. It might happen by chance though.
I managed to get the bug by running a modified version of the linked script which repeatedly runs forward and jumps after delaying for increasing amounts of frames, while in a laggy situation. The laggy situation wasted a lot of time but due to the missing falling platform in the end, it reaches the goal at exactly the same frame as the optimized no-bug version. I'm convinced I can get it much faster eventually and save time with it. I'll keep trying.
Link to videoModified luascript
You have to change booleans at the beginning of the script.
Currently it's set to have Mario delay, then start running/shooting, then jump.
Upcoming input in the next ~200 frames in TAStudio has to be cleared and Mario has to be on the ground, obviously.
The script running can be observed in the middle of the video.
You will want to add client.pause() in line 86 or 223 so the script stops when the bug happens.
This kind of test could be done in many places of the level. Of course it would be best to get the bug with the least amount of lag possible but it's already frustratingly hard to get the bug at all since it's very rare.
By running the above script and also a version that randomly lets go of Right or B, I managed to get 3 results with the bug.
They all take about 13 frames of delay (by idling and lag) and finish the level about 25 frames faster than the no-bug version.
I'm glad about saving this much time but it needs optimizing. It should be possible to trigger the bug with only 1 or 2 delay frames.
In one of the above-mentioned results, I was shooting and the bug happened before the first lag frame even happened - but the 13 lag frames that happened after that were unavoidable.
The script currently running looks like this
This being the responsible code:
Language: Lua
local waitframes = emu.framecount() +1
tastudio.onbranchload(function()
(...)
vary3 = math.random(22,45)
vary4 = math.random(0,3)
vary5 = math.random(0,7)
end)
(...)
if run_test[6] then
-- Have Mario on the ground, clear upcoming 200 frames in tastudio
-- script will do inputs at set chance
-- start this at 86282
local vary1 = math.random(1,80)
local vary2 = math.random(1,50)
local press_b = true
local press_a = false
local press_right = true
-- star block jump
if emu.framecount() >= waitframes + vary4 and emu.framecount() < waitframes + vary4 + 10 then
press_a = true
else
press_a = false
end
-- ending jump
if memory.read_u8(0xFFF3) > 0x83 then
press_a = true
end
-- b kill
if emu.framecount() == waitframes + 17 + vary5 then
press_b = false
end
-- random
if not press_a then
if not (math.random(1,1000) < (980-vary1)) then
if emu.framecount() > waitframes + 10 then
press_right = false
end
end
if emu.framecount() > waitframes + 17 + vary5 then
if math.random(1,1000) > (980-vary2) and (emu.framecount() > waitframes + 16 + vary3) then
press_b = false
end
end
end
tastudio.submitinputchange(emu.framecount(), "A", press_a)
tastudio.submitinputchange(emu.framecount(), "B", press_b)
tastudio.submitinputchange(emu.framecount(), "Right", press_right)
if emu.framecount() > waitframes + 155 or emu.lagcount() > 407 then
savestate.loadslot(5)
end
tastudio.applyinputchanges()
end
If anyone wants to help with this, it would be much appreciated.
EDIT: The script came out with a 0 lag, 7 idle frames scenario overnight. That's pretty good!
By running the above script and also a version that randomly lets go of Right or B, I managed to get 3 results with the bug.
They all take about 13 frames of delay (by idling and lag) and finish the level about 25 frames faster than the no-bug version.
Nice! Can you only do this 1 time per stage, or multiple times?
Nice! Can you only do this 1 time per stage, or multiple times?
Theoretically you can do this as often as you want but since the bug is rare you can only do it a few times.
The bug can theoretically be used to remove walls such as in 3-3 or at the pipe section in 4-2 to move on quicker.
But I'm not bringing fireflower into 3-3 so I can't create lag to make the bug happen - even if I did, shooting might not create any lag.
And in 4-2 the location where the bug has to happen is not convenient - I would probably have to idle or lag more than the time I could save back.
So for now I'm just aiming for the bug "anywhere" in 4-2 to remove the falling platform at the end.
EDIT: The script came out with a 0 lag, 7 idle frames scenario overnight. That's pretty good!
This saves 35 frames.
It reaches the goal at framecount 87396 whereas the no-bug version reaches it at 87431.
I might try a few other places to maybe come out with even less idle frames but other than that I'm content with this outcome.
There was not a single lag frame during the level.
The text is shifted to the left one row so it looks like it's related to the previously known scroll bug - which omits a vertical row during the level but here, the vertical row is omitted right at the end of the level.
It's not looking to be a timesaver. I changed the level to make the scrollbug not happen and the bonus game would still start at the same framecount.
V1.1 (Every few frames of running right)
Not sure what to make of this. Unfortunately, I'm not very good at this. Help on this would be very appreciated.
My goal is a luascript that will do one or more of these things:
- Detect when the scroll bug has occured
- Visualize with a red vertical line which row has been omitted
- For non-bug frames with writes to $FFEA, should show information like how many cycles have passed in that frame and how many cycles it should have been to make the bug frame occur (if that makes sense)
Here is the script with syntax errors "seemingly fixed".
Here is a movie file with the scroll bug happening.When running the "seemingly fixed" script, I noticed the information output is different between v1.0 and v1.1 of the game. V1.0 (Every few frames of running right)
This being the responsible code:
