366C: F5 PUSH AF A:bc B:00 C:6e D:c0 E:63 F:50 H:c0 L:af LY:90 SP:cfe3 Cy:1041059548For that matter, how many runs are there that might be improved in more "conventional" ways by subframe inputs? For example, if a game polls the controller input multiple times in a frame and assumes that it does not change in the span of a few instructions.
This run uses BizHawk's dual GB capabilities, and runs on BizHawk 1.7 and later. Due to how dual GB is implemented in BizHawk, it was unavoidable to use the new frame timing introduced in BizHawk 1.7. This frame timing can cause issues that have been discussed before, but being forced to use it gave me some more insight in which problems actually occur. The main issue arises when the joypad input is split between frames. The Gameboy polls the joypad in two stages with 4 bit each, one for the directional keys and one for the buttons. If they end up on different sides of the arbitrary frame boundary, weird things happen. You need to press your directional keys on a different frame than the buttons, even though they are used at the exact same time. In the worst case, multiple joypad polls happen on the same frame, so there is no input frame for you to do the inputs you want, and you need to wait frames until it fixes itself or work around it by using a different set of inputs that doesn't run into this problem.
EDIT. So W1 = 144 frames faster, W2 = 120 frames faster, W3 = 232 frames slower = we are still 32 frames faster vs. old route, but 144 frames faster at the beginning of W4 with every improvement included.
The old run syncs perfectly to the very end. It's possible that I screwed something up converting the new movie to bk2, but I dunno...
Yup, that's right. They used Item 2 in Wily 1 instead. It saved a couple weapon switches and refills throughout the run, which was worth it in the end.
We used item2 at the beginning of Wily1 and it saved a good amount of time. It saved us from a couple weapon switches and we used a different strategy at Wily 2 as well. We refilled at Wily 3 instead to take the advantage to get as much item1s possible. We saved two item1s from Wily 1 but used them after we we're supposed to refill at Wily 2 but that made it faster and we didn't have to change to the item2 at all. Wily 3 is slower because of these changes but when I enter Wily 4, I gain 32 frames instead doing the old setup like we did on a published one! Wily 4 is 68 frames faster because I updated my position at the top and I did a long zip instead like people do on RTA runs. Wily 5 is faster because I fiddled with subpixels and manipulation and got a frame and I found a new strategy for Quickman and I gained 28 frames from it.
Regarding the console verification thing: the run obviously syncs on FCEUX, but it desynced when I converted it to run on BizHawk. It desyncs at the third dog in Wood with NESHawk, and desyncs almost instantly with QuickNES. None of us have the hardware to test it for real, so we can't say which emulator is the most accurate as of right now.
Shift the 11-bit signed offset of the instruction left one bit. Sign-extend the result to 32 bits Adding this to the contents of the PC (which contains the address of the branch instruction plus 4).
bit11 = bit.check(result,11) and 1 or 0
if bit11 == 1 then
for i = 13,31 do
result = bit.set(result,i)
end
end
local result = bit.lshift(Offset11, 1)
if bit.check(result, 11) then
result = bit.bor(-4096,result) --writing as 0xFFFF FFFF FFFF F000 doesn't work
result = result - 0x100000000 --??
endhttp://spiraster.x10host.com/LADXWiki/index.php/LADX_Any_Percent So apparently, Gambatte is banned in any% runs because it doesn't accurately replicate the effects of the ACE glitch. It seems the only emulator that does is BGB. Current WR: https://www.youtube.com/watch?v=qNBRQNkhkXg
08102FB7: 0000F041 ORR r0, r1, #0 r0:00003A0D r1:085031B8 r2:00000388 r3:030034A4 r4:00000190 r5:084FE9F0 r6:00000000 r7:00000000 r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:0300040C r13:03007DD8 r14:0810F571 r15:08102FB6 r16:0000003F08102FB9: 0000FD74 r0:00003A0D r1:085031B8 r2:00000388 r3:030034A4 r4:00000190 r5:084FE9F0 r6:00000000 r7:00000000 r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:0300040C r13:03007DD8 r14:08143FB8 r15:08102FB8 r16:0000003F08144AA3: 0000B570 PUSH {r4-r6,LR} r0:00003A0D r1:085031B8 r2:00000388 r3:030034A4 r4:00000190 r5:084FE9F0 r6:00000000 r7:00000000 r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:0300040C r13:03007DD8 r14:08102FB9 r15:08144AA2 r16:0000003F08102FC1: 0000FBC8 SMLAL r0, r0, r8, r0 r0:00002048 r1:00000191 r2:03005E10 r3:8E5C88A7 r4:00000191 r5:084FE9F0 r6:00000000 r7:00000000 r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:0300040C r13:03007DD8 r14:081DCFC0 r15:08102FC0 r16:0000003F081DD753: 00002301 MOV r3, #1 r0:00002048 r1:00000191 r2:03005E10 r3:8E5C88A7 r4:00000191 r5:084FE9F0 r6:00000000 r7:00000000 r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:0300040C r13:03007DD8 r14:08102FC1 r15:081DD752 r16:0000003F
Double tap sprinted up a stair. Then held B and tried to move up right pass a corner. The game then forced me to walk OoB. This occurred on the roof.
This sets the address ptr + 0xB8 to 1, causing movement to get locked until an item is used. I have no idea what situations set this however; during door transitions and cutscenes it remains 0 like everywhere else.
As stated in the previous TAS by andymac, the pixel trick allows Mario to move an extra pixel every 8 frames. There was talk of a more restrictive, yet better pixel trick that yielded two extra pixels every 8 frames. Since it is both visually unappealing to be constantly jumping and very restrictive, I decided not to use it at all times. There are a number of instances of it throughout the run, but only when it was convenient to do it. It also turns out that jumping constantly leads to more instances of lag, so it was overall simpler to use an outdated version to save on lag and avoid tedium.
If I recall correctly, in a non-glitched run, you need to be level 25 to wake up the dragon in Magicant so you can fight it. Defeating the dragon gets you one of the melodies required to finish the game.
Finally, this game end glitch is valid on console. Hopefully, the last one in this category. Yes vote.
That's a thread with lots of different posts, and the quote is quite ambiguous regarding exact steps. What steps are you planning to execute exactly?
Note Leave the memory card out to skip the autosave at the start of the game. There are no autosaves after this so you can put it in any time after the curtain pulls.
So you want to a) load a savegame b) remove the memory card from the console c) restore the memory card to a previous version (with no save file) d) reinsert the memory card ?
Would this be allowed? The benefit is that when overwriting a save file the game gives an extra prompt asking if you want to overwrite it. Coping the memory card right after formatting it, and then copying it back after each save would avoid this. This is useful where save warps are used, and once a file is loaded it's never needed again. Since memory cards can be removed and files can be copied using freely available methods, this could even easily be done during a real time speedrun.
Streaming arbitrary data through an external port: this should be allowed depending on entertainment value. A huge number of games are vulnerable to ACE, so if you're going to pick a game to do an ACE movie with it should be for a very good reason. It should be allowed more generally in Vault unless movies are way too similar on the same console even across games. The controller port isn't the issue here.