Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Yikes, after watching your WIP I have no idea how you managed to get that far, let alone in snes9x. No wonder it was so demotivating. So the camera hack can cause desyncs, and I imagine in bizhawk it will be even more of a problem, hmmmm..... My first idea would be to create a lua hud that makes like a radar display of the terrain that is actually around diddy, regardless of where the camera is. That way we could TAS by looking at that, should be way easier then TASing blind. Of course this would mean a file of the outline of he entire level would be needed. Hmmm I wonder if I could write a LUA script to write points to a file as I hug the walls around the level, this would somewhat automate the process.... Well I'll give this some thought and maybe make a prototype, seems like an interesting challenge anyway. Let me know if you have any other ideas.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
^ Yup, that's the general plan. Once all the main improvements are implemented though I will be going back over each level individually and making final improvements. Currently I'm just roughing out the run. http://tasvideos.org/userfiles/info/26069510258273969 Ok, master Necky skip implemented. I also made some other improvements mostly in world 6. I guess the next big step is to work on 4-4. @Tompa: what exactly is needed for this and how does the glitch you mentioned work?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/26015201639726183 Alright complete game WIP is finally here! It's not particularly good, but it is 101% complete and syncs on bizhawk 1.11.1 I've gotten a bit busy, so things will be moving even more slowly from here. I think my next step will be to implement the Master Necky skip. Then I'll re-sync the whole run and give worlds 5 and 6 a second pass of improvement since they are pretty poor at the moment.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
A few days late but congrats samsara!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
well the backpack guy is a long shot indeed. I looked through the second half of the code, and nothing seems to stick out that would make anything strange happen. But, I do have another lead. After looking back where 003B gets set again, I found out that a timer at 002A gets set to FF and counts down. There is no other indication that this has happened. Once it hits zero, the stage ends just the same. So this pushes back the timing for the initiation of the glitch by ~4.25 seconds. In the video, this corresponds to when much more is happening and more possibilities for glitches exist. So I will start investigating this as a real possibility. EDIT: This point seems to be where an item is appearing out of a grey wall box and a red gun guy is getting hit by a bullet, might really be something here! Another thing I found is that I can make a jump to $EAEA to set $003B to 1 and $002A to FF without breaking the game. This is convenient since you only need to do 20 EA EA, and EA is coincidentally NOP code. The problem is that this alone won't set the flags to run the subroutine to run the timer, so the stage won't end, and I can't currently run the complete routine at $E740 without a crash. EDIT 2: So looking at subroutine EAEA a bit, it seems that main input is the accumulator. It runs slightly different for different values, based on the level you are in I would suppose. It will always set 002A to FF and 003B to 1 though. But, if a boss isn't loaded into a table slot, 002A will never get a signal to decrement, and if it stays at FF will never do so. So the interesting thing is, a glitch that calls EAEA could actually be relatively common, and you would never know it happened under most circumstances of the accumulator. It might simply be a rare case of the glitch that actually causes the level to end. How this might occur though is still unresolved.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Wow that is really neat! I love seeing clever hardware related things. I hope you can get sound implemented somehow to get a true game/hardware state loaded. keep it up!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I thought I might post some of my notes in case anyone else is also interested in this. By comparing the HQ video and my input file with 003B hex edited to 1, it seems like the glitch ending the stage occurs a few frames before the player hits the ground. This would seem to exclude the landing routine from playing a part in the glitch. So, this leaves not a lot happening. I so far have no way to effect the object table, no way to mess with the stack pointer, and even if I did no way to reproduce the glitch as demonstrated on the video. The stray values that didn't get reset when selecting 'end' seem only to be impacting sound effects and have no real impact. So I've focused in on the random backpack guy generation as the only likely candidate for something that can produce this glitch. This is about all I have to work with that involves random variables and nothing visually happening on screen. The basics of the code are that first, it checks the frame counter, it only attempts to generate a backpack guy every other frame. TIf it passes this check, it rolls the RNG 16 times, if it gets a value that sets a carry flag, 0079 is set to 2, indicating a backpack guy needs to be generated. Otherwise nothing happens. This doesn't necessarily create the enemy either though. The next frame, when 0079 is set to 2, another routine is executed that decides whether to create one or not and where to put him. This involves both random variables and the players Y coordinate. I haven't made it that far into this section though. So my working hypothesis is that an edge case of this generation code causes the glitch, possibly linked to your y location on screen. Basically because I have run out of any other viable alternative ideas. On a more optimistic note, this might mean that the reset isn't involved in the glitch, so might have a chance at being a time saver. Anyway anyone interested in looking into this can also find useful info here: http://acmlm.kafuka.org/board/thread.php?id=6035 The backpack guy generation can be found in bank 2 around $B5XX
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/25838401702180223 Alright world 5 rough draft done. It's nothing optimized and even falls behind the published run in some spots, but at least its in there. @Tompa: yeah I know I need to put in the skip and the 4-4 glitch still, I just want to have a complete rough draft. Next step will be going back to world 1 and 2 and finalizing it. At that point I will work out everything in world 3. No rush, I expected this to be a slow paced developement. Definitely something that won't be done until 2016 sometime.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Oh awesome! I would love to see a run of this game console verified. Unfortunately I don't have a 1.0 cart either, so I guess I won't be of much help. Hope one turns up though! I'm powering through the rest of world 5 and going to knock out world 6 in the next couple of days mainly following arne's run. It won't be optimal but a good start.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Alright Ice Climber is officially done! It will still need a revisit in the future, but for now time to move on. I will be working on double dragon next, it has known improvements already and I don't expect it to be really hard, but progress will likely be slow since it's not that interesting and Donkey Kong Country will occupy most of my attention.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/25770433474979414 ok got Tompa's WIP synced all the way up to the start of world 5. I think what I'll do at this point is complete the game to have a baseline and a file that actually has a complete run in bsnes. Obviously there will still be a lot to do after that, but I like to have a complete WIP, since the run only gets shorter from there! Quite a few seconds were added in the re-sync process, not surprisingly. It's about 75% loading time frames. EDIT: oops, just realized I quit a bonus too early in world 4. I will fix it in the complete WIP.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Resyncing Tompa's run is going pretty smoothly. I encountered more lag in world 2, especially in stop and go station, but I don't think there is much to be done about it. But now i have reached the first major decision of the run, the super jump in 2-5. In my testing so far it seems to be slightly faster to not use the super jump. The stutter rolling and general optimization seems to put the original route a bit ahead of the super jump route. But maybe I didn't optimize it enough, care to give it a try Tompa? So far I can't even get it to match the original route in the level, and it gets worse since you only have diddy and not donkey, so at some point even more time will be lost to get another barrel. Here is the version without the superjump (Tompa's 1.43 WIP resynced): http://tasvideos.org/userfiles/info/25710086525932007 Here is my attempt with it: http://tasvideos.org/userfiles/info/25710073228799523 Perhaps there is a substantially faster way to do the super jump, all I did was follow the tutorial video. Once this is resolved, my plan is to resync the run up to world 4, that way I can put markers in the project file so when I start hacking it up to do the Master Necky skip I know where to put things back together.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/25682262273489028 I probably should have done this from the start, but I started resyncing Tompa's 1.43 WIP that made it up to world 4. I resynced world 1 just as a test, it went pretty smoothly for the most part. It's about 1 second longer now of course due to longer loading times and a bit more lag, but it's a good baseline. I don't like reinventing the wheel, especially when Tompa put an incredible amount of effort into this, so I think this is a better approach. But I'm still glad I tried on my own, since now I know most of what I'm looking at and how things work. Hopefully things will move a bit quicker from here. I still need to look over world 1 and redo some lag management which is obviously a bit different in bizhawk then snes9x, but I think this is a much better strategy.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Since there are a couple high profile glitches out there right now that are not well understood, I figured I would list them here for reference. How does the contra wrong warp work? how does the SM64 upwarp work? I'm surprised these glitches both were discovered and had videos about them long before most people here became aware of them. Is anyone aware of any other glitches that are not yet understood?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
ok, so 0196 is counting how many backpack guys come on screen for a given section of the level. So at the time the glitch happens, we have 0195 at 09, and 0196 at zero. Now when the glitch happens, this could be when a backpack guy is about to appear on screen, which would change 0196 to 1, this happens a few frames before he visually appears on screen. If the stack pointer got down to there, and then 0196 changed like that mid-frame, it could change a return address to something that could end the level. Unfortunately, I've never seen the stack get below 01DD, so if this is indeed how the glitch is caused, we would need to find another glitch that corrupts the stack somehow first before recreating it. 0196 is also the highest address in the stack region that gets changed by the game code (at least in level 1), so if the glitch is related to the stack getting overwritten somewhere, there is a good chance it is here. EDIT: well, since the game doesn't use or initialize part of the stack anyway, I edited the ROM to jump to RAM each frame in the unused area. From there I tried to edit the stack values to make weird jumps but so far all I do is crash things. Even if I jump to the routine that normally sets stage end flag it crashes. So, no leads at this point.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Well I narrowed down on a few places where some slight glitches happen in the boss fight, where memory also doesn't get reset after dying and hitting end. The first case is address 016A. It changes to 7D as the boss comes on screen and it starts scrolling on its own into the boss area. If you happen to die while it is still scrolling, it gets stuck on 7D. The screen still stops scrolling properly, but normally it goes to 80 if you don't die. Then it goes to 83 after a few frames. It can also get stuck on 80 when dying. This doesn't seem to effect too much, but it is at least a glimpse of non-standard behavior. More interestingly, there is some uninitialized stack memory between 01C0 and 01FF. The game initializes memory in an interesting way. First, it initializes 0000-01BF to 00. Then, it sets 0200-07DF to 00. Then, for 07F0-07FF it sets to F1-FF for whatever reason. 07E0-07EF get set individually to various values. 07ED seems the most interesting. It is set to the value of $8000. So I'm guessing this has something to do with memory banks. Anyway this leaves 01C0-01FF untouched, presumably expecting this to be the maximum extent of the stack. This interesting because values kind of close to this are changed at the boss stage. For example $0195 also seems to control scrolling in some way. So right now my guess is that something went wrong with the stack, most likely related to choosing end after dying on the first boss. Oh one other important thing I noticed is $0196. 0195 seems to keep track of what screen number you are on, while 0196 seems to count how long you have been on that screen. However, sometimes 0196 behaves oddly. Usually it increments once per second, but occasionally it increments much quicker, I haven't figured out exactly why but it is the next thing I will look at.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nice! Yeah the physics changes for the DS are frustrating. But, glad to see a run of this game that is caught up to the present state of the art.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Oh nice a video, thanks zallard. Pressing 'end' definitely doesn't clear everything, but it does clear the object table. Well, so far here is what I know about how a level ends. When boss's HP hits zero, his state changes from 2 to 3 (wherever it spawns in the table between 04B8 and 04C7.) This triggers a routine which eventually sets 003B=1. When the main loop sees that 003B=1 , it changes 002C from 4 to 8 (via loading #$08 into accumulator and storing it in 002C.) This state remains until the explosion animation is finished. I haven't found the address for the timer yet. After the animation ends, 002C goes up to 9. The player loses control at this point. This is curiously done with an INC instruction, even though every other case is not. After that, if you are on the ground, the next frame 002C gets set to #$81 and the ending animation takes over. If you happen to be in the air, it won't change to #$81 until you hit the ground. To end the level as in the video, setting 003B to either 1 or 81 both work. Setting 002C to 08 works. Setting it to 9 eventually ends the level, but not in the same way as the video, at least not in my testing so far. So far I can't find anyway to distinguish between these working cases, it would be nice to narrow it down further.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Oh so that's why the backpack guy can shoot, ok thanks (clearly I've never played Contra, and certainly never made it to level 5.) Anyway, about the only interesting thing I can make happen so far is by giving a bullet a bad state, I can overflow the table , since the stationary guns that rise from the ground shoot bullets faster then they are cleared from the table. But all it does is crash, and so far I have no plausible way to give any object a bad state. So I think I will look over the ROM and see how else I might set the stage end variable. I also might try to recreate the video but am not very confident I can do it. Well its fun to experiment at least, the first level of contra must have been played tens of millions of times, I'm surprised such a glitch is unexplored. Of course it's also possible its just a random error, only 1 bit needs to be changed to end the level.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
So I started looking into the warp that Cartina posted here So far, I have at least found the address that can call stage end sequence. If you set $002C to 08, it will end the stage exactly as is done in the twitch video. Normally, the game sets this value to 8 after the last hit on the boss. (In normal play it is 4.) In terms of what this does, 002C is used to set the jump address for Jumps from 0002, which is where jumps are executed from in a normal frame. The first jump is always to CE30 The second Jump changes from CEE3 when 002C is 4, to CFEA when it is 8. The next step after this is D01F when it is 9. I haven;t tracked down exactly where 002C is changed from 4 to 8 normally yet, but this seems like a good start. EDIT: working backwards a bit, the same behavior can be obtained by changing 003B to 1 (it's normally 0) EDIT 2: ok, here is how 003B is normally changed to 1:
$E626:BD B8 04  LDA $04B8,X @ $04C7 = #$03                   A:00 X:0F Y:00 S:F4 P:nvUbdIzc 
           $E629:F0 2A     BEQ $E655                                    A:03 X:0F Y:00 S:F4 P:nvUbdIzc 
           $E62B:86 83     STX $0083 = #$04                             A:03 X:0F Y:00 S:F4 P:nvUbdIzc 
           $E62D:0A        ASL                                          A:03 X:0F Y:00 S:F4 P:nvUbdIzc 
           $E62E:85 04     STA $0004 = #$09                             A:06 X:0F Y:00 S:F4 P:nvUbdIzc 
           $E630:20 59 E6  JSR $E659                                    A:06 X:0F Y:00 S:F4 P:nvUbdIzc 
             $E659:BD 28 05  LDA $0528,X @ $0537 = #$11                   A:06 X:0F Y:00 S:F2 P:nvUbdIzc 
             $E65C:0A        ASL                                          A:11 X:0F Y:00 S:F2 P:nvUbdIzc 
             $E65D:A8        TAY                                          A:22 X:0F Y:00 S:F2 P:nvUbdIzc 
             $E65E:4A        LSR                                          A:22 X:0F Y:22 S:F2 P:nvUbdIzc 
             $E65F:C9 10     CMP #$10                                     A:11 X:0F Y:22 S:F2 P:nvUbdIzc 
             $E661:B0 18     BCS $E67B                                    A:11 X:0F Y:22 S:F2 P:nvUbdIzC 
             $E67B:98        TYA                                          A:11 X:0F Y:22 S:F2 P:nvUbdIzC 
             $E67C:E9 20     SBC #$20                                     A:22 X:0F Y:22 S:F2 P:nvUbdIzC 
             $E67E:A8        TAY                                          A:02 X:0F Y:22 S:F2 P:nvUbdIzC 
             $E67F:B1 80     LDA ($80),Y @ $E6CA = #$C7                   A:02 X:0F Y:02 S:F2 P:nvUbdIzC 
             $E681:85 02     STA $0002 = #$B0                             A:C7 X:0F Y:02 S:F2 P:NvUbdIzC 
             $E683:C8        INY                                          A:C7 X:0F Y:02 S:F2 P:NvUbdIzC 
             $E684:B1 80     LDA ($80),Y @ $E6CB = #$8B                   A:C7 X:0F Y:03 S:F2 P:nvUbdIzC 
             $E686:4C 6B E6  JMP $E66B                                    A:8B X:0F Y:03 S:F2 P:NvUbdIzC 
             $E66B:85 03     STA $0003 = #$D5                             A:8B X:0F Y:03 S:F2 P:NvUbdIzC 
             $E66D:A4 04     LDY $0004 = #$06                             A:8B X:0F Y:03 S:F2 P:NvUbdIzC 
             $E66F:B1 02     LDA ($02),Y @ $8BCD = #$40                   A:8B X:0F Y:06 S:F2 P:nvUbdIzC 
             $E671:85 04     STA $0004 = #$06                             A:40 X:0F Y:06 S:F2 P:nvUbdIzC 
             $E673:C8        INY                                          A:40 X:0F Y:06 S:F2 P:nvUbdIzC 
             $E674:B1 02     LDA ($02),Y @ $8BCE = #$E7                   A:40 X:0F Y:07 S:F2 P:nvUbdIzC 
             $E676:85 05     STA $0005 = #$00                             A:E7 X:0F Y:07 S:F2 P:NvUbdIzC 
             $E678:6C 04 00  JMP ($0004) = $E740                          A:E7 X:0F Y:07 S:F2 P:NvUbdIzC 
             $E740:20 83 C1  JSR $C183                                    A:E7 X:0F Y:07 S:F2 P:NvUbdIzC 
04C7 is the state of the enemy in that slot. Normally, this will be the boss. His state changes to 3 after the last hit. Now, other enemies can normally occupy that slot too. And their state also changes to 3 when they die. That is why the next check at 0537 occurs. This checks for the ID of the enemy in that slot. The boss has ID #$11, so this is the only time when the check BCS $E67B passes. After the check passes, the code continues onwards until eventually changing 003B to 1, the jump to E740 is what we need. Now when I change 0537 to 11 when another normal enemy has just died (has state 3) the explosion sequence occurs as if the last boss died. When I just change 003B to 1 manually, no explosion sequence happens. In the twich video, there is no explosion sequence, so I believe either 003B or 00C2 is being changed independently somewhere. But, there are very few places where this occurs, not sure where to look from here for edge cases where this might happen. Very little is happening at the time of the glitch. EDIT 3: hmmmm, there is something in the normal level that spawns with ID $#12. If I can get this object to spawn in 04C7, perhaps somehting interesting will happen? Well, looks like 12 is the bridges, so probably nothing there. EDIT 4: So I've been playing around with object IDs and their associated state variable. So far there are several combinations that cause glitchy things (or crash the game altogether) I haven't found anything so far that looks like a bad jump to end the level though. One neat thing I did find though is that the running backpack enemies actually have a gun. If you set their state variable to 4, they will point a gun at you, and on rare occasions will even shoot (a single bullet.) I guess this was something that was just never used.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nope, not a rookie, but thanks for the vote of confidence AngerFist : )
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm not sure how relevant this is, but I did notice on the youtube encode for Return of the Jedi, several comments expressed disappointment that the run wasn't done on Jedi mode. Not sure if this was just general viewers or people close to the site or what, but I think at least it does show that picking easy mode is not necessarily what people want to see, regardless of reason.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
xxNKxx wrote:
I think this run still need optimize more than, many points I think have waste time. Example 11:23, why red character didn't go left then jump up?
This run can eventually use a version 2 you are right, though personally I will wait for a next-generation emulator to do it. I would love to see a run that can sync on console. But in the particular instance you mentioned, it is actually better not to go up with pink as fast as possible, because as soon as you scroll the screen upwards, the cloud at level 8 is spawned. This creates a bad cycle for blue, and ultimately costs time since I need both characters for the bonus. There are several other spots like this throughout the game, actually the level 3 bonus improvement is an example too, (compare bonus 3 to bonus 19 to see what I mean.) EDIT: Oh, I just realized that Dimon's temp encode is the version with the seals instead of yetis. I'm surprised it syncs, and also surprised to see those sprites as I don't think I've ever seen them before.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
To beat each level , you need only reach the start of the bonus stage. You can promptly walk off the ledge and still beat each mountain after this point, which would result in 'no bonus' at the score screen for both players (and of course be several minutes faster.) This is why the run isn't simply 'any %' But if others find it misleading, feel free to suggest a more descriptive category name.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Would it be appropriate to simply define 'any %' as the fastest completion, regardless of difficulty? It would be something of a reversal of the current guideline, but at least it would be simple and consistent.