Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
I've been given a userfile for SMB3 that sets up the SRAM needed to ACE in SMB1. However, the savestate I got didn't exactly match the one used in the movie - and when I try to replay based off of my savestate, my BizHawk freezes up with no signs of life. Looking for someone else to verify the SRAM movie for me.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
What libTAS does is patch all calls to the system RNG function. I would imagine that Minecraft uses system RNG and thus an external tool could get away with fewer patches needed for RNG.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
fsvgm777 wrote:
I got it to sync just fine using the PICO-8 0.2.5g executable.
I am suspecting a config issue.
Here's the config I used.
I have an AVI dump ready.
That was it - I had foreground_sleep_ms 2, while you had foreground_sleep_ms 5. Not sure why it makes a difference for this game, maybe it has to do with the game's weird no-draw frames.
Thank you!
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
Merl_ wrote:
One weird thing about this game is that it has inconsistent load times, and that's probably what's causing it to desync in each room.
I just tested it again and it syncs perfectly fine for me.
It desyncs for me in the exact same spot every time I run it.
I've asked some other people to see if they can get it to sync.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
While judging #8702: Merl_'s PICO8 You Have to Burn the Rope in 00:23.37, I realized that the executable has literally nothing to do with the actual game. All game-specific data is stored in the data.pod file, and the executable is a just generic PICO-8 runner that can run any game. That means that the executable will have the same hash no matter which game you export it with.
This raises some questions as to whether we should catalog the runner hashes or the hashes of the actual game data itself, but that's another discussion.
By cross-referencing the hashes catalogued in #7687: ikuyo's PICO8 Star Anise Chronicles: Oh No Wheres Twig?? in 03:05.50, I figured out that the executable used in this submission was not PICO-8 v0.2.5g as you told me, but in fact v0.2.5c. (The version is also visible in the encode, and in the encode you provided, it says v0.2.5c.)
So after getting the Linux executable for PICO-8 v0.2.5c, the game will sync past the title screen. However, it desyncs at the second jump. The player character presses jump one frame too late, and that's probably related to the fact that this game seems to have some no-draw frame weirdness. Either the game sometimes has no-draw frames for no apparent reason, or the framerate of the movie is wrong, but I don't know which possibility it is.
I can remove one frame after the first jump and before the second jump to get it to sync past the second jump, but then it desyncs somewhere in the next room.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
Merl_ wrote:
What is an MD5, what is a Linux binary, and what does the stuff in yellow mean?
I'm using v0.2.5g for windows.
An MD5 hash is a type of hash. In general, a hash is a sequence of characters that uniquely identifies a string of data, such as a file. MD5 is a certain specification of a hash, and the important thing here is that libTAS stores the MD5 hash of the executable in the movie file, and will warn you if the hash of the executable you run and the stored hash are different. On TASVideos, we also use the MD5 and SHA1 hashes to identify specific versions of files in game catalogs.
By "Linux binary" here I am just referring to the Linux executable. A "binary" in this context is just an executable file.
The yellow highlights are the MD5 hashes of the files. What I'm saying is that the executable files I'm generating and the file you used to make this movie are not the same. And I don't know how exactly to generate the same file.
I tried generating the file by running the Windows version of PICO-8 in WINE, but it produces a Linux binary with the exact same hash. So I guess I would have to see if running it natively would change anything? I would have to do that later, though.
Transcription since Discord CDN links will soon start expiring:
rythin wrote:
open your game in splore
esc out until you're back to the main pico 8 screen
export gamename.bin
it will export the game for every platform, find gamename_linux
you're winner
Yes, I used the export command. However, the MD5 of the Linux binary is 6a21562c88a5f475272814d20e5145de whereas the MD5 of the binary used in the submission is b3edd6e3b0ef8dd2377b87db14e0d2e7. Also, like I said, it doesn't sync.
It might have to do with the version of PICO-8. Which version did you use? I used v0.2.5g_amd64.
Yes, those were the two links I found.
I don't see a download link on the Itch page. I can download the cart off of the Lexaloffle BBS, but it doesn't sync if I run it directly from the PICO-8 binary; neither do the checksums match if I create my own standalone binary nor does that binary sync.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
fsvgm777 wrote:
I successfully managed to get this movie to sync. All I did was carefully frame advance for the first 300 or so frames...though it seems I didn't need to do that anyway. The game's resolution was set to 1024x768 via libTAS (since it runs on fullscreen by default, so I set the virtual screen resolution to 1024x768).
I have an AVI dump ready.
It still doesn't sync for me after carefully frame advancing for 600 frames.
Is there a way you can send the AVI dump to me?
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
Randomno wrote:
Not that I know of specifically, just that Unity games can have inconsistent loads. I think this TAS is simple enough that it can be resynced, but I'm not sure what to.
Edit: I ran this in my Linux VM, as opposed to WSL, and it desyncs on level 2. Also I seem to have forgotten to note that I'm launching it with the command line option force-gfx-direct
Edit 2: Nevermind, apparently the game was the wrong size. I launched it outside of libTAS again and chose 1024x768, and the TAS syncs now.
I added 120 frames of blank input to the beginning, but the game now desyncs in Level 2. Same issue with Unity loading? And yes, I've been launching it with -force-gfx-direct. Otherwise, each frame takes an eternity to advance for whatever reason.
I also keep running into an issue that inconsistently happens where the game stalls on frame 5, 6, or 7, and refuses to advance time any more. This makes testing very annoying.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
Randomno wrote:
I extract Payload~ with 7zip as well. It's about 400MB for me.
Thanks, that should probably be in the instructions too.
After getting past that hurdle, the movie doesn't sync. It seems to start playing way too early before the "Broken Breakout" splash screen fades out and Level 1 fades in.
In the temporary encode, Level 1 fades in at 5 seconds in, but when I play back the movie, it fades in at 6 seconds in.
Is there any known reason for this discrepancy?
When I do this, 7zip only recognizes one file named Payload~ inside. Extracting it is massive and running file on it says ASCII cpio archive (pre-SVR4 or odc).
I'm unsure of how to open a .pkg. Is 7zip even meant to be able to open .pkgs or is there another, more appropriate tool for the job?
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
Randomno wrote:
Some games have a launcher, which will probably interfere with TASing even if they can successfully be ported:
libTAS will automatically bypass the launcher (by refusing to load ScreenSelector.so), so they should still work unless the porting process breaks libTAS's bypass.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
p4wn3r wrote:
Well, I've been in this site for a long while. In the old days there was even a page explaining how emulators could never be accurate, and it made no sense to compare TAS to real runs because of that, and how cosmic rays, temperature changes, or whatever, made it impossible to simulate real hardware.
Link?
And this is not the sort of specious, pedantic argument I'm making. Cosmic rays and temperature changes don't make for deterministic playback even on real hardware.
p4wn3r wrote:
The reason is that, for programming that makes sense, it doesn't matter. And if the programming doesn't make sense, don't even try to get it working, because it's likely that in original hardware it won't work either.
In Yo! Noid 2, on "original hardware" (i.e. outside of libTAS), the game works completely fine. The desyncs affect movement and desync the TAS by making the player character move in slightly different directions. To an RTA runner, it wouldn't matter, because they would adjust accordingly, but a TAS cannot do that.
p4wn3r wrote:
Take Pokemon RBY for example, it uses an RNG that calls a timing register several times per frame, and yet, real time runners can and do manipulate it with some tricks to get the input at the right time in lots of runs.
I would assume this is because it's deterministic. Which isn't much of a significant point; of course it would work, even for RTA.
p4wn3r wrote:
I cannot really comment about the run you linked, because I'm not familiar, but I've seen several desyncs, even in emulators, which control the entire execution. What's the evidence that you guys have that it was caused by multithreading?
If I remember correctly, it's because the desyncs happen whenever the game loads and transitions between levels.
p4wn3r wrote:
Asking sincerely, because I could take a look and learn from it. My first impression is that if you run Unity, which is a massive engine with lots of dependencies, many small configuration changes in the OS can affect the replay, which is the reason I'm running the game sandboxed.
Please do take a look at Unity and see if you can figure something out.
In theory, you're right that small configuration changes in the OS can affect the replay (which could be why it never synced for EZGames69 or fsvgm777), but in practice, I had to keep playing the TAS over and over before I got a run that would sync. And I'm pretty sure I didn't make any configuration changes to my OS between runs.
Experienced Forum User, Judge, Moderator, Player
(200)
Joined: 7/15/2021
Posts: 112
Location: United States
p4wn3r wrote:
Well, I think the problems introduced by multithreading are being overestimated. Definitely the end result of a program can depend on the order everything is processed, but it's in general extremely bad programming practice to do this. In fact, true concurrent code should never produce different results when you change execution order. While it's simple to come up with cases where this matters a lot, the fact is that code written by humans for humans to use does not look like that.
[...]
In general, if the output of your program depends on the order, there's a bug. In theory you could use this as a source of randomness, but it's a very bad one. It's very biased and the bias can drastically change with some small changes to the code or even changes in the platform running it. If you're using Linux processes, you really have to go out of your way to mess things up, because most interprocess communication in Linux makes everything order independent. You'd need to either use shared memory between processes and program terrible synchronization code to make this mistake. It's unlikely that an app would do this unless they explicitly want to detect virtualization.
This does not reassure me. Game development is full of buggy code. If your argument is that "programs wouldn't do this because it would result in bugs", well that's already a very tenuous argument in the best of circumstances, but these are games we are talking about. Games are full of bugs and extremely bad programming practices because developers care more about finishing their game than being correct and clean.
For a counterexample to your argument, consider any game made with Unity, a notorious engine known for inexplicable desyncs due to the many threads it spawns. Just look at how hard #7822: rythin's MacOS Yo! Noid 2: Enter the Void in 07:59.83 was to sync for publishers. After I accepted it, I needed to dump the game myself because no publisher was able to sync it.
