1 2
5 6
Emulator Coder, Site Admin, Skilled player (1226)
Joined: 4/17/2010
Posts: 11958
JosJuice wrote:
I would be interested in hearing how the PS1 handles it, as it's the console that immediately comes to mind when I think of disc swapping tricks.
I can't be sure it's safe to proceed without this technical insight. Does anyone know this detail, or maybe where to look for 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.
Emulator Coder, Site Admin, Skilled player (1226)
Joined: 4/17/2010
Posts: 11958
So we're hitting a bottleneck with PCem (which will be the same for 86Box and even PCBox). Maximum speeds of fastest CPUs they emulate are not enough for some newer (compared to CPUs) games that would otherwise work fine on them. People have tried simply increasing the clockrate of Pentium2 up to 2GHz and it really helped with a lot of lag. But Pentium2 never worked at anything like that, best it could do was 450MHz. 2GHz was out of reach until Pentium4 in 2001. Emulation of P4 is not gonna happen soon, because people who work on those emulators consider even emulated P3 too slow for usage, and P4 is not only a faster CPU (hence slower emulation) but also has lots of features P3 didn't have. There's progress in making QEMU work in libTAS, but I'm pretty sure I'm the only person who tried it aside from keylie who made it work in the first place. So until we make qemu+libtas stable, I feel we should allow speeding up PCem if it doesn't cause glitches. It wouldn't be emulation of an overclocked CPU, but rather overclocking the emulation of a CPU.
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.
Spikestuff
They/Them
Editor, Expert player (3647)
Location: The land down under.
Joined: 10/12/2011
Posts: 6714
Location: The land down under.
As one of the people who cannot actually run the verification movies for either 95/XP, because I get desyncs on them. I'm against it, due to it's being just another level of inaccessibility that I'm personally having, so having a higher core just makes it more of a headache to me personally.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Strong for yourself and also others.
Editor, Experienced player (598)
Joined: 2/11/2018
Posts: 286
To note a few things. This won't suddenly enable every modern game to be played in PCem, because of processor instruction sets (like SSE) that Pentium 2 doesn't support, and other limitations. There has been a TAS created with the 2GHz CPU: Link to video I don't know how difficult the process was and what FPS they got while making it (450 MHz is already quite slow to work with). I wasn't aware of anyone experiencing desyncs on existing PCem movies from poor performance. If that's the case then it's probably worth making a couple of test movies to check sync with others. Also I assume this discussion will also apply to DOSBox in BizHawk, which may be more popular and I could see people requesting this in the future.
Emulator Coder, Site Admin, Skilled player (1226)
Joined: 4/17/2010
Posts: 11958
Staff discussion so far resulted in agreeing to allow this, just noting everywhere relevant that it's an impossible hack and should not be used unless it's needed. And when it's needed, it's best to be explicit about its usage (and reasons).
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.
Player (195)
Joined: 7/2/2024
Posts: 6
Randomno wrote:
There has been a TAS created with the 2GHz CPU: Link to video
Actually, I believe the guy who made that TAS (I helped him set up pcemcompiled, his name is LookingForDreams) ran the game on both 800 and 2000mHz, and he chose to do 800 because of the same loading speed, but I made a TAS of the game that only worked on 2000mHz, even though the requirement said Pentium II 450mHz, when I tested the game, it lagged drastically. As for the emulation speed, only the Windows XP startup slows down drastically, everything else feels about the same or tiny bit slower than 450mHz. Here is the TAS: Link to video And also, I posted LFD's Zuma TAS on my channel, I encoded it myself (there's an encode on his channel too, but due to it being on original resolution, 800x600, the youtube converted the 50fps video to 30, so I wanted to make sure high quality encode is uploaded somewhere, along with his permission, which he gave me), the movie does sync only IF everyone has the same hashes as the TASer's, so I asked him to send me .img, .nvr, .bin, and everything synced perfectly.
Emulator Coder, Site Admin, Skilled player (1226)
Joined: 4/17/2010
Posts: 11958
feos wrote:
JosJuice wrote:
I would be interested in hearing how the PS1 handles it, as it's the console that immediately comes to mind when I think of disc swapping tricks.
I can't be sure it's safe to proceed without this technical insight. Does anyone know this detail, or maybe where to look for it?
I talked to people on PSX.Dev discord and they told me this:
  • It's possible for games to detect lid opening ("the mechacon sends an error interrupt if you open the shell; no, most games did not handle this"), which resets the "disc valid" flag.
  • It's impossible to detect disk removal.
  • If you open the lid, replace the disk, and close the lid, that disk will be checked for validity (by trying to read the wobble groove, which restores the "disc valid" flag if it succeeds) and then the TOC will be read. Then the game could "check for some expected file on the disc when the lid is closed again" to see if it's a disk it wants. Retail PSX games didn't do this tho.
  • It's impossible to detect disk swap altogether if the lid sensor was manually pressed and held in place. Lid opening won't be detected until you release the sensor. The old TOC persists and any new disk you insert is treated like the old disk is still there.
  • It's possible to periodically verify data on a given "current" disk, but it's completely impossible to bail out the instant it's wrong-swapped. Because no matter how often you check validity of the current data, the swap may happen between the checks and then there'd be completely different code running. Reading from the disc is not instant either.
Thanks to Stenzek, spicyjpeg, and smf! So we can't say that "failing to detect an erroneous swap" is the developer's fault and a bug, if the disk was swapped without letting the lid sensor know that the lid was opened. If we close the lid normally, play the game, open it again and put in the wrong disk, or the right disk but at the wrong time, then it's up to the game to check its validity and refuse to proceed. But it'd be weird to differentiate those 2 in emulation, because there we're not forced to close the lid in order to launch the game, and there's no way to emulate whether it was closed for real or whether we just fooled the sensor without closing 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.
Emulator Coder, Site Admin, Skilled player (1226)
Joined: 4/17/2010
Posts: 11958
feos wrote:
The analogy with save corruption sounds fair. The system does some action that depends on certain events happening (or not happening) in real life: while the program is doing its thing the user needs to not power off the device, or the user needs to put another disk in. Trying to come up with a solid borderline for those based on accurate technical knowledge would be hard. I can't find threads about why save corruption was allowed in the first place, and posts on the first few submissions that reset during saving don't explain it. It just happened to work in emulators and on console, and then it was automatically assumed to be a valid glitch technique. Thread #8026: How well do emulators emulate resetting during saving? happened after, and the explanation from then-admin was "because it's emulated and because it's awesome". How accurately it was emulated was questionable, but I guess fundamentally/conceptually it wasn't as bad as relying on emulator-only bugs but on bugs in games, because developers could have written protection against save corruption but haven't until later. So my main question with unintended disk swapping is this: Can game devs protect against disks being removed from the tray at the wrong moment?
Sorry I forgot about this. Turns out the analogy with save corruption is in fact not correct. Protecting against wrong disk swap on PS1 is unrealistic. Which means it's a part of the environment that just has to be assumed working correctly by developers, much like cartridge game developers have to assume you won't be partially pulling out (or entirely changing) the cartridge mid-play.
feos wrote:
arandomgameTASer wrote:
The grey area, of course, would be using discs outside of a run's context, which I think has already been covered with the Super Mario Bros. ACE movie which uses Super Mario Bros. 3 to achieve ACE in a different game. If we were to assume a different disc was used to setup a memory card, then that could be accounted for in the movie itself. If it's JUST the usage of a different disc being inserted at the right time, that can also be accounted for in the movie itself. Whichever way you look at it, the usage of these different discs can be considered part of the movie itself and not extrinsic to it ala SRAM manipulation to load a save file that immediately beats the game, or something. [6012] NES Super Mario Bros. "arbitrary code execution" by OnehundredthCoin in 04:52.65
That movie was a crazy technical feat aiming for amusement, so it could have only been published to Alternative. I do not think that using games images not belonging to the game in question should be eligible for Standard (aside from that unique case when the game explicitly demands arbitrary extra images to be used, but even there we limit to hand-crafted ones or other games for that system, since availability of those is a given for TASing that system). A movie using 20 different game disks for maximum insanity works fine as a technical showcase, but not as a legit speedrun of any of those games.
There's still a question where to put "wrong disk swap" movies other than Standard, and with our most recent proposal about Playground, difference between it and Alt will be just conceptual. Maybe PG would fit better because such a movie apparently does compromise the intended environment.
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.
Emulator Coder, Site Admin, Skilled player (1226)
Joined: 4/17/2010
Posts: 11958
Non-standard endings can now be dictated by the goal https://tasvideos.org/MovieRules/History#NonStandardEndingsCanBeDictatedByTheGoal20260603 https://tasvideos.org/Wiki/PageHistory?path=MovieRules&fromRevision=114&toRevision=115 It took is a very, very, VERY long time to figure this out, but I think the resulting policy covers all the important cases, while also more or less matching an existing trend/direction. The scope of changes that were actually warranted was the hardest to solve, like are we ready to declare game completion entirely optional? #9270: InputEvelution's Flash Papa's Donuteria "Rank 5" in 10:56.27 is an example of the trend, where rejecting something that's the most popular RTA goal felt like a very bad idea, yet it didn't meet our Standard rules, so it was accepted after some amount of in-game loops were completed, even though that ending may feel arbitrary in isolation given how TASVideos historically viewed game completions. But since those old strict times we switched to embracing the TASers and entire communities of TASers (and speedrunners). If a lot of people care about some goal, then it automatically has value, subjectively, which is the whole point of Alt. Strict formal definitions are not worth obeying (or even keeping) if they don't serve the overall community we are supposed to be inviting for. And isolation from actual TASers is the opposite of what this site existed for: we're not RulesVideos, we're supposed to stand for everything TAS that is creatively cool. But if we worded that rule as something simply community-dependent, then games without a community would be in a weird position, because what if some game only has 2 TASers, and they disagree on a given goal? Or what if some TASer had a different opinion on some goal than the rest of that game's community? We wouldn't want communities to stifle any one person's creative vision, the entire scene is big enough to fit everything that is really well done. So instead we moved the focus from game-defined endings to Alternative goal-defined endings. Because there's no other way to handle #9603: frKieran, mkdasher, SilentSlayers, snark, Krithalith, Crackhex, Manama, FeijoadaMolhada, ChouxZi3, Alexpalix1, Superdavo0001, tesserakt & IsaacA's N64 Super Mario 64 "all trees" in 08:25.183 without introducing a giant change to the whole scene (which warrants a giant discussion). The change we made is local and easy to understand. And that change is not fundamental, it just includes a few more things now, in addition to those already there: playarounds were always allowed to end wherever the authors wanted considering the creative nature of the goal. And entertainment is the main criterion for playarounds even tho the rest of Alt goals don't have it, but for playarounds there's no way to judge them by any other factor. So whatever is the most entertaining is much better than going out of your way, losing pace, just to meet some format requirement. That quite literally means that artistic ending made the most sense for playarounds. And that idea is safe to extend on the entirely of Alt goals: just end on something that makes the most sense for the goal! Of course traditional game end is preferred if it's a trivial matter to append it - meaning it's not hard to do and it doesn't change the nature of the goal. And if adding game ending changes the route to the point that it now looks like a different goal, it's perfectly fine to publish that separately.
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.
1 2
5 6