Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
eternaljwh wrote:
So...did you [try] writing a faster intermediate code-loading routine after you achieved the first, like the Pokémon ACE TASes did?
Nope, I wrote the whole code in the same way.
eternaljwh wrote:
illegal opcode
Please, they're undocumented instructions.
Wikipedia mentions illegal opcodes first so I win.
An instruction consists of an opcode and an address mode. I use the term illegal opcode because I want to focus on the actual opcode, not the whole instruction.
Yes, alright, I worded it bad in the submission text...eternaljwh wrote:
what IS it doing during the extended wipe transition, anyway? Why does it do that rather than just start the ending sequence? (Must one bankswitch to L9's bank to access the ending routine, and level-transition is the easiest way to provoke that and still include "go to end"?)
It actually is the ending sequence, only the timer for the fading isn't set correctly. It starts decreasing at 0x00 so it wraps over to 0xFF, which is a bit longer than intended. The reason for the crazy graphics is probably because other values weren't set correctly.
And yeah, the credits are loaded with Level 9, so I had to switch to that first.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Kurabupengin wrote:
It's a file selection screen where you name Link. Label it as a password would be weird...
It "would be weird"? Why would it be weird? Try to use arguments to support your opinion.
I think a password is just a word that lets you access some place, which fits this game.
Uses a password, let's just keep it at that.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Oh and btw, there were previousattempts at ACE that unfortunately were slower than manually glitching to zelda.
But at least we got the jump to the credits by using another code (an indirect jump), so it's all good :D
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Don't put the memory.registerexec in the while true loop. You only have to call it once (not every frame) for every address.
Also, in some emulators you can specify the number of bytes you want to look at, for example:
Language: lua
memory.registerexec(0xC000, 0x0FFF, function ()
--stuff
end)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Maybe you get some people interested if you do some research yourself? I mean you seem to like this game a lot...
I bet you can find at least some information somewhere in the internet.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Oh yeah, this kind of situation happens a lot when TASing.
Pressing a button 3 frames after [dialog box, animation, etc.] appears, seems to be always the fastest way!
After you test that a bunch of times at different locations and it indeed looks like it is always the fastest way, you have two ways to continue:
Assume that it is always the first possible frame and continue TASing that way without stopping at each situation like this
Always test the frame before the "fastest" frame to really make sure you actually optimized that situation without a doubt
If I only have a visual indication I usually go with the second way.
If I have an actual RAM address of some sorts then I often go with the first way, to speed up my TASing a bit.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
sockfolder wrote:
From $0602, it executes some instructions based on the note in the music (I think), and tends to hit a JMP $0000 instruction (after some side effects).
At $0000, there are a bunch of mostly fixed values (i.e. fixed instructions). It executes a couple of instructions based on Link's X, Y. Then it moves into a chaotic section that I don't know how to manipulate yet and in the movie, jumps to $EC6E and from there, back into the normal game play without any side effects other than the game being totally screwed up.
I can confirm that. To be more specific, Link's X position is the address of an ASL instruction, and the Y position is a new instruction (might be useful).
The "chaotic section" that you are talking about is probably the area from $0018 to $0024 which looks like RNG. The bits for the 13 bytes are just shifted to the right and the leftmost bit (MSB of $0018) is determined by XORing bit 6 of the first byte and bit 6 of the second byte together (which is done before the shifting):
Executing music data seems like it would be really unlikely to always execute the JMP $0000, but it actually isn't that unlikely, because there is always a 4C 00 00 (JMP $0000). The code just has to survive to there, which isn't too unlikely. The fact that a code that makes the game continue was executed IN THE RNG (or whatever those crazy addresses are) is really unlikely... (well, due to the shifting of the crazy addresses, the JMP $EC6E does indeed pop up at 11 different times, but still, actually getting those values in the first place is unlikely...)
Edit: Oh and of course... the JMP $EC6E which is 4C 6E EC in bytes isn't actually 4C 6E EC to begin with. It is actually 4C 6E F6, but the UNDEFINED instruction (1F) at $0614 actually shifts $0021 one bit to the left, which happens to be the F6 which is shifted to EC... wow.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
The Movie Rules state that movies of games that are not emulated well should not be submitted.
You also aren't allowed to use tools that manipulate the ROM.
It might be possible to accept a run that syncs on both the original game, and a modified sound-enabled game.
Else, if the game doesn't work quite as well with hourglass, you will have to wait for an emulator that emulates the game better.
Also, don't use spoiler tags where there isn't actually a spoiler!
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
However, there are certain games with unlockable modes, second quests, or other things of interest that can only be accessed if a save file (or an otherwise "dirty" SRAM) is present. If you really wish to submit a movie made on such a mode, you will need a verification movie made and provided alongside it.
[...]
In any case, ensure a run of your unlocked mode provides meaningful content over a fresh game.
I don't know the game but it apparently "adds a ton of bonus levels" and makes the game more interesting. If you think that this is enough meaningful content over a fresh game then go ahead and do it!
(hint: entertaining movies are usually received very well)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Alyosha wrote:
If you write RNG1=A7,...,A0 and RNG2=B7,...,B0 then after 1 of the 11 cycles you get
RNG2=B6,...,B0,A7
RNG1=A6,...,A0,NOT(XOR(XOR(A0,B7),A1)) (if I did all my math right)
But simplifying the loop, I think not, since after 11 cycles, RNG2 will look like:
A3,A2,A1,A0,NOT(XOR(XOR(A0,B7),A1),.... and RNG1 will be a mess.
Not bad.
I decided I'd try it on my own and managed to get to this final result. The way you read this is, the next two bytes of rng are in the form abcdefgh ijklmnop and let's say you want to figure out what value n will have. You look at the column for n and see that you have to XOR 1, g, h and i (from the given rng) together to get the value for n. There, it's easy to see why 0x00 0x00 will have 0x92 0x04 as the next value.
I agree that it is unlikely to be able reduce it even further.
Too bad.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
ASL: left shift where the new LSB (least significant bit) becomes 0 and the old MSB (most significant bit) goes into carry.
LSR: right shift where the new MSB becomes 0 and the old LSB goes into carry.
ROL: left shift where the new LSB becomes the old carry and the old MSB goes into carry.
ROR: right shift where the new MSB becomes the old carry and the old LSB goes into carry.
I think XOR and AND are pretty basic.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Ever since I wrote this script for predicting RNG in this run I wondered if the formula could be reduced.
Currently you call the function nRNG (line 44) with two bytes to let the function advance them one step further. As you can see, the bytes run through a bunch of binary operations like XOR and ROL which loops 11 times.
As an example, calling the function nRNG with bytes 0x00 and 0x00 will give you 0x92 and 0x04. With only two bytes there are only a limited number of solutions (0x10000 or simply 65536).
After some testing I found out that when you start at, for example, 0x00 0x00, you will go through every possibility once until you get back to 0x00 0x00... except for the combination 0x55 0x55 and 0xAA 0xAA. These are not occurring which makes sense because calling the nRNG function with 0x55 0x55 will give you 0xAA 0xAA and vice versa.
So my question is: is it possible to reduce the formula or function to a simpler one?
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Experienced Forum User, Published Author, Site Developer, Skilled player
(1971)
Joined: 10/12/2010
Posts: 1179
Location: Germany
Derakon wrote:
Does exposure (author of submission 4667) deserve co-author status on this movie? It seems a little cruel to have someone submit a movie, then go "Hey, nice submission, I see what you did there but I can do it better, no publication for you."
It's Spikestuff, get used to it.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Executing music data seems like it would be really unlikely to always execute the JMP $0000, but it actually isn't that unlikely, because there is always a 4C 00 00 (JMP $0000). The code just has to survive to there, which isn't too unlikely. The fact that a code that makes the game continue was executed IN THE RNG (or whatever those crazy addresses are) is really unlikely... (well, due to the shifting of the crazy addresses, the JMP $EC6E does indeed pop up at 11 different times, but still, actually getting those values in the first place is unlikely...)
Edit: Oh and of course... the JMP $EC6E which is 4C 6E EC in bytes isn't actually 4C 6E EC to begin with. It is actually 4C 6E F6, but the UNDEFINED instruction (1F) at $0614 actually shifts $0021 one bit to the left, which happens to be the F6 which is shifted to EC... wow.
