| Time |
Nick |
Message |
| 00:01 |
|
T4im joined #minetest-dev |
| 00:12 |
|
Taoki joined #minetest-dev |
| 01:50 |
|
calcul0n__ joined #minetest-dev |
| 01:54 |
|
TechDude joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:00 |
MTDiscord |
<Techy5> I know this would require breaking compatibility, but has anyone considered variable-width content IDs for serialized mapblocks? The vast majority of mapblocks aren't going to contain over 256 node types, so it's a waste to always use 16-bit content ids when 8-bit IDs would work. |
| 05:02 |
MTDiscord |
<Techy5> I tested 8-bit IDs on one fairly typical mapblock and was able to reduce the total size of the block by around 12%. Not huge, but that's an entire gigabyte saved on a 10 GB map. |
| 06:49 |
|
Fixer joined #minetest-dev |
| 06:58 |
|
troller joined #minetest-dev |
| 07:13 |
|
nerzhul joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:28 |
|
silver_est joined #minetest-dev |
| 08:48 |
|
Fixer_ joined #minetest-dev |
| 08:50 |
|
hlqkj joined #minetest-dev |
| 09:37 |
|
tech_exorcist joined #minetest-dev |
| 09:41 |
|
tech_exorcist joined #minetest-dev |
| 09:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:51 |
|
entuland joined #minetest-dev |
| 11:17 |
|
silver_estonia joined #minetest-dev |
| 11:48 |
|
troller joined #minetest-dev |
| 11:54 |
|
amk joined #minetest-dev |
| 12:03 |
|
silver_est joined #minetest-dev |
| 12:11 |
|
silver_est joined #minetest-dev |
| 12:22 |
|
Fixer joined #minetest-dev |
| 13:04 |
|
Taoki joined #minetest-dev |
| 13:23 |
|
silver_est joined #minetest-dev |
| 14:23 |
MTDiscord |
<Benrob0329> Wouldn't you need to store a map/dictionary/set for each mapblock then? |
| 14:23 |
sfan5 |
mapblock already do that |
| 14:25 |
MTDiscord |
<Benrob0329> I mean one for node_ids |
| 14:37 |
sfan5 |
yes? |
| 14:38 |
sfan5 |
there is no translation table at runtime but that's not what he meant anyway |
| 14:38 |
sfan5 |
there still is a legacy mode with 8-bit content IDs: content_width=1 |
| 14:39 |
sfan5 |
and for some reason it wasn't bound to the mapblock version so you can use it to save some space in mapblocks even today (with zero compat concerns) |
| 14:53 |
|
hlqkj joined #minetest-dev |
| 15:23 |
|
absurb joined #minetest-dev |
| 16:18 |
|
hlqkj_ joined #minetest-dev |
| 16:18 |
|
AntumD joined #minetest-dev |
| 16:18 |
|
p_gimeno joined #minetest-dev |
| 16:26 |
|
tech_exorcist joined #minetest-dev |
| 17:45 |
MTDiscord |
<Techy5> There might be some compatibility issues. It looks like the upper 4 bits of param2 were used to store the rest of the content ID if it exceeded a certain value (I'm not quite sure how this works): https://github.com/minetest/minetest/blob/master/src/mapnode.cpp#L811 |
| 17:47 |
sfan5 |
yeah |
| 17:47 |
sfan5 |
you can actually store 128 nodes with full param2 and 2048 nodes with param2 < 16 with this approach |
| 19:23 |
|
Fixer joined #minetest-dev |
| 20:01 |
|
v-rob joined #minetest-dev |
| 20:04 |
v-rob |
Say, are dummy mapblocks even used anymore? I tried removing `dummy` from the constructor, and Minetest compiled fine, and there's no other way for dummy mapblocks to exist except through the constructor as far as I can tell. |
| 20:04 |
sfan5 |
check where it's called and see? |
| 20:05 |
sfan5 |
oh wait |
| 20:08 |
sfan5 |
> If NULL, block is a dummy block. Dummy blocks are used for caching not-found-on-disk blocks. |
| 20:09 |
sfan5 |
this sounds useful though, why don't we have this anymore? |
| 20:11 |
v-rob |
Assuming we don't have a use for them, mapblocks could use a std::array for nodes and the `*Unsafe` methods could be removed, making the code simpler. |
| 20:38 |
|
hlqkj_ joined #minetest-dev |
| 20:51 |
celeron55 |
i think it would be up to ServerMap::loadBlock to set that |
| 20:52 |
celeron55 |
the logic there seems weird and possibly buggy |
| 20:57 |
|
proller joined #minetest-dev |
| 21:30 |
|
proller joined #minetest-dev |
| 21:36 |
|
olliy_ joined #minetest-dev |
