Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
What's the verification setup? Did any input have to be tweaked?
The movie file is the exact same as the one provided in the movie submission text. I used GBISR with some tweaks (mostly involving using the GBC color matrix and making it use 10:9, purely cosmetic and doesn't affect the actual GBC). I guess I should also point out I used a flash cart (it's not an SD card based on, in essence it's a JPN Pokemon Gold cart with its ROM chip swapped out with a flashable chip, so it has all the typical hardware a typical GB/C cart has like SRAM and a real MBC)... I guess I should point out Rockman used the MBC1, and my cart has an MBC3 chip, but they're mostly backwards compatible anyways barring extreme edge cases (none apply)... and this flash cart is the same one used in TCG2/Silver/DK94/Pinocchio verifications, the former two have gotten the checkmark (and I've been cleared I used a flash cart) so I assume it's okay anyways.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
While they're at that, the "uses death to save time" should also be removed from the GEG movie. Besides the "glitch" not actually needing death to work... they actually never died kek
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Do these really count when the solution is as simple as removing the battery (or at some point the battery dies and you can play the game, albeit with the cart unable to hold a save).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I would argue diagonal movement would be enough to satisfy "radical differences" in regards to gameplay. Besides the fact that diagonal movement inherently makes gameplay faster (e.g. Up+Right input goes the same distance as Up input then Right input), it also just allows me to solve puzzles in different ways than what was exactly "intended." Many solutions I used would just be straight up impossible if you can't go diagonally. Not to mention corner exiting cannot be done (since that relies on diagonal movement).
EDIT: lol samsara sniped me
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So looking at the RTA boards, the GCN version seems to be the version used in the top two times. From what I understand, the GCN version has a different setup than the N64 version, which is much faster than the N64 setup. So I'm wondering how this translate to a TAS.
To be clear, from what I understand the GCN version is just the original game being ran on a (shitty) N64 emulator, and this ACE exploit breaks out of the sandbox due to an emulator bug within this N64 emulator and executes the credits (which is apparently just a pre-rendered video, so GCN code can access it). I'm not sure if this would actually be considered legitimate due to the fact that it's abusing an emulator bug (albeit this wouldn't be abusing anything in Dolphin and this can be done on an actual GCN), but perhaps that should be discussed for potential future cases.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Link to video
And y'all thought this couldn't be console verified.
Well, I guess I should be transparent with my methods. I did some research regarding uninitialized WRAM... and as expected, it's just random data, with "patterns." Interestingly, the RNG byte used seemed to stay as a $52 byte for me, and as another note apparently the GBA BIOS zeros out the GB's WRAM if you boot into it? Anyways, I then looked into the claim that "hard reset turns off the console so WRAM won't persist." This was actually largely incorrect: through my trials testing this theory, only once did a hard reset result in different WRAM... and it was just a single bit being unset. The time the console is off is so short it makes it very unlikely that a hard reset will cause changes to WRAM. So essentially, if I run a ROM to write FFs to WRAM, I can then swap carts (well, in my case yoinked my flash cart out then flashed DK94 onto it before putting the thing back into my system), then hard reset and let the movie play, and it should sync, and indeed it did! Well, this actually took a few attempts, as I appeared to have hit some desyncs during my initial attempts. I'm not sure if they were related to RNG or not (according to DrD2k9 the RNG seemed to be correct), but in any case, one of my attempts synced completely, which is good in any case.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So I decided to try and verify this TAS on my flash cart, and by coincidence the RTC offset matched entrpntr's, so there's finally video of console verification! And this should mean that this movie can get the checkmark :3
Link to video
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Unlock everything fast
In the SRAM, the data about the items unlocked is stored last (SRAM domain, bytes 0x0220-0x0229). So if you turn off the console while saving a new game file, just before the the item data is written, you can have it kept to 0xFF uninitialized bytes, which means that you have all items unlocked, and money and exp maxed. Yay!
That sounds a lot bigger than half of a byte :P
Anyways, I don't think non-save glitch TAS logic should apply. Those TASes may unintentionally desync due to the state of SRAM. Needing an external device to clear SRAM is really just a sad necessary evil for console sync.
However, once we get into save glitch TASes, TASes that inherently exploit the state of save data, that is when abusing uninitialized save data should not be done. In fact... I'm just going to say the Red TAS is already somewhat guilty of this, it technically abused uninitialized save data, its only saving grace is that wiped save data is identical to the technically arbitrary pattern set by the emulator. Even then, I am wondering if that is enough to justify the choice, but I digress.
Anyways, I'm just going to put a case that I think can display the issues with letting save glitch TASes use uninitialized save data. Let's say there are 2 emulators with different patterns for uninitialized SRAM. One pads it with FFs, the other pads it with 00s. Both these patterns I would argue are perfectly valid for the purpose of establishing "clean" SRAM. Now it gets dicey when these patterns are abused with save corruption. One emulator could have a better pattern for one movie, the other emulator could have a better pattern for another movie. And, I would go as far as saying movies abusing these technically arbitrary patterns the emulator sets should be considered New Game+ (and thus ineligible for Vault). Your TAS actually displays perfectly why it should, you literally unlock everything because the pattern set the emulator effectively matches a New Game+ kind of SRAM. Again, the pattern set by an emulator is effectively arbitrary, a TAS specifically abusing this should not be allowed in my opinion.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So does the game have any way to wipe save data/does wiped save data pad SRAM with FF bytes? Wondering about the legitimacy of some of this save corruption.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
PikachuMan wrote:
There's this hacked called Crystal Clear which makes traveling less restrictive which means that all gyms can be done in any order. All HM moves can be used without needing certain badges. Gyms get progressively difficult. There are many starters.
For the start of the run of Crystal Clear, use Crystal Clear 2.0 Baby, choose Seel as the starter and you'll have access to Surf. Set text speed to none, animations to off, ask switch to no, menu account to off, encounter to fast, nurse to quick, continue to quick, disable calls from the Pokemon League, get to Goldenrod City ASAP. Get Kenya the Spearow and you have access to Fly. Fly to where you can catch a Legendary Pokemon, then beat the game!
By legendary Pokemon you mean Dodrio.
Also, the hack is still in development, and 2.1.0 is going to be released some time soon, and I doubt that'll be the last update.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
EZGames69 wrote:
As an aside, I am wondering how the previous movie not rejected for sub-optimallity, this input boundary was blatantly apparent by opening up the movie in TAStudio.
I looked at that movie previously in TAStudio but did not see anything that could be improved. It wasn’t an obvious improvement.
I think the improvement was just not obvious just due to a misunderstanding of the "glitch." Essentially, I believe that this is not an actual glitch, but rather a debugging feature. Dying actually has no relation to this trick. The only thing needed is to pause, then press Up, then unpause. And guess what, spamming up will go to other stages. It isn't some overflow from dying, it's just the game letting you select the stages.
That said, I believe the currently published TAS should be obsoleted by the previous TAS, as the TAS was simply not legitimate in the first place (and this explanation should probably be mentioned in the movie description). I'll be looking into this game, as it does seem to be a nice game to TAS, but gonna can this sub.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
"Glitch Explanation"
>doesn't have any actual technical explanation, just a tutorial on how to do it
Ok seriously this is pretty much some sub-optimal TAS of S3K and just does some useless glitch with debug mode of all things. The "glitch explanation" video was enough for showing off the glitch. It didn't need some low effort TAS.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I'm probably the minority here, but I don't think the music is that bad. Of course, it isn't stellar, but it is certainly better than other music I've heard, and certainly passable. The TAS's execution is fairly enjoyable anyways, yes vote.
I was looking through different games and runs for uses of uninitialized memory and saw this example in Pokemon Crystal. It happens during the start of the credits.
I tried setting D95D to one, and it does take a different code path but I didn't notice anything really different happening. Not sure what it could be related to, just thought I'd make note of it.
That is initialized. That's wPlayerState, 0 means the player is walking, 1 means the player is biking, etc. And besides that, Pokemon literally 0's all of WRAM and HRAM on boot...
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
That's what it does for WRAM, but what about HRAM (FF80 - FFFF)? I see in Gambatte initstate.cpp that it has a 'ffxxDump' array that it initializes from, but where is that from?
I don't think that's based on any actual testing, it seems to be just a padding value put in (not like it super matters anyways, the values would very likely be cleared out by the game, and also more accurate behavior would essentially be non-deterministic... which is bad for the purposes of a TAS).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
I made test runs of Prehistorik Man (worked fine) and RC Pro AM (desynced due to reading from uninitialized RAM at FFCC-FFCD.) R.C. Pro AM also desynced with a run made in Gambatte. It's a bit disappointing to find such a high percentage of games that use uninitialized RAM even just in the limited number of tests I've done.
GBHawk initializes RAM to all zeroes, both WRAM and HRAM. I did test HRAM initialized with all 0xFF instead and that run did sync on 2 spereate tries. So maybe starting up with all 0xFF is accurate? At least for HRAM maybe, WRAM seems to be much more random in my testing with Dirty Racing.
On a side note, it's been 3 whole years since I started this thread, where'd all that time go! It seems like there's always more to do and less time to do it, I'm happy to still be making steady if slow progress though.
It largely depends on where it's reading uninitialized RAM (I believe some places in RAM would have swaths of 00 data and then another place with swathes of FF data, with random bits not set in the FFs and such), and besides that, a lot of random bs in the real world.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So I was informed by Thunder that the game will crash if you press A at "The End" instead of going to the Mt. Silver Pokemon Center. After going through the tracelog, I found out that the cause of the crash is due to some minor stack corruption when going to Map 0xFF00, which will make the game return to FF00 (ie rJOY, which will be disabled) instead of 1:5E76, which just results in rst 38 being executed which crashes the game. The fix was actually as simple as writing the correct values back into the stack, which just requires 7 more frames to execute the code needed to do that.
Movie file: http://tasvideos.org/userfiles/info/65213740338583941
Diff for the payload: https://www.diffchecker.com/8pdQnd2b
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ais523 wrote:
If I remember correctly, Pokémon disables the reset chord (A+B+Start+Select) during a save, thus the only way to get a save-glitched run is to cut the power to the console (e.g. using the physical power switch on a Game Boy Color). The game also outright tells you that doing this is a bad idea, implying thtat it can corrupt the game.
Correct, the game will disable soft resets until the save message is done (technically not the save itself, since the save message has artificial delay put into it, it actually only takes a few frames for the game to actually save the game, 90% of the save message doesn't have any saving in it).
Also, technically, you don't technically need to use a power switch per se. The Gameboy Player (which is what is used for RTA runs, for console verification, and is the de facto console used for reference) has a hard reset combo on the Gamecube Controller, and the Reset button on the Gamecube also hard resets the Gameboy Player.
ais523 wrote:
It's basically a case of using the game's power switch (not the controller) in a way that the developers were aware was possible, were aware could break the game, but were also aware that they couldn't guard against.
Somewhat disagree with this. Yes, they can't physically stop the player from hard resetting the console, but they can (attempt) to prevent corruption, with the simple thing called a checksum. If the game sees the main checksum is incorrect, it will load the backup save (assuming the backup save's checksum is also valid, if that is also somehow invalid too, then the game will refuse to load the save altogether). So a TAS has to specifically craft save data so the checksums collide after save corruption, to trick the game into thinking you didn't corrupt the save.
(now just to be clear, the old cloning glitch works regardless of the checksum since the devs only bothered to checksum main data, and box data is not protected by a checksum at all. this glitch of course is not used in neither the Crystal save glitch TAS nor the current RTA Crystal WR, both of which use checksum collision)
But overall I do get what you mean by legitimacy, and I'll add another thing to the legitimacy question, since the save glitches TASes use checksum collision, they also need to use a subframe reset. Particularly, my submission requires a reset that only has about a 60 microsecond window to hit. While this might seem okay on face value, you then realize we can't programmatically reset the console, and the reset has to be done by a human... To be clear, the RTA WR of Crystal had a much bigger window to hit, about 3 milliseconds, which is fairly viable for a human to hit. 60 microseconds is insanely small, it's probably possible to hit, but you might as well just flash the expected save data to the cart after the reset for a possible console verification than spend many days to hit that tiny window. Which even then that is flawed because RTC can possibly just screw you over. So I'd find it somewhat unlikely that the save glitch TAS can be console verified (which I assume would be the objective measure to what's legitimate), at most in theory it should be possible.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Invariel wrote:
[stuff about PC manipulation and usage]
That's a very detailed and appreciated assessment of a tiny portion of the CCG run, but it doesn't address the roughly 29 minutes of comparable and practically identical content between it and the glitchless run.
That wasn't the point of that post. The point was to address a few minor inaccuracies. It was not to address the rest of the post, nor does it discredit the rest of the post.
