Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Spider-Waffle wrote:
Had an idea for a new zipping technique, I don't think I've seen it before:
This idea is indeed useful, and I have now used it in few levels. However, in the Iceman level, the resource management is still a problem, and because your idea requires 7 beams and I only have 5 allocated for that region of game, I can't use that trick there (yet).
Former player
Joined: 7/29/2005
Posts: 459
Location: Brazil
monster.. perhaps.. i see some frames lost in the cutman stage.. maybe its only my impression.. i.i
<small>My big signature was cleared by admin; i should read <a href="http://tasvideos.org/ForumRules.html">forum rules</a>. But... who does?</small>
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
daniayaw wrote:
monster.. perhaps.. i see some frames lost in the cutman stage.. maybe its only my impression.. i.i
There are indeed a few frames of non-progression. It's because the platform Megaman is supposed to land on is a few pixels too short. And, when taking the weapon refills, there's some very noticeable delay, but such delay is hard to avoid because the enemies really don't like to drop good stuff when you'd want unless you are extremely lucky.
Banned User
Joined: 5/11/2004
Posts: 1049
Bisqwit wrote:
However, in the Iceman level, the resource management is still a problem, and because your idea requires 7 beams and I only have 5 allocated for that region of game, I can't use that trick there (yet).
A 5 beam version still might be good. I don't know the actual length of that part of the map; was my guess of 4 max length beams correct?
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Spider-Waffle wrote:
was my guess of max length beams correct?
Your estimate was correct.
Editor, Reviewer, Experienced player (980)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
Gonna watch the new version tonight. But by the time I get back here, my guess is that you'll have a new version out already. One thing I've been wondering about, how do you make any sense out of the timing tables on your Rockman page? I can't understand how they're supposed to work.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Truncated wrote:
One thing I've been wondering about, how do you make any sense out of the timing tables on your Rockman page? I can't understand how they're supposed to work.
I actually yesterday made them a little better to understand. Columns in order: 1. Frame number. 2. Event name for which this frame number is. - the meanings of events "begin", "door", "battle", "finished" are explained in the beginning of the "Timings" chapter. 3. The duration of the previous event (this frame number minus previous frame number). The number in parenthesis is difference to the previous movie. 4. Duration of the entire stage until that point. The number in parenthesis is difference to the previous movie. Example: | 15031 Iceman battle 757 (+16) | 15301 Iceman finished 270 (-3) 3734 (+505) Means: - Battle began at frame 15031. - The corridor (door->battle) took 757 frames, and was 16 frames faster than in v4. - Battle ended at frame 15301. - Battle took 270 frames. It was 3 frames slower than in v4. - The entire stage took 3734 frames. It was 505 frames faster than in v4.
Joined: 5/27/2005
Posts: 465
Location: Turku, Finland
If the battle was 3 frames slower than the previous one, shouldn't you correct that and make it atleast +-0? Or was this only an example (yes, I didn't bother to check my self :) ).
Which run should I encode next? :)
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Maza wrote:
If the battle was 3 frames slower than the previous one, shouldn't you correct that and make it atleast +-0? Or was this only an example (yes, I didn't bother to check my self :) ).
L-a-g. The Elecman weapon is a very laggy beam, and combined with a few extra objects (Iceman's sweat drops etc), it just happens to be so that FCEU lags where Famtasia didn't.
Joined: 5/27/2005
Posts: 465
Location: Turku, Finland
Oh, I didn't know (/remember) that the previous one was made with Famtasia. Well, that's understandable then. Btw, I must say you are doing a really great job. There definitely wasn't a single spot in the run which could be done faster, atleast to my knowledge.
Which run should I encode next? :)
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Maza wrote:
There definitely wasn't a single spot in the run which could be done faster, atleast to my knowledge.
Nevertheless, I'm going to see if I'm right about the Fireman's corridor. I think it could be played faster, based on my experience in the Gutsman's corridor.
Editor, Reviewer, Experienced player (980)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
I checked the new version yesterday. About cutman: In one of the vertical screens, with the armoured cannons (you should number the rooms in the maps or something)... when you jump to the left of a platform and in to the right instead of going around it, it looks like you have to wait for a while to land on the ground. Could you grab-release the ladder to get faster above the floor to make your next jump? I don't understand why you did the rooms with the red blocks the way you did. In particular, in one of the laggy rooms you take damage and pause to go vertically trough one of them. At the boss, could you switch weapons on the way down on the right side of the guts block? It looks like it takes a while before you can pick it up anyway, and it's only vertical motion. I loved how you scrolled to be placed just above the lethal spikes, and then went upwards to scroll the screen down.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
> you should number the rooms in the maps or something I actually have numbered them in this map. http://bisqwit.iki.fi/kala/snap/cutman-numbered.png (Sorry, no numbered maps for other stages.) The numbering corresponds to the internal representation of the rooms in the game. Some numbers appear multiple times, but that's how the game works. Everything is compressed :) > About cutman: In one of the vertical screens, with the armoured cannons (you should number the rooms in the maps or something)... when you jump to the left of a platform and in to the right instead of going around it, it looks like you have to wait for a while to land on the ground. Could you grab-release the ladder to get faster above the floor to make your next jump? Unfortunately I couldn't understand what you are referring to. But I think I have tried grab-releasing in all applicable places and chosen the fastest way. > I don't understand why you did the rooms with the red blocks the way you did. In particular, in one of the laggy rooms you take damage and pause to go vertically trough one of them. Because it's faster. :P The first jump should be obvious (the apparent delay before jumping was because I had to move Rockman 1 pixel to the right), but why I paused in the second jump? It was to eliminate lag. The room lags a lot. Rockman's movement is purely vertical in that position, and pausing gives lag-free vertical movement at the cost of 2 frames. Edit: Actually, I think I should try to do it in room "3" too! Edit 2: I still probably should dare to try not using the magnet beam in the previous room. It could eliminate the lag in that next room. > At the boss, could you switch weapons on the way down on the right side of the guts block? It looks like it takes a while before you can pick it up anyway, and it's only vertical motion. That's a good idea! I'll do that. (I recall this idea is not new, but somehow I had forgot it.) > I loved how you scrolled to be placed just above the lethal spikes, and then went upwards to scroll the screen down. Yeah, it looks funny. But it was invented by Morimoto, not me. Thank you for the feedback!
Editor, Reviewer, Experienced player (980)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
>Unfortunately I couldn't understand what you are referring to. But I think I have tried grab-releasing in all applicable places and chosen the fastest way. The room I was trying to describe is number 8 in your map. You're supposed to go to the right (close to the cannons) but you jump out to the left after the first ladder instead. Perhaps you could hold the jump button for more upward speed, and kill it to 0 with grab-release on the ladder there to get a new jump sooner. That's what I was trying to describe. Just an idea, as usual.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Truncated wrote:
Perhaps you could hold the jump button for more upward speed, and kill it to 0 with grab-release on the ladder there to get a new jump sooner.
Sorry, but that particular jump is already maximum height. As it's now, grabbing the ladder and immediately releasing it doesn't save a frame (though it wouldn't lose one either).
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Bisqwit wrote:
> At the boss, could you switch weapons on the way down on the right side of the guts block? It looks like it takes a while before you can pick it up anyway, and it's only vertical motion. That's a good idea! I'll do that. (I recall this idea is not new, but somehow I had forgot it.)
Apparently, this idea is not useful. To kill Cutman with one brick, you need to walk closer to him. Otherwise it will only hit once even if you pause. (The brick has very strange collision detection.) If I use your suggestion, Megaman will be _standing_ when he comes off from pause, and there will be an acceleration delay. I can't cancel the acceleration delay with jumping, because then it just don't work (no two hits). I can't jump a higher jump either, because if I jump any earlier, Cutman will jump too and that's doesn't help at all. Of all the other improvement ideas so far, only the Fireman corridor was useful, but it was only 5 frames (and I lost 2 in the battle, resulting in 3 frame net gain) so I'll ignore this for now. EDIT: No, I actually got it. 4 frames shaved off the Cutman fight, thanks to Truncated.
Post subject: Bonus drop algorithm dissected
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I have disassembled the mechanism the game (Rockman 1) uses to create the drops when an enemy is killed. Every frame, lagging or not, the game does this:     RandomSeed = ((TempVar13 XOR RandomSeed) + FrameCounter) SHR 1 TempVar13 is a variable that is used by various parts of the game code. It looks like it's practically impossible to predict where it's used. For example, it is the Y coordinate parameter to a sprite update function, as a Y coordinate in sprite-sprite collision check and as a VRAM pointer in a scrolling function. Joypad input has no direct effect in the random seed. Only indirect effects exist, by affecting those other functions. The random function of the game is: Random(n) = RandomSeed MOD n When an enemy is killed, the game generates a drop with the following algorithm:     n = Random(100)     Item = nothing     if(n >= 12) { Item = BonusPearl     if(n >= 65) { Item = SmallWeaponRefill     if(n >= 80) { Item = SmallEnergyRefill     if(n >= 95) { Item = BigWeaponRefill     if(n >= 97) { Item = BigEnergyRefill     if(n >= 99) { Item = ExtraLife } } } } } } Addresses:     $0D TempVar13     $46 RandomSeed     $23 FrameCounter     $1C5A0 RandomFunc     $1D574 RandomUpdater     $BF13 CreateRandomDrop So, likelihoods are:  12% nothing given (chance 3/25)  53% bonus pearl (chance 53/100)  15% small weapon refill (chance 3/20)  15% small energy refill (chance 3/20)  2% big weapon refill (chance 1/50)  2% big energy reflil (chance 1/50)  1% extra life (chance 1/100) I'll implement a debugging measure to monitor values of the critical variables and see if they could be predicted after all. Contrary to what I previously thought, the item 0x49 is not related to weapon drops at all. When an enemy is killed, it's replaced with the bonus item (or not). The item 0x49 is just coincidentally is an object that, if placed on a map with an editor, dies immediately and spawns a bonus item (or not).
Joined: 9/16/2005
Posts: 26
Location: KY
It's amazing you have this much time to run formulas for such a random, yet great game. Very educational as well. :)
Joined: 3/31/2005
Posts: 148
Location: Colorado
Incredible. . . How in the world did you figure this out?
Do not try to bend the spoon, that's impossible. Instead only try to realize the truth. What Truth? There is nospoon. Then you will see it is not the spoon that changes, it is only yourself
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Thereisnospoon wrote:
Incredible. . . How in the world did you figure this out?
Analyzing a disassembly. It took lots of time (there were many things I needed to understand first in order to make sense of other things), but that part is now clear. Ps: If someone wonders how I indended lines in phpBB without using the
 tag -- I used the Japanese double-width space character for indentation, unicode value U+3000.
Skilled player (1828)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Some questions about item dropping by enemies: First of all, how big is the chance that an enemy will drop an item? Do stronger enemies have a bigger chance to drop an item? And how do you manipulate what item the enemy drops, is this framebased or are there more factors in this? Besides these questions, I think your movie looks amazing. Keep up this tempo, Bisqwit, for everlasting peace! :)
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Randil wrote:
First of all, how big is the chance that an enemy will drop an item? Do stronger enemies have a bigger chance to drop an item?
88% chance an item will be dropped. All enemies except bosses drop items. The type of the item does not depend on the type of enemy killed.
Randil wrote:
And how do you manipulate what item the enemy drops, is this framebased or are there more factors in this?
The frame counter affects the drops. So if you try 256 frames in a row, you could find what you wanted. (Actually 100 should be enough). It is also affected by the "temporary variable $0D", which carries the last result of a myriad of different calculations. What calculation was last performed depends on the situation on the game. Collision checks affect it - screen scrolling affects it - enemies' movement affects it. That all I know so far, but there are about hundred places where the variable is used in and I haven't analyzed them all. If you're unlucky, the temporary variable might change in ways that cancels out the changes in the frame counter, causing you to wait more than 256 frames without getting what you wanted. That's why it's important to try scrolling the screen, or to shoot or use different items, or to alter the enemies' behavior, so that the lucky combination of variables is created at the exact moment an enemy is killed.
Player (206)
Joined: 5/29/2004
Posts: 5712
Man, I was thinking of looking for the energy drop algorithm when I was skimming a Metroid disassembly somebody linked me to, but I forgot. Good stuff then.
put yourself in my rocketpack if that poochie is one outrageous dude
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I implemented a feature to watch the randomness stats in FCEU. It goes just before the "b1=RdMem(_PC)" line in x6502.c. For every frame, it prints what bonus the game would give if an enemy spontaneously died at that frame. It works perfectly. Analyzing the output, I see that the "temp" variable changes less than I thought. If there are no other objects on screen and Rockman stands still, the "temp" variable keeps a steady 0x7C value. When Rockman climbs, it keeps a steady 0x03 value. However, when there is even one "flea" jumping around, the number changes once every few frames. It seems, for the most part, to always contain values that are evenly divisible by 4, but not really always. If the value didn't change, I could predict the bonus drops for hundreds of frames ahead, but when it changes, I can predict nothing because it works in a bit similar way as the CRC calculation works: tiny ripples change everything. But I keep trying to find ways to abuse it. Curiously, sometimes there are situations where you wouldn't get a big weapon drop no matter how many frames you waited. The RandomSeed can enter a short loop of unhelpful values. The loop can only be broken by influencing the TempVar.
Bag of Magic Food wrote:
I was thinking of looking for the energy drop algorithm when I was skimming a Metroid disassembly somebody linked me to
Yeah, that's where I got the inspiration too.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3577)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
wow, this should help you out alot I assume you will test existing levels to see: a) where you do manipulate a drop, If there is a more optimal way of getting it b) if there are any "convenient" times to get a drop in other levels. That might allow you to do more zipping.
It's hard to look this good. My TAS projects