Commit Graph

13 Commits

Author SHA1 Message Date
nmlgc 3bf078b68c [Separate translation units] [th02/th03/th04] pi_load()
Part of P0132, funded by [Anonymous].
2021-01-05 20:01:44 +01:00
nmlgc c8fa3311b1 [Separate translation units] [th02] Unaccelerated page 1→0 rectangle blitting
Not using the EGC, because we gotta go slow in the main menus…?

Part of P0132, funded by [Anonymous].
2021-01-05 19:55:42 +01:00
nmlgc 4850d6d457 [Maintenance] Rename "seg2" to "SHARED"
There's the better name, in ALLCAPS for improved grepping. TH01 is also
going to need a pseudo-binary to bundle translation units that appear
in more than one .EXE, and since "segment 2" would be wrong for that
game, it makes more sense to have one consistent name for these
pseudo-binaries in all games.

(Maintenance mode commit)
2020-11-03 17:01:26 +01:00
nmlgc e8ae29ca4e [Maintenance] Remove the old `planar(8|16|32)_t` types
All code that used them has transitioned to C++, and can use the
Planar<> template.

Part of P0125, funded by [Anonymous].
2020-11-02 23:04:54 +01:00
nmlgc 1610d7b63d [Maintenance] Decide on a consistent place for file-wide `#pragma`s
(Maintenance mode commit)
2020-10-01 16:35:56 +02:00
nmlgc aee8a13958 [Separate translation units] [th02] game_exit_to_dos(), zun_error(), graph_putsa_fx()
Oh, wait. Due to ridiculously unlucky alignment, we can't actually
approach TH03's OP.EXE from the top of code segment 2… without
covering way too many functions at once, that is.
At least TH02 works out with "just" three functions at once. *If* we
add seg2 back to OP.EXE, where we previously needed to delete it… 😵

Part of P0114, funded by Lmocinemod.
2020-09-07 21:18:40 +02:00
nmlgc 6204fdd450 [Separate translation units] [th02/th03/th04] frame_delay_2()
Completes P0113, funded by Lmocinemod.
2020-09-07 21:18:38 +02:00
nmlgc f0511221b7 [Maintenance] [th02/th03/th04/th05] Establish a common name for code segment 2
About time I finally developed this piece of tech. Towards TH05, this
segment got more and more undecompilable ASM functions mixed inbetween
C ones. Which means that pretty much all of the current ASM land
`#include`s in that segment will have to become translation units. And
we *really* don't want an additional layer of numbered, per-binary
translation units that just `#include` maybe one or two functions.

Also yeah, no _TEXT suffix, to drive home the point that this is a
"library" segment, and not really "owned" by any one file.

Part of P0113, funded by Lmocinemod.
2020-09-07 21:18:38 +02: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