1 2
Posted: 10/15/2023 1:06 PM
Samsara
She/They
Site Admin, Expert player (2411)
Location: Northern California
Joined: 11/13/2006
Posts: 2874
Location: Northern California
NES TAS of 2024 Homebrew TAS of 2023 Exotic platforms TAS of 2020 Sega TAS of 2016
I'm going to go ahead and say that everything we would need to do to account for HK TASing in its current state is far beyond what we should be accounting for. Just reading through the list of things we need to change or keep in mind makes me think that the process is likely to fail at any given point, and strictly speaking as an Admin and the head of judging, I can't imagine putting staff through this with every new submission. It may have to wait until libTAS is better able to support Unity games or HK itself so we don't have to worry about the nondeterminism. As for the philosophical side of the arguments, I totally understand the concerns there. The movie rules and submission instructions were atrociously elitist for a very long time, and even after the massive amounts of overhauling I and others have done over the past few years to fix all of that, there's still a lot more work that needs to be done for everything on the site to accurately reflect our current policies. My ideal for TASVideos is for it to be an expansive archive and repository for TAS information, with the community focusing more on collaboration and support rather than trying to be the absolute best at everything. This thread in particular isn't meant to be us trying to force other communities to adhere to our standards, it's meant to be us trying to support everything we possibly can within reason in order for us to be a more complete source of information, but given our past I don't blame anyone for thinking otherwise and still getting bad vibes from us. If there's anything I can do to correct that, I'm absolutely willing to do it. I'll put it this way: Even if it's too much for us to support HK TASes on a technical level right now, I still want to and would love to put in the effort to supporting the community in any other possible way we can.
TASvideos' Third Strongest Site Admin 🩵 Currently unable to dedicate a lot of time to the site, taking care of family. Now infrequently posting on Bluesky
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Posted: 10/15/2023 1:20 PM
Memory
She/Her
Site Admin, Skilled player (1626)
Location: Dumpster
Joined: 3/20/2014
Posts: 1823
Location: Dumpster
GBA TASer of 2020 GBA TAS of 2020 GBA TASer of 2019 Exotic platforms TAS of 2018
Personally willing to consider some alternate methods of displaying runs that might not be able to run in one coherent segment. Honestly found that being extremely virtuous about certain things like has to sync in one go is just going to annoy people from outside communities. The big issues we have atm are largely technical and/or related to manpower. So such features might be a ways off.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Posted: 10/15/2023 1:26 PM
Jarlyk
Joined: 10/15/2023
Posts: 3
One option that would open things up a lot would be a way to list unverified/unverifiable videos (with a clear label as such), Because, I agree, I wouldn't want to subject verifiers to having to try to sync my movie files even if I cared about the stamp of approval; it's just too time-consuming and painful of an ordeal to ask volunteers to undertake. That said, I think there are some folks in the HK TAS community who'd be more interested in getting verified in some way, but I definitely don't think the traditional method of TAS verification would work for HK without fundamentally new PC TASing technology (even if it were more reliably deterministic, the slow encode speed is still quite onerous.) Another option would be something akin to 'rta verified', i.e. verified in accordance with the standards normally applied at speedrun.com for rta runs of equivalent categories. Most of the 'serious' HK TASers are following rta rulesets (with the obvious exception of using tool assistance) and so the only form of verification that's really applicable is whether it's following those rules. Which, of course, is game-specific, thus why every game on SRC has its own set of moderators/verifiers. Fundamentally I think the issue is that there's no way to create a single unified ruleset that makes sense for TASes in all types of games, especially when complicated PC games are in the mix.
Posted: 10/15/2023 1:31 PM
feos
Emulator Coder, Site Admin, Skilled player (1265)
Joined: 4/17/2010
Posts: 11795
NES TAS of 2011
Jarlyk wrote:
That said, I think there are some folks in the HK TAS community who'd be more interested in getting verified in some way, but I definitely don't think the traditional method of TAS verification would work for HK without fundamentally new PC TASing technology (even if it were more reliably deterministic, the slow encode speed is still quite onerous.)
If the game can run on a machine like this (or anything else PCem/86Box supports) running Windows XP or Debian 12, that might eliminate all of the verification/encoding problems.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 10/15/2023 1:39 PM
Jarlyk
Joined: 10/15/2023
Posts: 3
feos wrote:
If the game can run on a machine like this (or anything else PCem/86Box supports) running Windows XP or Debian 12, that might eliminate all of the verification/encoding problems.
Given that HK encodes at about 1/20th real speed using libTAS, which is executing natively with hooks to control reported time rather than via emulation, I imagine the encoding time on an emulator would be abysmal. It could be interesting for someone to try, since the biggest likely culprit for our nondeterminism issues is multithreading, but I'm not particularly hopeful that it would work well. HK is just not a very well-optimized game. (:
Posted: 10/15/2023 2:31 PM
(Edited: 21 days ago)
CasualPokePlayer
Emulator Coder, Judge, Skilled player (1140)
Location: California
Joined: 2/26/2020
Posts: 866
Location: California
Gameboy TASer of 2024 Arcade TAS of 2023 TASer of 2021 Gameboy TASer of 2021 Rookie of 2020 Gameboy TASer of 2020 Lucky TAS of 2020
The WinXP+PCem combo just wouldn't be viable at all here (and really this applies for most modern-ish PC games):
  1. This is an emulator. An emulator for a really old PC. It's not like libTAS being an "emulator" simulating an extremely powerful machine (with its ability to just lie about time). Rather, you will be dealing with running the game at however fast that really old PC can run it (which for Hollow Knight sounds like it would not be able to maintain full speed at all, so you can imagine that, assuming you were running PCem itself at full speed, you'd still be running the actual game at 5-10 fps or whatever, and that's going to be reflected in an encode.
  2. Hollow Knight, looking at its Steam page, already has a Windows 7 requirement, which cuts off support with the WinXP+PCem combo.
  3. Hollow Knight also, on it's steam page, seems to have a D3D10 requirement. This also cuts off WinXP, which only supported at most D3D9. Even then, the best GPU that PCem supports (3DFX Voodoo 3 3000) only supports up to D3D6.
  4. There is also a likely chance that even the 32 bit version (which apparently exists for HK?) wouldn't work, as it's highly probable it is built assuming SSE/2 support. With more modern compilers (e.g. more modern MSVC / gcc) the developer needs to add additional special flags to actually make a compiler spit out something not making these assumptions.
  5. 2 could in theory be worked around by using some modern Linux distro. But then you are swapping out 3's D3D10 requirement with some OpenGL requirement. The best GPU that PCem supports only supports up to OpenGL 1.1. For context, this predates support for shaders (also similar case with D3D6; D3D8 was the first D3D to support shaders). This itself is going to eliminate practically any modern game that uses the GPU as they are going to be using shaders, not the ancient fixed function pipeline ancient GPUs used (which is even possibly outright unavailable for newer GPUs, so even more reason for modern games to use the more modern APIs which that Voodoo card fundementally cannot support).
  6. 5 could in theory be worked around by forcing software rendering. Which just makes 1's issue get turned up to an insane level. Keep in mind that software rendering is going to be happening on that emulated CPU. An emulated CPU that only has 1 core (and no hyperthreading magic), and is only running at 450MHz, and predates even the basic SSE extensions that have been present for over 20 years.
Simply be, PCem is very much not a magic bullet once we talk about any modern-ish PC game. Especially not Unity games (along with most modern-ish PC games), which would all use shaders, and so fundementally would not work here.
Posted: 3/30/2025 6:57 PM
Randomno
Editor, Experienced player (550)
Joined: 2/11/2018
Posts: 273
Flash TASer of 2023 N64/DS TASer of 2021
Posting this to possibly refer to in future: Trying to make Minecraft acceptable for TASVideos
Posted: 21 days ago
TheBirdOfPrey
🇺🇸 United States
Joined: 3/10/2014
Posts: 13
Location: 🇺🇸 United States
Writing after a quick chat with Memory about the potential for the Dustforce single-game-tool of "Dustmod" / "Dustforce Script" to be considered and validated/approved for submissions. Past discussion for reference: https://tasvideos.org/Forum/Topics/14003?CurrentPage=2&PageSize=25&Sort=CreateTimestamp Based on what Memory wrote: The 3 main hurdles from what I understand from the "loose but vaguely also ideally tight to most/all of these requirements" from this thread https://tasvideos.org/Forum/Topics/22894?CurrentPage=1&PageSize=25&Sort=CreateTimestamp 1. Dustmod afaik is not open source because it was essentially built ontop of the game's source code itself. The developer of dustmod was given permission and access from the Dustforce dev's directly to the source code to make dustmod possible. Open sourcing it would run into copyright problems. 2. Dustforce/Dustmod lacks an AV dumping tool. I dont know about KKapture i'd have to look into it. 3. a movie parser does not exist for Dustforce. Hopefully the documentation in 6. is sufficient for that to be created? Non-issues: 4. Playback across PC specs is achieved. 5. Run time can be determined by the # of total input frames of the TAS, dustmod standardizes load times. The game runs at 60fps. 6. Documentation for how to run TAS input files can be found here https://dustkidblog.wordpress.com/2016/08/07/nexus-tasing-with-dustmod/ The bottom of that documentation page has an example script file, to "play the tas" or access "the tas" as a file it is literally just a notepad .txt document with the proper Dustforce script formatting. You simply input into dustmod a "fullgamessalllevelstas.txt" into the field and it will play the inputs within that script inside the game itself. This is how the youtube and streams were created as linked by Keylie in the game thread at the time. We have had intermittent contact with Kilaye and I'm not 100% certain of the most recent status but I believe the input calling dustforce uses causes issues with libtas and so while running Dustforce's scripts through dustmod DOES work on libtas (as it isnt "polling" to send inputs but "reading" the input file for what inputs to send), porting the scripts and running inputs natively through Libtas as an emulator more directly/standardly does not fully function. It would at least be a larger undertaking that is less likely to be pursued. Running vanilla dustforce inside libtas also does work, but playback is inconsistent due to the issues which dustmod has patched.
Posted: 20 days ago
(Edited: 20 days ago)
feos
Emulator Coder, Site Admin, Skilled player (1265)
Joined: 4/17/2010
Posts: 11795
NES TAS of 2011
TheBirdOfPrey wrote:
1. Dustmod afaik is not open source because it was essentially built ontop of the game's source code itself. The developer of dustmod was given permission and access from the Dustforce dev's directly to the source code to make dustmod possible. Open sourcing it would run into copyright problems.
While open source would have been ideal, it sounds like a case that requires a little bit more leniency than with acceptable emulators.
TheBirdOfPrey wrote:
2. Dustforce/Dustmod lacks an AV dumping tool. I dont know about KKapture i'd have to look into it. We have had intermittent contact with Kilaye and I'm not 100% certain of the most recent status but I believe the input calling dustforce uses causes issues with libtas and so while running Dustforce's scripts through dustmod DOES work on libtas (as it isnt "polling" to send inputs but "reading" the input file for what inputs to send), porting the scripts and running inputs natively through Libtas as an emulator more directly/standardly does not fully function. It would at least be a larger undertaking that is less likely to be pursued. Running vanilla dustforce inside libtas also does work, but playback is inconsistent due to the issues which dustmod has patched.
If you run the movie inside libTAS and capture video using libTAS, will that work?
TheBirdOfPrey wrote:
3. a movie parser does not exist for Dustforce. Hopefully the documentation in 6. is sufficient for that to be created? Non-issues: 4. Playback across PC specs is achieved. 5. Run time can be determined by the # of total input frames of the TAS, dustmod standardizes load times. The game runs at 60fps. 6. Documentation for how to run TAS input files can be found here https://dustkidblog.wordpress.com/2016/08/07/nexus-tasing-with-dustmod/ The bottom of that documentation page has an example script file, to "play the tas" or access "the tas" as a file it is literally just a notepad .txt document with the proper Dustforce script formatting. You simply input into dustmod a "fullgamessalllevelstas.txt" into the field and it will play the inputs within that script inside the game itself. This is how the youtube and streams were created as linked by Keylie in the game thread at the time.
Making a new movie parser is quite easy, if we get a pull request that implements support for your movie format, we'll gladly merge it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 20 days ago
(Edited: 20 days ago)
Memory
She/Her
Site Admin, Skilled player (1626)
Location: Dumpster
Joined: 3/20/2014
Posts: 1823
Location: Dumpster
GBA TASer of 2020 GBA TAS of 2020 GBA TASer of 2019 Exotic platforms TAS of 2018
While open source is ideal, I believe as long as there's enough transparency as to how dustmod works and what can be done with it, there shouldn't be too much a problem in my eyes. It will be assumed that TASes done through dustmod would match or be at least close to what can be done on the base game if one were able to do the same inputs. If there are additional modifications to say physics or something, that should be disclosed to maintain trust with the community and the audience. EDIT: To clarify, I don't think you all would intentionally hide such physics changes, it's just that should be the underlying principle.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Posted: 20 days ago
(Edited: 20 days ago)
TheBirdOfPrey
🇺🇸 United States
Joined: 3/10/2014
Posts: 13
Location: 🇺🇸 United States
Memory wrote:
While open source is ideal, I believe as long as there's enough transparency as to how dustmod works and what can be done with it, there shouldn't be too much a problem in my eyes. It will be assumed that TASes done through dustmod would match or be at least close to what can be done on the base game if one were able to do the same inputs. If there are additional modifications to say physics or something, that should be disclosed to maintain trust with the community and the audience. EDIT: To clarify, I don't think you all would intentionally hide such physics changes, it's just that should be the underlying principle.
Yes that is 100% the underlying principle, we have verified that our TAS replays do playback identically and match to baseline game behavior from a player-inputs perspective (meaning outside of the camera shake and stuff) on a vanilla version of the game. There hasn't been any dustmod physics-related changes for many many years at this point (the camera shake and load race conditions are the only ones that were ever made afaik) it has been stable and stagnant of changes as far as anything related to TASing goes.
1 2