Commit Graph

12 Commits

Author SHA1 Message Date
nmlgc 9b46ff7d99 [Maintenance] [th01] Move TH01-exclusive VRAM text functions to a new header
Neatly dissolves two of the three game-specific preprocessor branches
in `th01/hardware/grppsafx.h`. Moving at least one function into a
corresponding .cpp file will also simplify the corresponding debloating
commit on the respective branch.

Part of P0229, funded by Ember2528.
2023-02-28 08:07:52 +01:00
nmlgc a309e3f549 [Maintenance] [th01] Avoid direct usage of VRAM plane pointers where possible
Might not read as nicely for the 8-dot cases, but makes it easier to
get rid of the pointers if necessary.

Part of P0229, funded by Ember2528.
2023-02-28 08:07:52 +01:00
nmlgc cf95cc8717 [Maintenance] [th01] Remove `extern "C"` from all remaining areas of code
Nothing says "we're getting things done" quite as much as this.

Part of P0214, funded by Ember2528.
2022-08-14 23:03:15 +02:00
nmlgc 60a7e44b53 [Maintenance] Introduce proper Shift-JIS and JIS X 0208 types
Much more semantic than that twobyte_t abomination.

Part of P0212, funded by GhostRiderCog, Lmocinemod, and LeyDud.
2022-08-11 15:53:13 +02:00
nmlgc 96510b3cba [Maintenance] [th01] Don't #include grppsafx.h inside graph.h
That file is about to gain a dependency on a Shift-JIS type header.

Part of P0212, funded by GhostRiderCog, Lmocinemod, and LeyDud.
2022-08-11 15:50:46 +02:00
nmlgc 0062826327 [Separating translation units] [th01] Additional hardware effect functions
These could have been nicely separated into per-device translations
(one for GDC, one for EGC, one for regular VRAM accesses)… if their
original order followed that classification.

OK, so let's make it one full `graph_ex.cpp` translation unit… nope,
FUUIN.EXE needs graph_2xscale_byterect_1_to_0_slow() with different
compilation flags. 🤦

Whatever, fuck it, let's go for individual translation units, with
individual headers, so that we at least get predictably organized
source code out of this.

Part of P0196, funded by Yanga.
2022-05-31 23:15:14 +02:00
nmlgc efff8d61bb [Maintenance] Change line endings in old C/C++ files to LF
Yup, even a DOS compiler from 1994 considered CRLF line endings as
stupid.

Part of P0172, funded by [Anonymous] and Blue Bolt.
2021-12-27 01:06:32 +01:00
nmlgc ba29539fc7 [Maintenance] Declare a distinct type for VRAM offsets
… and this one, while I'm at it. I've been using pretty much every
possible type for VRAM offset variables, depending on my mood that day,
since signedness apparently never matters for those.
Except that it does. And so, just like with most of our high-level
types, we also have to account for ZUN's little signedness
inconsistencies here. Oh well, at least it's now only one of two types,
and there's no need to choose between `int` or `unsigned int` or
`short` or `unsigned short` or `int16_t` or `uint16_t` or `size_t` or…

Part of P0111, funded by [Anonymous] and Blue Bolt.
2020-08-28 14:53:33 +02:00
nmlgc d6f634631f [Maintenance] Declare distinct types for pixel and VRAM sizes
Oh wait, we also need one of those for an upcoming structure!

Part of P0111, funded by [Anonymous] and Blue Bolt.
2020-08-28 14:53:33 +02:00
nmlgc 368f151759 [Maintenance] Declare distinct types for screen, VRAM, and TRAM coordinates
Whew, time to look at every `int` variable we ever declared! The best
moment to do this would have been a year ago, but well, better late
than never. No need to communicate that in comments anymore.

These shouldn't be used for widths, heights, or sprite-space
coordinates. Maybe we'll cover that another time, this commit is
already large enough.

Part of P0111, funded by [Anonymous] and Blue Bolt.
2020-08-28 14:53:30 +02:00
nmlgc 67d35115e6 [Maintenance] Use inline functions for all VRAM offset calculations
At least those can all be moved to a single place.

Part of P0105, funded by Yanga.
2020-08-12 16:16:18 +02:00
nmlgc a75e0f8f53 [Maintenance] Compile all VRAM-accessing translation units as C++
Leading to slight complications in TH02's Music Room and shot type
selection menus. Thought about leaving those in C for a while, but I
still think it's worth it for the consistency we get with the VRAM
offset functions. Also, we'll have similar code for the main menus of
later games, and I'll surely won't be using C++ when starting out with
these.

Part of P0105, funded by Yanga.
2020-08-12 16:16:09 +02:00