It may be that these movies are impossible to sync on emulator with an unmodified ROM instead.
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
For my TAS I decided to stick with the Sword, just because it's the stock weapon. However, making a password that makes you start with the Wand would inevitably result in a slower movie, and thus it could feel harder. In any case, we would enter in an endless argument about which one is more appropriate for a truly hardest play. And this is just Rolan's Curse, which stores very little data in the game password. Now just imagine how messed it could get if we had more settable data to debate of. This doesn't allow for any kind of clear cut, so it shouldn't be allowed as main branch for publication. And the other hand, this submission isn't providing enough differing movie contents for warranting a separate branch, nor meeting the entertainment requirements of the Moons tier.
This term will be used only for these TASing tools (and others that might be created in the future) or it will be a broader denomination?
I figured out how to disable the startup window, for at least a couple of Unity games. Find any files named ScreenSelector.so and remove (or rename) them. (More specifically, remove Plugins/x86/ScreenSelector.so if you're on 32-bit, or Plugins/x86_64/ScreenSelector.so if you're on 64-bit.) As far as I can tell this has no effect on gameplay. Of course, I can't predict whether the judges would allow this for an actual submission; the rules say "No tampering with the files the game is composed of", but that's later qualified with "no ... deleting ... files that affect game-play", so it might be allowed?
QEMU also defines this translationing as the core feature (for emulation purposes): "QEMU is a [..] processor emulator using dynamic translation to achieve good emulation speed". QEMU calls his dynamic translation backend as TCG --> Tiny Code Generator. (linky for QEMU wiki)
Suggesting [3344] Arcade Metal Slug 3 "2 players" by zk547 in 24:27.80
Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
Great, I'm waiting for this movie been published. You guys find a new way to use double standart and accept DK3.
If DK3 can be accepted like this, why not this? NES circus charlie & Urban Champion in 3:21.35
Now that this is apparently accepted to the site, I wonder would it be allowed to obsolete some movies done on Windows with the Linux ports (if exists)?
