[WIP] cvar changes (DO NOT MERGE) #137
Conversation
| typedef struct Color_RGB8_t { | ||
| uint8_t r, g, b; | ||
|
|
||
| #ifdef __cplusplus | ||
| bool operator==(struct Color_RGB8_t const& other) const { | ||
| return (r == other.r) && (g == other.g) && (b == other.b); | ||
| } | ||
|
|
||
| bool operator!=(struct Color_RGB8_t const& other) const { | ||
| return !(*this == other); | ||
| } | ||
| #endif | ||
|
|
||
| } Color_RGB8; | ||
|
|
||
| typedef struct { | ||
| typedef struct Color_RGBA8_t { | ||
| uint8_t r, g, b, a; | ||
|
|
||
| #ifdef __cplusplus | ||
| bool operator==(Color_RGBA8_t const& other) const { | ||
| return (r == other.r) && (g == other.g) && (b == other.b) && (a == other.a); | ||
| } | ||
|
|
||
| bool operator!=(Color_RGBA8_t const& other) const { | ||
| return !(*this == other); | ||
| } | ||
| #endif | ||
|
|
There was a problem hiding this comment.
These changes were to make these types comparable, for CVarDefaulted::ShouldSave()
|
|
||
| namespace Ship { | ||
| typedef enum class ConsoleVariableType { Integer, Float, String, Color, Color24 } ConsoleVariableType; | ||
| typedef union CVarValue { | ||
|
|
||
| } CVarValue; | ||
|
|
||
| class CVarInterface { | ||
| public: | ||
| using VauleType = std::variant<int32_t, float, std::string, Color_RGBA8, Color_RGB8>; |
There was a problem hiding this comment.
In lieu of an enum to store the type, I opted for std::variant. This makes it more type safe and allows everything to be templatized.
| }; | ||
|
|
||
| template<class StorageType> | ||
| class CVarDefaulted : public CVarInterface { |
There was a problem hiding this comment.
This stores a CVar that has a default value. This is so we know to save this CVar only when it is not its default. This is to answer a question, "When asked to save, when should we save a CVar?" This is a question because these changes require a user to register all cvars in advance, so we don't necessarily want to save all of them if many of them are unchanged since they were registered.
This behavior was a struggle to me, since we are somewhat messy about things as it is. There are two possibilities:
- Save when they are not the default
- Save if they have ever been set (not just initialized), even if they are their default value.
I opted to do the first option since it allows use to change defaults if we ever decide a different default than what we had in a previous version is the best option for users. I am open to other opinions, however.
| @@ -99,6 +99,8 @@ void Window::Initialize(const std::vector<std::string>& otrFiles, const std::uno | |||
| InitializeControlDeck(); | |||
| InitializeCrashHandler(); | |||
|
|
|||
| CVarLoad(); | |||
There was a problem hiding this comment.
This was moved from the ImGui Init() because it made absolutely no sense there.
| @@ -30,4 +30,5 @@ DEFINE_HOOK(GfxInit, void()); | |||
| DEFINE_HOOK(ExitGame, void()); | |||
| DEFINE_HOOK(LoadFile, void(uint32_t fileNum)); | |||
| DEFINE_HOOK(DeleteFile, void(uint32_t fileNum)); | |||
| DEFINE_HOOK(CVarInit, void()); | |||
There was a problem hiding this comment.
The purpose of this hook is to allow clients to add their CVars after the CVar system has been set up, but before the config file has been loaded and the saved CVars are applied
Kenix3
force-pushed
the
main
branch
2 times, most recently
from
a3f18f7 to
c946c2c
Compare
|
Any interest in seeing this PR to completion? |
|
Yes! It has been a while since I've thought about this PR, and I have some new ideas for it. I want to further move towards CVars just being a name to point to one of several kinds of data. So, CVars are just a fancy way to dereference a pointer. Now, what they point to can be one of several things. The things they point to have two strata: if the data is static, and if the data is saved. Static meaning the data is known at compile time and is enumerated. And the data being saved is self-explanatory. This gives us some categories: Settings - static and saved Currently, all of our existing CVars are what I now call "Dynamic Settings." I want to move them towards "Settings," and then move some to "Globals" as we decide they don't have to be saved. I will work towards a v2 of this rework soon. |
This is a WIP example of reworking CVars to solve several issues with them. This is the LUS side of things, for the SoH PR, see HarbourMasters/Shipwright#2552.
The issues I am trying to fix:
To remedy this, I have introduced a new interface for CVars. The core idea is to disassociate CVars and their storage of data. That is, there are CVars and store the value they name, and also ones that just associate that name to a value stored elsewhere. This enables CVars to just be used as a name for a regular C variable, allowing clients of CVars to safely use that data without any additional overhead, whether that overhead be in access time or bug potential.
This PR adds this new interface alongside the old so I could used and test it, so it is a bit awkward. The intent is to entirely replace the old one, so in judging it, I would ask you to consider only the new additions, and not the modifications to the existing interface. I will try to note points of interest.