[BUILD] Decide/Develope concept on how to handle Game Objects

[TheRedDaemon]

There are two basic cases:

• The project builds the DLL, which means the logic needs to use the structs inside the games memory.
• The project builds standalone, which means the structs need to be created (and filled) inside the project.

There are roughly the following targets:

• The actual functions should not be touched. Instead, they should use a unified variable that works in both cases, even if the actual type of it changes.
• The resulting bytecode properly uses the references/ptr like the original games uses its struct references, in both cases.
• (Optional) At best, there would be only one file that decides on the nature of the reference.

The case is similar to the function resolver question, but has other issues. The following is just a collection of thoughs:

• I am unsure if the decision logic should be handled more by a macro or more by a template. A template could put the decision inside its code via a macro, but a macro could also do this via a submacro.
• Should the target be to provide the ptr to use, or references?
• The only way to handle this header only without multi-definition is to put the actual global object in a template class. Since this allows the definition to also be a template and inside the header.
• In general, there would be no issue if there is one ptr or ref per translation unit, but it should not duplicate the objects.
• While many objects in this game are global singletons, there are certain objects that have multiple instances. Creating them would require a system that allows to create different instances, which would mean different initialization. It does not matter in this case if a constructor or init function is provided, both would need to take parameters. This would not be compatible with the switch approach game-ptr/own-ptr, since they could not move their init code in the default initialization function. This issue would persist even in a macro case, where the init would have to be moved to a .cpp file, since it would be not generic. The only difference would be, if these would always dependend on the context of a global, but even then the init-code would need to be conditional on game/dll.
• It is unlikely to be a target to "replace" the games struct with our own. To do this, every single reference to it would need to be under our control, every function that uses it, every struct that might contain one. This seems too risky. So the concept of switching it per definition/declaration, like with functions, should not exist.

Closing thoughts:
I have no idea how many non-singleton, non-dynamically created object instances there are in this game. Parts of the UI elements might be such cases, with multiple existing that are not filled by any constructor. In this case, there might be no real way around using multiple files for the definition.
A possible idea would be to still use a template, but the generic code just provides a reference/ptr to the games version, while the exe-target (switched through a macro) will not provide any instantiation logic, forcing us to create explicit initializations in cpp files. These would then allow us to just use static instances and init the global references with it, potentialy.
This would all need to be tested, since it could be that there are optimization issues, and the references might not be inlined properly. We would need to test it.

I am open for every other idea, though.

[TheRedDaemon]

I added a first concept via 269311a.

• It is mostly template driven. Just like with the functions, a type is created, which here has a static variable ptr.
  -- If the global usage of own structs is (currently) off, the ptr will contain the game address given via the template.
  -- If not, then it will provide the ptr to an static obj of the requested type, handled by the template object.

This declaration of the object itself in the "own" case is required, so that the ptr to it can be inlined (which at least currently, with only one involved cpp file, happens).
The actual definition needs to happen in a cpp file, which also allows to call constructors on it, or assign via functions, which will copy, but that should be ok for our cases.

The negative side effect is, that we need the objects address in two places. The file structure is also uncertain at the moment.

[gynt]

What is wrong with &DAT_ViewportRenderState ?
269311a#r169461842

[TheRedDaemon]

What is wrong with &DAT_ViewportRenderState ?

Nothing. I just changed it for my approach. Or do you mean the naming? That is purely in-line with the other namings I used so far and open for debate.

The approach allows to using the games structures at the moment, until we build the structures on our side.
Basically, once the re-implementation is done, and we want to switch to standalone, we would need to provide all data in our exe.
The templated version would allow to not touch any logic or functions at this step and instead focus on creating the structures. The exe would refuse to compile until all of them are present.

[gynt]

In order to support the incremental approach, whether or not the declaration uses a game pointer or a pointer to a new object preferably is determined case-by-case as reimplementation progresses.

struct StructResolver {
private:
    template <typename T, int gameAddress, bool useOwnStruct = true> struct InternalResolver;
    template <typename T, int gameAddress> struct InternalResolver<T, gameAddress, true> {
    private:
        static T obj;

    public:
        static T* const ptr;
    };
    template <typename T, int gameAddress> struct InternalResolver<T, gameAddress, false> {
        static T* const ptr;
    };

public:
    template <typename T, int gameAddress, bool useOwnStruct> struct Resolver {
        typedef typename InternalResolver<T, gameAddress, useOwnStruct> Ptr;
    };
};

template <typename T, int gameAddress>
T* const StructResolver::InternalResolver<T, gameAddress, false>::ptr = reinterpret_cast<T*>(gameAddress);
template <typename T, int gameAddress> T* const StructResolver::InternalResolver<T, gameAddress, true>::ptr = &obj;

#define MACRO_STRUCT_RESOLVER(STRUCT_TYPE, GAME_ADDRESS, USE_OWN_STRUCT)                                                               \
    typedef StructResolver::Resolver<STRUCT_TYPE, GAME_ADDRESS, USE_OWN_STRUCT>::Ptr