1 2
Posted: 10/15/2023 1:06 PM
Quote
Samsara
She/They
Senior Judge, Site Admin, Expert player (2241)
Joined: 11/13/2006
Posts: 2822
Location: Northern California
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 Admin and acting Senior Judge 💙 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
Quote
Memory
She/Her
Site Admin, Skilled player (1558)
Joined: 3/20/2014
Posts: 1767
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
Quote
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
Quote
feos
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11495
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
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
Quote
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: 10/16/2023 12:07 AM)
Quote
CasualPokePlayer
Emulator Coder, Judge, Experienced player (732)
Joined: 2/26/2020
Posts: 790
Location: California
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 instance 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.
1 2