Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
As the format has a variable input rate, and seemingly no way to know when the rate switches statically, inputs cannot be used to derive the movie time. Therefore, GZ cannot become an "accepted emulator" like Doom replays. The format would need to be changed to add in movie time (directly or indirectly) in order to have GZ to become an "accepted emulator"
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
InputEvelution wrote:
CasualPokePlayer wrote:
This of course is not acceptable under normal publication rules, we cannot accept unofficial versions of emulators under normal publication, it must sync on an official release.
Reading this, I'm a little confused. Haven't exceptions been made before about this for Zelda? The published Twilight Princess TAS was done on a version of Dolphin specially modified to make GC Zelda TASing easier, with input files incompatible with regular Dolphin, but that didn't seem to prevent its acceptance. Was there a mistake in the process for that run? Did the rules change at some point to become more restrictive?
That kind of run is part of why we do not accept unofficial versions of emulators anymore. Rules in older days were much more relaxed in this regard (which has lead to other runs (particularly with ancient Dolphin) with lost source code/builds due to them being on deleted forks, leading to runs we cannot sync anymore), and even when they were tightened, judges could override that rule if it was "justified" (I believe this was the case for that Zelda TAS). We do not do that anymore, the closest we do that is just making whatever unofficial version official itself (integrating whatever into official emulator releases, although this is probably more typically making a quick ""release"" of an interim build if anything) or working to make it sync on an official version.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
I am submitting it now because recently the "Triforce%" run was accepted as an "Event", and believe that TASVideos are more open to welcoming non-standard TASes. I think a 100% TAS of Ocarina of Time fits right in, even if it is a bit non-standard (see playback information)
To be clear, "non-standard TASes" was not so much the direct use case for the "Events" class. It's more a rules override for handling TASBot events at GDQ etc, allowing for bypassing normal publication rules, with even the possibility just having some video of the event itself as the publication encode, as it's less the TAS being published, but rather publishing the event showcase of the particular TAS.
Now there can be some debate on what counts as an event (there is disagreement among staff on whether someone's livestream counts as such), but if it is determined this does not count as an event, then it needs to fall under normal publication rules in order to be published. As far as the goal goes, it seems perfectly fine within Standard or Alt (unsure exactly which this fits in, possibly Alt if there are major skip glitches within the TAS yet SRM is avoided; if SRM is the only possible major skip glitch then the goal could be accepted into Standard). For technical requirements, this means being able to replay the TAS, on an official release of an approved emulator (although console-only playback being accepted could come under a rules change; in that case the .gzm here should be the one parsed, not a bk2).
The created ROM is likely too big for the default mupen64plus core (since an entire macro is injected directly into the ROM), and so I've included a .dll that adds extra RAM to m64p in the submission (should be placed in /path/to/BizHawk/dll/).
This of course is not acceptable under normal publication rules, we cannot accept unofficial versions of emulators under normal publication, it must sync on an official release. I'm also skeptical of this kind of change; how does doubling the RAM work, if the problem was the ROM was too large for the emulator? Especially as you couldn't double the RAM on the N64 with just some flashcart, although with a flashcart you could end up having a much larger ROM than retail ROMs normally have. I assume by "too large" it's > 64MiB, as that's the limit mupen's code appears to have. However, mupen is not the only N64 core on BizHawk, another option is the Ares64 core. It appears to accept > 64MiB ROMs (although the commit for that isn't in BizHawk until after 2.9.1, i.e. it will be in 2.10's release). Could you try playing back the "large" ROM on that core in 2.10 rc2?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
TaoTao wrote:
Hi, thanks developers.
Not a bug report, but recently I have struggled to run BizHawk 2.10 rc2 correctly on Linux.
Previously, the sound was not working, and the error log says "client-rt.conf is not found". But I installed PipeWire and related dependencies, and now it looks working. (I'm using Debian testing, and resolved the issue by installing pipewire-pulse and wireplumber packages.)
By the way, BizHawk 2.9 works without PipeWire (only with PulseAudio).
If PipeWire is mandatory, it might be helpful to include this information in the documentation.
OpenAL is used to output audio, whatever underlying library OpenAL uses should be included as a dependency within its package by the package manager (if it's not, that's an issue with the package manager). OpenAL being a dependency is noted in the README file.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
This is probably just a bug with whatever romhack you're using. There's probably not much that can be done other than use really old emulators (which the hack might be relying on).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
Sarsath wrote:
I am having issues with the audio. Sometimes, the music disappears, and sometimes, the entire audio disappears as you can see in this linked video.
Link to video
Is there any way to fix this?
Try using a different a core (Config -> Preferred Cores -> SNES)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
stefanaleksic91 wrote:
In sega cd core cannot pass boot screen please fix it
You will need to give more info.
1. What version of BizHawk are you trying this with.
2. What game are you trying this with.
3. What is the hash of the CD files (the .bin files).
4. What is the hash of the BIOS file you are using.
You can find file hashes with 7zip (Right Click -> 7zip -> CRC SHA -> SHA-1) or just use some online hash website.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
They just use ACE here. ACE is not allowed for standard categories outside of fastest completion, and even then it wouldn't even be particularly interesting to use ACE here for ""Round 2"" since that completely trivializes it (along with any non-Any% category), to the point it'd just be the exact same as Any% with a slightly different payload to do ""Round 2"" (keep in mind you can quickly make ACE extremely overpowered in the context of a TAS where you could make a payload which creates a payload itself using your controller inputs, something that has been used in various Pokemon Any% TASes as it effectively allows for an infinitely long payload that can be created extremely quickly).
Outside of ACE there is some glitch potential, but it's not particularly overpowered. You can dupe items and perform battle corruption with glitch Pokemon to end up catching the opponent's Pokemon, but you can't skip any requirements. You also can't really use it to quickly obtain arbitrary Pokemon, the Pokemon actually has to be registered in the Pokedex to count for National Dex requirements, which the only way to do that with glitched in Pokemon is hatching an egg, which is not particularly fast (better reserved for Catch Em All for Pokemon with long/impossible obtainment requirements). Also the glitch does allow for creating arbitrary held items, but these can't be used for skipping requirements as the game checks for an event flag indicating you obtained the item rather than checking if you actually have the item. The glitch also has a fairly long setup time so it's very questionable whether it could even save time within a TAS compared to a glitchless Round 2 (if anything brings it over it's just being able to quickly complete battles with battle corruption, since you could just also run away from the trainer battle and it counts as a win).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
coolman wrote:
I wonder if a cart with a replaced battery could mimic the effect of being new. It would technically be in a fresh blank state. Would also be less expansive than an unopened game.
This assumes that the save type is actually SRAM (as in Static RAM), and not just one of the other SRAM (SaveRAM) types. GBA games come in a variety of save types. Only Static RAM is volatile (requiring a battery to hold its state), and many Static RAM games just insert Ferroelectric RAM instead, which works functionally the same for the game, except it does not need a battery to hold its state.
Superstar Saga specifically uses EEPROM, which does not need a battery to hold its state. EEPROM, along with Flash, also probably actually have defined initial states from the factory (likely being all 0xFF, which they would be defined as "all cleared"), rather than the ""random""-ish data Static RAM would have without power.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
Keep in mind various TASes (including many non-save glitch and even glitchless TASes) rely on the initial SRAM state for sync, and it's trivial to just write an arbitrary SRAM state to a cartridge, which console verification often does. The initial SRAM state is not a factor in considering whether console verification is possible or not. It is also not a factor for validity here, as it's been ruled that any default emulator initial state is assumed valid for purposes of TASVideos.
The actual issue for save glitch TASes being console verified is the presence of hard resets, which cannot be directly console verified due to a lack of an ability to programmatically hard reset the console (for at least GB/C/A, probably other consoles in practice too). You can kind of mimic it by just writing the correct save data to the cartridge externally between hard resets and playing back inputs for each section accordingly, although that doesn't really validate the save corruption itself, just validating the results of the save corruption.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
The PSP one seems to be added to the database in 2.10-rc1, but it was mistakenly not given unacceptable, this has since been fixed in the latest dev builds and will be marked as unacceptable in 2.10 proper.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
By "unacceptable" I mean the emulator marks them as "unacceptable" within the firmware manager, represented with a thumbs down icon. They would also not be automatically picked up in BizHawk's firmware folder, you would need to manually bind them, at which point you'll end up seeing the thumbs down icon. What you're doing is strictly a power-user type deal, like forcing wrong regions into firmware slots, with no guarantee it will work (and might or might not be grounds for rejection for TASVideos itself).
Regardless too, skipping some BIOS intro or whatever by just using a different (unsupported) BIOS file is just completely pointless for a TAS here: it just doesn't count as an improvement. We do not just use raw numbers here (there are many cases of TASes with longer movie time obsoleting movies due to having gameplay improvements, with the longer movie times ultimately coming from emulation/other non-gameplay differences), and trying to lower the time with just using a different BIOS file is more of a "cheap shot" to be frank.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
1. The available TASing emulators (i.e. BizHawk, which uses mednafen's PSX core) are designed under a specific revision, v3.0 / SCPH-5500/5501/5502. Other BIOS files are considered "unacceptable" by the emulator due to this, and might have other emulation issues.
2. For purposes of TASVideos, "starting faster" with a different BIOS file does not count as a gameplay improvement. Thus this does not count as an actual improvement capable of obsoleting a movie by itself.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
Something to possibly keep in mind: some of the entertainment came from some artistic decisions with the encode:
The SSD wasn't invented yet, so instead the almost 2 minute boot was shortened in the encode by removing duplicate frames.
Fun fact: The audio was added in manually. In fact, what you hear are my own recordings of a mouse click and some key presses.
Also, the setup used an unapproved setup for PCem, this came way before we had PCem setups made and approved, before we had the explicit -st releases, hence the PCem used was self-compiled. In fact, the version mentioned in annotations would be a really early version of the PCem single threading changes based on an older PCem. This early version of PCem single threading no longer appears to exist anymore, as the branch was just deleted off of the TASEmulators repo. Hence the rejection reason is Reason: Emulation and this submission is not sync verified (which at this point might be impossible, unless someone still has the old code stashed away and/or the author still has the old builds somewhere).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
You must provide the disc image (typically .cue file) alongside the ROM using the multidisk bundler. The multidisk bundler can be accessed in the Tools menu.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
Evan0512 wrote:
I found out that the Nintendo DS has more lag than the Wii U VC
The Wii U VC is Nintendo's garbage DS emulator running on the Wii U. From Pokemon RTA circles, it's been tested and it's been found to be the least accurate when it comes to timing, even worse than DeSmuMe 0.9.11 (which is already fairly bad here).
Evan0512 wrote:
running on the Nintendo DSi mode results in the same lag as the DS
The game is not DSi enhanced, so it runs under DS compatibility mode on the DSi, so the DSi should not any kind of improvement in this regard.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
You are not supposed to use Wine/Proton with BizHawk (they are not officially supported, and the Linux zips wouldn't have the Windows native libraries BizHawk bundles, rather just the Linux variants). You are supposed to use the EmuHawkMono.sh file, which launches EmuHawk with mono (and you are expected to install the mono "complete" package with your distro package manager).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
For Gambatte, the cycle count has 2097152 cycles in a second, which usually has 35112 cycles per frame, which corresponds to when vblank occurs. Except not all ""frames"" have that since the game is able to "turn off" the LCD and PPU, which completely throws out any PPU timings (since the PPU goes to "sleep" and doesnt drive the LCD at all), and thus vblank never comes until the LCD & PPU is turned back on (once it's turned back on, it starts back from the beginning at line 0). Gambatte thus might have "short" frames when the LCD is turned back on, since it ends a frame whenever vblank occurs or 35112 2MiHz cycles have passed, whichever comes first.
A cycle count is only actually known at the end of the movie, so it cannot actually be saved unless you're at the end of the movie (and due to some jank reason this has to be done outside of TAStudio with the exported bk2; this has been changed in 2.10 anyways where exporting a movie at the end will produce a valid cycle count). Without the cycle count saved, the site will just parse the movie assuming ~59.7275 FPS (which won't produce the right time, potentially being very off depending on the game).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(732)
Joined: 2/26/2020
Posts: 790
Location: California
(reposting from Discord)
It's important to remember flash player was originally intended just for movies. "Play" (forward/back/etc) are all intended as part of that movie flow. The difference with flash games is they hacked gameplay interactions with that movie format.
So with this, flash games are actually split into "movie clips" (literally called MovieClip) which typically loop waiting for some condition (or something along these lines), clicking these buttons means you're forcing the ""movie"" to go between different clips, instead of using the actual gameplay metric normally used to go between clips.
