Not sure if this is a good place to ask, but is there a custom zelda build ported to the latest dolphin? Would that help in the future in case another person makes a zelda run?
I considered it and even implemented Zelda Edition into a 5.0 branch before, only to be disappointed to find out that they are kinda bad for TASing Zelda games lol. You desync within minutes as soon as you start trying to use savestates. I checked 2 months ago and the problem still persisted. Until it is fixed for good there is really no reason to port ZE to a newer Dolphin branch as ours works better for what we do. The QT interface also seems very immature when it comes to the TAS input.
The better route would probably be to implement some QoL changes into my build such as ffmpeg dumping. I really lack time atm, but if Fog gets anything going I gladly merge it and all future Zelda TASes won't have this problem anymore. We are used to fixing it in post but I understand you guys are a bit more sensitive about these things
Its for fun and to show off a lot of crazy skips, routes and tricks that are just out of reach for a non cheated run (and might even become possible in the future). It's the dream speedrun scenario for this game. If TP were OoT. It is loaded with knowledge and tiny details about the game not many people are familiar with. It even contains some glitches I haven't even told anyone about until making this. So it's basically a 2 hour glitch video featuring most of my extensive research I have been doing into TP for the past 3 years.
Now it's up to him whether he decides to submit it here.
He will. Once he has finished his scripted commentary track. I'm already trying to sync his DTM with Fog, some hardware variations in playback emulation are currently giving us a bit of a hardtime, but we should be able to figure it out :)
A long time ago that was actually standard with Zelda TASes. It fell out of style when the runs got a lot more tightly optimised, but I think it's still considered an acceptable tradeoff.
Though I would assume that it's like any other Zelda and every time the name is said it costs time, not just at the creation, since more characters need to be drawn.
TWW has quick and slow text actually. Quick text you can always skip in 1 frame regardless of length. Trog ensured that Link's name doesn't ever come up in slow text in the TAS route at least, so name length only wastes time before starting a new file
I've discovered a potential problem in Dolphin. Basically, if you're using 4.0-3430 or newer, entering movie recording or playback by loading a savestate leaves Dolphin in a mode that is more desync-prone than if you had entered movie recording or playback in any other way. This problem isn't triggered if you already are recording or playing a movie when loading the savestate, but if you aren't, don't load savestates if you don't want desyncs.
Technical details are available at https://bugs.dolphin-emu.org/issues/9681
This is insane lol. I will die if FMA instructions or something being turned on during recording, but turned off during playback ended up causing most of my desyncs lmao
I talked with Trog now and he will submit his TAS here after the livestream reveal and uploading the TAS to his YouTube. The showcase of the TAS with commentary will happen in 2 weeks, so it should happen rather fast. Then you guys can discuss it out :D
jlun2 wrote:
With that said, I haven't seen the TAS yet, but does it take account into the time to activate commands on a real GBA? Because otherwise the TAS would be quite different than using a real GBA which is limited on said actions.
The code of the build would technically allow you to do things in TAS that aren't doable at all on a real console with a real GBA e.g. buy the floating ability twice with only a 3 second gap between instead of the ~15 found on a real console. That said, this specific TAS never abuses this or similar things and it's very transparent to check for since the game usually makes a sound when a tuner command is used. Trog routed this on a real console/Dolphin connected to a GBA emulator and made sure all tricks are doable in the exact same way. When Trog uses a tuner ability in the final TAS, he made sure that enough time has passed beforehand so that the shop could have been navigated and the ability activated on the exact same frame on a real console. The shop can always be navigated and an ability started as long as you are not inside a loading zone fortunately, so there are not many edge cases anyway in the current TAS route where it becomes close. One time where he could have activated an ability earlier than a real console, he ensured that he waited long enough so it was no longer an issue.
You can't ask everyone to have blind faith of course, as trustworthy as this runner is, so a judge familiar with the game or tuner would need to watch the Movie and at least check for basic irregularities I would say
Here's something to consider. Since the game receives GBA commands via the controller port, it's actually not necessary for the player to use a GBA to send the commands. The player could provide these commands through the controller port through other means (e.g. TASLink). We allow this for Super Mario World total control TAS. The game being TASed here is Wind Waker on GameCube. The GBA hardware is not strictly required from my perspective. Perhaps strict GBA emulation could be a separate branch though if this assumption really breaks things.
I guess this is a fair point. You could technically build some hardware, hook it up to the controller port and you would have an identical experience to the current tuner build. It's still breaking the design of the tuner shop somewhat, but at the end of the day the commands are valid and the game accepts them. Fortunately most things are implemented on the game side, for example you can't buy the floating ability in a few rooms because it would break puzzles, so they are flagged to not be available in the tuner shop while you are in such a room. If you try to send a command to the game to activate it anyway, it still won't work, because the game has an additional check to make sure the command is allowed for the current location.
JosJuice wrote:
My concerns aren't about the Dolphin build itself, but with the verifiability of the TAS. Normally, verifying that a TAS isn't using technical measures to cheat can be done by checking that it syncs in a standard emulator without using any ROM hacks, unverified save data or e.g. questionable emulator settings. That isn't the case with this run. If you want to verify that GBA commands aren't sent in a questionable way, you would essentially have to do it SDA-style, having someone who's knowledgeable about the game look through the run for any potential cheating. I suppose that could set a bad precedent and make accepting the run harder because of the extra verification work needed. It's up to the site staff to decide if that's an acceptable tradeoff, so I'm not going to say that this run should or shouldn't be rejected for the GBA implementation.
This concern is quite fair too, if you want to be sure you need to watch the entire run. Most of it was livestreamed and we can all vouch for it. But at the end of the day someone here needs to decide if is fine or not. I guess the one saving grace is that this case is extremely unique and likely won't occur pretty often. So it's unlikely an approval could be interpreted as a sign of lax ruling with people coming out left and right trying to submit movies done on questionable emulator versions. Making the Zelda Edition specifically official would help matters in this regard somewhat I suppose. It's a pretty good build in general for TASing games and the source is there for everyone to check. Maybe I need to rename it soon :P
MUGG wrote:
From the problems listed, the waiting on the name entry actually worries me the most. A TAS shouldn't sit on a screen for many seconds for no reason. A "mistake" like that shouldn't slip through, it's very avoidable too, so I'm not sure why it happened. Was it not clear to Trog that TASvideos runs are timed from power-on?
When I coded the fake tuner I discussed it with Trog and we both arrived at the conclusion that it wouldn't stand a chance to get a pass here. So the TAS was started on the assumption that only RTA time would matter and everything before file start doesn't need to be optimal. I just talked to him again though and the only thing he did was to spell his name out, so 20 frames wasted or so seems fine.
I'm quite pleasantly surprised actually that people want to see this Movie featured even if it might stretch the rules a bit. Some common assumptions about this site today are sadly quite untrue as it turns out. Most people I know including myself thought there wouldn't really be any exceptions made and that a movie has to sync for everyone etc. I have no problem with strict rules, but it's good to see special cases are being recognized.
Speed/entertainment tradeoff. As long as it's not overly long (like, a couple minutes or so), it's okay.
Definitely not. He is just spelling his name out. Like 20 frames wasted maybe. So that should be absolutely fine then :P
All it has to do is sync for an encoder or publisher. If one of them can get it to sync, then it won't be a problem (unless it completely fails to sync during the dumping process).
That is good to know. I'm sure someone out there will be able to sync it (I hope lol)
This is akin to the Sonic camhack encodes. As long as it syncs without the hack, it's absolutely fine.
Cool, I know for sure it does
We are considering (though it is absolutely not final yet) accepting it regardless, mostly under the condition that Dolphin TASes are technically always done on interim builds anyway. This would be something the Judges and Admins would have to talk about further, but I would say that it shouldn't stop the submission in case we do come to the conclusion that we can accept Dolphin builds like these.
Case in point, I would absolutely recommend he submits it. The worst that would happen is an extremely respectful rejection for a reason that might even be overturned or redacted later, allowing the movie to still be published. Either it doesn't sync for a publisher or we decide at the moment that we can't accept the Dolphin build: I feel like someone, probably Fog or RGamma, will get it to fully sync, and I also have the feeling that our audience will want to see the movie published even if it means a slight breach of the rules (which a couple of the staff are already slowly getting on board with anyway).
I will let him know. I guess trying doesn't hurt at the end of the day
I did supporting work for Trog's TAS and I also developed the tuner Dolphin build. I would certainly like to have the TAS on here, because of its extremely high quality and the unlikely chance there will ever be a better one in the near and far future. But as mentioned, there are several issues which I think will block a submission:
-Afaik Trog messes around on the file name screen and changes Link's name once or twice. Only RTA timing was considered at that point, so this would look bad and extends the TAS timing needlessly
-To skip dialog/text Trog simply turbo mashes A and B the entire time. It doesn't loose any time, but I know unnecessary button spam is looked down upon on here
-The TAS randomly desyncs even for Trog and it is unknown if any other PC can even sync it at all
-Trog uses a hack to disable fadeouts to black from door storage so the game remains visible. This is done for entertainment purposes so the viewers see whats happening since otherwise the screen would just be black for 30 seconds. Fortunately the TAS still syncs with the hack disabled, but the dump will have it
-The following rule is violated since the TAS uses a custom unofficial build for tingle tuner support: "Always make sure your movie syncs on the official releases, use interim builds on your own risk. If it syncs on some interim build , but doesn't sync on any official release, it will be rejected"
The tuner implementation is also problematic. The way it works is that a "real" GBA controller is added to Dolphin, so the game is accurately under the impression that a GBA is connected. It will send requests/commands through the link cable exactly as a real console would do it. So far so good. But since VBA-M and Dolphin dont work together well enough to create a syncable movie, the custom build takes a shortcut to provide consistency. The commands are still received at the same intervall as on a real console, but the code of Dolphin itself analyses the commands and responds to them like a GBA would do it. The connection speed thus is accurate. The knowledge about how the GBA responds to game commands was gained through dumping the message stream between a Dolphin and VBA-M connection.
Pulling the tuner out and connecting to the GBA for instance is very accurate. But the big problem here is that as JosJuice mentioned the TAS Movie file doesn't store any GBA inputs, but commands the GBA should send to the game. It's saved as an arbitrary ID designed by me and simply contains the end result e.g "d-pad up pressed" which is quite accurate, but also something like "user bought a health portion". This command gets send from the fake GBA to the game which then reacts to it (subtracts rupees, gives portion, etc.). Navigating the tingler tuner shop doesn't occur.
Second big issue is that the implementation isn't complete. For example there is an activation delay between buying an item on the shop and the GBA actually sending the command to the game to activate it. This is done so you can't for example heal yourself every 5 seconds. This is ignored on the custom build and you could use items much more often if you wanted creating situations that are unable to be re-produced on a real console. Now Trog tested every single tuner usage on a real console and paid close attention to make sure he arbitrarily respects the activation delay down to the frame and everything else. Thus everything the TAS actually does works 100% confirmed on a real console in the exact same way and time which can be easily proven as well.
Still, as legit and amazing as the TAS is coming from the most trustworthy person there is, it would need serious bending of the site rules to get through submission. Again I would like to see it on here to reach an even bigger audience, since the TAS easily deserves that for the amount of effort that went into every aspect of it and the fact there won't be a better one for a long time. Having TWW finally on here would be amazing. But rules exist for a reason and thus I wouldn't be surprised nor sad if there is no possible way this wouldn't get rejected. It will get plenty of attention elsewhere I'm sure :)
If you guys are having problems with savestates having desyncs, we're relying on you to report it so it can be fixed! If it only takes minutes (which, isn't TOO bad, but still kind of rough) a bisect shouldn't take more than an hour.
Very late response, but I just got back to testing this. I can't say for certain if it's even related to savestates, but in either case the issue of movies desyncing fast in Wind Waker and probably other games exists as early as 5875. I know for a fact it doesnt exist in 5371, so the issue likely crept up between those 2 points. I also tested the most recent build 9327 and it still had the issue. Didn't have time yet to nail it down further between 5371 and 5875 since recording up to 10k frames can be quite time consuming. But I will get back to it tomorrow :)
Figured I should briefly mention my Zelda Edition fork (https://github.com/dragonbane0/dolphin) here since a few people referred to it and it became the de-facto build to TAS Wind Waker, Twilight Princess and FSA and is used for all WiP TASes of those games afaik. It mainly adds a few comfort functions for TASing with the intention of making stuff more straightforward, fixes a few annoying issues and generally tries to keep up with useful improvements to the core that don't impede TASing stability (e.g. the memory leak fix).
The newest official releases sadly seem to be broken for TASing of a few games. Namely Wind Waker consistently desyncs within mere minutes of recording even if you use optimal settings. So I wasnt able to merge my build with a recent master yet and its still based of 5371, which is relatively old now. But at least its very stable for TASing and already includes the near console accurate loading emulation.
I'm hoping to polish up some of the things I added (it would need a lot of polish) to eventually bring them into the master or help with existing implementations. Some of the stuff I added:
-Display Memory Values directly on the OSD
-Basic emulation of a fake tuner to help with TWW TASing (so it can do the most optimal any% route)
-Helper UI that allows to splice DTMs together
-Use DTMs to create a video comparison inside Dolphin (including a timer) without having to own expensive video editing software
-Some comfort functions entirely exclusive to TP and TWW
-Basic LUA support for every game including auto starting scripts and launching scripts on command. The feature set isnt too great yet, but you can do the basic stuff (manipulate memory, save/load states, make inputs, do maths etc.)
A compiled version to play around with can be found here: http://www.mediafire.com/download/51lh1xefu3rg3q2/Dolphin_ZeldaEdition6.0.zip