Open XertroV opened 1 year ago
I still wonder if it makes sense to either:
Either way, I think re-implementing a GBX parser in Angelscript is not really the way to go.
some toughts:
I don't need this for anything atm, but it enables some stuff. The GBX parsing I do atm is to get the icon (which is in the header, so uncompressed), so game-texture rendering via openplanet would eliminate my need for gbx parsing in AS atm.
Reimplementing gbx.net might be a pain since it's all based on manual inspection / debugging / decomp (AFAIK), so there'd be a bunch of work involved (but might be something the community could work on as a new project). Bigbang is also writing a new scripting system that's much more flexible to get away from the painful impl atm.
Reverse engineering the game's parsing and having native AS bindings sounds amazing, but IDK how much work is involved there. The advantage would be "perfect" parsing, it works for all formats automatically, etc. I guess it would be something like Fids::LoadFrom(filepath)
in the simplest sense.
WRT gbx parsing, the nicest way I've seen it done is the recent gbx-py
by shadocalex. Here's an example (CPlugSurface): https://github.com/schadocalex/gbx-py/blob/b67e14bcf186a5f5716ceb9575c3183291858677/src/gbx_structs.py#L1548
This still involves manually writing the specifications for each chunk, but it's much more concise, and e.g., fixing a bug reading/writing gbx files only needs a change in one place to update everything.
Thought I'd mention b/c if there are any substantial efforts here then it IMO it'd be nice to spend time on the API so that it can be as nice as the linked example.
This would enable some native (angelscript) interactions with gbx objects