Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/Tupfile

127 lines
5.2 KiB
Plaintext
Raw Normal View History

[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
AS = tasm32 /m /mx /kh32768 /t
CXX32 = bcc32
# Silence incorrect warnings for Borland C++ 5.5
# ----------------------------------------------
# 'identifier' is assigned a value that is never used
CXX32FLAGS += -w-8004
# Comparing signed and unsigned values
CXX32FLAGS += -w-8012
# ----------------------------------------------
CXX32FLAGS += -O2 -v- -x-
[Build] 32-bit: Fall back on a dumb full .bat rebuild if Tup can't run And that's how we can still have a reliable 32-bit build part that runs on XP or earlier. Completes P0001, funded by GhostPhanom.
2020-08-31 12:12:20 +00:00
# Backslashes necessary for the .bat file generated by `tup generate`!
BMP2ARR = bin\\Pipeline\\bmp2arr.exe
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: Pipeline\\bmp2arr.c Pipeline\\bmp2arrl.c \
|> $(CXX32) $(CXX32FLAGS) -nbin/Pipeline/ %f \
|> bin/Pipeline/bmp2arrl.obj \
bin/Pipeline/bmp2arr.obj \
bin/Pipeline/bmp2arr.tds \
$(BMP2ARR)
[Pipeline] bmp2arr: Add -q for silencing debug output on stderr Part of P0113, funded by Lmocinemod.
2020-09-04 20:50:16 +00:00
!bmp2arr = | $(BMP2ARR) |> $(BMP2ARR) -q -i %f -o %o |> %o
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
[Decompilation] [th01] Interleaving both VRAM pages in an 8×8 square Some of the unused interleave masks are not that straightforward, so it makes sense to have all of them as a bitmap. I'm positive that this sort of thing could have been EGC-accelerated… although, simply writing better C would probably already go a long way. Part of P0121, funded by Yanga.
2020-09-27 19:45:32 +00:00
: th01/sprites/ileave_m.bmp |> !bmp2arr -sym _sINTERLEAVE_MASKS -of asm -sw 8 -sh 8 |> th01/sprites/ileave_m.asp
[Reverse-engineering] [th01] Shootout lasers: Hardcoded sprites First ZUN bug in sprite preshifting! One wrongly shifted pixel means that we can't use the auto-preshift feature of our sprite converter -.- Also, why did these even have to be hardcoded sprites to begin with. These dot patterns could have been easily generated procedurally… but even *that* wouldn't have been necessary, given that there's this nice function called, uh, graph_r_line_patterned()? Which could have rendered all of the lasers in the upcoming class and more? Part of P0122, funded by Yanga.
2020-10-03 14:46:14 +00:00
# ZUN bug: Supposed to be 8 preshifted sprites, with a height of 1 and a width
# of SHOOTOUT_LASER_MAX_W pixels each, but ZUN messed up a single pixel in the
# first pre-shifted sprite. So, we're forced to manually unroll them…
: th01/sprites/laser_s.bmp |> !bmp2arr -sym _sSHOOTOUT_LASER -of asm -sw 16 -sh 8 |> th01/sprites/laser_s.asp
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th01/sprites/pellet.bmp |> !bmp2arr -sym sPELLET -of c -sw 8 -sh 8 -pshf inner |> th01/sprites/pellet.csp
: th01/sprites/pellet_c.bmp |> !bmp2arr -sym _sPELLET_CLOUD -of asm -sw 16 -sh 16 |> th01/sprites/pellet_c.asp
: th01/sprites/shape8x8.bmp |> !bmp2arr -sym _sSHAPE8X8 -of asm -sw 8 -sh 8 |> th01/sprites/shape8x8.asp
[Decompilation] [th01] Invincibility sprite blitting In which ZUN accidentally the GRCG rather than the EGC in what should have been (?) the unblitting function. Which then ends up actually blitting yet another randomly background-masked version of the same sprite on top of the old one. And after just a few frames, you get those fully filled red diamonds you don't see in the sprite sheet. Then again, if the 16w×h rectangle unblitting function is all you have, and you can't be bothered to actually learn the EGC, this *is* the better option 🎺 Completes P0120, funded by Yanga.
2020-09-25 17:27:33 +00:00
: th01/sprites/shape_in.bmp |> !bmp2arr -sym _sSHAPE_INVINCIBILITY -of asm -sw 8 -sh 8 |> th01/sprites/shape_in.asp
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th02/sprites/pellet.bmp |> !bmp2arr -sym _sPELLET -of asm -sw 8 -sh 8 -pshf outer |> th02/sprites/pellet.asp
: th02/sprites/sparks.bmp |> !bmp2arr -sym _sSPARKS -of asm -sw 8 -sh 8 -pshf outer |> th02/sprites/sparks.asp
: th02/sprites/pointnum.bmp |> !bmp2arr -sym _sPOINTNUMS -of asm -sw 8 -sh 8 |> th02/sprites/pointnum.asp
: th03/sprites/score.bmp |> !bmp2arr -sym _sSCORE_FONT -of asm -sw 8 -sh 8 -u |> th03/sprites/score.asp
: th04/sprites/pelletbt.bmp |> !bmp2arr -sym _sPELLET_BOTTOM -of asm -sw 8 -sh 4 -pshf outer |> th04/sprites/pelletbt.asp
: th04/sprites/pointnum.bmp |> !bmp2arr -sym _sPOINTNUMS -of asm -sw 8 -sh 8 -pshf inner |> th04/sprites/pointnum.asp
: th05/sprites/gaiji.bmp |> !bmp2arr -sym _sGAIJI -of asm -sw 16 -sh 16 |> th05/sprites/gaiji.asp
: th05/sprites/piano_l.bmp |> !bmp2arr -sym _sPIANO_LABEL_FONT -of asm -sw 8 -sh 8 |> th05/sprites/piano_l.asp
[Build] Assemble all .ASM files in the 32-bit build part Yeah, why *were* we assembling them in the 16-bit part before?! Possible reasons: • In a time before Tup, it made no actual difference whether these little files were assembled in the 32-bit or 16-bit part. Now it sort of does, since we've temporarily given up on minimal rebuilds in the 16-bit part. • Emphasizing the temporary nature of the 32-bit part by deliberately moving everything to the 16-bit part as early as possible? • It all started with the ZUN.COM ASM code, which doesn't include any other files, and can therefore be perfectly tracked by a Makefile. Which *was* superior than the exclusive dumb batch file we had in the past. And then I've simply cargo-culted all new .ASM translation units into the 16-bit part well. Oh, and another positive side effect of temporarily not using 16-bit TASM: The build process now also runs on Windows 95. Part of P0113, funded by Lmocinemod.
2020-09-05 23:12:42 +00:00
!as = |> $(AS) %f %o |> bin\\%B.obj
[Separate translation units] [th02] Sound effect playback (undecompilable) Reason: Same as hflip_lut_generate() – wants to be word-aligned, and the function before it has an odd length :( Part of P0132, funded by [Anonymous].
2020-12-20 17:47:43 +00:00
!as2 = |> $(AS) /dGAME=2 th02\%b %o |> bin\\th02\\%B.obj
[Separate translation units] [th03] CDG: Non-alpha display (undecompilable) Reason: Self-modifying. -.- Part of P0114, funded by Lmocinemod.
2020-09-05 23:40:03 +00:00
!as3 = |> $(AS) /dGAME=3 th03\%b %o |> bin\\th03\\%B.obj
[Build] Assemble all .ASM files in the 32-bit build part Yeah, why *were* we assembling them in the 16-bit part before?! Possible reasons: • In a time before Tup, it made no actual difference whether these little files were assembled in the 32-bit or 16-bit part. Now it sort of does, since we've temporarily given up on minimal rebuilds in the 16-bit part. • Emphasizing the temporary nature of the 32-bit part by deliberately moving everything to the 16-bit part as early as possible? • It all started with the ZUN.COM ASM code, which doesn't include any other files, and can therefore be perfectly tracked by a Makefile. Which *was* superior than the exclusive dumb batch file we had in the past. And then I've simply cargo-culted all new .ASM translation units into the 16-bit part well. Oh, and another positive side effect of temporarily not using 16-bit TASM: The build process now also runs on Windows 95. Part of P0113, funded by Lmocinemod.
2020-09-05 23:12:42 +00:00
!as4 = |> $(AS) /dGAME=4 th04\%b %o |> bin\\th04\\%B.obj
!as5 = |> $(AS) /dGAME=5 th05\%b %o |> bin\\th05\\%B.obj
# Third-party libraries
: libs\\piloadc\\piloadc.asm |> $(AS) /ml libs\piloadc\%b %o |> bin\\%B.obj
# ZUN.COM
: zuncom\\zun_stub.asm |> $(AS) zuncom\%b %o |> bin\\zuncom\\%B.obj
: zuncom\\cstmstub.asm |> $(AS) zuncom\%b %o |> bin\\zuncom\\%B.obj
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th01_op.asm |> !as |> bin\\th01\\op.obj
: th01_reiiden.asm | \
[Decompilation] [th01] Interleaving both VRAM pages in an 8×8 square Some of the unused interleave masks are not that straightforward, so it makes sense to have all of them as a bitmap. I'm positive that this sort of thing could have been EGC-accelerated… although, simply writing better C would probably already go a long way. Part of P0121, funded by Yanga.
2020-09-27 19:45:32 +00:00
th01/sprites/ileave_m.asp \
[Reverse-engineering] [th01] Shootout lasers: Hardcoded sprites First ZUN bug in sprite preshifting! One wrongly shifted pixel means that we can't use the auto-preshift feature of our sprite converter -.- Also, why did these even have to be hardcoded sprites to begin with. These dot patterns could have been easily generated procedurally… but even *that* wouldn't have been necessary, given that there's this nice function called, uh, graph_r_line_patterned()? Which could have rendered all of the lasers in the upcoming class and more? Part of P0122, funded by Yanga.
2020-10-03 14:46:14 +00:00
th01/sprites/laser_s.asp \
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
th01/sprites/pellet_c.asp \
th01/sprites/shape8x8.asp \
[Decompilation] [th01] Invincibility sprite blitting In which ZUN accidentally the GRCG rather than the EGC in what should have been (?) the unblitting function. Which then ends up actually blitting yet another randomly background-masked version of the same sprite on top of the old one. And after just a few frames, you get those fully filled red diamonds you don't see in the sprite sheet. Then again, if the 16w×h rectangle unblitting function is all you have, and you can't be bothered to actually learn the EGC, this *is* the better option 🎺 Completes P0120, funded by Yanga.
2020-09-25 17:27:33 +00:00
th01/sprites/shape_in.asp \
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
|> !as |> bin\\th01\\reiiden.obj
: th01_fuuin.asm |> !as |> bin\\th01\\fuuin.obj
: th02_zuninit.asm |> !as |> bin\\th02\\zuninit.obj
[Separate translation units] [th02] Sound effect playback (undecompilable) Reason: Same as hflip_lut_generate() – wants to be word-aligned, and the function before it has an odd length :( Part of P0132, funded by [Anonymous].
2020-12-20 17:47:43 +00:00
: th02\\snd_se.asm |> !as2 |>
[Separate translation units] [th02] snd_mmd_resident() (undecompilable) Reason: Wants to be word-aligned, and the previous version in OP.EXE, game_exit(), is not, despite having an even length :( Oh well, at least I'm confident enough about it by now to document it. And out of all decompilations to be thrown away, this is a pretty dispensable one. Part of P0133, funded by [Anonymous].
2021-01-28 19:43:49 +00:00
: th02\\snd_mmdr.asm |> !as2 |>
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th02_op.asm |> !as |> bin\\th02\\op.obj
: th02_main.asm | \
th02/sprites/pellet.asp \
th02/sprites/sparks.asp \
th02/sprites/pointnum.asp \
|> !as |> bin\\th02\\main.obj
: th02_maine.asm |> !as |> bin\\th02\\maine.obj
: libs/sprite16/sprite16.asm |> $(AS) /DTHIEF libs\sprite16\sprite16.asm %o |> bin\\th03\\zunsp.obj
[Separate translation units] [th03] CDG: Non-alpha display (undecompilable) Reason: Self-modifying. -.- Part of P0114, funded by Lmocinemod.
2020-09-05 23:40:03 +00:00
: th03\\cdg_p_na.asm |> !as3 |>
[Build] [th03] Keep hflip_lut_generate() in ASM due to alignment issues Nooooo, gotta throw away that decompilation for the stupidest of reasons :( Turns out that a function may also be "undecompilable" if the original code layout places it at a word-aligned address, but the last byte of the previous function in just one of the original binaries (TH03's MAIN.EXE, in this case) also lies at a word-aligned address. There's simply no way to enforce per-function word alignment in Turbo C++ alone. You *could* fake it with `#pragma codestring`, but of course that won't work for functions that are part of the SHARED segment, and where the alignment previously would have been correct. Conditionally emitting that codestring would work, but then we'd also have to compile that translation unit at least twice. Now, I could have created a dummy .ASM file that just contains a single zero-length but word-aligned SHARED segment, which could be placed anywhere on the link command line where word alignment is needed… but the decompilation of this function was a mess anyway, and probably helped nobody. Part of P0127, funded by [Anonymous].
2020-11-12 16:16:35 +00:00
: th03\\hfliplut.asm |> $(AS) th03\\hfliplut.asm %o |> bin\\%B.obj
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th03_op.asm |> !as |> bin\\th03\\op.obj
: th03_main.asm | \
th03/sprites/score.asp \
|> !as |> bin\\th03\\main.obj
: th03_mainl.asm |> !as |> bin\\th03\\mainl.obj
[th04/zuninit] Initial state Yup, it's finally the right time to properly rebuild ZUN.COM. While all of these small binaries would still need some RE attention, putting in the few minutes to make them position-independent right now is definitely worth it. Adding them to the PI calculation on the website would take much longer 😅 Part of P0117, funded by [Anonymous].
2020-09-14 14:21:24 +00:00
: th04_zuninit.asm |> !as |> bin\\th04\\zuninit.obj
[th04/memchk] Initial state Needlessly linked with TCC rather than TLINK, adding almost 4 KB of completely unnecessary libc startup code. Or maybe not, since ZUN doesn't free the allocated memory himself, but relies on libc to do that? Part of P0117, funded by [Anonymous].
2020-09-14 15:59:20 +00:00
: th04_memchk.asm |> !as |> bin\\th04\\memchk.obj
[Build] Assemble all .ASM files in the 32-bit build part Yeah, why *were* we assembling them in the 16-bit part before?! Possible reasons: • In a time before Tup, it made no actual difference whether these little files were assembled in the 32-bit or 16-bit part. Now it sort of does, since we've temporarily given up on minimal rebuilds in the 16-bit part. • Emphasizing the temporary nature of the 32-bit part by deliberately moving everything to the 16-bit part as early as possible? • It all started with the ZUN.COM ASM code, which doesn't include any other files, and can therefore be perfectly tracked by a Makefile. Which *was* superior than the exclusive dumb batch file we had in the past. And then I've simply cargo-culted all new .ASM translation units into the 16-bit part well. Oh, and another positive side effect of temporarily not using 16-bit TASM: The build process now also runs on Windows 95. Part of P0113, funded by Lmocinemod.
2020-09-05 23:12:42 +00:00
: th04\\scoreupd.asm |> !as4 |>
[Separate translation units] [th04/th05] .CDG: Loading and freeing Undecompilable again. The loading functions have these *_noalpha() variants that simply set a global variable and fall through to the regular functions, while cdg_free() has its first `PUSH DI` instruction after the first expression we'd be decompiling. cdg_free_all() *could* be decompiled… but would also require _FLAGS trickery, and it's simply not worth starting a translation unit for one such small function. Part of P0127, funded by [Anonymous].
2020-11-14 16:24:04 +00:00
: th04\\cdg_load.asm |> !as4 |>
[Separate translation units] [th04/th05] bgimage_put_rect() (undecompilable) Reason: Self-modifying. -.- Part of P0135, funded by [Anonymous].
2021-02-26 10:52:52 +00:00
: th04\\bgimager.asm |> !as4 |>
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th04_op.asm |> !as |> bin\\th04\\op.obj
: th04_main.asm | \
th02/sprites/pellet.asp \
th04/sprites/pelletbt.asp \
th02/sprites/sparks.asp \
th04/sprites/pointnum.asp \
|> !as |> bin\\th04\\main.obj
: th04_maine.asm |> !as |> bin\\th04\\maine.obj
[th05/zuninit] Initial state On the surface, Version1.02 of the `INTvector set program` seems to be largely the same as Version1.01, just with fancier instructions, some redundancy removed, and some slightly different wording in the playful messages… or is there more to it? Stay tuned! Part of P0117, funded by [Anonymous].
2020-09-14 15:19:11 +00:00
: th05_zuninit.asm |> !as |> bin\\th05\\zuninit.obj
[Build] [th05] gjinit: Include the gaiji compiled from th05/sprites/gaiji.bmp Which means that edits to that image will now be immediately visible in TH05 after recompilation! Part of P0117, funded by [Anonymous].
2020-09-14 17:53:58 +00:00
: th05_gjinit.asm | \
th05/sprites/gaiji.asp \
|> !as |> bin\\th05\\gjinit.obj
[th05/memchk] Initial state No libc anymore, yet still no memory freeing…? Part of P0117, funded by [Anonymous].
2020-09-14 17:32:10 +00:00
: th05_memchk.asm |> !as |> bin\\th05\\memchk.obj
[Separate translation units] [th04/th05] Low-level input (undecompilable) Reason: Manual "tail call optimization" of input_reset_sense(), with execution falling through to input_sense() immediately below. Part of P0133, funded by [Anonymous].
2021-01-18 19:47:07 +00:00
: th04\\input_s.asm |> $(AS) /dGAME=5 th04\%b %o |> bin\\th05\\%B.obj
[Build] Assemble all .ASM files in the 32-bit build part Yeah, why *were* we assembling them in the 16-bit part before?! Possible reasons: • In a time before Tup, it made no actual difference whether these little files were assembled in the 32-bit or 16-bit part. Now it sort of does, since we've temporarily given up on minimal rebuilds in the 16-bit part. • Emphasizing the temporary nature of the 32-bit part by deliberately moving everything to the 16-bit part as early as possible? • It all started with the ZUN.COM ASM code, which doesn't include any other files, and can therefore be perfectly tracked by a Makefile. Which *was* superior than the exclusive dumb batch file we had in the past. And then I've simply cargo-culted all new .ASM translation units into the 16-bit part well. Oh, and another positive side effect of temporarily not using 16-bit TASM: The build process now also runs on Windows 95. Part of P0113, funded by Lmocinemod.
2020-09-05 23:12:42 +00:00
: th04\\scoreupd.asm |> $(AS) /dGAME=5 th04\%b %o |> bin\\th05\\%B.obj
: th05\\player.asm |> !as5 |>
: th05\\hud_bar.asm |> !as5 |>
: th05\\bullet.asm |> !as5 |>
[Separate translation units] [th04/th05] bgimage_put_rect() (undecompilable) Reason: Self-modifying. -.- Part of P0135, funded by [Anonymous].
2021-02-26 10:52:52 +00:00
: th05\\bgimager.asm |> !as5 |>
[Separate translation units] .PI: Row loop for masked blitting (undecompilable) Reason: Pascal calling convention with function parameters but no stack frame. Theoretically we can __emit__() everything inside this function, but there's no way we can get a `RETN 8` this way. Oh, and it also accesses SI and DI without backing them up to the stack. And thanks to TLINK apparently not reporting fixup overflows when segments are small enough (?), it took quite a while to get that CALL correct and not weirdly offset by 32 bytes. 😕 Part of P0134, funded by [Anonymous].
2021-02-18 18:40:37 +00:00
: th05\\pi_asm_1.asm |> !as5 |>
[Separate translation units] [th05] pi_free() (undecompilable) Well, it *would* have been decompilable, but that ridiculous placement of the nullptr assignment would have forced the entire function call to be spelled out in inline ASM, verbatim. No amount of comma operator trickery would have generated the same instructions either. And for a function this small and obvious in what its decompilation *should* be, it really defeated the purpose of adding a separate translation unit… Part of P0134, funded by [Anonymous].
2021-02-12 16:39:51 +00:00
: th05\\pi_asm_2.asm |> !as5 |>
[Separate translation units] [th05] snd_kaja_interrupt() (undecompilable) Reason: Pascal calling convention with function parameters but no stack frame. Part of P0135, funded by [Anonymous].
2021-02-22 14:11:05 +00:00
: th05\\snd_kaja.asm |> !as5 |>
[Build] 32-bit: Use Tup as a proper build system for the 32-bit part This Tupfile does in fact date back to January 2017, and I've been using it myself ever since. Time to finally deliver it on master! Part of P0001, funded by GhostPhanom.
2017-01-22 20:22:00 +00:00
: th05_op.asm | \
th05/sprites/piano_l.asp \
|> !as |> bin\\th05\\op.obj
: th05_main.asm | \
th02/sprites/pellet.asp \
th04/sprites/pelletbt.asp \
th02/sprites/sparks.asp \
th04/sprites/pointnum.asp \
|> !as |> bin\\th05\\main.obj
: th05_maine.asm |> !as |> bin\\th05\\maine.obj