Well in that case, what happens in bubbleman with that boss glitch where you fall down and appear in the mid boss room?
Same thing with the... uh... what stage was that... crashman.
Also, i'm quite confused about the item 1 above the screen and you randomly teleport above the next screen. Wouldn't you be able to do that earlier in crashman?
Sorry for all the questions. :S
Oh, and why do you have to use the flashmans freeze "weapon" after the zip in quickman?
Well in that case, what happens in bubbleman with that boss glitch where you fall down and appear in the mid boss room?
Same thing with the... uh... what stage was that... crashman.
Also, i'm quite confused about the item 1 above the screen and you randomly teleport above the next screen. Wouldn't you be able to do that earlier in crashman?
Sorry for all the questions. :S
Oh, and why do you have to use the flashmans freeze "weapon" after the zip in quickman?
There is no point to do it in earlier in the crashman stage even it would be possible. Check the page 36 of this thread and read Bisqwit's long post it should to explain why screenscrollings occurs :]
In the quickman I would die without using flashman's weapon there because after a zip I'm in a different room and there is no possiblity to avoid those lasers so thats the reason. Thanks for the questions.
EDIT1: Cool avatar Silent_Slayers!
Thanks. :)
I love metalman. I actually made a speedrun non-tas of it that is just under 10 seconds slower than one of your TASes of him. :P
I love him for his stage and music. :D
Since my playing with scrollings haven't done any progress FinalFighter decided to make a Japanese help thread to gather people and their knowledge of the game etc. and BasicBot. I've spent countless time to try that trick out even FinalFighter have tried it without succeeding yet. We're not playing together but he wants to support my project.
But still we do know what should to occur there but it just won't happend because the music code turns normal after one frame. It seems it is good to get 2xCrabs and 3xitem1s into same Y register value so the glitch should most likely occur with or without scrolling.
This site is in Japanese if you are interested to see what happens there :
Rockman 2 TAS Help
I divided a movie for that site so the other players can use it and I can simply copypaste it if there is a possibility for scrolling. You can find my Bubbleman's downscrolling from there.
This is done because my movie is in a critical state and it is almost impossible for one person to handle.
I've tried not to spoil myself as an observer, but I've seen some of what you've posted so far - it's all amazing.
I'm still patiently waiting for this TAS to be completed. Good job, and good luck.
http://www.yuko2ch.net/rockman/bubble_shutter_dscrolltest.avi
It remodels and cheats used, the scroll in the under will be caused surely, and it does.
It doesn't succeed if the shutter is not seen.
The scroll signal is not to cause if not going to the screen edge in a word.
This is meant to be used in the bubbledownscrolling part. Be sure to stop your emulator where you want bot to play (Stop -> Run Lua Script -> Maximize your speed).
According to FinalFighter this needs much improvement and planning because Bubble's downscroll succeeding percent is extremely low and the problem lies in the music code because it turns back to its normal state matter of what.
Mr. TaoTao from Japan is willing to help and also trying to make a lua bot but much more advanced one.
Hello.
I found a "temporary" solution of bubbledownscrolling. But this is not so optimal because it needs to wait one extra enemy and wastes about 2 seconds. According to Shinryuu, it saves only 12 frames.
About downscrolling, Bisqwit already described its mechanism in this article. But, I want to make the cause of the failure in downscrolling a bit more clear.
In the first place, when rockman touches the bottom of the screen, $82A1 makes a check to determine whether scrolling can occur. And, when downscrolling succeeds, the flow of code is like below:
$829E -> $C7A5 -> $C000 -> NMI($CFED) on $C006-$C019 -> $82A1
And, when downscrolling fails, the flow of code is like below:
$829E -> $C7A5 -> $C000 -> normal bank-switching(NMI doesn't occur) -> NMI
(NMI can occur before $C7A5, but it's quite a rare case in bubbleman stage)
In short, when downscrolling fails, NMI occurs after $82A1 had already been executed. $C000 is also called by various codes except $C7A5, but NMI during these calls never affects the success or failure in downscrolling.
So, we have to adjust the timing of NMI to achieve downscrolling, like below:
$C7A5 -> $C000 -> NMI on $C006-$C019
To know the actual timing of NMI, the trace logger of FCEUX is useful. For example, if $C7A5 is followed by 1000 instructions until NMI, we have to make the program execute about 1000 more instructions before $C7A5 to achieve downscrolling (In other words, we have to generate more delay of 1000 instructions).
Note: If the shutter is not completely seen, $C7A5 is never executed, so downscrolling never succeeds.
Next, I will post how to measure delay using the trace logger of FCEUX.
Hello.
I found a "temporary" solution of bubbledownscrolling. But this is not so optimal because it needs to wait one extra enemy and wastes about 2 seconds. According to Shinryuu, it saves only 12 frames.
About downscrolling, Bisqwit already described its mechanism in this article. But, I want to make the cause of the failure in downscrolling a bit more clear.
In the first place, when rockman touches the bottom of the screen, $82A1 makes a check to determine whether scrolling can occur. And, when downscrolling succeeds, the flow of code is like below:
$829E -> $C7A5 -> $C000 -> NMI($CFED) on $C006-$C019 -> $82A1
And, when downscrolling fails, the flow of code is like below:
$829E -> $C7A5 -> $C000 -> normal bank-switching(NMI doesn't occur) -> NMI
(NMI can occur before $C7A5, but it's quite a rare case in bubbleman stage)
In short, when downscrolling fails, NMI occurs after $82A1 had already been executed. $C000 is also called by various codes except $C7A5, but NMI during these calls never affects the success or failure in downscrolling.
So, we have to adjust the timing of NMI to achieve downscrolling, like below:
$C7A5 -> $C000 -> NMI on $C006-$C019
To know the actual timing of NMI, the trace logger of FCEUX is useful. For example, if $C7A5 is followed by 1000 instructions until NMI, we have to make the program execute about 1000 more instructions before $C7A5 to achieve downscrolling (In other words, we have to generate more delay of 1000 instructions).
Note: If the shutter is not completely seen, $C7A5 is never executed, so downscrolling never succeeds.
Next, I will post how to measure delay using the trace logger of FCEUX.
Oh, I didn't expect you to release/tell this information to here!
Really good news TaoTao and thanks for giving and also sharing this information with everyone. I'm really looking forward to this and also I'll try to help you with this much as I can :)
This information should be most likely vital to build LuaBot to aim for "Just to scroll" theory like FinalFighter said. In facr if bot lacks these values it cannot know well how to succeed and it only wastes time.
Like seen in your "temporary" solution it seems or if I recall and remember correctly jumping height also have a big role in your succeeding percent so it is good not to jump "fast jumps" and because music code is important it is OK to change weapon few frames later and so on to test things further.
We are trying to solve the mystery of using only 3xItem1s and 1xPause and it should be possible to perform. If that happens bubbledownscrolling part will save hige amount of time.
As I said, the essence of downscrolling is the amount of delay. So, I explain how to measure it.
To measure delay, we need:
* FCEUX
* Shinryuu's latest progress (.fm2 version)
* A text editor which can display line numbers
First, play after Shinryuu's latest progress (for example, shoot item1 three times and fall down) and create a movie.
Play the movie, and advance frames until rockman's foot touches the bottom of the screen:
Open the trace logger of FCEUX ("Debug" -> "Trace Logger"), select "Log to File", specify the filename of the log, and press "Start Logging".
Advance 5 frames, and press "Stop Logging". Now, a trace log is output to the log file you specified.
Open the log file with your text editor, and search "$C7A5" at the beginning of line, and note the line number. And, search "$CFED" at the beginning of line just after that, and note the line number.
In the pictures above, $C7A5 is executed at line 17633, and the next NMI($CFED) is executed at line 18330. So, $C7A5 is followed by about 700 instructions until NMI. In other words, we need more delay of 700 instructions.
That's all. We can measure delay of various patterns of movement. And we will be able to know the answers of the questions, like "What kind of action generates large delay?", "How about the limit of delay?".
If we found the pattern in which the shortage of delay is less than 100 instructions or so, it should be quite a hopeful pattern and downscrolling should succeed by modifying the details of it (In such a situation, bots may be help).
Next, I will post heuristics to increase delay. And, I will also post the shortage of delay in some movie examples.
Various factors affect delay:
* Objects in the screen (rockman's weapons, enemies, items dropped by enemies)
As a general rule, more objects generate more delay. And bigger object seems to generate more delay.
* The timing of music
The load of NMI routine varies every frame (about 600..2300 instructions, but about 1000 instructions at most frames). This variety comes from mainly sound-related code. So the timing of falling down will affect delay. Unfortunately, in Shinryuu's latest progress, the load of NMI routine will be at most 1600+ in reasonable frames.
The sound of weapons may also affect delay.
* The timing of horizontal scrolling
When we scroll the screen to right edge completely and fall down at a time, delay seems to be somehow increased. I call it "justscroll". The amount of delay caused by justscroll is not so clear. More advanced analysis will be needed.
Some movie examples and delay:
EDIT: Here, "NMI" means the NMI just before $C7A5.
The shortage of delay is about 230 instructions, NMI: about 1600 instructions
This movie uses justscroll and three item1.
This is the most hopeful one I found. But my LuaBot (tries all combination of 1 left button and 3 B button) couldn't find a solution based on this.
The "excess" (rare!) of delay is about 830 instructions, NMI: about 1370 instructions
This movie waits one extra enemy, and uses justscroll and three item1.
This movie shows that delay from justscroll is very unstable. But, it seems that delay from justscroll is about 200 instructions when we don't wait any extra enemies. This is strange. We'll need more deep analysis.
EDIT: Downloading my LuaBot with HTTP_REFERER may fail. Please copypaste the address to your browser. Sorry.
Some movie examples and delay:
But, it seems that delay from justscroll is about 200 instructions when we don't wait any extra enemies. This is strange. We'll need more deep analysis.
This is something I haven't thought also this sounds really weird. Maybe it does have something to do when second crab comes into the screen or when you take damage so can't it change something around?
Thanks for the .lua scripts you did they will be a big help :)
http://www.mediafire.com/?jyyxjtmjikjhttp://gocha.s1.zmx.jp/down/public/mirror/c7a5_fceu_custom.zip (mirror)
I created custom FCEU(for win) that measures the instructions of lines(Only downscrolling).
How To Use
1:You jump into the hole.
2:The message is displayed.
It is number of instructions:($CFED->$C7A5) ($C7A5->$CFED)
When it is a success example( "temporary" solution of bubbledownscrolling.), it is number of instructions of "4".
If the number of instructions is smaller than 100, the state is very promising.
Hahaha that was bloody and incredible result! Who would ever though this was in the end possible to do that fast . I got this movie from finalfighter early this morning and I've been investigating it since then. It seems that the key is even more harder to find from woodman's upscrolling because Mega Man is not in the screen and Heatman's weapon doesn't seem to help much to get instructions smaller. What I've experienced so far I was able to get 1400 instructions (or a bit less) with a slow performation.
It is good to get less than 100 instructions and seek even more because there is a possibility for the scrolling. Thumbs up!
These instructions appears in my movie :
Crashman = 10 instractions
Bubbleman = 4 instractions
cstrakm's idea saved 4 frames but I pushed it to 5 frames but 5 frames wasn't enought to break Quickman's frame rule so I had to do something for it and I was able to zip really quickly in the second zipping. After my discovery I gained much time and lost some to black screen. I investigated things there and there and was able to perform first Item1 scene in the Metalman stage 2 frames faster by different Item1 positioning (Quickman stage affected to it). For some reason boss battle gave me trendemous amount of time about 5-6 frames or so. When I entered Bubbleman stage the distance was in 20 frames. I had problems in the stage but I was able to manipulate enemies better (less lag) in the place where that mother fish is to gain 2 frames more.
This was somewhat interesting experience because one trick affected all of these events and scenes!
I'm very glad to see things progressing after a long, long halt!
Thank you, everyone who have contributed towards that goal.
Rejoice for that Shinryuu has so many fans :D
I'm trying to follow along here, so let's see if I have e'erything right...
A glitch was found that, by an interrupt occurring at the right time, corrupts a register value determining which way the screen can scroll. If this can be made to work at Bubbleman...
What then?
I am not yet fluent in 日本語, unfortunately.
I'm trying to follow along here, so let's see if I have e'erything right...
A glitch was found that, by an interrupt occurring at the right time, corrupts a register value determining which way the screen can scroll. If this can be made to work at Bubbleman...
What then?
Congratulations , Mr. pirohiko.
We were able finally to defeat BubbleMan!! :)
Time until jumping down doesn't change though it damaged.
In a word, it can be said "the solution" that we were expected.
We began to work on delay in the Woodman stage.
(upscrolling and death)
http://www.yuko2ch.net/rockman/delay-deaty--idea.jpg
I'm trying to follow along here, so let's see if I have e'erything right...
A glitch was found that, by an interrupt occurring at the right time, corrupts a register value determining which way the screen can scroll. If this can be made to work at Bubbleman...
What then?
Open the trace logger of FCEUX ("Debug" -> "Trace Logger"), select "Log to File", specify the filename of the log, and press "Start Logging".
Advance 5 frames, and press "Stop Logging". Now, a trace log is output to the log file you specified.
Open the log file with your text editor, and search "$C7A5" at the beginning of line, and note the line number. And, search "$CFED" at the beginning of line just after that, and note the line number.
In the pictures above, $C7A5 is executed at line 17633, and the next NMI($CFED) is executed at line 18330. So, $C7A5 is followed by about 700 instructions until NMI. In other words, we need more delay of 700 instructions.
That's all. We can measure delay of various patterns of movement. And we will be able to know the answers of the questions, like "What kind of action generates large delay?", "How about the limit of delay?".
If we found the pattern in which the shortage of delay is less than 100 instructions or so, it should be quite a hopeful pattern and downscrolling should succeed by modifying the details of it (In such a situation, bots may be help).
Next, I will post heuristics to increase delay. And, I will also post the shortage of delay in some movie examples.
