Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I made a rom hack of SMB that loads the required RAM at power on (by editing unused level data and jumping to that) to avoid having to do any cart switching, but I still can't get sync. I get a white screen about 40900 poll in. I occasionally get one (incorrect) frame of animation before white screen.
I think to narrow it down further I would need some kind of test rom to verify that the bot I have / hardware registers can keep up with the rate at which data is being pushed.
The closest thing I have right now is NESnake 2, which has 300k polls in 3 minutes, and that works on console but this run has several times more than that.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
With a cart that sets RAM to the initial state, I can get to the 'N' worlds about 1/4 times on console, but then it crashes at Bowser. I imagine I need a more sophisticating swapping technique then manually to get it to work. The probability of none of the bits decaying away in the time it takes me to swap is probably very low.
Anyway really cool project!
Do you think you will re-submit stop and swap now that it works in 2.9.1?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
2 months since my last post and now we are at 365 runs console verified. Pretty steady progress.
I suppose we could easily pass 400 with the numerous Action 52 runs alone, but I don't have any way to play those back myself.
At least on my end I expect progress to continue at roughly the same pace. Soon I'll be looking at Mega Man Zero I hope those are syncable.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
RetroEdit pointed out a serious bug in v2.1.1 which prevented using the default core without a pre-existing config file.
I fixed this issue and with a couple other minor fixes released 2.1.2. I also backported the fixes to 2.1.1, to avoid having to simply delete it altogether.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Here is a video and movie file for a complete test run of Super Monkey Ball Jr. Master stages. It is console verified, but quite a bit slower than the published run (which doesn't sync at all.) I had previously tested one level but wanted to follow up with at least a complete test run since I was previously unable to get the skip in level 4 to work.
Link to videohttps://tasvideos.org/UserFiles/Info/638464781749776967
I won't be working on a complete new run, at least not any time soon, a working test run was my goal and that's good enough for me.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I have updated the release of GBAHawk 2.1.1 to fix a save state error when using EEPROM or FLash mappers. This error has apparently been present all along, and happens when loading a state where saving to cart is happening. So, I strongly recommend updating to the the current release of 2.1.1 to avoid sync errors.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Dimon12321 wrote:
I wish I could have such a strong motivation to deal with my stuff! Great work once again!
I went through your repository and the console-verified GBA publications and, I guess it makes sense to clarify the things.
I assume a gbmv input file recorded in an elder version of GBAHawk (say, 2.06) will playback in the latest version, so there's is no point in marking them in the repository. However, you mentioned RNG manipulations for some of the games to become verified, like you had to add some blank frames here and there to make the movie successfully play on a real GBA. Does it make sense to store these input files as well, for example, in "gbmv files verified" folder? Even if this final step of input adjustment has to be done for each verifying device independently, this at least will give verifiers the right whereabouts where to add or remove blank frames.
The verified movie files are played back as is, there is nothing added to adjust for console after the fact. By RNG adjustment I mean compared to the original move file on either VBA / BizHawk. The only exception to this is that occasionally I need to adjust the time stamp on the input file that GBI uses, but this is a limitation of the resolution of GBI not an accuracy issue.
I do check some previously console verified movies with each new version release to make sure I didn't accidently break anything, so yeah movie files should all be forward compatible.
Your post reminded me that there is one exception to this though. Feline currently desyncs in current versions. At first this didn't make much sense to me since it seemed to work on console just fine. But it turns out I dumped the movie with an old version of the GBI input script that didn't a include start up offset. By some weird coincidence of error cancellation this let it work on console. When I dump it with the current script it desyncs the same as on emulator. So at some point I need to find some frames to save to get a new movie and remedy this.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
For some reason I am unable to add the console verified flag to Fire Emblem: https://tasvideos.org/1878M
When I pick the flag and hit save nothing happens.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
With some considerable effort I was able to get Fire Emblem to work on console after all!
I should get the Sacred Stones run done some time this week as well.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
GBAHawk v2.1.1 is released!
This version adds a sync setting for EEPROM timings, along with various bug fixes. This allows me to add a check mark to DKC 101%.
I also fixed a bug in reading from BIOS while not executing in BIOS region, which is supposed to return the last fetched instruction from BIOS. I was not properly reading the correct byte when only byte sized data was asked for. I found this out when trying to figure out a desync in Fire Emblem. It turns out this game has a bug in calculating enemy movement when enemies are on the edge of the map and attacking characters also close to the edge of the map. In this case the game ends up reading from an incorrect address (in this case 0x00000007) which is in BIOS region.
After fixing this I was able to get a resync of Fire Emblem to work on console. All the actual moves are the same with only small RNG adjustments needed, so I'll go ahead and give that one a check mark too.
I'm half way through the same process for Sacred Stones as well, so that one will be next up for verification.
It's pretty satisfying to get the Fire Emblem runs working, as when I first started testing it I couldn't even get past the first start press. Good Progress!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
https://tasvideos.org/UserFiles/Info/638446788869509673
With a bit better understanding of how the lag resync script works, I was able to get a good resync of Mario Vs Donkey Kong. Unfortunately it doesn't work on console because the save time is just way too long on my cart. As far as I can tell it's like 50% longer than the stated maximum on the data sheet, which is causing sync issues.
My cart uses the same Flash chip as Sonic Advance, so I'm not sure why the timings are so different, but perhaps after 20 years this is just what you get.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
despoa wrote:
Is it okay if you could provide extra input for the credits stage? It's kind of silly for a TAS for the credits to run while the player does nothing but fall into the abyss multiple times.
I'm not really interested in doing so, but I won't object if you or anyone else wants to add something there.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Deadcode wrote:
Saved another 0.72 seconds (primary-submitted replay file for this submission) using the information TAStudio provided, and that truly appears to be the best possible with this set of solutions. (But I still find it a bit of an inconvenient way to do this; a log file would be much better.
And then at first I thought, after seeing what TAStudio could do, that it explained how you did this:
But it appears that TAStudio loses the ability to do that magic when the GBHawk core is in use, and the replay file you posted was based on the GBHawk one. So how did you do that?
Cool, looks good!
Oh, I was playing around with possible improvements in 3-9, and I ended up with a solution that was a couple steps longer but shorter in frame count. I was doing the moves manually, so I was doing all the moves as fast as possible just holding buttons down, so I figured something had to be wrong with the original file.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Deadcode wrote:
Wait, what? How are you interpreting that graph in that way? It shows 4 frames in a row that are all the same color, against a gray* background. Can you actually tell just by looking at it that it accepts input on the 2nd? Why not the 1st?
*I guess it's grayish cyan, using a color-picker, but to my protanomalously colorblind eyes it looks gray. That's not the problem though, as all 4 frames in a row from 1313 to 1316 are the same green (I had to check, to make sure there wasn't just some color difference I wasn't seeing)
All the later moves also accept input on the second green frame and not the first, so I guessed it was the same for the first move. It's just something you get a feel for with experience.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
TAStudio is really helpful for cases like this since you can (generally) see where input is accepted.
Here is the first start press in your movie, you can see one green input frame 10 frames earlier:
Here is the first move in level 1-2, you can see the 'left' button is pressed on the fourth (green) input frame but input is accepted on the second:
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Deadcode wrote:
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission.
Seems like there are still some script issues. The very first start input can be pressed 10 frames sooner. Also a lot of levels are 2 frames late on the first move, with some even being 4 frames late.
How are you writing the replay in the same clean export format as I've been using, which only holds the joypad button for 1 frame exactly when it's needed?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Deadcode wrote:
So anyway, yeah, this means I'm going to have to re-solve all the levels that involve filling holes. Wow.
Why do they need to be resolved? Isn't just going back and removing the extra frames at each hole fill sufficient?
The original reason I stumbled upon this is that I wanted to look at 3-9 again (but my idea didn't pan out.) But yeah if I have anything else I'll use gambatte version for convenience.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
https://tasvideos.org/UserFiles/Info/638443243569823355
I'm not sure what happened, but it seems like all the moves in the last 2 levels are taking too long to move after a block has been placed. Here is a partial improvement of those levels.
I didn't check earlier levels, or checked if they had always been that way in previous movies.
EDIT: Looks like this happens in the earlier levels as well, even in the Gambatte movie, perhaps a bug in the script?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
This is amazing work! That 3-6 was very surprising, I never would have thought that shoving that 3x1 all the way to the right could have been part of the solution. 3-7 also looks super smooth now, really cool. The other small improvements were also neat though I'm a little disappointed in myself for not finding that 2-8 or 3-1 route.
I always like seeing big projects like this come to fruition, even if some of the levels are still out of reach. Great work!
Here is the first move in level 1-2, you can see the 'left' button is pressed on the fourth (green) input frame but input is accepted on the second:
