Use precompiled headers, fix weak data issues

This commit is contained in:
LagoLunatic
2025-08-19 17:15:39 -04:00
parent a32174dff6
commit 217775af4e
629 changed files with 646 additions and 445 deletions
+2 -7
View File
@@ -51,8 +51,7 @@ public:
virtual ~J3DMtxCalcBasic() {}
virtual void init(const Vec& vec, const Mtx& mtx) {
J3DSys::mCurrentS = vec;
// TODO: Same issue as J3DMtxCalcMaya::init.
// J3DSys::mParentS = (Vec){1.0f, 1.0f, 1.0f};
J3DSys::mParentS = (Vec){1.0f, 1.0f, 1.0f};
J3DSys::mCurrentMtx[0][0] = mtx[0][0] * J3DSys::mCurrentS.x;
J3DSys::mCurrentMtx[0][1] = mtx[0][1] * J3DSys::mCurrentS.y;
J3DSys::mCurrentMtx[0][2] = mtx[0][2] * J3DSys::mCurrentS.z;
@@ -94,11 +93,7 @@ public:
J3DMtxCalcMaya() : J3DMtxCalcBasic() {}
virtual ~J3DMtxCalcMaya() {}
virtual void init(const Vec& vec, const Mtx& mtx) {
// TODO: This breaks some TUs by adding extra data ({0x3F800000, 0x3F800000, 0x3F800000})
// This seems to be responsible for the @2100 Vec literal that gets added to most TUs.
// The strange part is that @2100 needs to be in the .data section, but uncommenting this
// will put it in the .rodata sections.
// J3DSys::mParentS = (Vec){1.0f, 1.0f, 1.0f};
J3DSys::mParentS = (Vec){1.0f, 1.0f, 1.0f};
J3DSys::mCurrentS = vec;
J3DSys::mCurrentMtx[0][0] = mtx[0][0] * J3DSys::mCurrentS.x;
J3DSys::mCurrentMtx[0][1] = mtx[0][1] * J3DSys::mCurrentS.y;
+4 -1
View File
@@ -992,7 +992,10 @@ struct J3DColorChan {
info.mDiffuseFn, info.mAttnFn, ambSrc);
}
J3DColorChan(u16 id) : mChanCtrl(id) {}
GXAttnFn getAttnFn();
GXAttnFn getAttnFn() {
u8 attnFnTbl[] = { GX_AF_NONE, GX_AF_SPEC, GX_AF_NONE, GX_AF_SPOT };
return GXAttnFn(attnFnTbl[mChanCtrl >> 9 & 0x03]);
}
GXDiffuseFn getDiffuseFn() { return GXDiffuseFn(mChanCtrl >> 7 & 3); }
u8 getLightMask() { return ((mChanCtrl >> 2 & 0x0f) | (mChanCtrl >> 11 & 0x0f) << 4); }
void setLightMask(u8 mask) {
@@ -4,7 +4,6 @@
#include "JSystem/JUtility/TColor.h"
#include "stdarg.h"
namespace std {
// no idea what this is or why it is used instead of va_list
struct __tag_va_List : __va_list_struct {};
-1
View File
@@ -5,7 +5,6 @@
#include "d/d_bg_w.h"
#include "f_op/f_op_actor.h"
class daMtoge_c : public fopAc_ac_c {
public:
inline BOOL draw();
-1
View File
@@ -8,7 +8,6 @@
#include "f_op/f_op_actor.h"
#include "m_Do/m_Do_hostIO.h"
class daNpc_Bs1_c : public fopAc_ac_c {
public:
typedef BOOL (daNpc_Bs1_c::*ActionFunc)(void*);
-2
View File
@@ -7,8 +7,6 @@
#include "f_op/f_op_actor.h"
#include "m_Do/m_Do_hostIO.h"
class SwMail2_c {
public:
typedef void (SwMail2_c::*SwMail_Func)();
-2
View File
@@ -5,8 +5,6 @@
#include "f_op/f_op_actor.h"
#include "m_Do/m_Do_hostIO.h"
class daNpc_Km1_c : public fopNpc_npc_c {
public:
typedef int (daNpc_Km1_c::*ActionFunc)(void*);
-1
View File
@@ -4,7 +4,6 @@
#include "f_op/f_op_actor.h"
#include "d/d_bg_s_movebg_actor.h"
namespace daObjOjtree {
class Act_c : public dBgS_MoveBgActor {
public:
-1
View File
@@ -3,7 +3,6 @@
#include "f_op/f_op_actor.h"
class JPABaseEmitter;
class JPABaseParticle;
-1
View File
@@ -8,7 +8,6 @@
#include "JSystem/J2DGraph/J2DScreen.h"
#include "SSystem/SComponent/c_phase.h"
class dDlst_Gameover_CAPTURE_c : public dDlst_base_c {
public:
virtual ~dDlst_Gameover_CAPTURE_c() {}
+10
View File
@@ -0,0 +1,10 @@
#ifndef DOLZEL_H
#define DOLZEL_H
#ifdef __MWERKS__
#include "pch/dolzel.mch"
#else
#include "d/dolzel.pch"
#endif
#endif /* DOLZEL_H */
+10
View File
@@ -0,0 +1,10 @@
#ifndef DOLZEL_PCH
#define DOLZEL_PCH
#include "math.h" // IWYU pragma: export
#include "JSystem/J3DGraphBase/J3DMatBlock.h" // IWYU pragma: export
#include "JSystem/J3DGraphAnimator/J3DJoint.h" // IWYU pragma: export
#include "weak_bss_936_to_1036.h" // IWYU pragma: keep
#include "weak_bss_3569.h" // IWYU pragma: keep
#endif /* DOLZEL_PCH */
+4 -4
View File
@@ -2,14 +2,14 @@
#define WEAK_BSS_3569_H
// Fake header.
// This is some kind of weak objects that get included in the .bss sections of several TUs.
// This is some kind of weak object that get included in several TUs.
// Goes in either .bss (for RELs) or .rodata (for main.dol: d_snap, J3DUClipper).
// Its true source is currently unknown, so include this header in TUs that need it to match for now.
#include "dolphin/types.h"
template <typename T> struct bss_3569 { u8 val[0xC]; };
#include "dolphin/mtx/mtx.h"
static inline void dummy_bss_3569() {
bss_3569<void*>(); // @3569
Vec vec = (Vec){0.0f, 0.0f, 0.0f}; // @3569 / @3599
}
#endif /* WEAK_BSS_3569_H */
-1
View File
@@ -13,7 +13,6 @@
// any of these weak bss objects. So that constructor is moved to functionvalue.cpp and this fake
// header should be included where necessary instead.
#include "weak_bss_3569.h" // IWYU pragma: keep
#include "JSystem/JStudio/JStudio/functionvalue.h" // IWYU pragma: keep
// They each have size 1, and alignment 1 in the debug maps, but alignment 4 in the non-debug maps.
-36
View File
@@ -1,36 +0,0 @@
#ifndef WEAK_DATA_1811_H
#define WEAK_DATA_1811_H
// Fake header.
#include "dolphin/gx/GXEnum.h"
#include "weak_data_2100_2080.h" // IWYU pragma: keep
// @1811 is a weak object that gets included in the .data sections of several TUs.
// Its true source is this line:
// u8 attnFnTbl[] = { GX_AF_NONE, GX_AF_SPEC, GX_AF_NONE, GX_AF_SPOT };
// Which appears in the weak function J3DColorChan::getAttnFn, which is supposed to go in a header.
// But that line causes the weak object to appear in .rodata, while this weak object need to be in .data.
// So for now, that function is moved to the .cpp file, and TUs that need this object should include this header.
static inline void fake_getAttnFn() {
// Value is equivalent to: {0x02, 0x00, 0x02, 0x01}
static u8 attnFnTbl_1811[] = { GX_AF_NONE, GX_AF_SPEC, GX_AF_NONE, GX_AF_SPOT };
}
// These two weak objects are strange, as they have no symbols associated with them.
// They always seems to come after @1811 ends at offset 0x1C, getting padded to start at 0x20 and ending at 0x30.
// These are likely the 3.0 and .5 double literals from std::sqrtf.
// But those literals get placed in .rodata, while these weak objects need to be in .data.
// Also, the order of these two literals is reversed. std::sqrtf has _half before _three.
// static f64 data_no_symbol_3_5[2] = {3.0, 0.5};
extern inline void fake_sqrtf(float x) {
static double _three[1] = {3.0};
static double _half[1] = {.5};
}
// Note: These weak objects get stripped out for main.dol, because all three of them are within the
// 8-byte limit for .sdata. They do not get stripped out in RELs.
#endif /* WEAK_DATA_1811_H */
-27
View File
@@ -1,27 +0,0 @@
#ifndef WEAK_DATA_2100_2080_H
#define WEAK_DATA_2100_2080_H
// Fake header.
#include "dolphin/mtx/vec.h"
// @2100 and @2080 are weak objects that get included in the .data sections of several TUs.
// Their true source is likely this line of code that appears twice in J3DJoint.h:
// J3DSys::mParentS = (Vec){1.0f, 1.0f, 1.0f};
// But that line causes the weak objects to appear in .rodata, while this weak object need to be in .data.
// So for now, the line is commented out, and TUs that need these objects should include this header.
// Note: For d_snap and J3DUClipper, these objects *are* supposed to appear in .rodata, but those are the only ones.
// Also, d_snap and J3DUClipper seem to be the only ones where the two symbols are in order by the compiler-generated
// names. In TUs where they appear in .data instead, their order is reversed (@2100 coming before @2080).
static inline void fake_data_2100() {
// Value is equivalent to: {0x3F800000, 0x3F800000, 0x3F800000}
static Vec data_2100 = {1.0f, 1.0f, 1.0f};
}
static inline void fake_data_2080() {
// Value is equivalent to: {0x3F800000, 0x3F800000, 0x3F800000}
static Vec data_2080 = {1.0f, 1.0f, 1.0f};
}
#endif /* WEAK_DATA_2100_2080_H */