Posts for Bigbass


1 2 3
6 7
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Woo! Yes and for NES specifically, we've reached over 200 currently published verified runs! Out of 696 total active publications. Recent homebrew has perhaps stacked the numbers slightly, albeit if anything it was Nalleland in particular, having 5 different branches. That said, I've recently verified many non-homebrew games too. I'd like to thank Alyosha for his work on NESHawk. It seems apparent to me that the success rate of NES movies made with BizHawk 2.8 is noticeably higher than previous versions, and similarly when compared to FCEUX. Although plenty of FCEUX movies do verify too, NESHawk has addressed many possible edge cases that have been encountered in the last couple years. Up until this month, for awhile I had been fairly absent in recording new verifications. Was working on unrelated projects, but also a new replay device. At this point the NES replay functionality is pretty solid and it has improved how efficiently I can make verification attempts (thus the influx of recent NES verifications). I'm going to continue attempting more NES movies for the moment, though I am looking into which console I want to work toward next. Will likely revisit N64 momentarily, and then either GB/C or Genesis. If anyone reading this is familiar with FPGA development. I'd really appreciate having an open source/hardware NES flashcart, with similar mapper support to the Everdrive, but cheaper, with USB uploading, and purposefully no boot menu (as the everdrive's menu changes the initial state of the NES, making some verifications impossible for me). I have an idea how to implement this, but I probably won't start working on a prototype until after SGDQ.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
OtakuTAS wrote:
Zelda (this era) is a much simpler game, with easier movement. That's definitely reflected in the count.
Reflected in what way? The linked example movie required more rerecords than frames, which would seem like the opposite of what you said. If the movement was easy, then why were there more rerecords? And more importantly, how do you know that the rerecords were because of the movement and not something else?
OtakuTAS wrote:
it also has no negative effects
But it does have negative effects, as feos pointed out:
feos wrote:
  • Sometimes low rerecord count is used as a reason to question the movie, without actually looking into its optimality, and sometimes authors are even asked questions about why the number is so low.
  • Rerecords cannot reflect research and development behind the scenes
  • Some people work with several movies at once, and their rerecords don't even reflect their actual TAS work (unless they explicitly sum everything up)
  • Regardless of research and development, rerecords can be set to an arbitrary number, which makes them a completely meaningless stat in those cases
  • Even legitimately high rerecord counts won't tell a lot about actual movie quality, because to understand it one has to understand the underlying challenge, which in turn requires facing the same problems as the author did. And that may be impossible because the ground work has already been done, or if the author is good at writing, it can be described in the submission text
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
I don't feel there is any definitive purpose of rerecords. We could say that it allows us to quickly identify movies that are likely low quality. Yet, actually it can't unless we look at other data. But that other data would already tell us the answer regardless of the rerecord count. For example, movies that are improvements on past publications. In some cases, but not all, the rerecord count is going to be very low. Does that mean that the movie is low quality or that very little effort was used? Impossible to say with just the rerecord number. We could say that in light of some witnessed behavior in the movie, that the rerecords offers a quick explanation of that behavior. But does it really? We don't know which sections of the movie the rerecords are from. Did the author struggle in one part which turned out great, and then simply missed/overlooked time save in another part? Was the author just highly skilled or knowledgeable about the mechanics of the particular game? Or were they completely clueless? We can't know for certain with just the total number of rerecords. It doesn't appear to me that rerecords are a good indicator of anything. At best, it can create speculation, doubt, or suspicion.
In considering what to say on this topic, I tried to calculate some statistics of movies on TASVideos (using the site's API). It was incredibly difficult to make any reasonable comparison based just on the rerecord value. To me, there's no obvious correlation between rerecords and anything else about a movie. For example, here are two movies. Both are in the Stars class, both from the same console, of similar length, and both were highly rated by viewers as entertaining. Yet, when we compare the number of frames to the number of rerecords, they are entirely different:
MovieRerecordsFramesDiff
[4268] Genesis Michael Jackson's Moonwalker by EZGames69 & Bloopiero in 18:30.009297166514+26457
[4473] Genesis X-Men 2: Clone Wars by Truncated & Sonikkustar in 15:58.982488057465-32585
What do the rerecord values tell us about these movies? Which one is better than the other? Which one had more effort and work put into it? The answers to these questions are not obvious. Here's two more movies. Again both Stars, same console, both fairly long length, highly rated by viewers. Yet again, the difference in rerecords vs frames is significantly different. Additionally, compared to the two Genesis movies above, the rerecord vs frame differences are fairly similar despite these movies being drastically longer.
MovieRerecordsFramesDiff
[3874] SNES The Legend of Zelda: A Link to the Past "full inventory" by fmp & Yuzuhara_3 in 52:52.44211959190660+21299
[2307] SNES Super Mario World "all 96 exits" by bahamete, kaizoman666 & Masterjun in 1:14:37.63246089269100-23011
What do the rerecord values tell us about these? Anything? Nothing? Who knows. Only a deeper study of the movie will give us answers.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
ThunderAxe31 wrote:
FCEUX doesn't emulate NES faithfully, so movies made on it can't be reproduced on real console. BizHawk movies instead can be reproduced on real console.
If by reproduced, you mean being able to succesfully replay a movie on real hardware, then that's not accurate. Movies made with FCEUX have been verified on real hardware. This even includes very old movies such as [905] NES Dizzy the Adventurer by alden in 07:49.67 published in 2007 and made using FCEU 0.98.16; albeit it depends on the game. Statistically speaking, BizHawk does appear to have a higher success chance though. Using only my own test results (in number of movies):
EmulatorVerifiedDesyncedPass % per Emu
FCEUX8811942.5%
BizHawk363650.0%
Note the sample size for BizHawk is significantly smaller primarily because for awhile after I first started attempting verifications, dumping inputs on BizHawk on Linux was quite slow and tedious. I know some of the desynced FCEUX movies have since been verified by Alyosha, often because it was resynced to BizHawk. Additionally, some movies from both emulators, would desync because they required WRAM initialization, which I don't have the hardware to do. That all said, it does appear that BizHawk, particularly Alyosha's NESHawk core, tends to enable higher chances of verifications than FCEUX. Plus, I know that Alyosha also has spent time emulating specific quirks that previously prevented some games from being verified, regardless which emulator was used. Regardless, movies made with FCEUX do have a decent chance of verifying on hardware.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
TaoTao wrote:
Sorry to bother you again, but could you verify this NES Dragon Quest (J) movie
No worries, it's not a bother. So good news and bad news. The replay works a lot farther than before, and when it's working, all of the NPCs are always where they are expected to be (which indicates the RNG is the same). But it desyncs during the glitch (approx. 05:53 in your video). As usual for my attempts, the replay was started from reset at the intro screen. I've uploaded a recording here for comparison (unlisted, and I apologize for the wiring mess and no input displays): Link to video (Please note, the camera is recording at 30 FPS, not 60, so anything that would be visible for only 1 frame, may not appear in the recording)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
TaoTao wrote:
But I found a strange quirk. I tried inserting a reset frame at the beginning of my movie
That could just be a quirk of the emulator. The initial boot sequence as seen from a TASing perspective isn't necessarily correct (although NESHawk I think gets it more correct than FCEUX). For example, there are games where you can have exactly the same inputs between FCEUX and NESHawk, but save 2 frames in NESHawk because the number of "lag" frames at the start is different. This was discussed as part of Final Fantasy's stair glitch branch. Furthermore, the experiments you show here don't represent what's happening when I reset the console to begin the replay. The initial reset could happen at any point after the game has started (it's impractical to start the replay within the first 5 frames of the game). It would be as if you inserted potentially hundreds of blank frames at the start of the TAS. Like I said, normally this doesn't matter, and I'm not sure it matters in this game either, since starting from reset always produces consistent results, albeit different from what the emulator expected. Additionally, even if I could start the replay at the same frame the emulator thinks is the start, the reset you're adding to the TAS inputs wouldn't actually be used until the first input poll. This is just due to a limitation of the replay device, as the only way to stay in sync with "lag" frames, is to monitor the composite video output of the console and watch for the VSYNC pulse (which may not be the same way the emulator tracks frames.)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Definitely a yes vote from me. Been waiting to see this a TAS of this game for at least a few years now. The game's mechanics are so absurd and convoluted, but it's done in a way I find quite hilarious. Seeing the player really sprint around the screen is fun too. Also thanks for the text commentary in the encode video. It was interesting to see that you were able to beat Hellsmoke without using a slower game speed. I still recall Mikwuyma's run of this game during GDQ, where he noted it was impossible to beat without using slow (though I see that's more of an RTA difficulty issue, since TAS can manipulate the RNG). Overall an entertaining TAS, and nicely detailed submission notes.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Hmm testing this one out and still encountering desyncs. I'm curious if the replay must be started from power-on. I normally start from reset, because I use an everdrive which means I can't boot directly into a game. For a majority of NES games, this is completely fine, but there are some games, like Hydlide for example, that performs different code on boot compared to on reset. (and some games change where the program flow jumps to at reset, depending on how far into the title screen you go.) You mentioned in the submission thread that the game updates RNG every frame. Now, starting from reset is still consistent between attempts (but different from the submission movie). However, if I don't reset when I start the replay, every attempt is indeed different, often desyncing by running into an NPC, or eventually entering an enemy encounter. What I'm curious about, is if somehow there is an RNG difference between power-on state, and reset state. Or in other words, if there is some part of the game that the reset routine doesn't affect, which results in a different (albeit consistent) result than what is seen in emulator. It is possible to start a replay from the everdrive menu, but it's a bit finicky and my replay device isn't designed to do that, at this time. A couple years ago, that's how I managed to verify Hydlide. I'd rather see someone else attempt this, ideally with either a reprogrammable cart or the original game.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
I performed three attempts to console verify this movie. Unfortunately all three attempts desynced in the same way, consistently. At approx 1:28 (of the encode video), on the 2nd green tile after exiting the city, I get an encounter with some kind of red blob (lol idk what the enemies are in this game). After fighting for a few moments, it exits the battle, moves around a bit, and then encounters a blue blob. The location of the encounters and seemingly the battles themselves, all appear to be consistent between attempts. I do not have the equipment necessary to initialize Work RAM; although given the consistency of the desyncs, I feel it's unlikely that initializing RAM would help (unless this is one of the rare cases where the Everdrive menu happens to consistently set values that the game depends on for RNG). In the past, I've tried and failed to verify the existing publication of this game, too. Perhaps it could be something on my end, some quirk that my device doesn't handle, honestly I don't know.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Congrats and welcome new judges! Your dedication to the community is much appreciated!
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
TheAmazingYucemu wrote:
Bigbass wrote:
Take note what I said about the "TASBot" name in my first post.
oh yeah, dwangoAC made that TASBot but it's closed source, i can't find his source code to his TASBot
You won't find any source. Not because it's closed source, but because it isn't a replay device. It's just a mascot, which may have any number of replay devices attached to it, but it itself is not such a device. And actually, the replay device typically used, is open source: https://github.com/Ownasaurus/TAStm32
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
TheAmazingYucemu wrote:
my open-source nintendo switch TASBot
Take note what I said about the "TASBot" name in my first post.
TheAmazingYucemu wrote:
Only IL TASes at the moment. Link to video
Did the TAS intend to miss the last jump? It also seems like all of the inputs from the script do not match up with the counter on screen.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Hello, nice to see more efforts toward input replay on the Switch. Has this been used for any full TASes? The demo seemed pretty short so it's hard to tell how effective this is over longer periods. Also, please take note that there is only one TASBot; he is simply a mascot which may utilize other devices to play back inputs on real hardware (akin to how a human uses a controller to play a game). Instead, devices like yours that relay inputs to real hardware, are typically known as "replay devices".
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
ThunderAxe31 wrote:
Here is the movie that I need to be console-verified: [3936] NES Code Name: Viper by XTREMAL93 in 10:56.62 This is important for me because currently there is a submission made with a different emulator and I'm not sure how to deal with it. I could still judge it without it, but a console verification would make it much less controversial, and I really wish to avoid controversy as much as possible.
Both movies desync on hardware for me. Perhaps RNG related? I don't have a way to initialize WRAM to test that theory. Alyosha or ViGreyTech may be able to test this. Worth noting that [3936] NES Code Name: Viper by XTREMAL93 in 10:56.62 does not sync in the latest Bizhawk version.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
I've followed this topic over the past couple weeks. I see myself in a situation where I don't know for certain what should be done, but I still want to share my thoughts. It's obvious to me that there are many different ideas and points of view involved in this discussion. On one hand, I understand those who are concerned about the idea of putting aside community-accepted rules in order to allow this submission, and others like it, to be published (in some form) on this site. This includes the concerns regarding reproducibility/verifiability. But on the other hand, I also understand the desire to bring this kind of content into light, as I see it as yet another form of TAS art. Over the past year, TASVideos has undergone many changes, both in the site itself, but also in the content that has been submitted and published. Every step of the way, community members have weighed in, bringing their own unique perspectives to the table. There may very well have been some decisions/changes that not everyone was satisfied with, which I think is inevitable given how we are all different in one way or another. However, the spirit of TASVideos remains strong in all of us: to curate Tool Assisted Speed/Superruns. One of those recent changes was the introduction of the Playground class. While Playground is still in its early stages, I think it is an important idea to think about in the context of this submission. Despite long standing site rules, this class was created with significant community backing so that the many creative TASes normally disallowed due to said rules, could be accepted onto TASVideos in some form. While it's true that some rules still apply to Playground, they exist so that the movies accepted for this class must still be of good quality and integrity (which, as I recall, were two major concerns that were discussed by the community.) Given the addition of that class, I believe the acceptance of this submission should not solely focus around whether or not it adheres to site rules. Just as Playground movies are made for different goals than the typical publication, so too this content was made with a different goal in mind. Again, I don't know what how precisely this situation should be handled. But, I do see this submission as an expression of art, in the same vein as every other movie that exists on this site. Yes, it certainly differs in content and goal compared to the typical idea of a TAS movie, but that doesn't necessarily mean it is less important or less deserving of attention or curation.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Spikestuff wrote:
Project64 will hopefully never support TASing as it holds the reputation of being a very questionable emulator for historical nagware reasons.
Plus it's horribly inaccurate, and not worth making a TAS with.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Spikestuff wrote:
Arc wrote:
You improved only the final boss but claim sole authorship credit?
Going to agree with Arc on this one as the current publication and this submission are identical all the way until frame 25229.
Perhaps the authorship was just a mistake, since they explicitly state they only changed that fight, and thank each of the previous movie's authors by name:
This movie contains only changes to the aforementioned fight (for a longer description of the rest of the game, see [2777] NES Ironsword: Wizards & Warriors II by Aglar, Randil, Alyosha, rchokler, Samsara in 07:14.32
Thanks to the authors of the previous movie: Aglar, Randil, Alyosha, rchokler, Samsara. Yours are the giant shoulders on which this movie stands.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Great improvement! Definite yes vote from me. Console Verification: Link to video
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
I really like the idea of this TAS' goal, but as Spikestuff brought up, I think this could be improved. This game/category feels perfect for the TAS environment too, compared to regular speedrunning, especially in the latter half when the movement speed becomes very fast. The challenge lies in the routing. As in, collecting the dots in the shortest route may not necessarily be the best score-wise. There were moments where it definitely looked like you could have diverted for a moment to eat a ghost, before returning to the dots; as such ghosts provide way more points than the dots do especially if you get at least two of them in a row. I'd be really interested in seeing you improve this TAS; really show off the best theoretical score a superhuman could get.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Is this submission different from the movie you had me test on hardware a few weeks ago? Is there any explanation for what's happening? What causes the crash? How did you make the movie?
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Console Verification: Link to video
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
If we count obsolete movies, the total is 345 published runs. Of which NES/GB/GBC account for 307 of them. 345 is ~7.2% of all published runs when including obsoleted. Either way, very good progress. And much of that progress was made just in the last 2 years. I'm still planning to explore both Genesis and GB/C (potentially GBA too). Genesis is likely what I'll do first, though. From everything I've managed to research so far, Genesis seems like something that hasn't really been delved into much in the public space. There's a few verifications out there; but little to no information about the problems (if any) faced by those people, or what they used for staying in sync. During this last SGDQ, I talked briefly with numbers about his Gauntlet IV work-in-progress TAS. He described something odd about how some games read controller inputs. Along the lines of games causing the console to poll the controllers multiple times, but not always actually reading their state from memory. However, based on official documentation from SEGA, the pins on the controller ports are directly accessible in memory. It's just that in order to read the entire controller state, the mode/select pin must be toggled in order to access some of the buttons (there are more buttons than available pins). Whatever the case, it should be easy to detect what's happening using memory callbacks in Lua (assuming the emulator core actually supports that in bizhawk). And then there's concerns about initial state and all that fun stuff too heh. If it's just a matter of initial RAM, or something like that, it should be possible to initialize state ourselves, similar to ViGrey's RAM initialization ROM. The Genesis cartridges are extremely simple, even compared to the Atari 2600, so designing/programming a cart for this shouldn't be too hard.
In the mean time, this week I've been catching up on recent NES publications (and some submissions). Verified 9 movies in the past few days. And continuing to grind away at the remaining NES games. Also been working on some tooling projects for dumping Quality-of-Life. Particularly VeriTAS which has the ability to take a TASVideos Pub/Sub ID number, or a local movie, and automatically run the entire dump procedure (including dumping multiple movies in parallel). It does work, but it needs some polishing before it's useful for the public. And ViGrey and I still need to finalize the new dump format we were working on last year.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
ViGadeomes wrote:
Here we go with my first console verification and maybe also the first PAL TAS ! The quality isn't the best but I wasn't able to do better without having to put an epilepsy warning.... https://tasvideos.org/1701M : https://youtu.be/RQocCif2IVM
Thanks, I've updated the publication. (Also, this forum thread should be up-to-date as of this post.)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
When I tried this for the first time on console, I didn't know that it was going to end so quickly. I was taken by surprise when you glitched through the floor (in a good way). Definite yes vote from me; short, but fun to watch. Console Verification: https://www.youtube.com/watch?v=cDlFJHZZ1LM Edit: Updated verification using improved submission: Link to video
TAS Verifications | Mastodon | Github | Discord: @bigbass
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 156
Location: Midwest
Console Verification: Link to video
TAS Verifications | Mastodon | Github | Discord: @bigbass
1 2 3
6 7