@FrodeSolheim is there a chance for this PR to make it into the next release? The tweaks are minor and should be safe for regular use, but it'd help the TAS scene immensely!

Hi, I think something like this can be included in FS-UAE soon, yes :)

But, I do not want to reuse the deterministic option - that's intended for deterministic emulation, for example netplay. In this case, one should not affect vsync operation, so this needs a separate option.

So you would like a specific option for this, right? Something like sequential_execution, without proper documentation?

@clementgallet Yes, I was thinking amount something like 'sequental_execution' (not sure what you meant with "without proper documentation"...).

This pull request can not be included as in FS-UAE due to the underlying fsemu library being rewritten, but I'm still positive to include a sequential execution option.

So I can better understand the need, can you give some more details regarding "Because libTAS executes some important code during render calls, which can happen in the middle of a computed frame, it messes up the result of the computed frame."?

Sorry, I probably meant to write "with" instead of "without".

libTAS is a program to add TAS tools to generic games/emulators, so it has to define when a frame starts and ends, without knowledge of the underlying game/emulator code. The definition of a frame that libTAS is using is the time between two screen rendering, which is usually what games/emulators are doing:

while (true) { // game loop
    getInputs();
    runEngine();
    renderScreen();
}

libTAS needs to run some important code between frames, including getting inputs of the next frame from the input file. So, libTAS hooks all rendering functions, and executes the frame boundary code.

It works well in a single-threaded execution, resulting in this:

while (true) { // game loop
    getInputs();
    runEngine();
    renderScreenHooked();
}

renderScreenHooked() {
    updateInputsFromFile();
    realRenderScreen();
}

The problem arises when the game/emulator runs the rendering code in a separate thread, while all the game engine/emulation is done in the main thread (including inputs handling). Inputs are now messed up in two different threads, resulting in undeterministic behavior:

while (true) { // game loop
    getInputs(); // rendering can happen here, resulting in mixed-up inputs 
    runEngine();
    signalThreadToRender();
}

@FrodeSolheim ping :)

@vadosnaprimer Sorry for not getting back to you; yes, your explanation was very clarifying, so I understand the usecase now :)

As mentioned previously, FS-UAE is being revorked, so this pull request itself is somewhat irrelevant for the future.

I'm positive to including an option for this in FS-UAE (either creating it myself or accepting a pull request). I can also accept this pull request into the fs-uae-3.0 branch in case there will be more 3.0.x releases (not certain) if there is a separate option to enable (deterministic_rendering?)

Closing for now (either implement separate option for FS-UAE 3.0.x, or we'll get back to this with another implementation for FS-UAE 4.x)