I'm working on a binding for The Machinery, which has this type:
typedef struct tm_tt_id_t
{
union
{
// Used for comparing objects or storing them in hash tables.
uint64_t u64;
struct
{
// Type of the object.
uint64_t type : 10;
// Generation of the object, used to distinguish objects created at the same index.
uint64_t generation : 22;
// Index of the object.
uint64_t index : 32;
};
};
} tm_tt_id_t;
{.pragma: impapi_typesHdr, header: tm_dir & "api_types.h".}
type
tm_tt_id_parts_t = object
`type`* {.bitsize: 10.}: uint64
generation* {.bitsize: 22.}: uint64
index* {.bitsize: 32.}: uint64
tm_tt_id_t* {.bycopy, union, impapi_typesHdr, importc: "struct tm_tt_id_t".} = object
u64*: uint64
parts: tm_tt_id_parts_t
But when I try to access generation via parts the C compiler complains: error: field not found: parts. The only way I've been able to get around this is to avoid the union and creating procs to bit twiddle for type, generation, and index.
I got a suggestion to use importc on the tm_tt_id_parts_t type and the parts field, but I get the same field not found: parts error. From what I understand, importc create the mapping from of identifiers from Nim to C.
Is there a better way to handle this?
Depending on the library, you can avoid the .header altogether and rely on the ABI instead. Or you exploit the fact that an importc'ed type is well imported:
{.pragma: impapi_typesHdr, header: tm_dir & "api_types.h".}
type
tm_tt_id_t* {.bycopy, union, impapi_typesHdr, importc: "struct tm_tt_id_t".} = object
u64*: uint64
`type`*: uint64
generation*: uint64
index*: uint64
Your suggestion for relying on the importc'ed type being well behaved did the trick. Thanks!
As for The Machinery, it seems like the founding team has earned a good reputation among other veteran game developers. I've hacked on the engine a little bit to make various modifications, and compared to Godot's C++ it's much easier to understand and modify. Also, I don't know of any other option to use Nim with a "AAA" game engine.