Commit Graph

18 Commits

Author SHA1 Message Date
nmlgc 22ebc48eea [Decompilation] [th01] Blocking palette fade-ins from a custom start color
 Unused…

Part of P0067, funded by Splashman.
2020-01-14 21:47:17 +01:00
nmlgc e55a48b700 [Decompilation] [th01] master.lib resident palette function reimplementations
Which store colors as GRB, as suggested by the structure's ID string.
Even master.lib's own functions add an additional XCHG AH, AL
instruction to get colors into and out of this format. MASTER.MAN
suggests that it's some sort of standard on PC-98. It does match the
order of ths hardware's palette register ports, after all.
(0AAh = green, 0ACh = red, 0AEh = blue)

Now we also know why __seg* wasn't used more commonly, as lamented in
c8e8e98. Turbo C++ simply doesn't support a lot of arithmetic on
segment pointers.

And then that undecompilable far call to a function within the same
segment, but inside a different translation unit…
Also, thanks again to Egor for the SCOPY@ hack that debuted in 0460072.
Would have probably struggled with this a lot more without that.

And *then* you realize that TH01 effectively doesn't even use the
resident palette. 😐

And yes, we're procrastinating the whole issue of potentially using
a single translation unit for all three binaries by using a common
segment name, because it *really* isn't that easy.

Completes P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 20:23:27 +01:00
nmlgc 6a274436db [Reverse-engineering] [th01] Basic hardware palette functions
Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 19:08:31 +01:00
nmlgc a3bba96a26 [Reverse-engineering] [th01] Main color palette
Part of P0066, funded by Keyblade Wiedling Neko and Splashman.
2020-01-05 19:07:48 +01:00
nmlgc 59bbe313ad [Decompilation] Add separate types for 1bpp planar pixel lines 2019-12-17 23:26:59 +01:00
wintiger0222 9173833a8d [Reverse-engineering] [th01] grcg_setcolor() C reimplementations 2019-12-17 23:26:57 +01:00
wintiger0222 01de2900dd [Decompilation] [th01] frame_delay
Closes #7.
2019-11-18 21:29:43 +01:00
nmlgc 35ef90f4d1 [Reduction] Page flipping
Funded by -Tom-.
2018-12-30 00:16:18 +01:00
nmlgc 6a6ce47c56 [Reduction] EGC-powered VRAM region copies
Funded by -Tom-.
2018-12-29 17:03:26 +01:00
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