Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Always nice to see more PICO love, voting yes but wanted to point out that I did TAS this gamea couple years ago and I believe I used some strategies that you seem to have missed. Overall optimization should be on par or most likely better than mine, Vexxter has this habit of improving my previous work without really trying I've noticed :p
Main things to look out for is the exiting of levels early and the damage boost on level 5. I'm not sure about the damage boost route being faster but the level exits could definitely be implemented to shave off a couple seconds, though I could see it being a stylystic choice not to do that as quitting the levels early means the stats don't get saved and displayed in the menu.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Taking hits leads to a pretty lengthy stun animation during which I can't shoot, you can see it at around 1 minute in the one damage boost of the run. To be fair I didn't time taking damage vs dodging but every boss except for mario maintains max fire rate despite jumping. Mario is the only one that loses a couple frames per jump (i believe i was like 1 or 2?), which is still a lot less time than the stun animation.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Nice run! I like that the waiting time caused by the animations make it so the TAS is actually fairly easy to follow, unlike some other point and click games.
As a note, TASes are not timed with the same conventions as RTA but rather just go from game startup to the last input. That's also what caused the submission title to say a much longer time than your timing following RTA rules, you didn't trim your input file so all those extra non-inputs are counted in the final time. You can upload a fixed input file to userfiles and link it here, a judge should replace it whenever they get a chance to.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
ikuyo wrote:
Just checked sync, and the movie desyncs right away in level 1
Could you check if you have a ~/.lexaloffle/pico-8/config.txt file? in my experience that tends to be the culprit for desyncs on PICO-8 games
Yep, here's the contents of my config:
// - - - - - - - - - - - - - - - - - - - - - - - - - - - -
// Configuration for pico-8
//
// config.txt is read on startup and saved on exit.
// To generate the default config.txt, delete this file.
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - -
// :: Video Settings
window_size 896 896 // window width, height
screen_size 0 0 // screen width, height (stretched to window)
show_fps 0 // Draw frames per second in the corner
// :: Window Settings
windowed 1 // 1 to start up in windowed mode
window_position -1 -1 // x and y position of window (-1, -1 to let the window manager decide)
frameless 0 // 1 to use a window with no frame
fullscreen_method 1 // 0 maximized window (linux) 1 borderless desktop-sized window 2 hardware fullscreen (warning: erratic behaviour under some drivers)
blit_method 0 // 0 auto 1 software (slower but sometimes more reliable) 2 hardware (can do filtered scaling)
// :: System Settings
foreground_sleep_ms 5 // number of milliseconds to sleep each frame. Try 10 to conserve battery power
background_sleep_ms 20 // number of milliseconds to sleep each frame when running in the background
sessions 20 // number of times program has been run
// (scancode) hold this key down and left-click to simulate right-click
rmb_key 0 // 0 for none 226 for LALT
// Desktop for saving screenshots etc. Defaults to $HOME/Desktop
desktop_path
// 1 to allow controller input even when application is in background
read_controllers_in_background 0
// :: Audio Settings (use "volume" for PICO-8)
sound_volume 256 // 0..256
music_volume 256 // 0..256
// :: usually 1024. Try 2048 if you get choppy sound
mix_buffer_size 1024
// :: map scancodes. Format: 44=47,80=89,.. (scancode a, scancode b -- when press a, generates b)
// run the program with -scancodes to determine which scancodes to use
map_scancodes
// :: pico-8
version 0.2.5e
// audio volume: 0..256
volume 256
// Location of pico-8's root folder
root_path /home/user/.lexaloffle/pico-8/carts/
// Location of cartridge save data
cdata_path /home/user/.lexaloffle/pico-8/cdata/
// Specify which player index joystick control begins at (0..7)
joystick_index 0
// Custom keyboard scancodes for buttons. player0 0..6, player1 0..5
button_keys 0 0 0 0 0 0 0 0 0 0 0 0 0
// Play notes as they are plotted in frequency mode
live_notes 0
// iff 1: when using keyboard cursor, snap to closest pixel / map cel
cursor_snap 0
// 0 default 1 dark blue background in code editor 2 black background in code editor 3 gray background in code editor
gui_theme 0
// scale of screenshots and gifs // 2 means 256x256
screenshot_scale 3
gif_scale 2
// maximum gif length in seconds (0..120; 0 means no gif recording)
gif_len 8
// when 1, reset the recording when pressing ctrl-9 (useful for creating a non-overlapping sequence)
gif_reset_mode 0
// 0 for off. 1 for auto. 2 to allow control of a cart's framerate due to host machine's cpu capacity
host_framerate_control 1
// filter splore cartridges
// 0 off 1 on (exclude cartridge tagged as 'mature' by community)
splore_filter 0
// tab display width (1 ~ 4 spaces)
tab_width 1
// 0 off 1 on: draw tab characters as small vertical lines
draw_tabs 0
// 0 off 1 on: record the current cartridge and editor view every 3 seconds (see [appdata]/activity.log.txt)
record_activity_log 1
// 0 off 1 on: allow F6..F9 (alternative: ctrl 6..9)
allow_function_keys 1
// 0 off 1 on: automatically check for a newer version of a BBS cart each time it is run.
check_for_cart_updates 1
// hide mouse cursor for n seconds when typing.
auto_hide_mouse_cursor 5
// 0 off 1 on: backup with a new timestamped filename on every run
// normally not needed -- was used for debugging crash-on-run
aggressive_backups 0
// back up cartridge in editor every n minutes when not idle (0 for no periodic backups)
periodic_backups 20
// global screen transformations:
// 129 flip horizontally
// 130 flip vertically
// 133 rotate CW 90 degrees
// 134 rotate CW 180 degrees
// 135 rotate CW 270 degrees
transform_screen 0
// 0 off > 1: colour to draw pixel grid in the gfx editor at zoom:8 and zoom:4 (16 for black)
gfx_grid_lines 0
I only ever changed the window size so I assumed it'd sync fine on whatever's default, hope this helps anyway.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
I don't see how using upper/lower case letters or accents would make it a single keyboard. On the physical device you still need to press the "base" key to modify it, in most cases at least, and if we're talking a theoretical keyboard with separate keys for lower/upper case then I think we can also assume that theoretical keyboard can have repeat keys.
I personally see it as the same thing as mixing keyboard/controller or using multiple controllers, which I haven't seen be questioned before.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Joining the improvement train to show off something really dumb I was made aware of while working on another game. Here's a 15 frames faster input.
I achieved this by manually editing the input file inside the ltm. Doing this allows for some cursed shit sending any inputs in any order in a single frame, including the same input twice in a row. It's strange behaviour and I suppose it might be good to have a discussion on whether something like this should even be allowed but as it stands it's probably the best way to do anything text-based in libTAS.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
I've always felt like Standard was missing a goal for something along the lines of "forgoes the use of one common glitch", where the movie can still feature many glitches of various severity, but omits one particular one that would otherwise be repeated throughout the movie.
#7874: GMP's GC Prince of Persia: Warrior Within "zipless" in 24:56.15 is a great example of this in recent memory, though I'm sure there's many others that also fit the description.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
From my understanding of it, using off-screen clicks can lead to one of two outcomes:
Option A - The technique is used to click a menu option before it slides into frame, saving a small amount of time.
Option B - The technique is used to save major amounts of time by directly interacting with gameplay in some way, either allowing for glitches that lead to major skips or significantly skipping intended waiting sections as happens here.
In the case of option A, I don't believe it's enough for a separate branch. I see it more like language choice - a cosmetic change that might end up saving time but should not be considered an improvement over a movie that does not use it.
As for option B, it absolutely should be a separate branch. My initial thought would be to put both branches in Standard, with the one using off-screen clicks as the baseline, since I believe that's how it currently works with L+R input in older console games? Though doing it another way may be more practical, I'm rather new to the site and don't yet fully understand the decision-making behind how the branches and classes are structured.
In the case of this movie, as well as Arsenal, I think it's more along the lines of option B.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
If user submits unoptimized TASes and shows no signs of trying to improve, I could see it being beneficial to limit them for some period of time. Definitely not permanently (which I assume is how it is currently? I'm fairly new to the site so unsure) but a couple weeks, maybe a month could serve as a "cool down" period or maybe an alert that they really should try harder before submitting.
I'm not really sure how to word it in a way that doesn't sound elitist so I'd just like to clarify that's not my intent here. I see it more as something like a timeout in a twitch chat or a kick from a discord server, something with temporary consequences that lets the user know they should change something in their behaviour.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
I can personally second what Spike has said about the game being very crash heavy, that said, from what the author has said and looking at the input file it appears the movie was simply made by playing the game in real time (well, as real time as libTAS will allow anyway) and as such is quite subopitmal. I understand dealing with a crash prone (and allegedly desync prone though I haven't played around with it enough to confirm myself) game is really frustrating but it seems to me that Tegron doesn't quite understand the TASing process. Luckily there are guides that go over just that, which I personally would recommend reading or watching the ones on youtube. Of course they don't apply to the libTAS workflow exactly, but they should still give a good idea of how the process should look like.
As for the goal choice, I understand starting out with the shortest possible ending, though I hope to see a more "full" run if the TASing conditions can be improved.
Voting No for poor optimization, but would love to see you have another go at it!
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
I'd argue they're not exactly entertaining either. Again, the run would look pretty much identical regardless of character, as any differences between them stop being visible the moment you finish your item build.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Character choice is also clear and aimed at optimization, and I’d be interested in seeing runs with other characters as well, which would also count as separate branches.
I can't help but feel this would introduce unnecessary bloat to the branches. While having different endings as separate branches absolutely makes sense, since the gameplay is significantly different to acquire the various endings, the characters in this game are all pretty much the same. Any differences they might have quickly get overshadowed by the item build acquired in the run.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Can you try running it with gl? I've had desyncs between gl/vulkan but from what the others were saying it seemed like I'm the only one, so the resync was for gl. Spikestuff was able to confirm sync on either option.
I don't think it should make a difference, but I'm on WSL.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Yeah, there's no SRAM needed. The game is meant to end at the Mom fight on the first run, after which you unlock the intended way to descend down further. By creating a trapdoor arbitrarily by using an item, rather than relying on one created by defeating the boss, you can sidestep that unlock requirement.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Gotta love the loud menuing jumpscare.
As for the run itself, I really liked it! The movement was smooth, the combat looked good and the skips were cool! It's a shame so much of the game gets cut out by the menu storage glitch, would love to see a no menu storage or all levels TAS in the future, though I imagine that would be quite the undertaking.
Yes vote!
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Short answer: You don't.
Long answer: At the moment there's nothing reliable on Windows. If your game has a Linux port, you can use libTAS. If the game is made in Gamemaker Studio or Unity, a Linux port can be attempted to use with libTAS, but is not guaranteed to work.
If all else fails, you could try Wine in libTAS or AutoHotKey, but both of these should be a last resort option as they're horribly unreliable and you're not likely to get anywhere with them.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Thanks!
Patashu wrote:
Would you consider TASing "Platnium God, Chest" too?
I was planning out a Chest run from a fresh file, I would like to do a TAS with some savefile progression and I have a way of making it not as repetitive as would be expected :p
I was considering doing one from a completed file aswell but I'm worried that it would just be the last segment of the fresh file TAS with nothing new that's full-save exclusive. I have big plans for Isaac though, there's definitely gonna be a couple more movies submitted from me over the next couple months.
Experienced Forum User, Published Author, Skilled player
(1144)
Joined: 11/4/2021
Posts: 47
Hello, over the last couple months I've been planning out a couple of TASes for some roguelike games like Binding of Isaac or Risk of Rain, however I'm running into something that could be a potential issue.
As you probably know, roguelikes have some randomization to each run to make it unique. For the purposes of a TAS, obviously one would manipulate that randomness to get the best RNG and save time. My issue is any run that revolves around acquiring unlocks rather than just reaching the credits once. With libTAS's ability to change the system time mid-TAS, it's possible to restart the game and re-seed RNG to the same value it was at the start, meaning that you don't have to manipulate RNG again for another good start when the TAS has to do multiple playthroughs (runs) of the game. Of course, this might make the TAS quite repetitive to watch, always having the same start of the run and only potentially diverging somewhere in the middle (or potentially not at all, depending on the task at hand).
So I guess my question is, what do I do about it? Do you think it's fine to have repetitive segments like that, or should roguelikes TASes forgo re-seeding to the same seed and do even more RNG manipulation?
Another question, also related to roguelikes. As far as I can tell, TASVideos prefers TASes made from what's essentially a "fresh install" of the game with no or minimal previous data. This is usually fine as a "default run" of most games would start from a new game, fresh savefile etc. However in roguelikes, both in normal play and speedrunning, the "default run" tends to be done on an existing savefile, usually fully completed. This is reflected in RTA speedrunning communities who will tend to run on either fully or partially completed savefiles.
So with that in mind, would it still be preferred for roguelike submissions to include the "setup" section as part of the TAS (for example, unlocking the true final boss), or should it be in a separate verification movie and have the actual submission be more comparable to a normal run or an RTA speedrun?
