Posts for NFITC1


Experienced Forum User
Joined: 5/12/2010
Posts: 38
Did my OoA RNG predictor end up being accurate for OoS? Even if it did it probably wouldn't help not knowing what values do what.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
There was apparently some thought given to the planning of this run. For that I won't say "give up". The game choice was poor though. After seeing enough of AVGN's LJN reviews I knew this was going to be boring or annoying to watch. LJN is notorious for getting things wrong with their games and this is a perfect example of that. Giving a "Meh" because it likely IS the fastest this game can be played.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
I am completely confused by the descriptions of Fatality, Animality, and Babality. Could someone re-write those?
Experienced Forum User
Joined: 5/12/2010
Posts: 38
Isn't hitting the bosses with the saber's beam faster than hitting them with the saber itself. I liked how the final Sigma fights were delayed so the final blows could be landed in all three games at the same time.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
It's not as solid as a TAS should be. I can understand manipulating, but there are still some unnecessary actions taken. IMO, final hits should be swift attacks that bring the opponent directly to 0, not keep hitting after victory is declared. Taking a hit in the first fight isn't entertaining either. I thought the vid had somehow de-synced. I also don't get the Rose -> Guy switch either. Doesn't that require you to take control of both players (I might be forgetting how the ARC version of this runs)? Why then, do you even move Rose other than to recover from falls faster? A "No" vote from me.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
I considered doing BattleToads for GB a while back but decided it was just too slow to make an interesting TAS. It's hard to make it interesting when its speed is always interrupted and you're forced to fight some enemies that take a while to defeat. Maybe I judged it too harshly. I suppose I should at least try the first level.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
I can get Yoshi's Story to work in PJ64 using those same plugins, but it reports that from beginning the start screen to just before choosing the lucky fruit, fps drops from 60 to 30. The listed version of Mupen does NOT like that. :( This might account for the desyncing everyone who can't get it to run is getting.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
Warepire wrote:
To find graphics and maps you should look for load instructions pointing to the vram/oam and DMA transfer starts in the code. The source for those loads should be graphics. Also try to look through the rom in tile/map edtors for GameBoy. You can look at the pandocs to find the data structure of tiles and maps. Best way to find the executable code is to basicly just to trace it using a hexeditor and instruction reference or a disassembler. (I suggest a combination of both) What does not appear to be executable code or graphics should be various tables.
This has been my approach so far with the exception of tile/map editors. I'll incorporate those in and see what comes out. That's likely easier than try to trace the code. Thanks for the advice.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
Warepire wrote:
Don't know how much it helps you but each ROM bank is 16 kilobytes (or 0x4000 bytes). Bank 0 (address range 0x0000-0x3FFFF) is always present, the other bank is switchable if the ROM file exceeds 32 Kb in size, the switchable bank have the address range of 0x4000 to 0x7FFF. Tables should be locked to a single bank. Logically functions in bank 0 can carry over into another bank, but functions can probably not carry over between switchable banks. (I have not studied this case a lot though)
I know about that, but that's the memory of the GBC itself. I want to know about the ROM as in which structures are actual code and which ones are tables and maps and graphics and such. I don't know the difference yet. I've just been plowing through block 0 and happened across the RNG. As for functions carrying over, the results can, but one function can't call a function in another block other than block 0 if I'm understanding it correctly.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
I'd like to dive in to this more, but I can't find a good technical document on the structure of a GBC ROM. If I knew where each of the code blocks started I could probably find where the item drop tables are. Can anyone point me to a good doc?
Experienced Forum User
Joined: 5/12/2010
Posts: 38
There are actually two functions that do this. They're identical except one "preserves" the values in the registers it uses. 0x043E: (this one preserves)
push hl
push bc
ld a, [0xFF94]
ld l, a
ld c, a
ld a, [0xFF95]
ld h, a
ld b, a
add hl, hl
add hl, bc
ld a, h
ld [0xFF95], a
add a, c
ld [0xFF94], a
pop bc
pop hl
0x0453: (this one discards hl and bc)
ld a, [0xFF94]
ld l, a
ld c, a
ld a, [0xFF95]
ld h, a
ld b, a
add hl, hl
add hl, bc
ld a, h
ld [0xFF95], a
add a, c
ld [0xFF94], a
If I were to write that in an upper level language, it'd be like:
__int32 RNG_0 = (word*)[0xFF94];
__int32 RNG_1 = (word*)[0xFF94];
RNG_0 = RNG_0 + RNG_0;
RNG_0 = RNG_0 + RNG_1;
(byte*)[0xFF95] = ( ( RNG_0 AND 0xFF00 ) >> 8 ) AND 0xFF;
(byte*)[0xFF94] = ( (byte*)[0xFF95] + (RNG_1 AND 0xFF) ) AND 0xFF;
I'm not sure if that's very clear or not. I don't usually write code like that (I program in VB.NET mostly). I do know that that LUA code that I wrote can predict the future values with accuracy although I'm not sure what all increases it and how much. Maple's interaction is what I'm trying to manipulate now because she won't give me the heart piece and I'm at the final Black Tower. I can't directly confirm, but I have no reason to believe that the RNG functions differently in OoS although the location of the actual generator and the stored address might be different.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
I haven't seen this mentioned in this thread so forgive me if this is known or being passed around. I've been playing with manipulating things in OoA for a while too just to make my game simpler. I found where the RNG is and how it's generated and how to predict what it will be. It's stored as a word at 0xFF94 and is generated like this:
now = [0XFF94]
next = (now * 3) AND 0xFF00
next += ( ( (next >> 8) and 0xFF) + (current AND 0xFF) ) AND 0xFF
in lua script it's like this:
next = bit.band( current * 3, 0XFF00 )
next = next + bit.band( bit.rshift( next, 8 ) + bit.band( current, 0xFF ), 0xFF )
-Sword swipes and shovel digs do this once. -Monsters call this twice. I'm assuming for a new direction and a distance of travel. -If the current value meets some condition when an enemy dies or pot is lifted or dirt is dug, an item will be dropped. Another call determines what is dropped (so one step when you dig and find nothing, two steps if you dig and find something). -Keese call this every other frame so if there are Keese in the screen then chances are manipulating will be difficult while they're roaming around. -Maple calls this once when her shadow appears and once when she appears. She then calls this 15 different times to see what gets dropped. -Moving to a new room does this 256 times regardless of the contents of the new room. I think things like enemy positions and facing direction are decided here. I've yet to find what any values do under different conditions (maple drops, gasha seed items, etc). I DO know that a value of 0x00D8 will dig up a huge rupee. :) I have a little LUA script to tell me what the next relevant values will be.
Language: lua

function DEC_HEX(IN) local B,K,OUT,I,D=16,"0123456789ABCDEF","",0 while IN>0 do I=I+1 IN,D=math.floor(IN/B),math.mod(IN,B)+1 OUT=string.sub(K,D,D)..OUT end return string.sub( "0000" .. OUT, -4 ) end function get_next( now, iteration ) if iteration > 257 then return end next = bit.band( now * 3, 0XFF00 ) next = next + bit.band( bit.rshift( next, 8 ) + bit.band( now, 0xFF ), 0xFF ) if iteration == 1 then print( "Sword swing/shovel use: "..DEC_HEX( next ) ) elseif iteration == 2 then print( "Monster Action/dug up item: "..DEC_HEX( next ) ) elseif iteration == 3 then print( "Dropped Item: "..DEC_HEX( next ) ) elseif iteration == 256 then print( "New Area: "..DEC_HEX( next ) ) end get_next( next, iteration + 1) end local next local now next = 2 --to prevent nil comparison when the script starts while true do now = memory.readword( 0xFF94 ) if now ~= next then print( "Currently: " .. DEC_HEX( now ) ) get_next( now, 1 ) next = now print( "===================" ) end vba.frameadvance() end
I don't know how to clear the console so it's constantly adding text every time the RNG changes per frame (room changes will usually show two or three changes since it's displaying per frame). Hopefully, someone will find this useful.
Experienced Forum User
Joined: 5/12/2010
Posts: 38
Derakon wrote:
Does anyone here know where I could find statistics on Samus's various max speeds and accelerations? I'm working on my own platforming game and I'd like the protagonist to control similarly. Specifically, I'm curious about max runspeed (without speed booster), max fallspeed, jumpspeed with and without hi-jump boots, gravity, and rolling speed. But any information you can give would be helpful.
I believe I have the info you want. I'm trying to find a shorter shinespark pattern for my no-damage TAS so I can get the XRay scope without breaking it up like one of the previous videos showed. I'm not sure if this is possible, but at least I want to find the shortest stagger-boost even if it is the one we know (consequently, what advantage does boosting for those three frames at the end give? Why boost at all until the magic frame?). Horizontal: Samus' max non-boosted velocity is 2 3/4 pixels per frame. She delays motion for 2 frames (for the first two frames that a direction is pushed her velocity is 0), then is forced forward 1 pixel (velocity still technically 0) and accelerates @ 3/16 (.1875) pix/frame^2. When she reaches the point that she WOULD have a velocity of 2 pix/frame, she's "shoved" to her max velocity of 2 3/4 pix/frame. Running adds 1/16 pix/frame per frame for a max of 2 pix/frame added to the velocity. This is virtually stored at a different memory address and the total of the running velocity with the normal velocity is added together to get her new position for the next frame (a combined total velocity of 4 pix/frame is necessary to safely run across crumbling blocks) Once the direction is released some mechanics kick in and the previous running velocity gets added to the normal velocity (max at 4.75). She delays for another three frames before she decelerates at .25 pix/frame^2 from this combined velocity. For this reason, running is reset to 0 if velocity decreases, but if the direction is still pressed before Samus hits 0 she'll still be considered to be moving forward and won't stop her running animation. While jumping horizontal velocity is immediately capped at 1 3/8 pix/frame, but the running velocity will remain until landing. Landing reduces all velocities to 0. Changing direction while jumping like this accelerates at a rate of 3/8 in the new direction after a two frame delay. Any running speed is added to the normal velocity the same as on the ground. While falling with a horizontal velocity of 0, horizontal acceleration is .75 pix/frame^2 until it hits 1 3/4 pix/frame then fluctuates between that and 1 pix/frame every frame. While rising, horizontal velocity will change from 0 to 3/4 in one frame then cap in the next frame at 1 1/4. As for rolling, the three frame delay occurs again, but she accelerates @ .75 pix/frame^2. Rolling's max velocity is 3.75, but is forced back to 3.25 the frame after it occurs. Rolling has no deceleration and stops dead 2 frames after the direction is released. It is subject to the "mockball effect" though. Velocity is perserved if transforming while in the air. If you land in the middle of that transformation then the horizontal velocity won't be reset when you hit the ground and the horizontal "running" velocity will still be positive. If off-center to a bomb, upon detonation horizontal acceleration becomes 3/16 pix/frame and caps at 3 pix/frame until vertical velocity (see below) becomes 0 again and then Samus will be considered falling. If applicable: taking damage makes Samus accelerate @ 1.5 pix/frame^2 in the opposite direction that Samus is facing. This caps at 5 pix/frame then is reduced to 0. In water, all these calculations are the same, but you can't run and acceleration is reduced to 1/64 pix/frame. Vertical: Without the High-Jump boots Samus begins an upward velocity of 4.875 pixels/frame. There's the two frame delay before this velocity is assigned, and another two frames before her vertical position actually changes. With the High-Jump boots this velocity starts at 6 pixels/frame. NOTE: This is just ADDED to whatever her current vertical velocity is at the time. If she's moving up a hill at a vertical velocity of 2 pixels/frame then her High-Jump speed makes that 8 pixels/frame. Springball works like normal jumping. Bombs set vertical velocity to 2 3/4. Wall-jumping with the high-jump boots gives her a vertical speed of 5.5 pix/frame. Without the high-jump boots, wall-jumping gives 4.625 (4 5/8) pix/frame Letting go of the jump button resets her vertical velocity to 0 after a two frame delay and she's pulled down by gravity. Gravity pulls her down at 7/64 pix/frame^2 for a terminal velocity of 5 1/32 pix/frame. If the morphball hits the ground (fully morphed) it is given a upward velocity of 1 pix/frame and is subject to gravity as normal. Unmorphing in the air sets all velocities to 0. If applicable: taking damage sets Samus's upward vert velocity to 5 and decelerates @ 7/64 pix/frame^2. She decelerates for about 4 frames then vert velocity is reset to 0 and she is airborne again. Underwater gravity is a downward acceleration of 1/32 pix/frame^2 with a terminal velocity of 5 pix/frame (going down a slope that creates a vertical velocity greater than this causes her to be mid-air and fall). In the water her High-Jump boot initial vert velocity is 2.5 pix/frame. Her normal jump makes it 1 3/4 pix/frame in the water. High-Jump boot wall-jump underwater vert velocity is 1/2 pix/frame. Normal boot wall-jump underwater is 1/4 pix/frame. I think that's everything. I might be missing something. I left out speed booster and grapple, but speed booster only increases the max running velocity to 7 and you didn't ask for grapple.