..., as how hash-life does it. see Drawbacks ... Like many memoized codes, Hashlife can consume significantly more memory than other algorithms, especially on moderate-sized patterns with a lot of entropy, or which contain subpatterns poorly aligned to the bounds of the quadtree nodes (i.e. power-o...

it similiar Conway's Game of Life, but not it Yep, i use graph and binary tree, but i need store links for fast search in graph store 2 values in 1 - help it - 197 vs 33mb (78mb in C scruct, but C struct create and calculate slower...) I dont need superspeed and super optimization (OpenCL, preHashin...

15 000 000 x 15 000 000 tiles - realy overkill)))
and i not render it, all data going to log in text mode, but i need GUI to control and see group state
using threads - good idea )
project and algoritm samiliar https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life.....

it need for project (not game)... dinamic map 1000x1000 titles. (small version) 1000000 object (this object constantly moving) * 3 z layers = 3000000 pos + pos ---- faster, than: pos.x + x; pos.y + y If i use {x,y} or anyfing else //// And ---- LuaJIT's memory limited to 1-2 GB ... i cud take C, but...

int8_t - 62mb
int32_t, 78mb
16mb different not critical at 3000000 elements

I use FFI... it powerfull...
C struct = 0.84 sec and 62mb ||| 1 value = 0.37 sec and 33mb ||| {x, y} = 1.35 sec and 197mb

Hm....., before, i used pos = x*100000000 + y map not bigger than 99999999x99999999 titles for items on map Is enough... 100000001 - [x = 1, y = 1]; and 99999999 99999999 - [x = 99999999 , y = 99999999 ] y = math.fmod ( pos, 100000000 ) x = math.floor ( pos / 100000000 ) ... but this, faster: pos = ...

Small tip for store coordinats, eg map item, buttons, entity positions(player, enemy) typical use - testtable[id].x and testtable[id].y, for store, but... testtable - 3000000 elements testtable[id] = {["x"] = x, ["y"] = y} -- generation 1.4 sec for 3000000 elements and use 267390...

i use - collectgarbage("collect") + gcinfo() and collectgarbage("count") {[0] = x, y} (197 mb) - zero index not change array to hash table, becose {["x"] = x, y} (314mb) and why - {x, y} - not eq - {[1] = x, [2] = y}, ? -- 197mb and 267mb http://lua-users.org/wiki/Table...

-- testtable = {x, y} -- 1.088 \ 230 \ 197078
-- testtable = {[0] = z, x, y} -- 1.120 \ 230 \ 197080

testtable = {x, y, z} -- 1.1 \ 256 \ 220516
testtable = {[0] = vvv, x, y, z} -- 1.3 \ 257 \ 220511

zero index is exist? lua reserve memory, but not use it?