Commit Graph

12 Commits

Author SHA1 Message Date
nmlgc 062e775f41 [Reverse-engineering] [th04/th05] .BB file loading boilerplate
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-.
2019-03-01 16:17:52 +01:00
nmlgc d08a7f49b6 [Reduction] [th04/th05] Redefined GRCG mode/color setting functions
Funded by -Tom-.
2018-12-06 22:39:11 +01:00
nmlgc c592464121 [Reverse-engineering] [th03/th04/th05] Basic keyboard input functions
Funded by zorg.
2018-09-11 19:34:19 +02:00
nmlgc 5a5c347e82 [Reverse-engineering] [th04/th05] Generic motion structure and its step method
Seemingly included in every other larger structure describing anything
remotely sprite-like. Couldn't find this in the earlier games,
unfortunately…

Funded by zorg.
2018-09-02 21:06:48 +02:00
nmlgc 4b8baf1413 [Reverse-engineering] [th02/th03/th04/th05] Random number ring buffer
Yes, you're reading that correctly. If the cursor is at 255, reading a
16-bit value will fill the upper 8 bits with the neighboring cursor
value, which always is 0xFF.

Funded by -Tom-.
2018-03-16 18:12:21 +01:00
nmlgc f98fba3c9d [Reverse-engineering] [th02/th04/th05] .map file loading
Funded by -Tom-.
2018-03-16 08:02:14 +01:00
nmlgc 92979e8f31 [C decompilation] [th02] Code segment #2 of all three executables
Only one code segment left in both OP and FUUIN! its-happening.gif

Yeah, that commit is way larger than I'm comfortable with, but none of these
functions is particularly large or difficult to decompile (with the exception
of graph_putsa_fx(), which I actually did weeks ago), and OP and MAIN have
their own unique functions in between the shared ones, so…
2015-03-14 23:25:50 +01:00
nmlgc 46eb3792cf Move frame_delay into the hardware/ subdirectory 2015-02-23 10:29:12 +01:00
nmlgc 6d8ff6b72e Make previously reduced ZUN functions available to C 2015-02-21 14:12:22 +01:00
nmlgc bead27b781 Use TASM calling convention syntax for previously identified ZUN functions
With TH03 changing the calling convention for most of the code from __cdecl to
__pascal, I've been getting more and more confused about this myself. So,
let's settle on the following consistent syntax for function calls:

* C where the calling convention is actually __cdecl and where TASM's emitted
  __cdecl code matches the original binary
* PASCAL where the calling convention is actually __pascal
* STDCALL where the calling convention is actually __cdecl, but where
  the caller either defers stack cleanup (summing up the stack size of
  multiple functions, then cleaning it all in a single "add sp" instruction)
  or where the stack is cleared in a different way (e.g. "pop cx").

Unfortunately though, when using the ARG directive to automatically generate
an appropriate RET instruction for the given calling convention, TASM always
emits ENTER and LEAVE instructions even when no local variables are declared,
which greatly limits the number of functions where we can use that syntax. -.-
2014-12-16 05:53:56 +01:00
nmlgc f40819b0e5 [Reverse-engineering] frame_delay 2014-11-23 22:32:26 +01:00
nmlgc f303222ffc Replace MASTERMOD with a per-game constant
Yup, packfiles finally proved that we really have a different set of changes
to master.lib in every game. Also, there are bound to be more of these game-
specific small changes to otherwise identical code in ZUN's own code.

And hey, no need to define that value in the build scripts anymore.

(I've also considered just copying modified versions into the individual game
subdirectories, but it's not too nice to expect people to diff them in order
to actually understand why these copies exist and where the changes actually
are.)
2014-11-15 02:03:41 +01:00