~dokomix/dokomix/+git/taisei:better-laser-api

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

5fa84da... by Andrei Alexeyev <email address hidden> on 2024-04-14

stage5: convert boss nonspell2 laser rule to new style

ef4c00e... by Andrei Alexeyev <email address hidden> on 2024-04-14

stage5: convert cathode laser rule to new style

b01f5cb... by Andrei Alexeyev <email address hidden> on 2024-04-14

stage6: convert maxwell laser rule to new style

119c5d1... by Andrei Alexeyev <email address hidden> on 2024-04-14

stage6: convert TOE laser rule to new style

f0680da... by Andrei Alexeyev <email address hidden> on 2024-04-11

stages: use new-style rules for common laser types

be7ccec... by Andrei Alexeyev <email address hidden> on 2024-04-11

lasers: add an experimental "dynamic" laser rule

daa1b38... by Andrei Alexeyev <email address hidden> on 2024-04-08

lasers: prototype a better interface for position rules

e3a4e90... by Andrei Alexeyev <email address hidden> on 2024-04-20

ringbuf: add a generic ring-buffer data type

34963e2... by Andrei Alexeyev <email address hidden> on 2024-04-20

stage: remove v1.4 bug compatibility

4a50c85... by Andrei Alexeyev <email address hidden> on 2024-04-20

stage: fix pause menu related crashes

There were two distinct things going on here:

1. If we receive multiple buffered TE_GAME_PAUSE events in the same
   frame, we'd process all of them and create a pause menu for each.
   This could theoretically overflow the evloop stack and crash the
   game.
2. The `stage_comain` task starts before scheduling the stage main
   loop via `eventloop_enter`. It initializes systems that depend on
   tasks, and then immediatelly enters its per-frame async loop,
   finishing its first iteration before yielding back to `_stage_enter`
   and thus allowing `eventloop_enter` to be finally called. If there is
   a TE_GAME_PAUSE event in the queue at this point, it would be handled
   right there, and a pause menu would be created before the stage main
   loop is scheduled. This messes things up quite a bit, leaking a
   "zombie" pause menu into the evloop stack. After the stage is
   destroyed, the evloop would try to switch to the frame created for
   this menu. The menu's draw function would then attempt to reference
   free'd resources of the destroyed stage, crashing the game. This
   crash has actually been observed and reported (thanks @0kalekale)

To fix #1, the stage now tracks its paused state and refuses to open a
pause menu if one already exists.

To fix #2, `stage_comain` now yields before starting its async loop, to
let the stage set up its main loop early.

Note that because the stage main loop runs all coroutine tasks before
incrementing the frame counter, `stage_comain`'s per-frame logic would
execute twice on frame 0. This is obviously wrong, but this behavior
must be preserved to maintain compatibility with v1.4 replays. For that
reason, the `stage_comain` loop now skips its first YIELD. This hack can
be removed once v1.4 compat is no longer a concern.