Lua cannot unpause when user presses frame advance key

[SuuperW]

Summary

The frame advance key pauses, and this happens after Lua has run for the frame that was advanced.

Repro

Run this Lua script:

while true do
	client.unpause()
	emu.frameadvance()
end

Observe that the frame advance key still causes emulation to pause, and this is true even when already paused: Lua cannot unpause on frame advance. A user frame advancing through a movie will want their Lua script to be able to conditionally unpause (e.g. to enable Lua-based seeking).

This is a unexpected behavior that has existed for a long time, but was unreported and perhaps unknown until #4347.

Related to this, is the question of whether the above Lua script should keep emulation unpaused when the user presses the pause button. After all, it would make sense if client.unpause(); emu.frameadvance(); always triggered a frame advance.

An alternative solution for the particular use case that uncovered this issue might be to introduce a new Lua method that does what emu.frameadvance suggests in its name: actually trigger a frame advance. This would still need to be done in a way that does not pause emulation. And regardless of if we do that, I think Lua should be able to unpause after a frame advance.

[RetroEdit]

For the pause button more broadly, I have occasionally found Lua pause interactions to be unintuitive, but having an "unpausable" script (where the only way to pause is to disable it and then pause) also seems like it might be somewhat annoying. I think the basic status quo should retain pause button responsiveness, but I'm not opposed to further new Lua API components that are able to override it.

[SuuperW]

having an "unpausable" script (where the only way to pause is to disable it and then pause) also seems like it might be somewhat annoying

Yeah, but supposedly anyone running such a script actually wants that. And my example script was just to demonstrate behavior, a typical Lua script would only unpause when some condition is met. I think it's more important to focus on what makes sense for people creating scripts, and on what is possible to do.

For scripts that seek only a few frames to get into some particular state (as it seems is the case for some camera hack scripts that apparently need to do this, but there are other reasons one might want to have a similar behavior) I think that it makes sense for users to want to be unable to interrupt the seek (except that stopping the script should always be an option). It might actually be the case that we need to support more than one kind of seeking?

I think that it might be helpful for Lua scripts to be able to know if the user is holding the frame advance key, as well as for Lua to have a OnPauseToggle event.

I made a Lua function that should be a reasonable short-seek:

-- Seek forward to a given frame.
-- This will unpause emulation, and restore the users' desired pause state when seeking is completed.
local function invisible_seek(frame)
	local pause = client.ispaused()
	client.invisibleemulation(true)
	client.unpause()
	while emu.framecount() < frame do
		-- The user may pause mid-seek, perhaps even by accident (e.g. releasing frame advance)
		-- In this case, we will unpause but remember that the user wants to pause at the end.
		if client.ispaused() then
			pause = true
			client.unpause()
		end
		-- Yield, not frameadvance. With frameadvance we cannot detect pauses, since frameadvance would not return.
		-- This is true even if we have just called client.unpause.
		emu.yield()
	end
	
	client.invisibleemulation(false)
	if pause then client.pause() end
end

With a quick test, the seeking and pausing seems to work on master. But, it does not work reliably with the linked PR because releasing frame advance won't pause and so the Lua script won't know that it should pause after a seek if the seek began while continuous frame advancing via frame advance hotkey. So we need a way for something like this to work, while also making it so a simple client.unpause() works as expected if it happens during a frame advance.

EDIT: Fixed. But I did notice that invisible emulation doesn't work. Code comment says it Disables updates for video/audio, and enters "turbo" mode.. Idk if the disabling of video is just for cores with support for skipping rendering, but I did not observe any disabling of video and it definitely did not enter turbo mode. There's a property FastForward that is used for CPU throttle, but this property is never written to. Uses of it should probably be replaced with IsFastForwarding. Separate issue.

[vadosnaprimer]

Why is client.invisibleemulation() involved if we only need to seek? Does the problem appear without client.invisibleemulation()? I can't understand the actual workflow described in OP that this problem hinders.

[SuuperW]

I only used invisible emulation in the function I posted to speed up the seek. The problem occurs without it.

I can't understand the actual workflow described in OP that this problem hinders.

I didn't really describe one beyond "seeking". But I can imagine someone may want a Lua script that does something similar to skipping lag frames. Maybe there's some game-specific notion of lag. Or maybe there's some entirely different reason someone wants to only see certain frames while stepping through a movie.

while true do
  emu.frameadvance()
  while not frameIsRelevant() then -- pretend the user made this function
    local pause = client.ispaused()
    client.unpause() -- this has no effect in either current release or master, and that is the problem
    emu.frameadvance()
    if pause then client.pause() end
  end
end

I suppose an alternative solution to this issue that requires no behavior changes would be to update the documentation for client.unpause, to inform the user that it must not be used in combination with emu.frameadvance(), and that emu.yield() should be used to wait for a particular frame instead.