Commit Graph

9 Commits

Author SHA1 Message Date
nmlgc 41622254a8 [Reverse-engineering] EGC register writes
Funded by zorg.
2018-12-25 23:45:24 +01:00
nmlgc 43001161e3 [Maintenance] Fix any whitespace issues in our own code 2015-09-07 15:44:48 +02:00
nmlgc 14e69ceb6d [C decompilation] [th01] VSync interrupt handler
Time to get back into this.
2015-09-05 22:33:07 +02: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 519e24c459 Rename the *_copy_region_* functions to *_copy_rect_*
TH01 copies a lot of different shapes from plane 1 to 0, so "region" feels
awfully unspecific.
2015-03-10 14:18:28 +01:00
nmlgc d058666929 [C decompilation] [th02/maine] Rotating rectangle animation
Small detour into MAINE.EXE because it has all the juicy algorithms that will
explain the remaining unknown members of the highscore data structure, and
there's this one code segment here we need to get out of the way first.
2015-02-28 22:37:40 +01:00
nmlgc 2f1b287f3d [C decompilation] [th01] VRAM region copy via EGC
The same function appears unused in TH02's MAINE.EXE. Separate commit because
this was painful enough and we can link the C version into FUUIN.EXE right
now.
2015-02-27 23:11:47 +01:00
nmlgc a7235304ed Make the VRAM plane constants available to C 2015-02-24 22:16:31 +01:00
nmlgc 07519a7238 [Reverse-engineering] 32-bit VRAM plane pointers
I've looked at every openly available piece of PC-98 documentation, and there
don't seem to be any official names for the individual planes. The closest
thing I could find was the description at

	http://island.geocities.jp/cklouch/column/pc98bas/pc98disphw2.htm

explaining that they represent the blue, red, green, and brightness component
when using the default PC-98 palette. However, these planes correspond to
nothing else but the 4 individual bits of the final index into the color
palette, and you can assign any color to every single palette slot. Therefore,
it's merely a convention that your own palettes don't have to follow (and in
Touhou, they don't).

Nevertheless, there doesn't seem to be an alternative, and the Neko Project II
source code uses the same B/R/G/E convention, so I'll go with that as well.
2015-02-10 23:43:34 +01:00