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

54 lines
4.2 KiB
Batchfile
Raw Normal View History

[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
: Dumb, full batch build script, provided as a fallback for systems that can't
: run Tup. Auto-generated via `tup generate`; make sure to re-run that command
: if the Tupfile changes.
@echo on
bcc32 -w-8004 -w-8012 -O2 -v- -x- -nbin/Pipeline/ Pipeline/bmp2arr.c Pipeline/bmp2arrl.c
[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
bin\\Pipeline\\bmp2arr.exe -q -i th01/sprites/ileave_m.bmp -o th01/sprites/ileave_m.asp -sym _sINTERLEAVE_MASKS -of asm -sw 8 -sh 8
[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
bin\\Pipeline\\bmp2arr.exe -q -i th01/sprites/laser_s.bmp -o th01/sprites/laser_s.asp -sym _sSHOOTOUT_LASER -of asm -sw 16 -sh 8
[Pipeline] bmp2arr: Add -q for silencing debug output on stderr Part of P0113, funded by Lmocinemod.
2020-09-04 20:50:16 +00:00
bin\\Pipeline\\bmp2arr.exe -q -i th01/sprites/pellet.bmp -o th01/sprites/pellet.csp -sym sPELLET -of c -sw 8 -sh 8 -pshf inner
bin\\Pipeline\\bmp2arr.exe -q -i th01/sprites/pellet_c.bmp -o th01/sprites/pellet_c.asp -sym _sPELLET_CLOUD -of asm -sw 16 -sh 16
bin\\Pipeline\\bmp2arr.exe -q -i th01/sprites/shape8x8.bmp -o th01/sprites/shape8x8.asp -sym _sSHAPE8X8 -of asm -sw 8 -sh 8
[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
bin\\Pipeline\\bmp2arr.exe -q -i th01/sprites/shape_in.bmp -o th01/sprites/shape_in.asp -sym _sSHAPE_INVINCIBILITY -of asm -sw 8 -sh 8
[Pipeline] bmp2arr: Add -q for silencing debug output on stderr Part of P0113, funded by Lmocinemod.
2020-09-04 20:50:16 +00:00
bin\\Pipeline\\bmp2arr.exe -q -i th02/sprites/pellet.bmp -o th02/sprites/pellet.asp -sym _sPELLET -of asm -sw 8 -sh 8 -pshf outer
bin\\Pipeline\\bmp2arr.exe -q -i th02/sprites/sparks.bmp -o th02/sprites/sparks.asp -sym _sSPARKS -of asm -sw 8 -sh 8 -pshf outer
bin\\Pipeline\\bmp2arr.exe -q -i th02/sprites/pointnum.bmp -o th02/sprites/pointnum.asp -sym _sPOINTNUMS -of asm -sw 8 -sh 8
bin\\Pipeline\\bmp2arr.exe -q -i th03/sprites/score.bmp -o th03/sprites/score.asp -sym _sSCORE_FONT -of asm -sw 8 -sh 8 -u
bin\\Pipeline\\bmp2arr.exe -q -i th04/sprites/pelletbt.bmp -o th04/sprites/pelletbt.asp -sym _sPELLET_BOTTOM -of asm -sw 8 -sh 4 -pshf outer
bin\\Pipeline\\bmp2arr.exe -q -i th04/sprites/pointnum.bmp -o th04/sprites/pointnum.asp -sym _sPOINTNUMS -of asm -sw 8 -sh 8 -pshf inner
bin\\Pipeline\\bmp2arr.exe -q -i th05/sprites/gaiji.bmp -o th05/sprites/gaiji.asp -sym _sGAIJI -of asm -sw 16 -sh 16
bin\\Pipeline\\bmp2arr.exe -q -i th05/sprites/piano_l.bmp -o th05/sprites/piano_l.asp -sym _sPIANO_LABEL_FONT -of asm -sw 8 -sh 8
[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
tasm32 /m /mx /kh32768 /t /ml libs\piloadc\piloadc.asm bin\piloadc.obj
tasm32 /m /mx /kh32768 /t zuncom\zun_stub.asm bin\zuncom\zun_stub.obj
tasm32 /m /mx /kh32768 /t zuncom\cstmstub.asm bin\zuncom\cstmstub.obj
[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
tasm32 /m /mx /kh32768 /t th01_op.asm bin\th01\op.obj
tasm32 /m /mx /kh32768 /t th01_reiiden.asm bin\th01\reiiden.obj
tasm32 /m /mx /kh32768 /t th01_fuuin.asm bin\th01\fuuin.obj
tasm32 /m /mx /kh32768 /t th02_zuninit.asm bin\th02\zuninit.obj
tasm32 /m /mx /kh32768 /t th02_op.asm bin\th02\op.obj
tasm32 /m /mx /kh32768 /t th02_main.asm bin\th02\main.obj
tasm32 /m /mx /kh32768 /t th02_maine.asm bin\th02\maine.obj
tasm32 /m /mx /kh32768 /t /DTHIEF libs\sprite16\sprite16.asm 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
tasm32 /m /mx /kh32768 /t /dGAME=3 th03\cdg_p_na.asm bin\th03\cdg_p_na.obj
[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
tasm32 /m /mx /kh32768 /t th03\\hfliplut.asm bin\hfliplut.obj
[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
tasm32 /m /mx /kh32768 /t th03_op.asm bin\th03\op.obj
tasm32 /m /mx /kh32768 /t th03_main.asm bin\th03\main.obj
tasm32 /m /mx /kh32768 /t th03_mainl.asm 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
tasm32 /m /mx /kh32768 /t th04_zuninit.asm 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
tasm32 /m /mx /kh32768 /t th04_memchk.asm 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
tasm32 /m /mx /kh32768 /t /dGAME=4 th04\scoreupd.asm bin\th04\scoreupd.obj
[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
tasm32 /m /mx /kh32768 /t /dGAME=4 th04\cdg_load.asm bin\th04\cdg_load.obj
[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
tasm32 /m /mx /kh32768 /t th04_op.asm bin\th04\op.obj
tasm32 /m /mx /kh32768 /t th04_main.asm bin\th04\main.obj
tasm32 /m /mx /kh32768 /t th04_maine.asm 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
tasm32 /m /mx /kh32768 /t th05_zuninit.asm bin\th05\zuninit.obj
[th05/gjinit] Initial state And with that, we finally dumped every single PC-98 Touhou binary! Since it'd be overkill to merge bmp2arr into the re-baseline branch though, we also have to start out with the raw image bytes here. Part of P0117, funded by [Anonymous].
2020-09-14 17:53:58 +00:00
tasm32 /m /mx /kh32768 /t th05_gjinit.asm 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
tasm32 /m /mx /kh32768 /t th05_memchk.asm bin\th05\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
tasm32 /m /mx /kh32768 /t /dGAME=5 th04\scoreupd.asm bin\th05\scoreupd.obj
tasm32 /m /mx /kh32768 /t /dGAME=5 th05\player.asm bin\th05\player.obj
tasm32 /m /mx /kh32768 /t /dGAME=5 th05\hud_bar.asm bin\th05\hud_bar.obj
tasm32 /m /mx /kh32768 /t /dGAME=5 th05\bullet.asm bin\th05\bullet.obj
[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
tasm32 /m /mx /kh32768 /t th05_op.asm bin\th05\op.obj
tasm32 /m /mx /kh32768 /t th05_main.asm bin\th05\main.obj
tasm32 /m /mx /kh32768 /t th05_maine.asm bin\th05\maine.obj
@echo off