Lua: Show a future frame

[SuuperW]

This is an alternative to the invisible emulation changes made in #4592. (If this is merged, the unpausing thing from that PR still needs to be done.)

The old seekframe and invisibleemulation API methods have been removed, in favor of show_future.

Tool updates do not run during future emulation. Tools used to update during invisible emulation, which caused problems. But Lua would not update during seekframe (except that input and memory callbacks would run), so this matches old Lua behavior.

It is possible that a user would want Lua to run during future emulation (or in old terms, invisible emulation) but we can't know that. If we want to support this, it should be something such that scripts must opt-in to running during future emulation since most things should not run there. Maybe a new type of event.

Check if completed:

• I have run any relevant test suites
• I, the commit author, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant

[vadosnaprimer]

This is an alternative to the invisible emulation changes made in #4592. (If this is merged, the unpausing thing from that PR still needs to be done.)

What if the other PR is merged first?

It is possible that a user would want Lua to run during future emulation (or in old terms, invisible emulation) but we can't know that. If we want to support this, it should be something such that scripts must opt-in to running during future emulation since most things should not run there. Maybe a new type of event.

An event sounds good, tho I'd wait for a request to add it, because I can't imagine a case when it's needed.

[vadosnaprimer]

Looked at the code and I absolutely prefer this approach, great idea! Just please mention in the docs that the function we pass will be automatically passed current frame as an argument (or whatever its argument is, but that's what I understood by looking at it).

Also mention that actual current frame remains the same, the only thing that changes is visuals that are taken from the target future frame... and possibly what it's used for, like we hack memory and then make that hacked frame appear. Because fake frame advancing now happens under the hood, so this info needs to be explicit.

[SuuperW]

What if the other PR is merged first?

It should not be merged at all. I think this one is better and since you agree (and no one has disagreed) I will go ahead and close the other. I can directly commit the unpause fix to master.

An event sounds good, tho I'd wait for a request to add it, because I can't imagine a case when it's needed.

Agreed. Besides, the callback that already exists for checking if the desired future frame has been reached would likely be able to serve that purpose.

[vadosnaprimer]

I can directly commit the unpause fix to master.

Any news on this one?

[vadosnaprimer]

I tested this with sonic advance camhack in tastudio and it feels seamless! Video in the encode works as intended too.

Audio is unusable but it wasn't usable before either, and we don't exactly needed it anyway because normal encode's audio could be used. Fixing the audio may be tricky too because it can't have pauses in the dump anymore, so that bit would have to be fixed first. Low priority overall.

[SuuperW]

Any news on this one?

The "fix" I had intended to make at that time was somewhat problematic. I went with updating the documentation instead, telling users why the behavior is what it is and how to get what they want. That's still not totally ideal, since it won't work from a callback. But that is not related to this PR. Re-open #4591 if you want something done about that.

Audio is unusable

I was wondering about that, it looked wrong. But I don't plan on fixing that since it was already broken.

Suggestions were either implemented or not considered worthwhile.

[vadosnaprimer]

conflicts appeared :(

[SuuperW]

conflicts appeared :(

And were resolved. I'll go ahead and merge it for you.