Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
Bisqwit wrote:
In any case, I don’t know what calculations the site uses today to derive the movie times in seconds, as I have been kept out of the loop for years.
https://tasvideos.org/PlatformFramerates stores all platform framerates used by the site. How the site derives times is explained on that page (surprisingly very detailed in that regard).
For NES, 60.0988138974405 FPS is in fact used for most publications. Most publications using 60 FPS would just be really, really old legacy movies that used 60 FPS (generally with Famtasia or FCEU, that kind of old, around FCEUX the framerate was switched over it seems), whose framerates aren't stored in platform framerates (framerate was just derived from the movie time when the site data was imported from the old (previous) and new (current) site, a needed step as the new site does not store movie times explicitly, but rather only a frame count and framerate).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
Firmware is not required for Gambatte, unless a movie is being recorded, then BizHawk mandates that firmware be used.
There isn't really much of a "good community" to ask on dumping the bootrom, besides maybe the gbdev community? Even then, most do not actually do that, since again, it is a process which requires a clock glitching setup (being, quite literally, opening up the Game Boy and attaching wires to glitch the CPU's clock, something which can easily damage a console if done very improperly). Most simply just acquire them the same way they acquire game ROMs.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
iceci2804@gmail.com wrote:
Also, in the latest BizHawk, whenever I try to open TAStudio with the Gambatte core, I get a warning saying, "Couldn't find required firmware: GB+world."
Is there any way to fix this?
You acquire the firmware and put it in BizHawk's Firmware folder.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
Acquiring firmware is like acquiring games, generally legally you'd have to dump it from your own copies, and generally other ways aren't legal. The exact process for dumping the GB and GBC BIOS is a bit complex, since it requires a clock glitching setup (this forum isn't really the best place for that info).
Also, I would strongly recommend not using SubGBHawk, but rather use the Gambatte core in BizHawk. It can be set to subframe inputs in its sync settings (rather than being a separate core), changing the Frame Type to User Defined Frames.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
Looking at the TAS it seems fairly optimal. However, doing light checking I found out the menuing can be slightly improved. The options menu can be exited by pressing the "Option" button instead of needing to scroll over to the Exit option, saving 7 frames. Although resyncing the TAS with this changed ended up only yielding 4 frames of improvement, as later transitions had extra lag.
My userfile with this minor improvement is here. dekutony, if you wish the movie can just be replaced with this (without any co-authorship, the improvement is so minor and doesn't even touch gameplay I'd rather not have such in this case) and judgement could continue onwards, or you can look into trying to eliminate that extra lag or do any other improvements if you wish.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
CoolHandMike wrote:
What is the recommended way to play this back in Bizhawk or encode a video for it from Bizhawk? Taking a look at the bk2 file and it is 68.7 million frames long.
You just play back the bk2. Set to unthrottled. Optionally disable host rendering (Config -> Display -> Misc -> Absolute Zero) and sound output (Config -> Sound -> untick Sound Master Enable) for more speed.
For encoding a video, just do AVI Writer with native resolution and upscale later with AVISynth or whatever. Don't use the FFmpeg Writer, it will not be happy with the subframe input spam. Also of course use Sync to Audio (default) for encoding.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
lapogne36 wrote:
Dolphin settings : Dolphin 2412 default settings (it seems to sync fine with Dolphin 2503)
Please post your Config folder within Dolphin's user folder (go to File -> Open User Folder in Dolphin's main window to open such). Also post the SRAM.raw file within the GC folder in that user folder.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
Spikestuff wrote:
blinks
Ok... question. Or alternatively highlighting my terrible reading ability.
Would this method for what's produced mean that there's a way to make a more fluid/clearer, GB TAS?
For how the video is produced exactly, probably not, not without cutting the framerate to 10 or maybe 8.5 FPS? (and even that is likely going to have tearing regardless as you can't transfer that many tiles at once, and that's ignoring audio needing to be handled). Or perhaps instead of cutting the framerate the resolution is cut with some kind of letterboxing in place.
Keep in mind the amount of bytes I'm constantly transferring to VRAM, 5760 bytes within 3 frames, is much much higher than the 360 bytes transferred within 2 frames that the Yellow GB TAS is doing, and this is only possible due to the benefits of double speed mode (doubling the rate I can read out of the joypad) and VRAM DMA (more than quadrupling the rate I can send bytes over to VRAM, not to mention reducing register pressure).
The current method of only replacing the tile map however likely could be improved (mostly guessing due to the numbers, even 360 bytes should be able to be sent within a single frame and thus have no tearing). Perhaps even different tricks could be used to increase graphical fidelity.
For audio, that very much could be improved with the volume trick, as acknowledged in the Yellow GB TAS submission (although whether it can go as high as 36KHz is another matter, perhaps that would need 18KHz rather, but I digress). Even the write to wave ram while channel active quirk could be used, although that is somewhat questionable if that ends up just meaning using a GBC in DMG compatibility mode (which of course retains the hardware quirk the same as a GBC game).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
Patashu wrote:
At 5:11 to 5:13 there's what sounds like an audio glitch (one of the instrumental hits clips for a moment). Is that a defect in the TAS or in the encoding or just some weird consequence of how it was set up?
The audio defects just come down to the effectively reduced bit depth. With the audio setup, only 104 unique amplitudes are available, non-linearly spread out, with more unique amplitudes available within the center. There isn't much that could be done to fix this (other than maybe doing some manual adjustments within the PCM converted data to reduce the impact).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
TiKevin83 wrote:
But at the same time, reductio would say it would be crazy to accept 50 TASes of Yellow like this that ACE in different videos.
A better question here is actually, why Yellow? Why not Red/Blue, Gold/Silver/Crystal, maybe Link's Awakening, or even Shiren GB. Bad Apple itself has pretty much no connection to these games, just like Yellow, and all could potentially end up running nearly the exact same code.
Of course, if you want to say "use the fastest ACE exploit," Japanese Yellow is likely not the fastest GB game in this case, Red/Blue is probably faster (language differences aside). Maybe even Shiren GB is even faster (although how much extra time is needed to gain full control is difficult to ascertain). "Use the fastest ACE exploit" would end up possibly being English Yellow for the GBC however (which is kind of partly a reason for MrWint to use that, but even then there's artistic reasons besides that).
Of course, then again, you have the NES Bad Apple TAS which just decided to use Super Mario Bros with cartridge swapping to allow for ACE (and even that is somewhat sketchy since that was just abusing loading a savestate made in Super Mario Bros 3, which acts as a pseudo cart swap), which throws game choice even more out the window. The run technically had some gameplay before Bad Apple, although that is somewhat more shoehorned in before the actual ACE playaround (keeping in mind ACE already happened before that point, with Super Mario Bros 3).
We also have this in the movie rules, which proceeds to make the above even more questionable
ACE is freely allowed in playarounds, though the spirit of the original game should be maintained, and copyright should not be infringed. Fair use applies here.
This rule is arguably violated by this run and the Super Mario Bros run, since the actual ACE playaround is just Bad Apple.
Of course, this is if we're saying this is actually an ACE playaround. The fact it is devoid of originality and just effectively plays a video which has no connection to the game means it is more just a technical demonstration, like demoscene (which at that point these Bad Apple runs exactly matches such).
Of course, if we're effectively just doing demoscene, why even use an actual game? Why not just create a custom ROM which streams video/audio from the joypad and play it back. With say Super Mario Bros 3 that's only a very very minor step away from an actual game. With such a custom ROM, you also could just "recreate" whatever game you want. Play back a video "doing ACE" in whatever game, play the video you would be playing in that ACE payload within that video, and have the end of the video being "completing the game," fanfare and all. As far as some YouTube viewer would tell, it would be exactly the same as doing ACE within the game. Only when you look at the description do you find how the game is no longer actually present.
That last point is more hyperbole, as it is more like if you were to video edit some ACE segment within an existing movie video. The only difference is you have a movie file in the end, although you couldn't actually play it back in any actual game, only within this custom ROM which is not a video game.
These points aren't necessarily against having this movie published nor for having Bad Apple NES unpublished (Bad Apple NES being published arguably marks precedent in itself which we would not want to reverse), but more shows there needs to be discussion on how to handle these TASes, if they don't actually qualify as ACE playarounds under the current rules, but are more just technical demonstrations.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
TiKevin83 wrote:
I kinda want it to be, because here there's uniqueness enough possible between JPN vs ENG Yellow and as you said possible technical aspects of the video player (I am not enough of an assembly expert yet to validate that).
The main reason why JPN and ENG would even have differences within the video player is just because JPN Yellow is a Game Boy game, while ENG Yellow is a Game Boy Color enhanced game. Even ignoring color (which you practically can do if you want to due to the way GBC graphics work), you have 2 very unique tools available on the GBC: double speed mode (doubling the amount of CPU cycles you have in a frame) and VRAM DMA (allowing for the fastest possible VRAM transfers).
Bad Apple also technically itself gives a difference, it's mostly black and white, with some grayscale for aliasing. It mostly looks the same even if you reduce it down to 4 colors/2BPP (i.e. white/black and 2 shades of gray). It's also not exactly made so you can just easily replace it with normal tile based rendering (therefore the effective video resolution gets reduced if tile based rendering is done). So on the GBC, you could potentially substantially improve the video quality, depending on what you want to improve, what you're willing to sacrifice, and how carefully timed your code is.
TiKevin83 wrote:
RE emulator choice, lsnes is fine since you can't console verify these anyways, GBI's playback format doesn't have the resolution to send inputs this fast.
This being done on the GB ends up bringing up a different point which also "prevents" console verification. For these TASes, Channel 3 is abused in order to output effectively arbitrary PCM (although Bad Apple probably could be done "chiptune" regardless, but for completely arbitrary audio from completely arbitrary videos off the internet you want arbitrary PCM). In MrWint's TAS, he also abuses the volume register to turn the 4 bit Channel 3 PCM into roughly 7ish bit PCM (the volume register is a multiplier here, with 8 different values (3 bits), although it won't result in all sample values being available due to a lot of multiplications resulting in the same value).
Why bring this all up? In order to create arbitrary PCM, MrWint's TAS abuses a quirk with wave ram here, one which is unavailable to the GBA. MrWint writes to wave ram while it's active, keeping it active forever constantly looping through values he writes. If you end up writing to wave ram while it's active, on the GBC (but not the GBA), the written byte will just go to wherever the channel last read wave ram. This only ends up played 32 samples later anyways since the last read sample is cached). On the GBA, instead the write just gets ignored, requiring the channel be disabled to write to wave ram (although you don't want to force disable the channel). The GB also mostly acts like the GBA here, except on the exact cycle which wave ram is read by the channel, which allows the write to go through (and redirects the write over to where the channel read wave ram, like on the GBC), requiring exact precise timing if this quirk is abused. However, that would end up creating some (minor?) distortion with the volume register abuse, since it couldn't be timed to the exact sample read (as that has to be delegated to the wave ram write rather).
In the case of this TAS, neither of these quirks actually abused, somewhat like if it was done on the GBA, resulting in the very low quality PCM, especially so as wave ram has to be constantly reloaded. In the case of this TAS, it ends up disabling the DAC in order to disable the channel, which you don't really want to do as that would result in an audio pop (although, I'm not sure if old gambatte here is accurate enough for that or if it's just the audio being so crunchy it's not really noticable). And on the GBA, due to even more quirks with how channel 3 was implemented, this doesn't just cause an audio pop, it results in a loud spike (there are techniques to avoid this, but that of course consumes more precious CPU time, which is even more precious if you also want to abuse volume).
Of course, a GB TAS can just be done on the GBC rather in its DMG mode and abuse this quirk. But either way, it prevents console verification being done on the GBA, even if the input rate was not an issue (unless you don't care about the audio here anyways and consider sync "good enough").
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
To be clear, I am not saying "you shouldn't do this because it has already been done." I'm saying the run becomes heavily devalued from an artistic perspective. Purely on the technical side, it isn't really devalued from that (even the "wasted potential" is more on the artistic side if anything).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
For more an actual criticism for this TAS.
It's Bad Apple.
As funny as that is as a meme... it's a well known old meme. As such, the actual playaround segment is effectively completely unoriginal in an artistic sense. And to be frank, this criticism also applies to the Super Mario Bros Bad Apple TAS.
Even on a technical aspect, the TAS is somewhat unoriginal. It follows the same principle as MrWint's Yellow TAS and the other Bad Apple TAS: you turn the video game into a video. The originality then just becomes the setup for such (which is impressive mind you), but at such a point it seems kind of like wasted potential if it's just used for Bad Apple (something that the other Bad Apple TAS frankly has for a criticism, but slightly less so since they were "first" wrt doing it within a TAS). At the very least, MrWint's Yellow TAS was fairly original for what it was, and kept a semblance artistically of it still being a game (even if by a technical aspect it's not actually much different than playing a Bad Apple video).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
So I tried 2.8 Octoshock, and the problem isn't there. (Edit: Strangely for 2.9 and 2.10 Octoshock, there's still that input delay problem.)
This doesn't make sense, there are no core changes between 2.8 and 2.9 Octoshock. Testing it myself, and I find no difference between 2.8 Octoshock and 2.9 Octoshock and Nymashock. Are you sure your controller configuration is identical between the two?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
In this case, I would rather not submit, as again I do not want Round 2 to obsolete a pure Any% run, as I do not want the Any% category to require beating Round 2.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
I've submitted a TAS of Pokemon Black. This is an "Any%" run, defined under the same ruleset as RTA.
Like other Pokemon games, the game features a "Round 2" for the Elite 4 and Champion. However, most Pokemon games, unlike FireRed/LeafGreen, do not actually place any extra conditions in order to fight this round 2, other than the possible pseudo-requirement of getting better Pokemon due to the levels jumping up dramatically. As such, you can just directly fly back to the Pokemon League and immediately fight the harder second round of the Elite 4 and Champion.
In this game too, round 2 is slightly more interesting as it is the only time you fight the Champion, as he is not fought in round 1, due to plot reasons, and is also the only time you would enter the Hall Of Fame that traditionally ends Pokemon runs. However, even with this... Round 2 ends up only being 5 extra fights after Any%, leading to a potentially nearly identical TAS compared to one purely aimed at Any%. However, also despite this, Round 2 has extremely interesting routing, and is possibly a miracle if a run aimed for Any% can even complete Round 2, due to the massive level difference.
I've already made such a round 2 TAS, continued directly off my Any% run. I would want to possibly submit it, however, the run has 2 rather conflicting goals.
A goal for this run is to be continued directly off an optimized Any% run, not having some arbitrary amount of time to just overlevel my own Pokemon before completing Any%, as that would trivialize the goal.
A goal for this run is not be a new definition of "Any%", I do not want such a run to just "obsolete" my Any% run, despite the beginning of it just being identical. Any% could very well end up developing strategies which result in being unable to complete "Round 2" (noting that my own Any% run is more a miracle in being able to beat Round 2 due to the massive level difference).
For the second goal, I wouldn't particularly mind if this run was changed so it just start off SRAM (would need some time to resync but that's somewhat trivial), so the content of the entire movie is rather the unique round 2 fights. However, that of course starts conflicting with the first goal, since the goal is again to not have some arbitrary amount of time "preparing" for Round 2 (since that trivializes the goal). Or in another way: the goal requires optimizing the verification movie along with the save anchored movie, as if the verification movie is "suboptimal" that can compromise the routing potential of the final goal. Would this goal be able to be ensured in such a case, and comparisions for obsoletion made with consideration with the verification movie?
If such a category including entire Any% within the submitted movie does not result in obsoleting pure Any%, I would not mind too much if I just submit my movie as is, with Any% included. However, I would want it to end up potentially having just an encode for just the "unique" Round 2 fights (i.e. everything after the soft reset after first round of credits). Would this be able to be done, even if as some secondary encode.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
This goal of this game was to exhaust all available puzzles as the game seems to loop through the last 3 puzzles indefinitely after each one has been played. ... Thus, this TAS stops after completing level 24 as no new levels show up after that point.
This doesn't seem correct.
Looking into this game's code, it has a level counter, which appears to technically increment "forever" internally (until it overflows to 255 -> 0 -> 1). Each level increases in difficulty, until level 22, which is the difficulty cap. Any other "level" past that appears to be just a result of different RNG (until of course eventual overflow).
The "22/23/24" looping seems to be more the result of the poor RNG implementation used, along with partly the initial seed that ended up being used (from what I've found, the game's RNG ends up looping either 3 maps or 4 maps in the end). As such, levels 23 and 24 shouldn't be needed here, once level 22 is completed, the maximum difficulty has been completed, with any other level just being a result of different RNG.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
You need to actually describe what parts are bad about the Hex Editor and what can be improved with them if you want any improvement. "why cant u just copy the mesen on" it's a completely different codebase written with a completely different underlying code, you cannot just directly copy paste some Hex Editor in another emulator; if we actually knew which parts conceptually are better we can try to mimic them, but that requires actual specific details.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(926)
Joined: 2/26/2020
Posts: 834
Location: California
CasualPokePlayer wrote:
Fortranm wrote:
Out of curiosity, how different would the portion from the start to Ghetsis be if the ending point is Hall of Fame (Alder) instead? Is it mostly just getting X items early on?
I don't think much would actually change. Stoutland is perfectly capable of dealing with round 2 of the E4 and the Champion. X Items wouldn't save any time here. If anything, the Quick Claw probably wouldn't be unequipped (or maybe it can just be re-equipped mid-E4?).
Link to video
In some Any% TAS that optimizes for E4R2, Quick Claw would not be removed ever. Also, maybe Work Up would be taught much sooner.
Note that the strategy employed here was one which balanced out absurd RNG. This is around the limit of how lucky a battle can realistically be (with Marshal and Shauntal being the luckiest battles). After a certain point, there aren't battle RNG seeds that can be easily found (if even possible).
