Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
Dimon12321 wrote:
I recorded a small TAS of Duke Nukem Advance: User movie #638491602391815310 The game features unusual usage of hardware. The sound chip participates in calculation and doesn't play music during the gameplay. Besides, the framerate is uncapped. So I think it will be a good accuracy test for GBAHawk, if you have the game around.
Woah that's really interesting! I don't have a cart right now, but I'll be sure to get one when I can and give this a try, thanks!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
https://tasvideos.org/UserFiles/Info/638490759514684900 I was going to console verify this but I found a couple improvements in the latter levels. Maybe there are still some other improvements out there that can be found before I make a new submission.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
So what exactly is happening here? Mupen memory management bug?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
Link to video Here is a test run of the first level of Megaman and Bass GBA. This game uses the other variety of EEPROM (8kb while the other games I tested use 512b.) As it turns out my cart has very different timings compared to the other 2 EEPROM verifications I did so far. Those were -9000 or so on the cycle timing offset while this one is +28000. This value seems pretty stable at least. Right now the only other 8kb cart I have is Ty 2, so I'll have to go back and check the timings of that one more carefully to see what kind of agreement I get.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
I figured out how to output the audio through OBS, so I replaced the previous live capture video with one with audio.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
despoa wrote:
Is it possible for you to verify this again on camera?
Best I can do is a low quality cell phone video with no audio (i don't have a crt and my monitor won't recognize the NES component inputs.) EDIT: Figured out how to output audio through OBS, video updated. Link to video
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
Link to video I finally managed to console verify this! It turns out the data rate was only too high for a short time when the code is first being loaded. So I increased the latches per command from 28 to 32 (with some minor fiddling to prevent buffer overruns) in that area, then returned it to default 28 for the rest of playback. With this tinkering and using my hacked SMB ROM that sets RAM for me, it worked out first try. Really amazing that this worked out, you have really mastered the NES OnehundredthCoin!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
OnehundredthCoin wrote:
Alyosha wrote:
The files (both the submission and user file) seem to have corrupted input logs. I'll try to verify this when i can get it running.
Ah, that was intentionally modified in an attempt to reduce the file size.
Could you post an un-modified input log somewhere? I keep getting fatal exceptions when trying to dumb input latches.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
The files (both the submission and user file) seem to have corrupted input logs. I'll try to verify this when i can get it running.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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 video https://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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
RTA timing starts at character select and ends at the last goal. By RTA timing this run is ~2:07.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
Location: US
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3521)
Joined: 11/30/2014
Posts: 2726
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.