WOW paosidufygth another huge find for a classic Mega Man game, your amazing!!! Really looking forward to the new Mega Man 4 and 5 TASes now!!!
Mothrayas wrote:
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
With all due respect, that would look really bad, cheap and make route planning non-existant. When tasing nes mega man games through all these years, all of us spent so much time planning the route within what an __original__ game offered. That's also paying tribute and respect to these games.
Going for the psx version due to getting fast weapon switching really is a cheap move. This is also why you are unfortunately having a hard time getting your submission of Mega Man (psx version) accepted. The psx version offers nothing new. Though we have the vault category now.
Glad though Pike is improving Mega Man 5 using the original version. Sorry for the long post but you know by now that I really dislike taking the easy way out. Good luck in the end to all participants.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
I strongly disagree that TASing Complete Works would be cheap or bad-looking, or not show proper respect to the NES games. Quick-weapon switching and lagless rooms changes a lot of what's possible and would produce a unique companion speedrun to the original version.
I don't know what strats have changed from Glitchman's TAS other than Crystal warp or the new Wily 3 zip, so I don't know how different a new MM5 TAS would be, but I would be just as interested to see a very optimized CW TAS as that.
(to be fair I'm probably less interested in a NES MM5 TAS than I would be if it had more RTA applications, as the optimal TAS route is mostly about manipulating weapon drops for Super Arrow.)
How different timewise would the PSX version be compared to NES? Is it large enough to have 2 of them published?
Edit: Although if something like this is also featured in future virtual consoles/compilation games/official emulators, I'm not sure how would the obsoletion process be like nor which version outside the original to use.
I'm not that familar with Rockman Complete Works series other than their music tracks. I don't really think they would obsolete anything because they're a totally different things in existence. I think their runs would look somewhat similar to Mega Man 9~10 games because you can change weapons on the fly. If a tool-assisted speedrun existed about some of them; I bet they would allocate opinions in many different ways.
Is there anyone familiar with this game or emulator differences that can help me to understand something?
First of all, is the RNG address 00E4? I'm able to get the same drops every time by freezing it, but the sequence doesn't seem very random. Most of the time, the current value is just the previous value divided in half.
But comparing the run I've started on BizHawk 1.11.6 to Glitchman's run on FCEUX 2.1.2(and Pike's Star Man WIP as well), the bytes of the values in this address are reversed. For example, on FCEUX it goes C891, 6448, 3224, 9912, CC89, whereas on BizHawk it goes 91C8, 4864, 2432, 1299, 89CC, etc..., and I can't seem to get anywhere close to the same asteroid patterns in the first room(and am getting a lot more lag as a result).
Does anyone have any idea what's going on here?
Glitchman's published run syncs for me on 1.11.6 all the way up to the boss door. To sync it I had to add 1 frame at the beginning to account for start up differences, but that's it.
I did not notice any differences in 00E4/5. The asteroids looked identical.
If you can post an input file I can try to track down anything potentially wrong on the emulations side, but I don't see anyhting different at the moment.
I am not sure if 00E4 is RNG. But it does affect enemies’ drop. I kinda suspect that 00E4,00E5,00E6,00E7 are all RNG but not independent. In fact, at many but all cases, the value of 00E4 is 8 values earlier than 00E5, the value of 00E5 is 8 values earlier than 00E6 and so on. For example, at frame 1000 the value of 00E4 is AA, then at frame 1008 the value of 00E5 will be AA and frame 1016 00E6, etc. In addition to RNG, there are other factors affecting enemies’ drop, too. One of them is the game time, sorry I forget its address. And there are more. I failed to figure out the rule of enemy dropping, it is too hard, after all. That’s why I am stuck in GRYO MAN now(the other reason is that I am working on Castlevania AOS). If someone can solve this problem, it will help a lot.
BTW, are you working on MM5 now, Hetfield90?
Oh, I just noticed your signature. I just started working on it actually. Would you perhaps be interested in collaborating? Maybe we can get someone with disassembly knowledge to help with RNG.
Go ahead and send me a PM if you're interested. I'm sure you'll be very busy with AoS, but I'd be happy to collaborate on it in any sort of capacity.
Maybe we can get someone with disassembly knowledge to help with RNG.
Fine, I'm pulling myself out of lurking for a bit...
Language: lua
local R1u= memory.read_u8
--My personal preference to rename related mem functions to something short.
--Also, if emulator is different, we have one line to change for new function.
local Thresholds= {2,3,8,10,14}
local function ItemDropCalculation()
--Pretend we did other stuff in this function
local Calcs= ((
8
+ R1u(0x00E6) --R2
+ R1u(0x00E7) --R3
- R1u(0x009D) --Frame timer, affected by lag
- R1u(0x00E5) --R1
)%255 + 1
+ R1u(0x0092) --Frame timer, always runs
)%256
Calcs= Calcs%50 --Game does divide routine, and uses modulo portion
local v
for i= 1, #Thresholds do
if Calcs%50 < Thresholds[i] then v= i; break end
end
--Pretend we do more stuff here
end
I've generated a little lua code after reading the item drop routine. This is simplified to the best of my ability.
Basically, the game does a bunch of consecutive ADC and SBC. The function always enters with carry set, to my knowledge, and the way SBC are mixed in there makes me think it's better to see it as ADC (255 - var) instead of SBC var.
The function also affects one byte of the RNG. If I'm understanding the RNG right, this change in the byte will only modify behaviors for 16 frames, then the upper bit of the modification finally gets shifted out and tossed away, with no impact on future numbers. Which means destroying an enemy will only affect item drops if another kill was made within 16 frames.
With the way timers work, lag will affect the calculation. Since one timer always increments, and the other only increments when gameplay happens, this means that by intentionally triggering lag, you adjust the calculations. I'm not surprised this hasn't been console verified, considering what the timers do here.
In any case, I got that bit from using FCEUX and disassembling certain parts, after setting breakpoints on anything that reads the RNG. Here's the disassembly:
RNG function
0E:AE59 LDA $0540,X
0E:AE5C CMP #$04
0E:AE5E BNE $AE58 Esc
0E:AE60 LDA $002F
0E:AE62 BMI $AE58 Esc
0E:AE64 LDA $00E6 R2
0E:AE66 ADC $00E7 R3
0E:AE68 ADC $0000 #$59 (used for function call)
0E:AE6A SBC $009D Frame timer (affected by lag)
0E:AE6C STA $00E6 Modify R2 right away
0E:AE6E ADC $0001 #$AE (used for function call)
0E:AE70 SBC $00E5 R1
0E:AE72 ADC $0092 Frame timer (always runs)
0E:AE74 STA $00E7 R3
0E:AE76 STA $0000
0E:AE78 LDA #$32 Decimal: 50
0E:AE7A STA $0001
0E:AE7C JSR $F207 Divide routine
0E:AE7F LDY #$04 Loop start
0E:AE81 LDA $0003 Temp (remainder portion of division)
0E:AE83 CMP $AF1B,Y 0E 0A 08 03 02
0E:AE86 BCC $AE8E Checking which item to drop
0E:AE88 DEY
0E:AE89 BPL $AE83 Loop end
0E:AE8B JMP $F2C4 Stuff after this isn't too important
0E:AE8E LDA $AF20,Y 77 74 75 78 76 (obj ID?)
0E:AE91 JSR $EA98 I guess this spawns the object
0E:AE94 LDA #$00
0E:AE96 STA $0408,X
0E:AE99 STA $0420,X
0E:AE9C LDA $AF25,Y
0E:AE9F STA $0468,X
0E:AEA2 LDA #$FF
0E:AEA4 STA $0480,X
0E:AEA7 JSR $EA1E
0E:AEAA LDA #$B7
0E:AEAC STA $0300,X
0E:AEAF LDA #$CC
0E:AEB1 STA $0588,X
0E:AEB4 LDA #$AD
0E:AEB6 STA $05A0,X
0E:AEB9 RTS -----------------------------------------
Divide routine
0F:F207 LDA #$00 Blank things out
0F:F209 STA $0002
0F:F20B STA $0003
0F:F20D LDA $0000 Temp 1
0F:F20F ORA $0001 Temp 2
0F:F211 BNE $F216 Forget it if it's 0/0
0F:F213 STA $0002 Set zero in $02 (again)
0F:F215 RTS -----------------------------------------
0F:F216 LDY #$08
0F:F218 ASL $0002
0F:F21A ROL $0000 Numerator
0F:F21C ROL $0003
0F:F21E SEC
0F:F21F LDA $0003
0F:F221 SBC $0001 Denominator
0F:F223 BCC $F229
0F:F225 STA $0003
0F:F227 INC $0002
0F:F229 DEY
0F:F22A BNE $F218
0F:F22C RTS -----------------------------------------
User movie #33370844597556344
A script I generated to assist in RNG related stuff. By no means is it perfect, but I did put something out for you all to try.
If you're going to make an improvement, I'd like to see it with everything available to you.
Thank you very much for the help, FatRatKnight.
Basically, the most important info we need is when ammo will drop from enemies, since with super arrow out there is little option for when you can kill enemies, so much of the manipulation has to be done far in advance.
Which value should I look at value in which column should I be looking at to determine what type of drop would occur on the current frame?
Also, I am getting this error when I try to run the script in FCEUX, which is what we're making the TAS on(right now I'm looking at the script in BizHawk).
\MM5_RNG.lua:4: attempt to call field 'usememorydomain' (a nil value)
I assumed BizHawk is the go-to emulator these days.
Give me a moment to transplant the script to FCEUX. I've used a few features of BizHawk that FCEUX doesn't have (the memory domain thing, for example, and the canvas especially).
In general, the right column of the BizHawk script is what you would want. The left column is in case you need to make plans involving destroying two enemies in close succession.
So how exactly do I read it? Does each color correspond to a certain item drop, and the value that corresponds to what is being polled on the current frame is the value at the top of the right column? That's how I assumed it would work but I'm not noticing any sort of correlations like that.
User movie #33375453760541627
FCEUX script.
The colors are what item will drop, and the numbers are the values behind whatever mechanism the game is using to figure out which item to drop. The numbers are going to be useful whenever there's lag, since you'll have an idea how many lag frames it'll take to shift it to some type of drop, or when it shifts back out of the desired drop. Values of 0, 50, 100, 150, 200, and 250 are the important spots when a drop becomes possible.
The position is simply how many frames. The top-most number is the immediate value, the one below that is what it will be in one frame, the number after that in two frames, and so on.
Well, now that I'm noticing some acknowledgement of my posts (even if I ended up making something that isn't working perfectly yet), I feel much more willing to ensure the scripts are doing what they're supposed to. I'll try the script under TASing conditions for a bit rather than glancing to see if it's doing what looks right.
Oh, and to figure out the right instructions and documentation to make sure the scripts I'm giving are getting used right.
It's a rather basic RNG tool. I'm not sure how much better I can have it predict things, but I might come up with other ideas. What makes things harder to predict is the lag does affect what drops come down. Hmm...
EDIT:
Alrighty, running the script with the TASEditor, hex editor, and all that fun stuff!
A calculated 149 is giving an item. Well, that needs fixing. I assume I'm off by one, so lets try a bunch of memory edits. Would like to make sure I'm consistently off by one or if I have a carry somewhere that needs to be handled appropriately.
Yes, this is a major error. Sorry about that mishap, I'll be working a bit to figure that mess out.
EDIT2:
Extent of what I can tell, my constant is off by one. Essentially, I need to turn my 8 into a 9. My constant for the sub calculation to get R2 is probably also off similarly. I do have a few thoughts about making the script smarter, such as keeping a comparison of the two timers and looking farther ahead for item drops. I'll have the idea for later, anyway.
User movie #33395645917665711
Okay, here's an updated script. Should fix an off-by-one somewhere in there. New colors, now that I took a look as to what, exactly, will drop with each value. Finally, I added in one more column that specifies number of frames until each of the next 20 item drops.
The more I work on this script, though, the more it seems my optimism fades away. There are three factors that adjust the RNG. I can create a pretty good predictor if it were just one factor (such as number of RNG calls only). But there are three factors at play here. It wouldn't be so bad if these factors weren't so common. Lag is everywhere, and the game needs the RNG for several things, apparently.
Even so, I ask that you test it out a bit and see if it provides any useful aid. Against this kind of effect the RNG has, there are limits to what I can script up. I have no idea how to predict when lag happens, after all.
Alright I understand how it works now. In areas where lag isn't involved I can reliably see what is going to drop, but as you say the areas with lag(which is practically everywhere) the drops do not correspond with what is being shown in the script.
Do you know how much it can get off by, or will it still be able to give me an general idea of around where upcoming drops are going to be when heavy lag is involved?
The rightmost column shows the RNG value behind the item drop. On a lag frame, the RNG advances, as well as the "always running" timer, but the lagged timer doesn't advance. So overall, the column will advance upward, but its values also increment (lag timer subtracts from the calculated RNG value for the item drop).
If you see a greyed out 49, 99, 149, 199, or 249, a lag frame will turn that into a 50, 100, 150, 200, or 250. According to my notes, that should get you a big weapon refill, along with one more lag increment. Two more lag increments, and it becomes an extra life instead. My script will recolor things for the changed values.
Since numbers change as well as move, I may want an aesthetic change to the script. Namely, some kind of visual marker every 5th frame or so. Should help the eyes track a specific number you're thinking about.
Lag is a pretty major factor, since just three of them can go from "no item drop" to "you just skipped the big weapon refill." It's not the only effect -- I believe some enemies end up affecting the RNG as well, so if something "thinks" just before your kill drops an item (by "just before", I mean 16 or fewer frames), that can mess up the RNG for the item drop, too. Destroying two enemies close together can also tweak the RNG like this.
Anyway, now I'm thinking about an adjustment to the script. Give me a moment, and I'll have a new one up. This is to have markers every 5th frame, just to help track which frame that RNG value is coming up on.
EDIT:
User movie #33508220465369883
A bit different from what I thought, actually. Lag frames might not advance the RNG on the same frame of lag, but regardless, one timer does still advance while the other doesn't, and this shifts the calculated RNG up by one in most cases. Regardless, here's the updated script that should tell you when every 5th frame happens, assuming the RNG shifts every time.
I got a problem. Player gets in the wall by RJ in the initial movie that skips Boss Rush posted by paosidufygth. That reminds me RJ may also be used to perform a glitch allowing Megaman to pass through walls like SA. However, it doesn’t work. I wonder why the same inputs result in the different consequences(though coordinates are not identical, I don’t think that is the reason because in RJ-movie Megaman gets deeper in the wall).
Is there anyone who can explain?
http://dehacked.2y.net/microstorage.php/info/393841925/RJ%20fails.fm2http://dehacked.2y.net/microstorage.php/info/1843265743/SA%20succeeds.fm2
Anyone working on this game or have WIPs to share? I started to do some experiments.
- By using same asteroid manipulation you can actually take damage from an asteroid to drop really fast down. Big health refill might be a problem later on. If combined with a strategy I mentioned below it will save at least 10 frames.
- At the beginning you can lose pixels for an more optimal drop to save couple of pixels. This needs a good position and it relies on sliding timer as well.
EDIT1. It seems these are already being used by Pike when I checked userfiles out!
Pike wrote:
I got a problem. Player gets in the wall by RJ in the initial movie that skips Boss Rush posted by paosidufygth. That reminds me RJ may also be used to perform a glitch allowing Megaman to pass through walls like SA. However, it doesn’t work. I wonder why the same inputs result in the different consequences(though coordinates are not identical, I don’t think that is the reason because in RJ-movie Megaman gets deeper in the wall).
Is there anyone who can explain?
http://dehacked.2y.net/microstorage.php/info/393841925/RJ%20fails.fm2http://dehacked.2y.net/microstorage.php/info/1843265743/SA%20succeeds.fm2
I'm not a technical expert but to me it looks like that Rush Jet version somehow gets its position being reset when you go to the menu. Super Arrow version doesn't seem to have that problem and it looks like that arrow might actually push you from the back so you stay in your position inside the ceiling.
I started to make a run for this game and I've been comparing my work against Pike's work. I noticed couple of things why I'm going to switch from US to JP version instead. First reason is that you can actually select a stage 153 frames faster on JP version because it doesn't have an extra screen at the beginning. Second and the most important reason is that after you defeat Dark Man, JP version is around 18.3 seconds faster! Nothing was changed but Japanese text appears faster and doesn't have that much dialogue.
On JP version it's impossible to achieve same asteroid manipulation setup for Star Man (this is pretty damn hard to figure out) so I'm going to lose at least 4 frames over Pike's effort on US version. On US version one freame wait was needed before you started the stage but on JP I have serious issues on RNG because I'm there 153 frames sooner.
This project might need other people around because this game is a horrible RNG lagfest and there's always a random way to do something faster. GlitchMan and Pike might have the best knowledge about this game at the moment.
I started to make a run for this game and I've been comparing my work against Pike's work.
I'm glad that an experienced TASer like you is interested on this game for a new run.
I'm extremely curious about this particular skip that was found on Rockman 5: Air Sliding and replicate it on the original game, basically a deathwarp that takes you directly to the boss checkpoint. A similar skip is possible on Mega Man 5: Second Strike. The thing is that these two skips have a different circumstances.
Rockman 5: Air Sliding
Link to video
Mega Man 5: Second Strike
Link to video
I started to make a run for this game and I've been comparing my work against Pike's work.
I'm glad that an experienced TASer like you is interested on this game for a new run.
I'm extremely curious about this particular skip that was found on Rockman 5: Air Sliding and replicate it on the original game, basically a deathwarp that takes you directly to the boss checkpoint. A similar skip is possible on Mega Man 5: Second Strike. The thing is that these two skips have a different circumstances.
Rockman 5: Air Sliding
Link to video
Mega Man 5: Second Strike
Link to video
Thanks for the thumbs up! I have seen these skips several times being done on hacks. FinalFighter investigated skip glitch not too long time ago and he was unable to find other places to perform that besides Crystal Man stage. Hacks tend to have objects and stuff arranged much more differently or that's how I see it right now. I don't know how to give you an actual or precise answer because no one really knows :D
I was able to contact Pike but that person is quite busy right now. If you have any interest or if you want to be a part of this project, feel free to do so.
EDIT: I suspect that some of those objects appearing around at ~38s have something do with that skip glitch, especially the ones dropping those skull bombs. If you happen to have fm2 files I can try to ask FinalFighter to look at them.
