Async improvements + Async Inn Sequence

[mateofio]

Depends on #1742

The PR has 2 goals:

• Refactor the async framework:
  • Don't use globals
  • Kill transition game temp vars
  • Support parameters for async ops
• Change Inn Fade Out, BGM, Fade In sequence to be asynchronous

Test Cases of #1689

• Test 1
• Test 2 - Requires message fixes - to be done in a later PR after message refactor commits get in.
• Tests 3 - 5
• Test 6 - not sure we even want to emulate this..?

[mateofio]

I retested #1819 and Ghabry's async test case from #1784

I rebased a local copy of this onto #1881 and retested both #1261 and #1840

This is as much as I can do for the Inn until some of the message work is done.

This PR is done and ready for review.

[Ghabry]

RFC: Is there any way to combine this with the Async code we have for emscripten or do you consider them too different?

[mateofio]

RFC: Is there any way to combine this with the Async code we have for emscripten or do you consider them too different?

Which async code are you referring to specifically?

This one is a sort of poor mans way of turning our game loop into a resumable co-routine.

[Ghabry]

I mean the Async code for downloading files that emscripten calls (async_handler.cpp)

[mateofio]

They already kind of work together since file IO works the same as animating transitions.

Do we have any case where we would need to suspend and resume the game loop at a specific point for a file load? I could add an AsyncOp::eFileLoad to do that.

It would likely cause the game to stutter though, as everything would have to freeze in the middle of the frame until the IO finishes.

As far as I'm aware, most things in the game logic don't depend on file IO to be done and are fine waiting until the end of the frame.

Things that are dependent, such as:

ChangeSystemGraphic
Msg: Hello

Would be better served using another method, such as an OnSystemGraphicChanged() callback swapping out the underlying graphic when it finishes loading.

[Ghabry]

No, we already suspend via "ImportantFilePending" when the game loop returns and for non-important files which don't suspend there is code which delays rendering operations on these files (e.g. when Width/height are necessary), but update code still runs as expected.
Just thought that this can be maybe simplified by merging it with the new AsyncOp code, but not necessary.

[Ghabry]

not a full review just what I saw on first glance

[mateofio]

I pushed another change which creates a Scene_Inn for the inn logic. Now the inn logic is separated from Scene_Map. This change allows us to use push and pop scenes within async operations.

This will enable #1891 to be implemented using this same machinery.

[mateofio]

Redid the inn test cases.

This is ready again

[mateofio]

I took out the async Scene_Inn. I'm still on the fence about whether it's good idea to support asynchronous scene calling.