FWGS
[WIP] abi2 prototype
This is just a prototype. Now made in more thoughtful process, and proper class wrapper that helps to avoid string_t<>int conversions.
Though I'm really have mixed feelings on how it turned it anyway, especially with broken engine headers.
I also think it must be pretty much possible to load both abi1 and abi2 binaries on engine side.
Stuff like pev->team = MAKE_STRING is absolutely stupid.
It's already defined in save restore as FIELD_INTEGER.
I think the string could be moved elsewhere, I don't see where it's used by the engine, and it's not really used by game dll as a string value that much. But it's more porting existing code compared to ABI1 anyway.
Could you provide more context on what it is? Proper support for strings on 64-bit platforms?
@FreeSlave yeah. Historically, string_t workaround was made in an attempt to load original GoldSource 64-bit binaries, like cs_amd64.so which still present in Counter-Strike distribution.
But it has few downsides:
- It tries to allocate the string base somewhere closer to the server library, which isn't reliable on almost all platforms.
- It makes
MAKE_STRINGoptimization useless, because we can't store 64-bit pointer in a 32-bit data type, obviously. - It forces server.dll to rely on engine's string pool, making
ALLOC_STRINGmuch more expensive, potentially being able to exhaust the string pool (though that never happened to me). ALLOC_STRING's deduplication mechanism potentially breaks the API, and it's enabled by default.
By just making string_t larger these problems become irrelevant. And we get few more.
And we get few more.
By making process of 64-bit porting a bit more complicated.
In short, first ABI was easier on HLSDK side but harder for engine. ABI2 makes it very easy for engine but harder for HLSDK and mostly because of fixing up for buggy string_t↔int conversions.