Commit Graph

4 Commits

Author SHA1 Message Date
nmlgc 6e0c33a8bf [Decompilation] [th01] High score menu: Input handling
It's exactly as terrible as you would have expected after hearing
"alphabet cursor actually stored as on-screen position". Nothing gained
in reducing redundancy any further here, any meaningful change would
pretty much have to rewrite the entire thing.

Part of P0093, funded by Ember2528.
2020-05-25 15:07:59 +02:00
nmlgc f2543c8336 [Decompilation] [th01] Keyboard input in REIIDEN.EXE
Yes, TH01's memory info screen will recurse into itself for every 3
frames the PgUp key is held, requiring one additional PgDown press per
recursion to actually get out of it.
You can, of course, also crash the system via a stack overflow this
way, if that's your thing.

Part of P0091, funded by Ember2528.
2020-05-12 15:06:11 +02:00
nmlgc 07dab293ad [Decompilation] [th01] Input declarations shared between REIIDEN and FUUIN
Of which we can express precisely *nothing* as an inline function,
because Turbo C++ always emits a useless `JMP SHORT $+2` at the end of
such an inlined function if it contains nested `if` statements. This is
also what forced some of the functions in 90252cc to be expressed as
macros. By now, this is clear enough to be documented separately.

And to warrant this separate commit.

Completes P0090, funded by Yanga.
2020-05-12 15:05:49 +02:00
nmlgc 389b9a1056 [Decompilation] [th01] Keyboard input in OP.EXE
Starting with the odd one out, the one that doesn't use master.lib and
has two input sense functions: one for the main menu, and one for the
option window.

Both of which also immediately perform the ring arithmetic on the menu
cursor variable… because there's nothing else to be done with these
inputs in OP.EXE? Separating input sensing from processing apparently
wasn't all too obvious of a thought, and it's only truly done in TH02
and later.

Part of P0090, funded by Yanga.
2020-05-12 14:55:09 +02:00