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

36 lines
831 B
C++
Raw Normal View History

[Decompilation] [th05] Committing the score delta Completes P0029, funded by zorg.
2019-09-14 14:41:16 +00:00
/* ReC98
* -----
[Reverse-engineering] [th02/th04/th05] Score update and display The TH02 version is a piece of cake… … but TH04 starts turning it into this un-decompilable piece of unnecessarily micro-optimized ZUN code. Couldn't have chosen anything better for the first separate ASM translation unit. Aside from now having to convert names of exported *variables* to uppercase for visibility in ASM translation units, the most notable lesson in this was the one about avoiding fixup overflows. From the Borland C++ Version 4.0 User's Guide: "In an assembly language program, a fixup overflow frequently occurs if you have declared an external variable within a segment definition, but this variable actually exists in a different segment." Can't be restated often enough. Completes P0032, funded by zorg.
2019-09-18 16:33:38 +00:00
* 2nd part of code segment #1 of TH05's MAIN.EXE
[Decompilation] [th05] Committing the score delta Completes P0029, funded by zorg.
2019-09-14 14:41:16 +00:00
*/
[Reverse-engineering] [th02/th04/th05] Score update and display The TH02 version is a piece of cake… … but TH04 starts turning it into this un-decompilable piece of unnecessarily micro-optimized ZUN code. Couldn't have chosen anything better for the first separate ASM translation unit. Aside from now having to convert names of exported *variables* to uppercase for visibility in ASM translation units, the most notable lesson in this was the one about avoiding fixup overflows. From the Borland C++ Version 4.0 User's Guide: "In an assembly language program, a fixup overflow frequently occurs if you have declared an external variable within a segment definition, but this variable actually exists in a different segment." Can't be restated often enough. Completes P0032, funded by zorg.
2019-09-18 16:33:38 +00:00
#pragma codeseg main_01_TEXT
[Decompilation] [th04/th05] Handle subpixels at the C++ type level I've had the idea to hide this implementation detail and improve code readability for some time now, but it obviously must still all inline, to be indistinguishable from a direct assignment of the correct value… … which, amazingly, it does! Even the static_cast from float to int. The latter allows us to exclusively implement this for float, since we do have to express the occasional value smaller than 16. Who needs macros anyway. Yay, C++ in TH04 and TH05 after all! Part of P0030, funded by zorg.
2019-09-15 17:36:17 +00:00
extern "C" {
#include "th05/th05.hpp"
[Decompilation] [th05] Committing the score delta Completes P0029, funded by zorg.
2019-09-14 14:41:16 +00:00
[Decompilation] [th05] Stage setup "Yeah, let's do this real quick, how can this possibly be hard, it's just MOVs and a few function calls"… …except that these MOVs access quite a lot of data, which we now all have to declare in the C world, hooray. Once it came to midbosses and bosses, I just turned them into C structs after all. Despite what I said in 260edd8… after all, the ASM world doesn't care about the representation in the C world, so they don't necessarily have to be the same. Since these structs can't contain everything related to midbosses and bosses (really, why did all those variables have to be spread out like this, ZUN?), it also made for a nice occasion to continue the "stuff" naming scheme, describing "an obviously incomplete collection of variables related to a thing", first seen in 160d4eb. Also, PROCDESC apparently is the only syntactically correct option to declare an extern near proc? Also, that `boss_phase_timed_out` variable only needs to be here already because TCC enforces word alignment for the .data segment… yeah, it's technically not related to this commit, but why waste time working around it if we can just include that one variable. Completes P0030, funded by zorg.
2019-09-15 18:14:00 +00:00
void pascal far nullsub_1(void);
void pascal near nullfunc_near(void);
void pascal near playfield_fillm_32_0_320_192(void);
void pascal near playfield_fillm_0_0_384_192__2(void);
void pascal near playfield_fillm_0_205_384_163(void);
void pascal near playfield_fillm_64_56_256_256(void);
void pascal near playfield_fillm_0_0_384_192__1(void);
void pascal near playfield_fillm_0_104_384_192(void);
[Decompilation] [th05] Resetting boss-related variables Part of P0031, funded by zorg.
2019-09-16 12:07:37 +00:00
#include "th04/boss/reset.cpp"
[Decompilation] [th05] Stage-related .BB file loading boilerplate Yay for alignment, allowing us once again to only move unrelated variable declarations over to C… Part of P0031, funded by zorg.
2019-09-16 11:01:53 +00:00
#include "th04/formats/bb_stage.c"
[Decompilation] [th05] Stage setup "Yeah, let's do this real quick, how can this possibly be hard, it's just MOVs and a few function calls"… …except that these MOVs access quite a lot of data, which we now all have to declare in the C world, hooray. Once it came to midbosses and bosses, I just turned them into C structs after all. Despite what I said in 260edd8… after all, the ASM world doesn't care about the representation in the C world, so they don't necessarily have to be the same. Since these structs can't contain everything related to midbosses and bosses (really, why did all those variables have to be spread out like this, ZUN?), it also made for a nice occasion to continue the "stuff" naming scheme, describing "an obviously incomplete collection of variables related to a thing", first seen in 160d4eb. Also, PROCDESC apparently is the only syntactically correct option to declare an extern near proc? Also, that `boss_phase_timed_out` variable only needs to be here already because TCC enforces word alignment for the .data segment… yeah, it's technically not related to this commit, but why waste time working around it if we can just include that one variable. Completes P0030, funded by zorg.
2019-09-15 18:14:00 +00:00
#include "th05/stage/setup.cpp"
[Decompilation] [th05] Committing the score delta Completes P0029, funded by zorg.
2019-09-14 14:41:16 +00:00
// Adds the entire score delta at once to the current score.
void pascal score_delta_commit(void)
{
while(score_delta > 0) {
score_update_and_render();
}
}
[Decompilation] [th04/th05] Handle subpixels at the C++ type level I've had the idea to hide this implementation detail and improve code readability for some time now, but it obviously must still all inline, to be indistinguishable from a direct assignment of the correct value… … which, amazingly, it does! Even the static_cast from float to int. The latter allows us to exclusively implement this for float, since we do have to express the occasional value smaller than 16. Who needs macros anyway. Yay, C++ in TH04 and TH05 after all! Part of P0030, funded by zorg.
2019-09-15 17:36:17 +00:00
[Decompilation] [th05] Stage-related .BB file loading boilerplate Yay for alignment, allowing us once again to only move unrelated variable declarations over to C… Part of P0031, funded by zorg.
2019-09-16 11:01:53 +00:00
static int unused_6CAC[3];
[Decompilation] [th04/th05] Handle subpixels at the C++ type level I've had the idea to hide this implementation detail and improve code readability for some time now, but it obviously must still all inline, to be indistinguishable from a direct assignment of the correct value… … which, amazingly, it does! Even the static_cast from float to int. The latter allows us to exclusively implement this for float, since we do have to express the occasional value smaller than 16. Who needs macros anyway. Yay, C++ in TH04 and TH05 after all! Part of P0030, funded by zorg.
2019-09-15 17:36:17 +00:00
}