Posts for keylie


1 2
7 8 9
15 16
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Personnellement, je suis sur Skype et Discord, mais je préfère le second.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
I'm totally in!
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Spikestuff wrote:
Question: What's was the significance of the pause buff?
Forgot to explain that indeed. It's a rope glitch. If you pause when holding left or right on a rope, you will continue swinging on the left/right during the pause but without undergoing the effect of gravity, wind, obstacles, etc. When unpause, the game updates your position. This allows me to move right against the wind and pass through a wall, as well as avoid a trigger that moves down saws from above.
Spikestuff wrote:
Also, please playaround the credits.
Ahah, no way. I already have 50 playaround screens to work on. That is more than enough to fill everything I can think of.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Finally, the last stage of the game. It was hard for me to gather motivation to do the autoscroller section. Anyway, the TAS is not over yet, I will try to hexedit playarounds during loading screens. Link to video
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Link to video Link to video Edit: switched to YT videos, thanks Spikestuff.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
There is a problem with GameShark Converter on PSX. Codes are supposed to replace two bytes of the memory, for exemple: Code 8009D2A6 0000 is supposed to write 2 bytes 0x0000 in address 0x09D2A6 of the main memory. However, in Bizhawk, GameShark Converter is converting this code to a write of 1 byte 0x00 in address 0x09D2A6 By the way, writing the GS code without the space triggers a Bizhawk error message. EDIT: Tested with Bizhawk 1.11.9.1
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
S'il y a déjà une soumission pour ce jeu, tu peux déjà ne mettre que les techniques qui n'existent pas dans l'ancien TAS, et pointer vers celui-ci.
Post subject: Völgarr The Viking
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
The dev of the game has released an update of the game with a complete level editor, hitbox viewer and a frame advance mode. See this post
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 3-1: Link to video - Water is hard to optimize - Ice is very convenient, as you don't loose speed due to friction, so it is easy to keep several characters at the head - Small size status change a few things in the gameplay, and the worst thing is that kicking someone to project him at high speed does not work. Also, the coop boost as known in Rayman legends (climbing on top of someone, kicking, then jumping to instantly get cap speed) does not work either. So we rely on spin attack, which is also slower when small. EDIT: Link to video Link to video Link to video EDIT 2: Link to video Link to video
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 2-2 Link to video For the coin of the third part, I had to take advantage of offscreen characters getting pushed toward the inscreen. I managed to get over the wall, then used a ground pound offscreen, which resulted in a tilted ground pound to grab the coin without being killed.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 2-1: Link to video lums hunting was hard in this level because I skipped a chest, I lost a few frames here and there to grab extra lums. There is a glitch in this level: if you free the fairy on the first possible frame, then you cannot access to the next screen. The game scrolls the camera backward to the place where the fairy was saved, and not to the next screen, which kills all your characters. Thus I waited one frame before freeing the fairy.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
sonicpacker wrote:
It is 100% true that every SM64 publication (0, 70, 120) since 2010 has linked to my Direct64 encodes as the YouTube link
It looks like these do not link to your YT encode: [2062] N64 Super Mario 64 "70 stars, no Backwards Long Jump" by Jesus, Kyman, MICKEY_Vis11189, MoltovM, Nahoc, snark, sonicpacker, ToT, CeeSammerZ, coin2884, Eru, Goronem, Mokkori, Nekuran, Nothing693 & pasta in 42:58.52 [1784] N64 Super Mario 64 "0 stars" by MICKEY_Vis11189, snark & ToT in 05:04.47 EDIT: Congratulations for this very strong technical performance! Vote yes.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
It takes me about 15-20 hours for each level. The way I work is that for each screen I make Rayman go as fast as possible to the end with the help of the other characters. Then I collect as much lums as possible during the free time. If I get enough lums that way regarding my route planning, then it doesn't take much time to do. If not, this is when it becomes much harder, balancing time and lums. Don't forget that I can enter inputs for controllers separately. This is what makes this TAS possible in a reasonably amount of time. I wouldn't work on it otherwise. I can also modify inputs for previous screens (getting more lums if I'm short of) and it won't affect future screens as long as I don't modify the screen length. I use this a lot to get the exact amount of lums, to skip a animation at the end.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 1-5 Link to video - I used a door transition skip between the second and third screens which saves about 3 seconds. Just hold down during the transition. - On the next screen, I found a skip by going over the level with Rayman and jumping oob. I ground pound at the specific place, and before he gets killed (which happens when you are inside walls), I place another character in bubble next to him, and he was able to get inbounds somehow. This saves a screen transition and about 5 seconds. - The problem with this skip is that I get short on lums, so I need to collect almost all lums in the first and second screens, and all coins. Also I could not collect many lums in the third screen because it would lower the scrolling and kill Rayman.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
FitterSpace wrote:
Is there a difference between any of the characters?
Yes, there are several differences. The one that matters here is that Rayman cannot suicide itself by pressing A, as opposed to the other characters. A level transition is triggered when all characters either enter the door or are dead. Because of this, Rayman usually enters the doors because the others characters can suicide themselves rapidly.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 1-4 Link to video lums were not a problem this time, but I could not help Rayman to collect a lot of lums.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 1-3 Link to video Lums were harder to collect this time. Many lums are collected offscreen before the characters die. Lums balancing between characters is not very good :(
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Stage 1-2: Link to video Collecting the left coin offscreen in the second screen of this stage and not die was harder than expected. Indeed characters are pushed by the scrolling when offscreen, and I needed the time to get down to get the coin validated before the scrolling goes too far on the right which kills the character. Geysers are annoying. I had to wait on the second to last screen because the geyser cycle was bad and I couldn't jump on any of them.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
I'm planning on doing the any% (50 electoons) category, if I can keep the motivation.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Here is the first stage: Link to video Couple of notes: - The fastest way to move in this game is to get punched in the air. Before I got the attack power, the way to get more speed is to stop running for a frame then press down, which will trigger a dive and increased speed - For a level transition to trigger, all characters must pass the door or be killed (in bubble form). However, they will keep their bubble form at the beginning of the next section. So I must choose which character must pass the door and which must suicide itself. - Balancing the lums between characters saves time at the end of the level when the lums are filled in the bottle. I didn't get perfect balance here, but I didn't loose any time collecting lums.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
Fog wrote:
Would this also apply to Gamecube controller?
Not right now, because I only bother implementing it for wiimotes, and GC controllers are handled in different functions. But GC is actually easier to modify than wiimotes, so it would not be a problem.
Fog wrote:
Also, feel free to test this and possibly make a pull request for inclusion with Dolphin.
Yes, I thought about that. There are still a few things to fix: - Movie endings: There are still bugs when you go over the movie end with partial read-only, but this shouldn't be hard to fix - Wiimote input lenght: as opposed to GC controllers, Wii controller inputs have variable length depending on what is plugged in. Currently I don't check for the length, I assume that the input length of a controller is constant in the entire movie. It would require a bit more coding to correclty handle this case - User interface: Some more work to do here, like detecting what is actually plugged in, probably using a sub-menu, translation, etc.
got4n wrote:
Have you tried doing a few levels in TAS? This game had huge desyncs at the time! There were also multiple times I didn't TASed this game along the desync: -RAM different per levels (small reason though) -very technical, multiple ways to get different results -routing -some glitches unexplored like the zipping one -coop potential
I only tested one level and didn't see any desync, so I assumed it was fine. I will do more testing then. RAM different per level is bad. I tested that addresses were constant over rebooting Dolphin, but didn't test other levels :( I saw your zip video, I will definitively investigate that. By the way, there is a rope glitch using the pause.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
jlun2 wrote:
Would there be any plans for RAM watch?
This is not a priority, but yes. It is not a complex feature to implement, but requires time for the user interface mainly.
Fog wrote:
Is support for WINE a possibility?
I guess it may be possible, but for now you would still require to launch SDL games, which are quite uncommon on Windows. There would be several issues to address first I guess. I don't know if the hook method would work natively. Also, I don't know if the calling convention is the same for Windows DLLs and Linux shared libraries. If it is not, you have a problem here.
feos wrote:
Question: You will be able to run sdl-driven emulators that way too, right? You know... TASing emulators with no TAS tools in them.
Yes, I guess. This is conceptually making things much harder that it should be, because the emulator has much more knowledge of the game. Thanks ais523 for your feedback. I agree that my solution is less accurate in design and may completely fail on some games. This is partly because of my weak programming background and skills that I decided to go along an easy path. It is also better for my motivation to be able to get results rather quickly. I tried to look at CRIU code, but it is a very large project to understand. Also, I was thinking that as opposed to CRIU who must save the state of the process as it is, maybe we could make things easier to save the game state by shutting down some stuff. As an example, we could close all opened files before doing the savestate.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
libTAS is a software for Linux that provides TAS tools to games, such as frame advance, inputs recording, savestates. It is not a Linux emulator as games are running natively on the user system, but it creates an intermediate layer between the game and the operating system, feeding the game with altered data (such as inputs, system time). We can call such tool a translayer - a code translation layer. It tries to make the game running deterministically, although it is still an issue when dealing with multithreaded games. This layer connects to an external program to provide a graphical interface to the user, with tools such as input editor or RAM watch/search. Wiki pages: http://tasvideos.org/EmulatorResources/LibTAS.html Code repository: https://github.com/clementgallet/libTAS Stable releases: https://github.com/clementgallet/libTAS/releases
</hr> Original post: last edit: 07/2018 Hey everyone, I would like to present a project that I've been working on in the past months that brings TAS tools to GNU/Linux games. In short, this program works similarly to Hourglass. It consists on a program and a library. The library is loaded with the game, to override some API functions that the game calls. The program and the library communicate with a Unix socket. The program is in charge of gathering inputs and send them to the game, record/playback movie files, savestates, and offer a user interface. This project is still highly experimental and there are many things still to implement, but it already runs a bunch of commercial games correctly. The main lacking functionality right now is savestate support. Many ideas come from the Hourglass project, thanks to all the people that took part in its development. The source code can be found here. If think there is a benefit in developing a tool for GNU/Linux even if there is already one for Windows and the catalog of games is much larger on Windows: - OS are different, and games may be coded differently on different platform, so the compatibility list can be different even with the same approach - Part of the design are much easier on GNU/Linux that on Windows. For example, hooking functions in Windows requires multiple operations (replacing the first instruction of the function with a jump, saving that instruction to execute the original function). On GNU/Linux, it simply consists on declaring a function with the same name as the function to hook and use the LD_PRELOAD trick - If necessary, it is easier to mess with the core system by modifying the Linux kernel Here is a description of the different features currently implemented in the program: Game compatibility This project aims primary at supporting games based on SDL/OpenGL. This concerns many indie games (Super Meat Boy, Volgarr, VVVVVV, Limbo, Braid, Dustforce, etc.), including games written originally on XNA framework and ported to GNU/Linux using FNA (TowerFall Ascension, FEZ). There is also a support for low-level functions, so games using other librairies (Unity, GM:S) may have basic support. Frame Advance Frame Advance is performed by overriding the different draw functions. Frame boundaries are located just after the screen draw, and it is where the communication between the program and the game is done. Fast-forward All sleep calls by the game are intercepted and are delayed until the next frame boundary. A sleep call is done at each frame boundary to get a normal game speed, or is bypassed to obtain a fast-forward. All OpenGL render commands are skipped during fast-forward for a big speed boost. Joystick support SDL1 Joystick and SDL2 GameController APIs are captured, as well as Linux jsdev and evdev interfaces. The program support mapping keys to joystick buttons, and there is a specific controller input window to send analog inputs (sticks, triggers). Mouse support SDL Mouse API and Xlib API are captured. The pointer is made visible to be able to perform inputs frame by frame. For games using the absolute values of the coordinates (FTL, Dustforce), it works fine. For games using an ugly combination of pointer warping and using relative movement (Braid), there is a constant offset between the OS pointer and the game pointer that needs to be addressed. Input recording/playback Keyboard, mouse and controllers inputs can be saved in a file and played back. There is a basic input editor to modify inputs during recording/playback (including analog inputs), and to insert or delete frames. Determinism There is a deterministic timer implemented to advance time by 1/fps at each frame boundary. It gives the time to every function accessing time. There are several problems on multithreaded games: - Threads can have a loop that waits for time to advance. The current solution is to advance time by a tiny amount after enough time queries have been made by this thread, which is a potential source of desyncs. - Extra threads are basically uncontrolled because they are not related to frame increments. One example of such thread causing sync issues are loading threads, i.e. threads that perform a job while the main thread is still running, and notify the main thread to continue when it has finished. Video dumping Video coming from either an OpenGL rendering or a SDL software rendering is captured and encoded using ffmpeg's avcodec/avformat library. Audio playback and dumping Audio sources are captured and the mixing is done by our program. This allows us to control the playback of the audio (pause it, skip it during fast-forward, etc.). Audio can also be dumped that way, and encoded using ffmpeg. Currently SDL Audio and OpenAL librairies are supported. Also, ALSA and PulseAudio Simple are hooked so that unsupported librairies (e.g. FMOD) that output sound using one of those drivers can still be captured. HUD Some information can be displayed on top of the game screen. Currently frame count, inputs, log messages and ram watches are displayed. This works for OpenGL and SDL software renderers. Savestate Savestates are implemented by suspending all threads (using signals) and dumping the whole game process memory. Savestates can be either stored on disk or on RAM. Also, there is an incremental savestate feature to lower the size of savestates: after the first savestate, every memory page that is written to by the game is flagged (using the recent soft-dirty bit), so only modified memory is saved on a subsequent savestate. This requires extra work to save/load a savestate, but drastically reduces savestate size. Savefile management For TAS, we want to prevent the game from saving, and also store savefiles in savestates. I hooked file IO functions to detect the opening of files that are possibly savefiles (currently regular files with write access). When such a file is detected, I load the file in memory and return a file descriptor to it (using memfd_create or open_memstream). That way, modifications are made on memory and the file content is intact. User interface The user interface was implemented usng Qt5. RAM Search/Watch A basic RAM Search/RAM Watch feature is implemented. You can search on every kind of memory segments of the game (code/static data/heap/anonymous memory/etc.). You can search for integers (signed/unsigned 1-byte -> 8-byte) and float/double. You can filter results by comparing against the previous value or a constant value. For games with high memory usage, the memory search can break if stores too many values (> 1 GB for me). RAM watches can also store pointers (and pointers to pointers, etc.). To be able to get watches that are still valid upon game restart, there is a pointer scanning feature (similar to Cheat Engine). You can search for chains of pointers->offset->pointer->offset->... from a static address to the address you are looking at. Finally, you can poke values into game memory.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
I add four options "Read-only" for each controller. When the option is on, the emulator will read the inputs from the movie file. When it's off, it will read from the controller and write it in the movie file. You can see the modifications I made to the code here. I didn't test, but there is no reason it would not sync on an official build.
keylie
He/Him
Editor, Emulator Coder, Experienced Forum User, Expert player, Published Author (2822)
Joined: 3/17/2013
Posts: 391
I modified Dolphin so that I could record inputs from each controller separately, by providing a "read-only" option per controller. Here is a test on Rayman Origins: Link to video
1 2
7 8 9
15 16