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

77 lines
3.1 KiB
Batchfile
Raw Normal View History

Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
@echo off
echo Running the first, 32-bit part of the ReC98 build process.
Let Turbo C++ link in the Borland C/C++ runtime for the main EXE files This took long enough, so we're not covering the COM files right now. Like, I can't even tell how you're supposed to work around the forced word alignment for the _TEXT segment. Guess we'll just have to decompile all of these in one go, just like we did with ZUNSOFT.COM. Also, it really seems as if we're merely trading one ugly workaround for another in our quest for identical binaries.
2015-02-19 06:46:36 +00:00
set ReC98_ASM=tasm32 /m /mx /kh32768 /t /ilibs\master.lib\
[Build] Add a dependency on Borland C++ 5.5 for the 32-bit build part Yup. Lengthy justification and official download link in the README. It's also been added to the DevKit.
2020-07-09 19:55:01 +00:00
set CXX32=bcc32
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
[Build] Compile bmp2arr as a 32-bit binary
2020-07-08 18:52:08 +00:00
REM Silence incorrect warnings for Borland C++ 5.5
REM ----------------------------------------------
REM 'identifier' is assigned a value that is never used
set CXX32FLAGS=%CXX32FLAGS% -w-8004
REM Comparing signed and unsigned values
set CXX32FLAGS=%CXX32FLAGS% -w-8012
REM ----------------------------------------------
set CXX32FLAGS=%CXX32FLAGS% -O2 -v- -x-
Rename all code segments to names that Turbo C++ would generate Well, duh, of course, we *can* do this in order to allow decompilation to be started at the end (not the beginning) of any segment. In fact, if we hadn't done this, we would have had to start by moving _TEXT out to libraries....
2015-02-21 11:47:24 +00:00
del /S *.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
for /L %%i in (1,1,5) do mkdir bin\th0%%i 2>NUL
%ReC98_ASM% 1>NUL 2>NUL
if errorlevel 9009 goto no_tasm32
[Build] Add a dependency on Borland C++ 5.5 for the 32-bit build part Yup. Lengthy justification and official download link in the README. It's also been added to the DevKit.
2020-07-09 19:55:01 +00:00
%CXX32% 1>NUL 2>NUL
if errorlevel 9009 goto no_bcc32
[Build] Convert all known hardcoded sprites during the 32-bit build part You can now mod them by simply editing .BMP files!
2020-07-08 21:57:52 +00:00
set BMP2ARR=bin\Pipeline\bmp2arr.exe
[Build] Compile bmp2arr as a 32-bit binary
2020-07-08 18:52:08 +00:00
%CXX32% %CXX32FLAGS% -nbin/Pipeline/ Pipeline\bmp2arr.c Pipeline\bmp2arrl.c
[Decompilation] [th01] Pellets: Reset and decay functions Or, in more relevant news: That's the function that forced TH01's pellet sprites to be defined in C land. First sprite to make that jump. Part of P0102, funded by Yanga.
2020-07-06 19:43:55 +00:00
%BMP2ARR% -i th01/sprites/pellet.bmp -o th01/sprites/pellet.csp -sym sPELLET -of c -sw 8 -sh 8 -pshf inner
[Decompilation] [th01] Pellet delay cloud blitting and unblitting And immediately, we discover another two hardcoded sprites, with, of course, another set of functions for blitting and unblitting them… Part of P0099, funded by Ember2528.
2020-06-23 08:04:12 +00:00
%BMP2ARR% -i th01/sprites/pellet_c.bmp -o th01/sprites/pellet_c.asp -sym _sPELLET_CLOUD -of asm -sw 16 -sh 16
[Decompilation] [th01] 8×8 diamond, star, and snowflake sprite blitting More hardcoded sprites! These are prominently seen in the Konngara, Elis, and Sariel battles, respectively. Completes P0105, funded by Yanga.
2020-08-03 18:45:14 +00:00
%BMP2ARR% -i th01/sprites/shape8x8.bmp -o th01/sprites/shape8x8.asp -sym _sSHAPE8X8 -of asm -sw 8 -sh 8
[Build] Convert all known hardcoded sprites during the 32-bit build part You can now mod them by simply editing .BMP files!
2020-07-08 21:57:52 +00:00
%BMP2ARR% -i th02/sprites/pellet.bmp -o th02/sprites/pellet.asp -sym _sPELLET -of asm -sw 8 -sh 8 -pshf outer
%BMP2ARR% -i th02/sprites/sparks.bmp -o th02/sprites/sparks.asp -sym _sSPARKS -of asm -sw 8 -sh 8 -pshf outer
%BMP2ARR% -i th02/sprites/pointnum.bmp -o th02/sprites/pointnum.asp -sym _sPOINTNUMS -of asm -sw 8 -sh 8
%BMP2ARR% -i th03/sprites/score.bmp -o th03/sprites/score.asp -sym _sSCORE_FONT -of asm -sw 8 -sh 8 -u
%BMP2ARR% -i th04/sprites/pelletbt.bmp -o th04/sprites/pelletbt.asp -sym _sPELLET_BOTTOM -of asm -sw 8 -sh 4 -pshf outer
%BMP2ARR% -i th04/sprites/pointnum.bmp -o th04/sprites/pointnum.asp -sym _sPOINTNUMS -of asm -sw 8 -sh 8 -pshf inner
%BMP2ARR% -i th05/sprites/gaiji.bmp -o th05/sprites/gaiji.asp -sym _sGAIJI -of asm -sw 16 -sh 16
%BMP2ARR% -i th05/sprites/piano_l.bmp -o th05/sprites/piano_l.asp -sym _sPIANO_LABEL_FONT -of asm -sw 8 -sh 8
Let Turbo C++ link in the Borland C/C++ runtime for the main EXE files This took long enough, so we're not covering the COM files right now. Like, I can't even tell how you're supposed to work around the forced word alignment for the _TEXT segment. Guess we'll just have to decompile all of these in one go, just like we did with ZUNSOFT.COM. Also, it really seems as if we're merely trading one ugly workaround for another in our quest for identical binaries.
2015-02-19 06:46:36 +00:00
%ReC98_ASM% th01_op.asm bin\th01\op.obj
%ReC98_ASM% th01_reiiden.asm bin\th01\reiiden.obj
%ReC98_ASM% th01_fuuin.asm bin\th01\fuuin.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
%ReC98_ASM% th02_zuninit.asm bin\th02\zuninit.obj
%ReC98_ASM% th02_op.asm bin\th02\op.obj
%ReC98_ASM% th02_main.asm bin\th02\main.obj
%ReC98_ASM% th02_maine.asm bin\th02\maine.obj
[th03] Identify ZUNSP.COM as a rebrand of Promisence Soft's SPRITE16.COM driver Which was actually found out by @m1yur1 last year, who thankfully tweeted this in reference to ReC98: https://twitter.com/m1yur1/status/1018855232371998720 Thanks a lot! But what makes this more than a piece of trivia is the fact that the StormySpace release actually *was* bundled with documentation. Shoutout to the Neo Kobe PC-98 collection for preserving the original release! This should now greatly simplify any RE efforts related to TH03's INT 42h calls. (Not *trivialize*, because there's still all this EGC hardware to be understood…) And sure, you *were* allowed to use this driver in your own game, but replacing the copyright with your own isn't exactly the nicest thing to do… That now makes three library programmers that ZUN didn't credit. Makes me wonder what makes M. Kajihara so special. Probably the fact that Touhou has always been about the music for ZUN, first and foremost. Part of P0056, funded by rosenrose and [Anonymous].
2019-11-01 08:41:15 +00:00
%ReC98_ASM% /DTHIEF libs\sprite16\sprite16.asm bin\th03\zunsp.obj
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
%ReC98_ASM% th03_op.asm bin\th03\op.obj
%ReC98_ASM% th03_main.asm bin\th03\main.obj
%ReC98_ASM% th03_mainl.asm bin\th03\mainl.obj
%ReC98_ASM% th04_op.asm bin\th04\op.obj
%ReC98_ASM% th04_main.asm bin\th04\main.obj
%ReC98_ASM% th04_maine.asm bin\th04\maine.obj
%ReC98_ASM% th05_op.asm bin\th05\op.obj
%ReC98_ASM% th05_main.asm bin\th05\main.obj
%ReC98_ASM% th05_maine.asm bin\th05\maine.obj
goto eof
:no_tasm32
echo Could not find TASM32.
echo Please make sure that the BIN directory of Turbo Assembler 5.0 is in your PATH.
goto eof
[Build] Add a dependency on Borland C++ 5.5 for the 32-bit build part Yup. Lengthy justification and official download link in the README. It's also been added to the DevKit.
2020-07-09 19:55:01 +00:00
:no_bcc32
echo Could not find BCC32.
echo Please make sure that the BIN directory of Borland C++ 5.5 is in your PATH.
goto eof
Add build batch files and some documentation about the build process So yeah, that'll be our build environment - just plain batch files calling the Borland command-line assembler, linker, and eventually C compiler. These are the exact tools that ZUN used as well. There certainly are other assemblers, compilers and linkers that could compile this code into 16-bit DOS executables; Open Watcom is the only free one I know, and the master.lib manual also mentions C compilers by Microsoft and Symantec. However, I favor having one clear build path for a single toolchain that will, with the correct command-line switches for each game, create builds that are bit-perfect to ZUN's original ones over the possibility of cross-platform builds and the maintenance nightmare they add. So, Borland-only it is. (Also, no Makefile, due to our messy build setup. I think I still prefer this solution though, as we can have these really nice error messages that double as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
:eof
Finally use standard segment names everywhere And I guess we just have to ignore and disable that segment alignment warning for TH01. It's not like this changes anything in the binary.
2015-02-18 11:07:37 +00:00
echo -------------------------------------------------------------------------------