Posts for Bigbass

1 2
6 7
Posted: 1 hour ago
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Dimon12321 wrote:
Does it match an emulator configuration or should the emulator be adjusted to that?
I don't know enough about it to say one way or another. I'd expect changing the emulator to match would be easier, but might invalidate existing movies. On the other hand, I don't know how flexible the mod is, and I don't know if emulators are even accurate to begin with.
Dimon12321 wrote:
Like Sega Genesis, I suppose. I see, all verified movies were done years ago, and those were old Gens movies. The last year, I asked in dwangoAC's Discord channel about verifying Genesis movies and someone responded that not much attempts were initiated to do that, so maybe there is another platform just waiting for its time.
Actually I verified [570] Genesis Wonder Boy in Monster World by Aqfaq in 42:10.45 last year, despite it having been published in 2006. Though, it required me modifying the Lua API in Gens to expose necessary information. It was the first Genesis verification since 2014. I feel that there could be a lot of existing Genesis movies that are verifiable, they just need to be attempted. Without a flashcart though, I'm unable to do anything more on that console. While I do have a prototype design for my own flashcart, it's not functional yet.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 19 hours ago
(Edited: 19 hours ago)
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Alyosha wrote:
Patashu wrote:
SNES is also very hard to console verify, IIRC the reason is because two different components have their own timers and in any actual SNES their timers are slightly desynced due to physical inaccuracies.
My opinion on this is that either a hardware mod is needed, or some other new form of TAS is necessary for these systems. Maybe something like a scripting language + machine vision can account for non-determinism in real time? At least for SNES I have personally seen that verification is just generally not possible with the same pipeline as NES.
SNES might become a lot more possible in the near future. rasteri has created a hardware mod (open source) that essentially synchronizes the APU (audio) clock to the CPU clock, which should improve how deterministic the console is. But more testing is needed.
Alyosha wrote:
This discussion reminds me how young a technology console verification still is.
Definitely! There's been amazing progress in the past few years, across many different systems. Yet, from my experience researching and testing, it's clear there are still many unknowns. But I think that's okay! It means there is much more to explore and learn.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 1 day ago
(Edited: 1 day ago)
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
N64:
TiKevin83 wrote:
It doesn't do as much generally for the N64 but rcombs' 15 hour Watch for Rolling Rocks .5 A Press verification is the longest I know of which is an achievement itself for the stability of the tooling.
Patashu beat me to it, but yeah, that was definitely not the longest. rcombs also successfully replayed a TAS of the pendulum crash bug in SM64, which was a little more than 39days long. Which is certainly impressive, and I recall there being some failed attempts beforehand due to interrupted power or something along those lines. However, SM64 isn't a challenging game to replay on hardware (timing inaccuracies in emulators don't affect replayability.)
Patashu wrote:
because its physics don't change if there are more or less lag frames, and it doesn't poll on lag frames, so if you just give it input on non-lag frames you're good to go.
Technical Explanation: The game was programmed to poll for inputs one time per game loop, regardless of how long it took to complete each iteration. N64 games typically used a double or triple buffering scheme. The video output hardware is more or less automatic, with some level of configuration. It's either on, and outputting a framebuffer given its position in memory, or it's off completely. Games will render (rasterize) into one framebuffer, while the video hardware is outputting the other framebuffer. When the rendering is complete, games will typically wait for VSYNC, and then swap the buffers. "Lag frames" are really just the frames in which the game wasn't ready to swap the buffers yet, and so the video hardware displayed the previous framebuffer again. The difference between SM64 and many other games, is that most games will poll controllers automatically every video frame (e.g. typically around VSYNC), and store the data in memory for the game to use whenever it wants. Replay devices aren't capable of knowing which poll actually gets used, nor when it should increment to the next input. SM64 polls once per game loop. So regardless of how long it takes to complete one iteration of logic and rendering, the game will poll only once, making TAS verifications extremely easy. Emulators don't have to be highly accurate.
Ultimately, not enough experimentation has been performed on the N64 to confidently say what would be the "capstone" of the system in regards to TAS verification. The most immediate issue continues to be inaccurate emulation. Sure, it's getting better, particularly with Ares, but there are still issues with emulating accurate timing which is critical for verifying many games on this system. However, even if Ares has reached a sufficiently accurate point for some games, we wouldn't know because extremely little testing has been done to understand what issues may exist or what games may be viable for verification.
NES: I agree that Bad Apple really pushes the replay hardware in a variety of ways. However, I feel there are still some edge cases that don't come up in Bad Apple:
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 12 days ago
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Nice job Alyosha! Also, if you count obsoleted TASes, we're currently at 521 verified publications. :D
As for the N64.. some in-depth testing needs to be performed to really know how viable the system is for verifications at this time. SM64 and a couple other games are verifiable already, even with the much less accurate mupen64 core. But this appears to be because the way those games poll and make use of controller input, makes them unaffected by timing inaccuracies, at least as far as the replay device's ability to stay in sync. If you actually measured the realtime it took to replay, I'm certain it would be different than the emulator (based on what Ridley has explained to me, through her efforts regularly verifying SM64 TASes.) I suspect it might be possible to "scan" the N64 library of games with a Lua script in BizHawk, to try to predict games that are similar to SM64. But you'd have to manually play each game to induce some lag into the test. RDRAM initialization shouldn't affect anything. Maybe if a game depends on the initial state somehow? but I haven't heard of any N64 game doing that, and the initial state of RDRAM may actually be deterministic (needs more research). If necessary, it may be possible to initialize at least most of the system to expected values before starting the game/TAS replay.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 13 days ago
(Edited: 13 days ago)
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
If that's the case, there's nothing wrong here. The game "Super Metroid: Kaizo Edition" doesn't have any game versions in the catalog, so the site can't know which system(s) the game belongs to. Despite this, the reason the one existing submission for this game (#5902: Hoandjzj's SNES Super Metroid: Kaizo Edition in 1:17:59.24), is listed as a SNES TAS, is because submissions have a separate field for specifying the system. Edit: Ohhh the game list, I thought we were talking about the general search bar (top right corner of the site). The game showing up regardless of which system is specified, could be considered a bug I guess? For games without any versions: either it never shows up, or it always shows up. I'd think the latter would be preferable so the game doesn't become too hard to find.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 13 days ago
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Sticky wrote:
I ran a search for movies by type (PSX), and a super Metroid came up. Not labeled PSX or SNES, but does redirect to the SNES game's page. Turns out it was only submitted, not published. Only bringing awareness in case this is a bug with un-labeled games. :)
What do you mean you ran a search by type? Not sure what you mean by "un-labeled games" either. Could you provide more context/specifics to what you're referring to?
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 4/14/2024 2:07 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
linja wrote:
what is it about Lua that makes it the only contender in this space?
linja wrote:
outside of popularity (which doesn't immediately translate to UX here)
Popularity most certainly does affect the user experience. The more popular, the more resources there are, and more people to offer help when someone has questions. Additionally, Lua's popularity also means that a user who has used Lua scripting one place, doesn't need to learn a brand new language just to write a script in another place. Lua is also a highly extendable language without being overly complicated. All classes/objects are just tables in disguise.
linja wrote:
Lua has thousands of tiny quirks
I don't know about thousands, but yeah it's got quirks, however, so does every other language too. That doesn't mean the language isn't worth using. Many of Lua's quirks are those that typical uses likely won't encounter anyways.
linja wrote:
where does a language like Janet or Wren fall short
Besides the fact I've never heard of such languages before (and I suspect the same goes for many people), Janet definitely doesn't look simple or beginner friendly at all. There's a lot of superfluous syntax which gives off a strong esoteric vibe. Plus, there seems to be only one implementation, and its Github repo admits there is no language spec. This means that the number of emulators that can readily use it, is somewhat limited. Some languages may be able to produce C bindings and use it that way, but not all. Also not seeing any clear way of extending the provided functions, may not even be possible. In which case, it is completely useless for the emulator use-case (which requires being able to add custom functions that hook into the rest of the program.) Wren's syntax is better, but compared to Lua it's also more complex (more keywords and concepts the user must understand). It appears to include some kind of foreign module loading, but it's not super clear to me what's possible. It also has much better docs than Janet, but again no language spec as far as I can see. Otherwise it suffers many of the same problems as Janet. Lua on the other hand, has much better and more comprehensive docs. It has been reimplemented probably hundreds of times, across many different languages. It's relatively easy to extend. (Programs can provide custom APIs, with or without using imports.)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 4/12/2024 2:52 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
I concur with EZGames69 and DrD2k9. To me, April Fools is seen here as a time to submit all the wacky and bizarre ideas people have come up with since the previous year, even if only to make a joke. It's the act of submitting the TAS for people to enjoy, among all the other silly submissions, that I think people enjoy the most. If it happens to get published, great, if not, no big deal.
htwh wrote:
[...] publishing the best (and nothing but) gag runs on 4/1
Rules regarding what does or doesn't get published are the same regardless what day it is. Just because it's April Fools Day doesn't mean we should only publish "the best gag runs". Just because a movie is funny, doesn't mean it should be published. Generally speaking, most April Fools Day submissions do not end up being published, and that's completely expected by TASers.
htwh wrote:
Everyone else who just appreciates the runs, and would appreciate a good joke too, misses out.
I don't believe that's true. People can and do still enjoy the jokes even if they are not regulars in the community. Anyone is free to lurk in the Discord server, or to check in on new submissions on the site (especially on a specific day of the year). If you choose to only focus on the YouTube channel, then of course you're only going to see the content that gets published there. The whole point of these submissions is to try whatever strange, abnormal, or random ideas you can come up with. The goal is not publication.
Most importantly though, I fear this idea would put far too much pressure on judges and publishers leading up to April 1st. It's just not practical to try coordinating everything in advance. Especially considering that sometimes these TASes are created within days of April 1st. The judging process can take awhile, depending on many factors, including how much time the judge has to allocate to the site and the complexity of the TAS. Even if a TAS is explicitly made as a joke, it still deserves just as much consideration as any other TAS.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 4/6/2024 6:51 AM
(Edited: 4/6/2024 6:53 AM)
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
warmCabin wrote:
Do you happen to have a VOD of your console sync attempts? Not that I have any remote ability to help, I just wanna see.
Here's several tests I had done for 100thCoin, one of which was the longest I was able to achieve. (I had also performed numerous other attempts besides these.) Note that these attempts were performed with a custom test ROM. Link to video As part of my testing, I had use my logic analyzer to monitor the controller signals for each replay attempt. As far as I could tell, each attempt seemed to replay the inputs perfectly, despite the replay apparently failing at random.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 3/23/2024 1:59 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
DJ_Incendration wrote:
dwangoAC wrote:
SmashManiac wrote:
The run cannot be reproduced by an independent 3rd party because some of the data needed to do so has never been released publicly due to copyright concerns.
As was the case with SMB on SMW, site rules dictate we cannot link to ROMs and as such we also can't release the full payload for the same reason, we'd be in violation of the site's rules if we did. Instead, we've released the open source portions, and those have been independently verified.
If you can't link to roms, and a payload in itself is not a rom, it doesn't make sense that the full payload can't be released. Same for this submission.
The payload is indeed not strictly a rom, but it does contain copyright protected materials. As such, it still falls under the same rule.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 3/23/2024 4:44 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
dwangoAC wrote:
EZGames69 wrote:
For what it’s worth, the current all levels publication says it’s console verified, but I’m unsure how it handles the resets and if it has different rng each time.
Just like this: 
python3 tastm32.py --hardreset --blank 2 --console nes --players 1,5 --transition 675 S --transition 1614 S --transition 2910 S --transition 4067 S --transition 5153 S --transition 6318 S --transition 7279 S --transition 8247 S --transition 9118 S --transition 9995 S --transition 10832 S --transition 11676 S --transition 12528 S --transition 13385 S --transition 14247 S --transition 15170 S --transition 16133 S --transition 17313 S --transition 18515 S --transition 19573 S --dpcm drmario-resets-2b.r08
Just to provide some context in case this is unfamiliar to anyone: What dwangoAC posted above is the command used to tell the TAStm32 replay device what inputs to replay (drmario-resets-2b.r08), and on which input "frames" a reset should occur (--transition X). As long as the replay starts from power on (for Dr Mario), the moments the resets must occur at are consistent between attempts. Actually, that's how resets are always handled on the NES; they are initiated at predetermined frame or latch counts relative to the beginning of the replay.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 3/19/2024 3:08 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
PLANET wrote:
Also from perspective, a few years ago it was not ok to be even somewhat slightly harsh to a person here, now - not even the product of this person. What's next? Feels like a poison of (political) correctness spreading further and further...
You were warned a few years ago for blatantly insulting a TAS author, and after being called out, you insulted the author again. Now today, whether intentionally or not, you've conveyed disregard to another author and their work. You've made no attempt to apologize for this, quite the opposite actually.
PLANET wrote:
Being straight to the point when it comes to the run is exactly what it is, a criticism, even if not always the most constructive.
There are many more considerate and respectful ways to convey that a TAS needs improvement. Your repeated disregard for other people and their work on this site, will not be tolerated here. You are now banned indefinitely.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 3/19/2024 12:27 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
PLANET wrote:
fsvgm777 wrote:
PLANET wrote:
Waste of time.
Calling this submission a "waste of time" is very unhelpful and at worst, may actively discourage the TASer from actually learning from their mistakes. In fact, darkman425 and KusogeMan already provided some pointers on where they could improve.
"Waste (loss) of time within the run" : > Some advice was left on YT video actually, where author actually responds.
That's not what you said though, and is just as unhelpful as before. If you felt there were areas that could be improved, then state that constructively rather than disregarding the submission as a "waste of time". Even if that's not what you meant, your words can still have consequences, and as such care should be taken when providing feedback.
PLANET wrote:
Some advice was left on YT video actually, where author actually responds.
This is no excuse for being rude here on the forums.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 3/5/2024 5:09 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
While debatable, I don't think there's any version of Linux that is strictly "intuitive for a long time Windows user", though it can vary greatly on your experience and understanding of computers. That said, getting into Linux isn't incredibly difficult either. Can't speak to the other emulators you named, but BizHawk has actually worked on Linux for awhile. It's just that Lua wasn't supported until recently, and even before that, you could run it in a Windows VM (as annoying as that was). Generally speaking, anything that only releases on Windows, will probably still function on Linux via wine. There are a plethora of Linux distros available. You could spend a lifetime exploring them all hehe. First though I think it's best to understand some basic concepts when choosing distros. Under the hood, most distros are very similar to each other, but have a different set of pre-installed packages (software) and configuration that give it its distinct look and feel. One of the most critical differences will be which package manager the distro uses. The package manager is software that you use to install/update/remove other programs; it's vital to using Linux in any practical capacity. Some of the most common include apt, yum, and pacman. Within that, the next major difference comes from which package repositories the distro makes use of by default. The package manager uses a list of these repositories to actually find packages for installation. Many distros will often have their own repositories for various packages (and this isn't necessarily a good thing). The other defining feature is which "desktop environment" the distro uses. This is a collection of packages that (usually) gives you a Windows-like desktop, with windows, a taskbar, maybe some desktop shortcuts, file explorer, etc. Some distros will offer multiple options (Linux Mint is a good example of this). Theoretically, because desktop envs are just a set of packages like any other piece of software, you should be able to swap them out with whatever you want, but sometimes you can run into problems if a distro expects a certain desktop env (like missing or broken functionality).
That all said, I recommend you try out Kubuntu. It is a "flavor" of Ubuntu, which uses the KDE desktop environment. Ubuntu is one of the most popular distros and package repositories in the Linux ecosystem. Ubuntu normally comes with Ubuntu's own desktop env, but frankly I don't like it, and it's definitely not like Windows at all. KDE on the other hand, is pretty similar, and extremely customizable. Kubuntu is essentially just Ubuntu, but with KDE installed by default. I suggest choosing version 23.10. The older "LTS" version is often touted for stability, but you also often get stuck with very out-of-date software. Also, I would strongly suggest you get a new (decently sized) drive to install Linux onto. A clean drive makes the install process a lot simpler (you don't have to mess with existing partitions). To actually install it, this should be a pretty decent guide, just that you'll be using the Kubuntu ISO file instead. The installer may look different, but it should follow the same general flow.
Personally, I go for a more custom approach. I install Ubuntu's "Server" version and choose its "minimal install" option. It gives me a practically empty Ubuntu-based installation that has minimal bloat (though I still have to remove a few annoying packages). From there I'll usually install KDE but it depends on my use-case. This isn't something I'd recommend to someone unfamiliar with Linux though; as it requires some experience using just the terminal to perform tasks.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 2/29/2024 6:11 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
I think it would be useful to come up with some written guidelines for determining when a warning is beneficial. If anyone knows of some reputable sources for learning more about photosensitivity and epilepsy, particularly in regard to videos, possible triggers and risks involved, that would be quite useful. If anyone here actually has epilepsy or a related disorder, I'd be very curious in hearing their opinions on this subject. Such as what would be most helpful for them when viewing a movie, and what sorts of situations we should look out for. The most common trigger I've heard of is rapidly flashing lights, but it seems there is more to it than that. Does the whole screen have to flash, or just a small part of it? Does the flashing have to be sustained, or would a single flash warrant a warning? Is a notice in the video description or publication text sufficient, or would placing a momentary message at the start of the video be best?
alexheights1 wrote:
loading time should be removed from ZX Spectrum encodes by default because literally nobody wants to watch that noise.
The loading screen is counted in the TAS timing, and so it's part of the movie. Removing it, despite how annoying it may be, isn't something I could agree with. Just because the encode includes something you expect no one would want to watch, doesn't mean it should be removed from the video. For example, [5109] NES Home Alone by ShesChardcore in 00:17.87 contains almost 20 minutes of watching the same screen before the game ends, and that isn't even part of the TAS movie, yet it is still included to show that the game actually finishes.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 1/30/2024 2:00 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
TakuikaNinja wrote:
Another thing to note is that the SMB1 speedrunning community no longer approves FCEUX for submissions due to the default settings being deemed not accurate enough for high-level runs.
RTA rules do not apply here. FCEUX is a completely acceptable emulator to use for TASing, and TASVideos still accepts movies made with it. I've also had pretty good success console verifying TASes made with FCEUX, and there are many verified publications from as far back as FCEU 0.98.12. SMB1 in particular is emulated plenty accurately for TASing, as evidenced by how all current publications of SMB1 were made with FCEUX and have been verified on hardware. There are definitely games out there that are more accurately emulated in BizHawk, but it's not perfect either. The NesHawk core in particular is also rather slow compared to FCEUX, which could be problematic for some people depending on their computer hardware.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 10/2/2023 3:41 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Darth_Marios wrote:
I tried to make a script to pause at specific frame, but i keep getting syntax error. Im not good with C and other languages, but i used something similar with psxjin (just changing client.pause with emu.pause) and it worked, but in EmuHawk it doesnt: What i did wrong?
For reference, you should use Wiki: Bizhawk/LuaFunctions to know what functions are available in bizhawk. Syntax-wise you're missing the () parentheses on the pause function, and you're missing an end keyword. I also suggest indenting your code, it helps with readability and knowing where the end keywords should exist. 
Language: lua
while true do
  if emu.framecount() == xxx then
    client.pause()
  end
  
  emu.frameadvance()
end
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 9/21/2023 7:25 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Bigbass wrote:
So from here, the next thing to try is to insert the 2 input frames into the original dump.
This worked! The player entered the door as intended. However, it then fails to grab onto the vine, and falls down the waterfall. I'm not too surprised by this. I've never had complete success trying to insert inputs into a desyncing TAS. But at least this further supports the idea that the emulator has an inaccuracy. In addition to your research and the circumstances of where exactly the desync is occurring, I think it's safe to conclude the emulator is at fault here. Unfortunately that means there is likely no way for this TAS to ever verify unless resynced to a different emulator. Theoretically, it might be possible to keep inserting/removing inputs until it works, but this would take significantly more time than it would in an emulator, and makes it difficult to compare to the original movie.
If someone wishes to try resyncing this for the purposes of verification, I highly suggest stopping around the 8 minute mark, and then asking myself or another verifier to check whether it works on hardware. That way if there's still a problem, they don't waste time trying to resync a 2 hour movie.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 9/21/2023 5:26 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
For what it's worth, just because something doesn't directly port to another emulator isn't a strong indicator of anything, including accuracy. Sadly based on your research, this appears to be an instance of what I consider a flaw in how TASing tools typically operate. In that TASers must provide inputs based on whatever the emulator claims is a "frame", regardless of how the game is actually reading inputs. (SubNESHawk in BizHawk is an example of the other methodology, where each row in TAStudio represents a single latch, rather than an entire "frame".) That said, I'll still attempt doing what I described in my previous post.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 9/21/2023 3:37 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Unfortunately I am unable to get this to verify on console. The desync consistently occurs little under 8 minutes into the run. It's first visible at frame 28258, when the player fails to enter the door. Everything leading up to that point visually looks correct, except that it seems like the player turns to the left 2 frames too early (on frame 28258 instead of the expected 28260). I tried modifying the movie by add 2 duplicate frames immediately before 28260, and redumping the input data. (The movie desyncs on emulator shortly after this point, so this isn't a fix, but just an easy way to test what would happen with 2 extra frames.) Interesting, this change enables the replay to move into the door as the TAS expects! This also indicates a high chance of an emulator inaccuracy. So from here, the next thing to try is to insert the 2 input frames into the original dump. I don't have tooling for doing this, but should be doable still. Will try later today and post back with the results. (note: even if this works, there's still 2 hours left in the run for something else to break..)
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 9/4/2023 5:49 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Here is the console verification of this movie. Link to video While the movie does indeed verify, I'm a little suspicious of how much time was actually saved here. It's been shown before that BizHawk can have less lag frames at the start than FCEUX. Similarly, this submission has 1 less lag frame at the start than the current publication. That said, the other saved frame may truly come from more optimal game play. The quantity of input frames is the same between these two movies, which would seem to indicate the other saved frame is a result of less lag.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 9/4/2023 4:22 PM
(Edited: 9/4/2023 5:51 PM)
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
ThunderAxe31 wrote:
I wish to see a console verification of this movie: #8581: Pankaj's NES Batman in 09:11.86 This game as a huge history of optimization, and now for the first time we got a BizHawk movie file, unlike all the previous ones that were done on FCEUX.
Testing right now. Edit: Movie verified!
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 8/1/2023 4:07 AM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Samsara wrote:
I started with rewriting Wiki: WelcomeToTASVideos, which should hopefully better reflect how we currently operate. Let me know ASAP if anything can be improved/added/changed: Given that this is one of the first pages new users are likely to see, it's extremely important to me that it's as good as it possibly can be.
As far as I can see, there's no mention of the Discord server. So perhaps under the Wiki: WelcomeToTASVideos#WhatIsTasvideos section, add a link and a brief description of what exists there? Also, I noticed the introduction video is 11 years old now, and the image quality is quite low. Are there any other videos that might better show off TASing in the last decade?
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 7/28/2023 12:06 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
Thanks Randomno for compiling these lists. Worth noting however that these changes can only be performed by judges or other staff. Editors cannot modify submissions (except for catalog changes).
TAS Verifications | Mastodon | Github | Discord: @bigbass
Posted: 6/15/2023 9:20 PM
Quote
Bigbass
He/Him
Experienced Forum User, Moderator
Joined: 2/2/2021
Posts: 163
Location: Midwest
dwangoAC wrote:
https://wiki.tas.bot was created to specifically address console verification and charity event TASBot aspects
Any console verification topics that don't directly involve TASBot, should remain here, not on wiki.tas.bot. Last year I reworked Wiki: ConsoleVerificationGuide to provide more details about each step of the verification process, and have made a few updates since then. There's still parts missing, I only have so much time/energy for projects. Plus some parts, like the Console Specifics section, needs more research to write properly/accurately.
dwangoAC wrote:
there's a lack of folks who have an interest in editing the wiki
That will always be a problem. Writing documentation, especially in one's free time when other projects could be worked on, isn't something most people have motivation to do. Additionally, the kind of information that would be written on these pages, can't be written by just anyone; it needs someone who understands the subject matter. In the case of console verification for example, there are very few people capable of adding to the wiki(s), since so few people do regular console verifications. Or in the case of TASBot's charity work, it requires someone who is familiar with the events TASBot has been apart of, or knows how to research such details.
TAS Verifications | Mastodon | Github | Discord: @bigbass
1 2
6 7