I suppose you would need some kind of protocol for ensuring that the two emulators stay in sync time-wise, unless you're going to embed both emulators into one program. (The idea of embedding mGBA into Dolphin has been floated in the past, though more for the purpose of emulating the Game Boy Player than for making GBA linking TASable.)
They'd still be able to just write and read files from disk, similar to how save files are usually handled?
I'm not sure what you're referring to here. The games all have separate save files, and these save files are handled like in any other game.
feos wrote:
It this process inherently interactive and parallel on a real device?
Yes. You connect a link cable between the GBA and one of the GameCube's controller ports, essentially the same way as you would link two GBAs up for a multiplayer game. The GameCube can then communicate with the game running on the GBA, or if the GBA is just booting up, the GameCube can send an executable to the GBA BIOS which it will then execute from RAM. (Usually, such an executable contains code for doing further communication with the GameCube.)
Yes. Dolphin and VBA-M have support for GC-GBA communication, but the current code for it is very spotty even for casual use and impossible to use in a TAS.
For reference for those who are unfamiliar with the relevant games, transferring Chao between games in this way is similar to trading Pokémon with a link cable. There has been a TAS published to Moons which uses Pokémon trading, so I suppose the concept in general is something which at least can be accepted to Moons. There are however the important differences that in this case you wouldn't be playing two copies of essentially the same game but rather three entirely different games, and that you (presumably) wouldn't be beating all three games but only SA2B.
I don't believe the "The ROM image must be integral" rule is any obstacle to this. The developers intentionally made it possible to link these specific games to each other.
That PR doesn't actually fix the problem that games which replace code without invalidating the icache can behave differently after using a savestate. It's more of a hack to get a few specific games working without having to use the savestate "trick". I suppose the PR would solve some desync problems in those specific games, though. Do however keep in mind that desyncs caused by loading a savestate after a game replaces code without invalidating the icache generally cause game-breaking glitches, so if you have a desync where the input just comes out on the wrong frame or something like that, it most likely has no relation to issue 9561.
He means, a dtm input file can't have 2 different controller inputs at once. Switching from GC contr. to Wii Remote (and vice versa) is impossible during a movie recording.
You can absolutely have two different controllers at the same time. What you can't do is connect or disconnect a controller during the movie.
If I have both GC controller and Wiimote with nunchuck or classic controller connected, the input of the GC controller does not register duing gameplay.
Okay, so this game doesn't let you use a GameCube controller if you have a Wii Remote connected...? That's weird, but I guess it's in the realm of possibility. (Most games that support both controller types determine which controller you want to use by checking which controller you used for getting through the title screen or something similar, though I do also know of at least one game that doesn't let you use a Wii Remote if you have a GameCube controller connected.)
I'm afraid there isn't much you can do about it other than using the Wii Remote then. I would very much like to solve the desyncs, but I have no idea where to start looking.
He means, a dtm input file can't have 2 different controller inputs at once. Switching from GC contr. to Wii Remote (and vice versa) is impossible during a movie recording.
You can absolutely have two different controllers at the same time. What you can't do is connect or disconnect a controller during the movie.
If you want a submittable movie that starts from power on, you have to use a Wii Remote. No way around it, unfortunately.
Regarding the desync problem, do you mean that having a Wii Remote connected is affecting the inputs of the GameCube controller? Or only the inputs of the Wii Remote?
While it is possible to combine two DTM files (maybe you forgot to change the tick count), it is rather annoying to do and is not something you're supposed to do in normal cases. Instead, when you want to continue on a TAS, load the DTM file you already have into Dolphin and continue appending inputs at the end of it.
I was under the impression that nKit compression didn't have any adverse effects on the emulation, and I guess that's not the case.
Most casual players don't think of having identical loading times as something important, and if you ignore that, then it has no adverse effects on emulation... usually. It has been discovered that there's one game that NKit more or less breaks entirely (Super Paper Mario).
Now, the good thing about NKit is that you can convert it back to a good dump that has none of these problems. But of course, this has to be done before you start TASing, otherwise you'll have a rather annoying resyncing process in front of you.
Is there an easy way to resync it with a different ISO?
How easy it would be depends on factors such as how the game's RNG works and whether you used a GameCube controller or Wii Remote. (Wii Remote inputs are harder to hex edit.)
EDIT: The DTM file says that you had both a GameCube controller and a Wii Remote plugged in, so hex editing is going to be tricky. By the way, fsvgm777: If you didn't have both of these controllers configured, that may be the source of your desyncs.
Chamale wrote:
Is this a Wii-only problem or do GameCube ISOs have a similar disc image issue?
GameCube disc images that have been converted to NKit have the same problem.
Oh, so this was done on an NKit disc image... They always have inaccurate loading times (sometimes slower, sometimes faster), and I would not suggest using them for submissions. (The Verify tab in Dolphin's game properties specifically warns you about this if you run it on an NKit disc image.)
1) Its possible to dump a video higher than monitor resolution? I mean, if i have 1080p monitor, can i dump 1440 quality videos even if my monitordownscale them to 1080p then? (for instance, in Dolphin, by using 4x IR and set "dump at internal resolution")
If you turn on Dump at Internal Resolution, then Dolphin lets you do this. However, you can't do it if you're using an older version of Dolphin where the Dump at Internal Resolution setting doesn't exist.
First, I'm running Dolphin on Linux, and while I am aware that using non-stable versions of Dolphin is allowed since stable versions release very infrequently, I'm unsure if the non-stable version I have would be acceptable, since the version numbering isn't consistent with what I see on the Dolphin website (I plan on updating Dolphin as soon as I start the TAS, but at the moment I have "5.0-0491831-dirty". The "dirty" also concerns me.) If I did the TAS on this version, would that be okay?
The different version formatting and the -dirty is due to how the build process works for the Ubuntu PPA. The version you have should match an officially released development build (5.0-11617 in the case of 0491831) in all aspects that matter. The important thing is that the run you made will sync on an official development build, and the builds from the Ubuntu PPA are sync compatible with those builds as far as I know. But if you want to be completely sure, I would suggest compiling Dolphin on your own instead of using the PPA.
And also to ask about ways to be able to quickly tag videos as being for children or not - ie. if anyone has figured out alternative methods for tagging the videos, rather than spending about a minute per video - which is an incredible amount of labour for bigger channels.
You can mass tag videos by going to YouTube Studio > Videos, selecting videos, and picking Edit > Audience. The tagging operation can take a while to complete (or at least it did when I used it the day YouTube sent me an email about it), but you can leave it unattended (and even close the page) once you have started the operation.
what are the rules on using saves from another game
I would assume it's covered by the same rule as using a save from the same game (it doesn't mention that the save has to be from the same game, and the reasoning behind the rule makes sense in both cases):
However, there are certain games with unlockable modes, second quests, or other things of interest that can only be accessed if a save file (or an otherwise "dirty" SRAM) is present. If you really wish to submit a movie made on such a mode, you will need a verification movie made and provided alongside it. Any input file that starts from power-on (for example, a previously submitted movie for that game) and creates the exact circumstances for your submission to sync will generally do.
Note that you don't have to optimize the verification movie: it only serves as a save or SRAM generator that makes it possible to claim the legitimacy of your effort. This submission is a good example.
In any case, ensure a run of your unlocked mode provides meaningful content over a fresh game. For example, if the unlocked mode features all new bosses, but your run triggers the endgame sequence before meeting any of them, and this same glitch exists in a fresh game as well, then there is no benefit to unlocking this mode.
And to be accepted the TAS has to sync with dual core off no matter if it was off or on during the TASing process
The requirement is just that the TAS syncs. You can actually get TASes to sync with dual core nowadays, but you couldn't do it in Dolphin 5.0 stable (barring special settings). While single core is still recommended for TASing, if you've managed to make a TAS that syncs fine on dual core, I don't see why that would prevent it from being accepted.
Dolphin revisions from 5.0-10039 to 5.0-10093inclusivelyshould not be used for TASing due to non-determinism exposed by tweaks to idle skipping. It was fixed in 5.0-10095.
This determinism problem is just that TASes made on Windows won't sync on other operating systems, and vice versa. So while not using the versions that has that problem would be preferable, it is still possible to TAS on them. (Also, the problem technically existed before 5.0-10039 but wasn't as exposed back then.)
Darth Marios wrote:
Just a info about the Dual Core option:
I know it must be off to sync the movie (playback), but its essential to be disabled during the record as well? I mean, it doesnt work if you TAS with Dual-Core ON and then turn it OFF before playback the movie?
The dual core setting must be set to the same value when playing back as when recording.
The time is stored in the movie file and will be used on playback so that you don't desync due to the time being different. But you can still desync due to other reasons, like if you're using an existing save file and the contents at recording time don't match the contents at playback time.
While I do like the idea of calculator TASes, I have to say that TI-BASIC on the TI-83 just is too slow to produce a game that an entertaining TAS can be made for. The gameplay in this (but not the live coding) looks like something a human could have done, including the luck manipulation (since making frame-perfect inputs isn't too hard when the game runs at about 1 fps).
Also, I find the addition of an extra rand in the game's code a bit questionable. Using rand in a loop in that way is commonly used to arbitrarily slow down a game, and this game is already pretty slow, so I don't think a normal game author would want to put a rand there. Does it really make sense to modify the game's code for the specific purpose of potentially make the TAS more entertaining?
