Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
SuperSqank wrote:
I’m cool with looking at it. I was actually interested in TASing the game myself, willing to remake the whole thing. I will see what I can do and I will look into sending you an improved movie when I’m done. Could you provide a BK2 or TASPROJ file for the run?
Here is a bk2 but note that it will desync around frame 8000 due to incorrect lag emulation in mGBA. I can always resync a final movie back to GBAHawk again later anyway for console verification.
https://tasvideos.org/UserFiles/Info/638528620588612122
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
^ Thanks for the detailed comments. Are you interested in improving the TAS? This run is short and sync friendly enough that it could be improved relatively easily so I don't mind just cancelling it.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
Bigbass wrote:
Nice job Alyosha! Also, if you count obsoleted TASes, we're currently at 521 verified publications. :D
As for the N64.. some in-depth testing needs to be performed to really know how viable the system is for verifications at this time. SM64 and a couple other games are verifiable already, even with the much less accurate mupen64 core. But this appears to be because the way those games poll and make use of controller input, makes them unaffected by timing inaccuracies, at least as far as the replay device's ability to stay in sync. If you actually measured the realtime it took to replay, I'm certain it would be different than the emulator (based on what Ridley has explained to me, through her efforts regularly verifying SM64 TASes.)
I suspect it might be possible to "scan" the N64 library of games with a Lua script in BizHawk, to try to predict games that are similar to SM64. But you'd have to manually play each game to induce some lag into the test.
RDRAM initialization shouldn't affect anything. Maybe if a game depends on the initial state somehow? but I haven't heard of any N64 game doing that, and the initial state of RDRAM may actually be deterministic (needs more research). If necessary, it may be possible to initialize at least most of the system to expected values before starting the game/TAS replay.
I was considering starting N64 testing myself with the Ares core, but my impression is that I should probably wait for a few more updates as it's not quite there yet.
For NES, GB/C, and GBA, pretty much every edge case emulation detail has been necessary for console verification for at least some games. Assuming this extends to other systems as well, it's hard to dedicate a lot of time to testing before a high degree of accuracy is guaranteed from the emulator. But not being an N64 dev myself it's also hard to judge when that point is reached.
Still maybe it would be a good idea to make some simple test runs for games like Goldeneye or Rogue Squadron to check if replay is at least deterministic for games developed by other publishers.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
We just hit 400 current console verified TASes! Another hundred milestone hit about 14 months after the 300 one, relatively quick progress.
Despite this being a big numerical milestone, it all is still coming from the same systems. There is however a lot of interesting development happening that could lead to some verifications on newer systems in the not so distant future.
There is a big PR open in melonDS ( https://github.com/melonDS-emu/melonDS/pull/1955 ) that implements a lot of the complicated cache stuff. Seems to fix some timing issues so it could be a big step forward in DS accuracy once it gets merged. Looks like it still needs a bit of work but pretty exciting to see such a complicated thing being worked on. DS seems like it is the next likely console where a mature console verification pipeline can be built up. I'm looking forward to seeing this happen.
The N64 situation in Ares is also looking good. N64 has RDRAM initialization though, which could impact determinism to some extent. I'm no expert so I don't know how bad it could be. Obviously some runs sync reliably on N64, but this might not extend to more of the library.
If anyone was watching the Team 0% stuff in Mario Maker, they know that the last level was uploaded using TAS playback tools for the Wii U. I found this really surprising and it's cool too see stuff like that come out of nowhere. I haven't researched any of the technical details, but presumably the inputs were hand crafted similar to the Mario Maker 2 demo by TASBot folks. Maybe this approach has some potential for longer runs with some more work to make it less painful?
I personally don't have time to start any new big projects, so I'll be grinding out GBA verifications for the foreseeable future. There are still a lot I want to do.
Onward to 500,
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
v2.1.3 is now released, fixing the EEPROM size detection problem here (and in the other run.)
Resyncing is just a matter of adding lag frames, I can provide them tomorrow if desired.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
GBAHawk v2.1.3 is now released. This is a bug fix release which reworks EEPROM size detection (fixing probably ~1000 incorrectly entries based on MAME DB.) I probably should have done this from the start but didn't realize how bad the state of affairs was. This also re-balances audio between FIFO channels and GB style channels.
Next release will have manual Flash timings, which I wanted for this release but don't currently have the time to sort out properly, as there are a lot of variables.
I haven't encountered any core accuracy problems in a while which is promising. I know some of some very edgy edge cases that could cause problems, but they haven't popped up yet, so for now I am content to keep grinding out console verifications.
EDIT: There was am bug in audio mixing, I fixed it and updated the 2.1.3 executable / downloads.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
feos wrote:
Alyosha wrote:
What you want to do here is verify that the RAM state at the end of the SMB3 movie matches that at the start of the SMB1 movie. BizHawk lets you export RAM as a text file (from hex editor), which can then be used by online diff checker or something similar to verify they are the same.
I did so and they match, so it's good.
You mean even tho savestates don't match, RAM state inside them does?
Yeah. But really the savestate is an unnecessary complication here since NESHawk has the ability to load RAM via sync setting.
Here is a .bk2 version of the run that starts from power on and loads RAM in this way so the savestate is avoided. I played it back and it syncs just fine:
https://drive.google.com/file/d/1iss7PgrndTHwzg3UCJ9TBj29u6LxgTlV/view?usp=sharing
I would suggest using this version as the publication file actually, since savestate is not garaunteed forwards compatible, and the verification movie only really generates RAM anyway.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
InfoTeddy wrote:
I've been given a userfile for SMB3 that sets up the SRAM needed to ACE in SMB1. However, the savestate I got didn't exactly match the one used in the movie - and when I try to replay based off of my savestate, my BizHawk freezes up with no signs of life. Looking for someone else to verify the SRAM movie for me.
What you want to do here is verify that the RAM state at the end of the SMB3 movie matches that at the start of the SMB1 movie. BizHawk lets you export RAM as a text file (from hex editor), which can then be used by online diff checker or something similar to verify they are the same.
I did so and they match, so it's good.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
This game does not use the correct save type on GBAHawk v2.1.2. It uses 64K EEPROM instead of 4K.
The runs still sync after adjusting for the extra loading times with correct save type though, just by adding in blank frames during saving.
I would ask that this run and the other one be delayed until I can release a new version that addresses this (in the coming days.)
Apologies for the error.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
EZGames69 wrote:
So I noticed there's some audio mixing issues that I first noticed for games like https://tasvideos.org/9040S in GBAHawk.
In the first level's track, there's a guitar like instrument that comes in (might be a different instrument idk what it would be) that is mixed pretty quietly in comparison to the console footage in that submission. I make a video highlighting the differences using mGBA as a comparison:
Link to video
In the TAS itself, this part of the track kicks in at around 1:06.
Wow, not sure how you were able to notice that but I agree it does sound a little too quite. I'll open a github issue for audio balance for 2.1.3.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
Dimon12321 wrote:
In scope of TAS movies provision to test emulation accuracy, I'd like to provide two movies (following previously posted Duke Nukem Advance movie):
- Serious Sam Advance: User movie #638512881522132559
- Doom: User movie #638513118358303271
Speaking of Doom. For some reason, GBAHawk doesn't make an in-game save. I don't know if I should create an issue on GitHub or maybe I missed some warning on this regard, but since battery-backed saves were mentioned in previous verifications, I think that means the emulator must be capable of doing saves.
For comparison, here is my BizHawk 2.6.1 TAS, where game is being saved just fine: User movie #74380673068812668
Thanks for the movies! I'll look into them as soon as I get the carts.
Doom probably just needs a gamedb entry. One way or another I'll have it fixed for v2.1.3.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
SBDWolf wrote:
I have found a Credits Warp in the Famicom Disk System 1.0 version. This method however takes roughly 2 hours to set up, so it's not currently a faster way to beat the game.
Full explanation in this pastebin: https://pastebin.com/75tbpnLJ
tl;dr: The glitch screen accessible by damage boosting up to the stage exit in Stage 10 contains a spawner with an invalid index that ends up making the game execute code from RAM. A payload can be prepared to warp to the credits (though with some limitations).
I haven't been super rigorous in my research, but I have not found an accessible screen with potential for RAM execution in any of the cartridge releases.
Input file: User movie #638511647302356536
That's a pretty intense set up. Hope it leads to something time saving.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
GoddessMaria wrote:
So, after trying a couple of things... I have a few things to say.
Most recently, I attempted to get the Knuckles TAS to sync again using a genuine Japanese cart as they do work interchangeably with each other when played back on emulator alongside the save data working with each other. With that being the case, there shouldn't be any issues with playback... or, at least, what I had thought.
As shown in the video, it still desyncs in Secret Base Zone Act 2 like with the flash cart in the same place. I'm perplexed what could be the reason for it failing on both flash and an authentic cart. Here's a video of the same movie being played back on the Japanese ROM using the movie file from GBAHawk v2.0.2 played back on v2.1.2.
---
Also, an aside... something seems amiss when it comes to the way that the RTC seeds are being handled with Pokémon as they don't exactly generate correctly.
Manual flash timings aren't implemented yet, so you won't be able to match the run to your particular cart unless you rebuild the core with a different value. (The current value is 325, if you use 425 you get the desync as in the video.)
I don't know anything about the internal workings of Pokemon, what are the specifics of what is wrong?
I'm not a fan of turning off the music, the game is too slow to go without it for over an hour.
Nice job finding some improvements though, I'll try to console verify when it's done.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
EDIT: New run submitted
In the RTA run there is a glitch where you can pause and unpause the game and that stops pearls from despawning after being used by clams.
This saves ~2 seconds in the second level and ~20 seconds in the seventh level.
I resynced up to the level past the angler fish chase, still needs some work, but works on console:
Link to video
There is some limited RNG in this game apparently. The flag in the fish tank level for example moves the wrong way in this test run so that level is ~1 second slower.
I'll finish this up and that should be another run verified.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
Currently relevant sync notes:
Sonic Advance: Runs that didn't use BIOS seem to desync due to RNG at the pinball boss
Sonic Advance 3: Desyncs on wheel boss.
FF Tactics Advance: Lag inconsistent, so script doesn't work. Might sync with a large amount of manual effort.
Banjo Kazooie: I can't fix the RNG of the enemies, so damage boosts don't happen.
Advance Wars 2: Seems like it might sync in emulator but desyncs in a strange way on console, the game polls input in a weird way.
Mega Man Battle network 2: Bad encounter RNG
Bionicle: Desyncs half way through the run.
On the up side, 3-in-1 runs and Ice Age resynced easily, so that's 4 additional verified runs. Now over 40 GBA runs are verified, almost as many as GBC and slightly more than GB.
There are still several runs for which I am lacking carts but have GBAHawk runs or test runs: DKC2, Duke Nukem, and Power Rangers. Also I still don't have a 32 MB dev cart for some Metroid Zero Mission ROM hacks (they always seem to be out of stock.) So getting to 50 runs verified should be easy.
Still no shortage of stuff to do, hopefully the percentage of resync failures stays low.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
https://tasvideos.org/UserFiles/Info/638506352392123556
I improved RetroEdit's run (which is itself an improvement over the cancelled submission by Entepp) with a new skip and some minor optimizations.
I console verified this run, but I'll hold off on making a video in case any more improvements are found. This run is pretty sync friendly, so it's relatively easy to look around and test things throughout the run.
If no one else finds anything I'll submit what I have.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
I was asked to respond about the potential time saves, but really I'm happy with the current run and don't plan on putting more time into it. This game is not sync friendly at all, and it probably needs a specialist to optimize a new modern TAS. Personally I think a 1 minute improvement and console verified is good enough to warrant it obsoleting the current publication, but if optimization rules don't allow for it then fair enough.
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
I went back and tried Sonic Advance runs again, so far I managed to get the Tails run to work without much issue, not sure what I was doing wrong before. I'll try the rest of them as well. EDIT: nope other runs don't sync, maybe tails worked because it used the bios? not sure.
Link to video
Editor, Experienced Forum User, Published Author, Expert player
(3619)
Joined: 11/30/2014
Posts: 2756
Location: US
https://tasvideos.org/UserFiles/Info/638501074303052118
Here is a run that beats the game. It uses the old route through level 4, which is in fact much faster. Additionally I eliminated the waiting for the first platform in 4-2 with a swing, so that saves additional seconds.
There are other small time saves here and there. It is console verified:
https://www.youtube.com/watch?v=biFIl6l-1bY
EDIT: new run submitted but I'll leave this test run up here since it shows a drill despawn in level 4 that couldn't be reproduced in the new run.
