Commit Graph

35 Commits

Author SHA1 Message Date
nmlgc 766a34d044 [Reverse-engineering] [th04/maine] Single-plane CDG display
Only used in the staff roll.

Funded by DTM.
2018-10-16 01:04:46 +02:00
nmlgc fc8d51c7d7 [Reverse-engineering] [th04/th05] Non-color CDG display 2018-10-16 01:04:46 +02:00
nmlgc aa47bb33d9 [Reverse-engineering] [th04/th05] Non-alpha CDG display 2018-10-16 01:04:46 +02:00
nmlgc bfef793805 [Reverse-engineering] [th04/th05] Normal CDG display
In which the th05 difference is the lack of self-modifying code.
2018-10-16 01:04:46 +02:00
nmlgc 286c6431d8 [Reverse-engineering] [th04/th05] CDG loading 2018-10-16 01:04:46 +02:00
nmlgc 79cc3ed71c [Reverse-engineering] [th03/th04/th05] Input change delay function
With TH05 definitely being the Galaxy Brain version of this function.
You'll see once I get to push the C decompilation for that one…

Anyway, that covers all shared input functions of TH02-TH05!

Funded by zorg.
2018-09-17 22:10:42 +02: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 0052606563 [Reverse-engineering] [th04] Dream item number and score
The score table is also still present in TH05.

Funded by zorg.
2018-09-02 21:06:47 +02:00
nmlgc 746681db22 [Reverse-engineering] [th04/th05] Enemy drop table
TH02 just seems to use a sequence of branches in sub_D6CA.
I thought about keeping variable and function names consistent with
uth05win (on which most upcoming reverse-engineering commits will be
based). But as it will turn out, it ignored a certain very important
substructure, so I don't think it's worth introducing this naming style
clash.

Funded by zorg.
2018-09-02 20:42:17 +02:00
nmlgc 755a0564ae [Reverse-engineering] [th02/th04/th05] Shot power levels
Funded by -Tom-.
2018-04-20 19:33:40 +02:00
nmlgc 843905ecea [Reverse-engineering] [th04/th05] ZUN Soft logo explosions
Which seemed a nicer and more debuggable intro to how ZUN implements
sprites than starting with a random structure from MAIN.EXE.

Funded by -Tom-.
2018-03-21 23:20:04 +01: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 39c169c30d [Reduction] Separate functions for 1D and 2D vector construction
Look at that TH05 vector2_at_opt function. What the hell, the caller is
supposed to set up the stack frame for the function? How do you even get
a compiler to do this (and no, I haven't found a compiler switch)? No
way around writing a separate "optimizer" as part of the compilation
pipeline, it seems.
2017-01-08 21:01:13 +01:00
nmlgc c5f53d9cf1 [Maintenance] Rename snd_kaja_func() to snd_kaja_interrupt()
Oh, right, these functions can have parameters. So, let's turn snd_kaja_func()
into a macro that combines the function number and the parameter into the AX
value for the driver.
2015-03-15 23:51:11 +01:00
nmlgc de491f225d [Maintenance] Move the sound driver function slices from hardware/ to snd/
And renaming them all to the short filenames they will be decompiled to for
consistency. These functions aren't really immediately hardware-related, as
we've established earlier in the decompilation.
2015-03-15 23:01:31 +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 404044f32b [C decompilation] [th02/op] [th03/op] [th04/op] Frame delay #1 2015-03-04 02:47:16 +01:00
nmlgc cd33367b51 [C decompilation] [th02/op] Music Room
Yes, all of it. Including the bouncing polygons, of course. And since it's
placed at the end of ZUN's code inside the executable, the code's already
position-independent and fully hackable.
2015-02-24 22:38:44 +01:00
nmlgc 22332a71fa Make all sound functions and variables available to C 2015-02-23 18:28:38 +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 2d5d38426f Finally use standard segment names everywhere
And I guess we just have to ignore and disable that segment alignment warning
for TH01. It's not like this changes anything in the binary.
2015-02-18 14:04:43 +01:00
nmlgc 2cac434455 [Reverse-engineering] Sound effect playback 2015-02-13 12:56:51 +01:00
nmlgc 0b89233e48 [Reverse-engineering] Music Room comment loading 2014-12-24 21:39:34 +01:00
nmlgc f0ab47fd18 [Reduction] Hardware text colors and effects
Turns out we're not quite done with reduction yet, as there still are a bunch
of macros in master.h that #define PC-98-specific hardware constants and I/O
ports.
2014-12-20 22:36:38 +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 46b2d67143 [Reverse-engineering] Music and sound effect loader 2014-11-30 00:18:40 +01:00
nmlgc 08db7d6392 [Reverse-engineering] Sound mode determination
Note how it's only one *mode* in TH02/TH03, but two *modes* in TH04/TH05,
since you can't select between FM and Beep sound effect modes in TH02/TH03 (or
even disable sounds altogether). Might be a bit confusing, but it seemed
appropriate enough to distinguish the two functions.
2014-11-29 00:56:26 +01:00
nmlgc de25d6de3e [Reverse-engineering] PMD and MMD function call wrapper
Well, the naming.

Even though only TH02 actually uses MIDI (and thus, the MMD driver), every
game since then contains interrupt instructions for both functions. We could
just name it "pmd", since it seems like that's what came first - the AH
numbers of the 6 functions that make up MMD's interrupt API are identical to
those of the equivalent functions in PMD, even including gaps in the numbering
for PMD functions that don't have an equivalent in MIDI. However, except for
the FM sound effect handling and the key display in TH05's Music Room, these 6
functions are all the games actually use. Also, we already distinguish between
PMD and MMD in the driver check functions, and it might be confusing to only
imply PMD from now on?

So, "kaja" it is, collectively referring to the shared aspects of both
drivers.
2014-11-26 21:21:57 +01:00
nmlgc 98de0abfab [Reverse-engineering] Sound driver and hardware checks 2014-11-24 22:36:57 +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
nmlgc 69f85fa2de Identify and reduce gaiji strings across all executables 2014-09-13 12:26:33 +02:00