This topic is for the purpose of discussing #6564: letcreate123's Linux You Have to Win the Game in 04:46.58

ngl, when I saw the thumbnail for your temp encode, I thought you were recording your tas with your phone camera. (yes vote)

Either way: nice run, and 3:54 would be nice screenshot.

Just like for the first time, it's a yes from me

Still crashes after frame 1, with libTAS 1.3.5 i386, on 64bit Ubuntu.

Attempt 1: Connected.
[libTAS f:0] Thread 1250 (main) OpenGL vendor: VMware, Inc.
[libTAS f:0] Thread 1250 (main) OpenGL renderer: llvmpipe (LLVM 8.0, 256 bits)
[libTAS f:1] Thread 1250 (main) ERROR: Could not import symbol swr_alloc
Got unknown message!!!

Made it run by going to /usr/lib/i386-linux-gnu and executing

Language: shell
sudo ln -s libswresample.so.2 libswresample.so

Getting this spam though:

Language: shell
[libTAS f:1] Thread 1356 (main) ERROR: Could not import symbol av_opt_set_int
[libTAS f:1] Thread 1356 (main) ERROR: Could not import symbol av_opt_set_sample_fmt

I'm getting this error when trying to dump a video:

Language: shell
Error while decoding stream #0:1: Invalid argument
[rawvideo @ 0x5555557de100] Invalid buffer size, packet size 1224898 < expected frame_size 1228800
Error while decoding stream #0:0: Invalid argument
Finishing stream 0:0 without any data written to it.

I used these game settings to make it look bearable too (doesn't affect the dumping error): https://i.imgur.com/58czpho.png For direct manips, the game folder is in /home/you/.local/share/Minor Key Games/You Have to Win the Game

This should be added to movie annotations then.

That can be fixed by simply running the following from /usr/lib/i386-linux-gnu (suggested by keylie on Discord, confirmed to work):

Language: shell
sudo ln -s libavutil.so.55 libavutil.so

That also fixes the two errors that popped up every frame.

Thanks. I never ran into this issue when testing my TAS on my native (non-VM) Linux Mint environment, so I never knew it was a thing, but I tested this on my Kubuntu Virtualbox VM on Windows, ran into the same error as feos, then did as fsvgm777 suggested and the TAS played properly from that point on. I will post the movie file with updated annotations shortly. EDIT: Here it is. EDIT 2: Link that actually works.

I get "Downloading: TheGame_NFML.ltm" that never gives me the actual file. Use this instead http://tasvideos.org/userfiles/my#uploadfile

Dump: if anyone wants to publish this: https://yadi.sk/d/G5QgpwIOlKPUKA

Pretty fun and short speed game. I tried it out for myself and even got a couple deathless runs, though nowhere near RTA speed. You managed to work out the desync problems, which is cool (but why are there even desync problems in the first place? I thought libTAS was invented to play back computer game TASes in a deterministic manner). Certainly I wouldn't have the patience to stick around if desyncs were going to be a problem.

ngl, when I saw the thumbnail for your temp encode, I thought you were recording your tas with your phone camera.

Same here! I wonder what the average time was so far for the viewer to figure this out.

This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [4087] Linux You Have to Win the Game by letcreate123 in 04:46.58

Hi everyone. I have a question about the encode. I noticed that the pixels aren't all the same size—I think they've been point upscaled by a float value rather than an integer value. So some lines are 3 physical pixels in size, and others 2. Is this intended? Judging by the frequency of the larger pixels (one every two lines) it seems the game is 320x180 (16:9) and was point upscaled to 320x240. I get that this is designed to be displayed at 4:3 since it's designed as a late 80s game (although I'm sure the 320x180 size was also intentional to be able to nicely fill today's TVs and monitors) but wouldn't it be preferable to physically upscale it to 2560x1440 and then down to the final dimensions? It's been a long time since I encoded anything for this site, so I apologize for barging in and asking this question. :) I'm just confused because back then it was considered important to always keep the pixels square physically and use meta-info to force it to a specific aspect ratio if that was desirable.

The game renders a 640x480 screen, and its weird pixel sizes seem to be intended.

I don't think that's the case. When you look at official screenshots using the CRT emulation mode, you can tell it doesn't have different sized pixels. It's visible even without zooming in. Besides, that would be an extremely weird creative decision anyway. No game from the 80s ever had anything like this. The game seems to simply set a convenient, compatible resolution and then scales to that resolution. 640x480 is a common and compatible resolution, but 640x400 or even 640x360 are not. This also happens in the browser version. Setting the canvas to 320x200 causes the game to have square pixels. Anything else that isn't a multiple of that and the pixels are not square. If you set it to a high resolution 4:3 size, the pixels naturally look much more even. Just to clarify, I'm not saying someone has to go and immediately redo this encode. But it seems clear to me that the game was meant to be rendered as square pixels, then scaled to 4:3.

If you get the linux release and configure it to show all square pixels without any filters, I'll agree.