-
-
Notifications
You must be signed in to change notification settings - Fork 196
Description
Extracted from a series of on the Mach discord starting with this one. Seems important enough to document in an issue here too.
TL;DR: One should be able to have up to 64 object types per module, but the actual number is much smaller and depends on the names of the object types.
According to a comment in the module code, the object system should handle up to 64 object types per module.
Lines 21 to 26 in 8ef4227
| const PackedObjectTypeID = packed struct(u16) { | |
| // 2^10 (1024) modules in an application | |
| module_name_id: u10, | |
| // 2^6 (64) lists of objects per module | |
| object_name_id: u6, | |
| }; |
In practice, this isn't the case, as the object_name_id is set to the ID of the name in a string table.
Lines 654 to 660 in 8ef4227
| const object_name_id = try m.object_names.indexOrPut(allocator, mod_field.name); | |
| // TODO: use packed struct(TypeID) here. Same thing, just get the type from central location | |
| const object_type_id: u16 = @bitCast(PackedObjectTypeID{ | |
| .module_name_id = @intCast(module_name_id), | |
| .object_name_id = @intCast(object_name_id), | |
| }); |
The string table ID is the offset of the name in the string table's byte storage, which causes the object name IDs to grow faster than one would expect:
Object names + their IDs:
name: windows, id: 0
name: shaders, id: 8
name: vertex_data, id: 16
name: scenes, id: 28
StringTable's byte storage:
0 1 2
0123456789abcdef0123456789abcdef012
windows0shaders0vertex_data0scenes0
^0 ^8 ^16 ^28
This causes a panic after more than 64 bytes are written to the string table, as the ID can't be casted to an u6 without trucating. Object names with e.g. 85 bytes were also noted to cause issues on the discord conversation.
A comment from the BDFL on this issue can be found here.