News

posted by Samsara 5 days ago
Well, hey, it's been a year since the last one of these, so at the very least it's still annual. Of course, that also means there's a lot to get through... In this post:
  • BizHawk 2.10 has a release candidate!
  • Windows 95 runs are now accepted!
  • Content and sensitivity warnings have been added!
  • A very important thread regarding the future of TASVideos!
  • New sync verification system and a call for new Reviewers!
  • Oh also other staff, a call for other staff as well ._.
  • Revamped Alternative and Playground classes!
  • New Events class!
  • And one last quick thing from your third favorite admin!
Major thanks to dwangoAC for helping with information and wording, particularly in the Events section! There's a whole lot of major site stuff to get into, but I'd like to start with some smaller things first so they don't get buried:
Wake up, babes. New BizHawk just pre-dropped: https://github.com/TASEmulators/BizHawk/releases/tag/2.10-rc1 This release candidate for BizHawk 2.10 contains a fully functional 3DS core (Encore), as well as new cores for the Fairchild Channel F (ChannelFHawk), the Commodore Amiga (PUAE), and the Atari 2600 (Stella). On top of these new cores, there were many updates to the current cores, most notably a major update and reimplementation of the Genesis Plus GX core. Note that this is not the official 2.10 release, but just the first release candidate, so please help us check for regressions, especially in TAStudio and the rest of the TASing workflow, and in Lua. Remember: if it's not reported then it won't be fixed! Report bugs on the BizHawk Github or on Discord, TASVideos, or Reddit. As this is not an official release, we are not currently accepting any submissions using it. The new cores are not supported by the site yet, and the updated cores will likely not sync on previous versions. We will be making a separate announcement post once 2.10 is officially released to formally announce support for the new cores.
As a notable update to last year's acceptance of Windows XP TASes using PCem and libTAS, we now have a setup for Windows 95 games, and as such they are now accepted! Like Windows XP, only TASVideos releases of PCem are allowed. These releases are marked st to indicate single-threading, a modification required for determinism that isn't available in the original PCem. Please see our movie rules for libTAS submissions, as well as our rules for PCem. For more information, including help on how to set up the environment, we have a Guide on TASing Windows games in PCem+libTAS.
I'd like to highlight a recently added quality of life feature to the site: Content and sensitivity warnings. Due to the nature of TASing and the devil may care attitude of older games, we've had a number of people point out that a good number of publications should have photo- and phono-sensitivity warnings on them, to alert users of the presence of flashing lights and sudden loud noises. Separate to that, with advancements in TASing starting to reach more platforms with less market regulation, we also have a number of runs that require content warnings, as they contain dark, disturbing, or otherwise potentially triggering content. We were, and still are, noting these in publication descriptions, but we've just added proper warning icons for these movies to make it more clear: - We use this yellow icon for photo- and phono-sensitivity warnings... - ...and this red icon for content warnings. We're still in the process of flagging movies, so if you see a run that should be tagged with a warning, let us know!
Alright, time for the big things. If you've looked at the workbench recently, and I'd like to think you have if you're reading this news post, you've most likely seen the huge influx of new submissions and new submitters over the past couple years. We broke our nearly two decade old submission record in 2022, and then in 2023 we broke our nearly one year old submission record again. I've said it before, I'll say it again here, and I'm going to say it many times more in the future: This is fantastic, I love it, I'm so happy to see the resurgence and growth of the site and even happier to have participated in and facilitated it directly. This is exactly what we wanted to see while we were developing the new site! Of course, there is a slight catch... It's a lot more than we were expecting. Something that we've realized recently, and unfortunately later than we should have, is that our current submission and publication system might not be sustainable with our growth path. The system worked great when we were receiving 300-400 submissions per year and only publishing about 70% of them, but now we're not only receiving double the number of submissions as before, but we're also publishing them at a higher percentage due to all of our recent rule changes. To quickly put it into perspective, here's a fun stat: We've published as many movies since the release of the new site as we have in the last six years of the old site. 1544 publications since January 1, 2022 at the time of writing, compared to 1559 publications covering 2016 to 2021, meaning that by the end of the year we will have effectively more than doubled our previous publication rate by year. If you want a second fun stat, we published more runs in 2023 alone (721) than we did in the final three years of the old site (712). If you want a third fun stat, not only did we have more submissions in 2023 (885) than in any other year, but we also published more runs that year (721) than we've had submissions in any other year. Needless to say, that's a lot more work than we've ever had to do before, and we're doing it with effectively the same number of staff members. We've made a lot of changes to make things easier, of course, but we realized that we're most likely going to have to go deeper in order to stay afloat. Therefore... TASVideos must die. That provocative statement, as well as the next four words in this sentence, links to a thread posted by ikuyo, and I highly recommend reading through it and posting your thoughts. To clarify, the site itself isn't going anywhere. We just need to make much bigger changes than we've been making, even if it means "killing" parts of ourself that we've been carrying since inception. I'd like to think that we've spent the past few years systematically killing the negative parts of the site, correcting our previous wrongs and re-opening doors that we had violently slammed in peoples' faces, but some of those negative aspects are still built so deeply into the core of the site that we've honestly overlooked them for way too long. That's the TASVideos that must die. Not the site itself, but the underlying core we've ignored until now. We're already planning on making some changes to the site based on feedback and discussion in and inspired by that thread, and to prove it, I'll announce a couple of them right now!
If you've looked at the workbench recently, and I'd like to think you have if you're reading this news post, you've most likely seen a new tag in the Submission Status column: Sync Verified. This, of course, means that the submission was verified to sync on a machine other than the author's, which is quite useful for the entire way TASing works. Verification is arguably the most important part of judging, and as such Judges were almost always required to run the input files for their claims. This was not always possible: Tech knowledge, hardware requirements, and in rare (read: Linux) cases game availability have been barriers to verification many times in the past for us, which would result in us needing to reach out to other staff or the community at large for help. Waiting to reach out never really got us anywhere fast, though, and as speedrunners we do enjoy things being fast, so we decided to build verification directly into the site. What this means is that we want Reviewers, and a lot of them! I had originally envisioned Reviewers as filling this exact role, making judging more accessible to people who are qualified in every way except "being able to run the input file", so now that there's a proper system put into place it means we can really ramp up the number of Reviewers. The only requirements are being able to run and verify input files and having a professional attitude, so if you're interested, please reach out to myself or feos, or just talk about your interest publicly and someone will pick it up and bring it to us.
That being said, of course, we would love to have more staff in general. With the manifesto thread, and yes I am going to link to it every time I mention it thank you very much, it's clear that while we can change a bunch of systems to make things work with our current staff, having more staff is objectively still a great idea. Changing the machine can only do so much when we don't have enough minds to properly interface with it. Rest assured, though, that once we perfect the mind/machine interface, we're hard pivoting to copters and immediately aiming for Cloudbase Academy. I'm going to let you all in on a little secret: Being staff isn't hard! I've gotten the feeling over the years that people are a little afraid of becoming staff due to what they perceive as a lot of hard work. The reality is that it's easy work! Of course, I can't say it isn't a lot of work because the manifesto exists and outright says there's a lot of work, but the more people that sign on to help us, the less work it is for everyone involved. In particular, we are (and have always been) in desperate need of Publishers. While encoding to site standards sounds complicated, we've effectively automated the publication process to a point where even complete newbies like myself can do it, so there really isn't a barrier to entry outside of being able to spare some PC usage and hard drive space. If you're interested in encoding for us, even if you don't currently know how to do it, please reach out to fsvgm777, or do the time-honored tradition of randomly bringing it up on Discord and we'll see it.
Three years ago, we completely revamped our old tier system. Instead of the old system of Vault for boring any% and 100% movies and Moons for everything deemed entertaining enough, we redefined Vault to become standard publications, where all "standard" categories go, and we redefined Moons into Alternative, which was for all non-standard categories that were deemed entertaining enough for publication. This, we thought, would remove the old entertainment bias from the site, since entertainment was no longer a factor for about 90% of the movies coming in. It did remove a lot of the bias, yes, but not as much as we thought. Perfectly good movies were still being rejected from Alternative. In response to that, we drafted and partially implemented Playground, a system designed to catch and showcase Alternative movies that slipped through the cracks due to low entertainment, lack of audience interest, or being a rule-breaking category to begin with. That way, we wouldn't have to discourage people from creating tech demos, things like "fastest crash" or "fastest game over" runs, as we could still put them on the site in some way. To be blunt, Playground didn't really work. We wanted to encourage creativity in TASing by giving creators room to do whatever they wanted, but what we ended up doing was inadvertently bringing back the entertainment bias and the old Vault/Moons divide. Entertaining non-standard runs were still published to Alternative, of course, but non-entertaining runs were just given a submission status and put into a different subforum. It took until last month, two and a half years after Playground was drafted, for us to show those runs on game pages. We completely dropped the ball on it. Part of that I think was due to lack of interest across... Everyone on the site, really. People weren't really interested in making runs specifically for PG, and as a result the staff weren't thinking much about it. We had plans and ambitions of course, but for the most part the runs that ended up there were just Alternative runs that didn't quite make the entertainment barrier, and the site infrastructure that would've needed to be added was just going to push dev work away from more critical site features and fixes. The manifesto got us talking about it, and we came to a fun conclusion: We should have talked about it WAY sooner. The answer to every perceived problem we had with PG was staring us in the face since the beginning, and we all somehow overlooked it: Why not just publish everything? It sounds insane, especially given my stats from earlier, so let me explain. The overarching problem a lot of people had with PG was that it didn't do a good job at showcasing runs on the site. We had the status, which was always meant to be a temporary implementation, but without a clear direction it ended up being permanent. Proper showcasing would involve PG runs being archived to the same degree as any other run. Easily accessible, searchable, manageable, award-eligible, able to be flipped to Alternative or even Standard if rules changed... We were hyperfocused on the idea that this needed to be a separate system, because they weren't meant to be publications, and that stopped us from realizing that literally everything we want is already in the publication system. We could have just done this with Alternative from the beginning. Instead of continuing to divide unique branches by entertainment, we could have just had all of them from the beginning without needing to do much different. After all, a lot of these unique branches still aim to finish a particular goal in the fastest possible time, right? While the actual goals may be more subjective than any% and 100%, there is still the objective underlying goal of "whatever you're doing, do it as fast as possible", and there really shouldn't be any barriers for that. Going forward, Alternative will expand to include many speed-based branches, regardless of their entertainment level. This is far more in line with our original vision for PG. Creativity no longer requires an audience, meaning you can create a run of the exact branch you want to see and we will showcase it the same as any other run. Naturally, this change leaves a couple roadblocks that needed to be discussed. First, notice that I said many speed-based branches, as opposed to all. This means there's still a degree of quality control on what is now accepted. While we will be much more lenient than before, there's still a difference between making a TAS of a niche challenge you've always wanted to see done and making a TAS where you put nine pieces of chewed up gum on your face and sing the "I'm Just Me" song and hop around on one foot. In other words, don't try and game the system by making up hyperspecific new branches to try and guarantee a publication. Count Longardeaux would not stand for that. Second, PG accounts for rule-breaking runs, so what happens to those? The simple answer is that... Well, we still have PG, don't we? We have a system that labels runs and places them on game pages, so we can still use that for runs that still don't end up making it to Alternative for technical reasons. For now, this will also include individual level (or IL) runs: We want to officially support these in some way, but they explicitly require new site infrastructure and a clear vision of implementation, and that will take some time. Third, I need to briefly discuss playarounds. Playarounds will not be affected by this expansion, as they are not speed-based runs. The entire concept of a playaround would be made redundant if we were to stop judging them on their entertainment level, so they must still be deemed entertaining by our audience to be accepted. Finally, and most importantly, encodes. This was the biggest PG roadblock for me, the fact that opening a new category that allowed effectively any reasonably optimized TAS of any kind to be submitted and showcased meant that there needed to be a way to control the potential impact on the publishing team. The solution here is as simple as it is groundbreaking for us: Publication encodes will not be immediately required. This means we can still publish the runs on TASVideos itself, giving them publication entries and allowing for all of the fun features attached, but we don't increase the load on the publication team by outright requiring them to encode every new Alternative run. Standard runs are prioritized as they are the vast majority of our submissions and publications, so there may be times where the publishing team is unable to spare the time for an official Alternative encode. In these cases, published Alternative runs will have temporary encodes attached so that they are still easily watchable. An official encode can still be made at any time. Because I feel as though that was a lot of explanation, and because I like summarizing, here's a brief summary of how the new system works by class:
  • Standard is staying the same, containing common objective branches such as any% and 100%. Runs will still be published and officially encoded as normal.
  • Alternative is now accepting any and all speed-based branches that aren't standard publications. Outside of playaround runs, entertainment is no longer considered a barrier to publication. Runs will receive publication entries, but official encodes may be deferred.
  • Playground will still catch all quality runs that are currently considered unsuitable for Alternative, usually for technical reasons. Runs will not be published, but they will be listed on game pages.
  • Events will...
Oh, right. I should talk about that last one, shouldn't I?
If you've looked at the workbench recently, and I can't believe the rule of three is still in effect for this bit, you've most likely seen Triforce% sitting at the very top, and also by "recently" I mean "two years, it's been two years, oh my god it's been two years". It has taken us quite a long time and more than a few conversations across both the community at large and internally as staff, but we've finally come up with a solution for it, and you're not gonna believe what it is. That's right: For the immediate second time in this post, we realized that we were hyperfocusing on implementing a new solution when we could have easily used what we currently have. We have implemented a new Events class that will contain submissions that were created for live events such as GDQ. You can probably tell this revelation came hot on the heels of Playground, as it is literally the exact same solution: We wanted live event runs to be treated the same as any other publication while not technically being official publications, and because of that we consistently overlooked the fact that we could have just published them anyway under different rules. Now, that being said, this is admittedly not a perfect solution, in that it's not quite everything we wanted or promised, but the important thing is that it's both something we can do immediately while also being big enough of a step forward to not feel like a half-measure. We made that mistake before with PG, and I'd like to avoid repeating that mistake in the future. Since Events will be using the standard submission system, a few rules will need to be followed:
  • Event runs are technical showcases or transformative displays of published runs that would otherwise be unpublishable as they are.
  • Event runs can be submitted by anyone, but all parties involved with the presentation must be properly attributed and any objections raised at any time must be taken into account.
  • Events that showcase multiple runs must be split by run and submitted individually.
  • Videos of the event must be provided.
  • If a proper input file cannot be provided for technical reasons, a dummy input file must be provided that matches the game and console.
  • The event itself must have some degree of common sense notability.
For that first point, we are mainly looking to prevent publication redundancy. Published runs are often shown at live events as console verification demonstrations or for live commentary. In cases like these, since we already have flags for console verification and commentary, we would prefer to just add those flags to the current publications instead of going through the process of creating an effective duplicate Event entry. However, if a published run was shown in a transformative or unique way that we don't already account for, that would definitely warrant a separate Event class publication. That being said, we could definitely add an Event flag on top of the commentary/verification flags, just so all published runs shown at events can be easily categorized. For the second point, the main thing we're asking here is due diligence. Due to things like technical aspects and language barriers, it's not realistic for us to restrict event submissions to only those who are directly involved, so we will allow event submissions from anyone. Still, submitters must attempt to seek permission from those who are involved, must properly attribute everyone involved, and should not attempt to take credit if they are not directly involved themselves. The third point is just a site limitation for now, and is one of the reasons I said this wasn't a perfect solution: We currently can't catalog multiple games to a submission. Our current multi-game publications use a single game entry that covers all of the games simultaneously. If we were to accept full events that use multiple games, each event would need to have its own singular game entry, and that both adds redundancy and complicates organization. Separating multi-game events means we can properly catalog each game, allowing event runs to show up in their respective game's entry. The fourth point is a given, so to explain the fifth point: In cases where an event run's actual input file was strictly created for the event and cannot be reproduced outside of that environment, such as runs that rely on multiple pieces of hardware or runs that rely on live human input, a dummy input file must be provided as a way of complying with the submission system. This input file must match the game and console, but does not have to accurately reflect what was shown in the video, as this input file will not be judged. Finally, to explain "common sense notability": This is just a fancy way of saying "don't try and game the system by inventing events". TASing is a niche hobby, and events that showcase it are even more niche in turn. Because of this, requiring a certain objective level of notability would be wrong of us to do. However, it's still reasonable for us to have a small foundation based off of common sense, where we can "reject" events that were clearly made for the sole purpose of exploiting what looks like a loophole. We're still figuring out the logistics of showcasing events that do not contain any runs, such as talks or panels, but we intend to have a spot for those as well. Feel free to share ideas on how we can handle these!
Long as this update post already is, there is one last thing I need to talk about for my own sake, and I apologize in advance for ending this post on a down note. For the past year or so, I've been unable to keep up with the site as much as I'd like to, as I've had to spend more and more time taking care of a family member. The situation has worsened significantly over the past few months, often leaving me completely drained of energy and unable to put anything towards TASVideos, and as such I'd like to apologize for my recent long term absence as well as continuing to have a reduced presence on the site for the foreseeable future. I say this mainly in regards to all of the promises I've made and projects I've started over the past year that I haven't been around to progress or keep. My time away from the site has caused me to forget most of them in some form, whether it's forgetting what still needs to be done or completely forgetting what they are in the first place. Now, I still intend to keep those promises and finish those projects, but I do have to shamefully admit they will take time and motivation that I do not always, or even often, have. If I can defer them to other staff members, I will, but anything that directly involves me is likely going to have to wait a bit longer. I know I was spearheading wiki reorganization, and I know I was supposed to help out with CelesteTAS support and verification, but past that I can't bring anything to mind, so please feel free to message me reminders and/or resurrect one of my hundreds of unfinished discussion/proposal threads in order to get the balls rolling again on them. Other staff are also available to talk to if I'm not around, too, but given that I managed to find the time and energy to write this entire post, I'd like to think I should be around more often than before. In short, I'm not going anywhere. Eternity lies ahead of me, and I haven't drunk my fill.
Hopefully there won't be another full year before the next progress report. As always, feel free to contact us with any questions, or reach out on Discord for faster and much less easily findable answers!
posted by feos 11 days ago
openMSX 20.0—Autumn Spring—is a major release, in which we introduce the new Graphical User Interface, replacing the OSD menu. A faster and more powerful debugger is now included in openMSX itself. Configuration for MSX joystick/JoyMega has been improved drastically using the new GUI. If you still want to use Catapult, you can use the Catapult release that came with openMSX 19.0. Please read the release notes for details of the openMSX changes. Please note that as of now, a system with OpenGL 2 support is required to run openMSX.
posted by feos on 6/6/2024 6:15 PM
The site is expected to be down in about 12 hours due to work being done at the hosting provider. Site staff will be working with said provider.
Everyone who has at least once attempted to gather a soul from each of the 120 different enemies in Aria of Sorrow, especially during a speedrun, knows the frustration it incurs after a hundredth failed attempt to get the required drop. That just makes this all-souls TAS, played on hard mode, even more impressive.
This is an improvement of 1:38.85 over the previous movie, thanks to a more optimised route and newly used items. Please read the authors' comments for more details.
If you would like to see the game beaten even faster, don't miss the any% run by one of the authors, klmz.

Note: Starting from reset was necessary to use hard mode. However, doing so is normally not allowed — refer to the rules to see the reasons.

Latest Publications

Newest Submissions

Newest User Files/WIPs

UploadedByFilenameTitle
13 minutes ago Technickle Top Gear 2 (USA) 2 Players.bk2 TG2 2 Players
13 hours ago SuperMonkeypotato HP CoS Updated.bk2 Updated
23 hours ago Technickle 2 Games in One! - Dr. Mario + Puzzle League (USA, Australia) Puzzle Mode full.bk2 Puzzle League "Puzzle Mode"
1 day ago DarkRiolu27 Draft 3.bk2 KDL Draft 3
1 day ago DarkRiolu27 Draft 2.bk2 KDL Draft 2
More User Files...

Contribute

Want to help? Everyone has something they can contribute.