No leading underscore for functions with Pascal calling convention, but
we do have one for all variables, because it's not worth it to put
keywords in front of everything for no reason.
Seemed to have forgotten this rule in 2017?
Part of P0030, funded by zorg.
Going with the classic pointer-in-typedef approach here, because the
syntax you'd otherwise have to use is terribly inconsistent. It'd be
farfunc_t *near near_ptr_to_far_func;
but
nearfunc_t near *near_ptr_to_near_func;
And that'd hopefully be the last change to ReC98.h for a long time!
Those glacial compile times if every .c file is affected… Really
stands out if your build system is otherwise perfect.
Part of P0030, funded by zorg.
Slightly different in TH04 and TH05, and the TH05 version will be
decompiled in the next push… yeah, not going to worry all too much
about this one right now.
Part of P0029, funded by zorg.
These are used from quite a few places, so it seems best to just name
them after the rect on the playfield they leave out, which is then
typically where the background picture goes.
…*except* that in doing this, we quickly run up against the symbol
length limit of 32 characters. TASM can expand it via the /mv option,
but TCC only lets you *reduce* it to even less. (Why?)
So, my initial idea of `playfield_fill_around_(x)_(y)_(w)_(h)` wouldn't
have worked. But those coordinates are kinda important, I'd say…
Well then, let's just go with `fillm` instead of `fill_around` then.
"Fill with mask at the given coordinates"… yeah, that would work.
Part of P0029, funded by zorg.
… yeah, I don't really like these ambiguous "mode" and "mode change"
variable names either, but what's the alternative? Something something
"sub-phase", to distinguish them from regular phases? Feels way too
early to decide on something more specific. And pretty much nothing I
could come up with right now would have made their inconsistent use any
clearer.
But I need to decide on *something* before moving on, so… eh, let's
just go with what uth05win chose.
Also, yeah, dealing with those 0xFE and 0xFD boss_phase constants some
other time 😛
Also, today in "Weird TASM crashes": Trailing commas at the end of
`public` lines…
Completes P0028, funded by zorg.
Turning these into a struct will be very painful with all the
collisions. Not going to do that until we decompiled every single
reference to those.
Part of P0028, funded by zorg.
As in, "HiScore Entry!!", "Extend!!", "Full PowerUp!!", etc.
Class CFloatingText in uth05win… but I decided against naming it like
that because of some stage/BGM title-related variables in the middle.
Funded by -Tom-.
Many thanks to http://bytepointer.com/tasm/index.htm for providing a
better searchable resource for TASM's default `LEA imm16` → `MOV imm16`
optimization, which we initially had to hack around here.
Funded by -Tom-.
In which ZUN uses little-endian BCD as the exclusive internal storage
for both the current and the high score. Which are then updated using,
once again, ridiculously micro-optimized ASM code that uses the
venerable x86 BCD instructions.
Funded by -Tom-.
So apparently, this way of distorting a circle into an ellipse (?) by
adding a value to the angle for one of the two coordinates isn't
actually widely known in math and doesn't have a name. Fair enough.
Funded by -Tom-.
Sure, I like me some global variables too. If you have to temporarily
replace them for a single function call though, it's pretty much the
textbook example of where *not* to use them.
Funded by -Tom-.
Yup, nothing interesting in here.
Except for maybe the confirmation that LS00.BB is used for the curved
bullets used by Shinki and EX-Alice?
Funded by -Tom-.
… because TH04's version of this takes the ASCII stage ID directly from
the resident structure.
So boss battles are simply triggered by setting the background tile
scroll speed to 0? That means…
Funded by zorg.