Sounds like a good idea! Thing is, I'd like it to still work with the stock precompiled libgraphices just like it works now...
It is most certainly my intention to not disrupt dfhack operation in any way.
From the technical point of view, you still need a good chunk of DFHack, as it needs to init some stuff - it needs to determine the version of DF and load up the appropriate version info (really an extension of DF's symbol table) from an xml file. All you'd be cutting out is the console and the plugin API, which are rather minimal anyway. The modules are helpful too, providing some abstractions on top of DF's structures...
I abstracted out whatever df-structures need from dfhack into
class essentials {
public:
virtual std::string readClassName(void *) = 0;
virtual void lock() = 0;
virtual void unlock() = 0;
virtual std::map<std::string, void *>& getVtable() = 0;
virtual void *getGlobal(const char *name) = 0;
};
I mostly split dfhack and df-structures already, moving them into depends. Now I'm cleaning up resulting bugs.
Since the code that prepares data for a frame to be rendered needs to run as fast as practical, wrappers are out of question.
Since df-structures are in fact inseparable from DF version, I expect Memory.xml being removed from dfhack runtime, globals' and vtable addresses being moved into df-structures. Only code checking that the DF version is correct/compatible with the df-structures build is in fact needed; addresses can be compiled in since it is most likely that each DF point release would require verification of entire df-structures xml data, baking a corresponding release compared to that is trivial.
On the other hand, the hackish way DFHack interfaces with DF's execution could be much improved. Right now, DFHack hooks some SDL calls, which isn't exactly ideal. It would be nice to be able to paint into DF's window and sync with the graphics thread for example. Or have libgraphics directly call Core methods.
Anyway, more details could certainly help.
Well, I most certainly can define some weak no-op symbols (in my libgraphics.so) to be called wherever you like, so that when dfhack is preloaded, it will be able to substitute its own. I don't know much if anything about windows in this regard above suspicion that making a libgraphics.dll would be hell of a headache.
Author
Topic: [PRINT_MODE:SHADER] (Read 89647 times)