Increase Simulation Performance #51

New Issue

2018-08-31T09:29:43Z

marty-oehme commented

2018-08-31 09:29:43 +00:00

(Migrated from gitlab.com)

simulation:

keep it to one loop through the cells
subdivide grid into smaller grids containing cells -> only activate grids with cells close-by
increase efficiency of getNeighbors function (is called 10.000x on 100x100 grid)

rendering:

only render on changes
only (re-)render the cells which have changed

simulation: * keep it to one loop through the cells * subdivide grid into smaller grids containing cells -> only activate grids with cells close-by * increase efficiency of getNeighbors function (is called 10.000x on 100x100 grid) rendering: * *only* render on changes * only (re-)render the cells which have changed

marty-oehme commented

2018-10-15 15:14:30 +00:00

(Migrated from gitlab.com)

We ONLY ever have to iterate over cells which are alive (since they have to be checked against 'survival' every tick) and cells which are neighboring those that are alive (since they can be 'birthed' by having a sufficient number of neighbors). No other cell has to be checked

so, one thing to do would be keeping a list of all cells that are alive (and only those) and then when updating rolls around just iterating through them. the changeSet would have to be applied to them each frame as well.

We ONLY ever have to iterate over cells which are alive (since they have to be checked against 'survival' every tick) and cells which are neighboring those that are alive (since they can be 'birthed' by having a sufficient number of neighbors). No other cell has to be checked so, one thing to do would be keeping a list of all cells that are alive (and only those) and then when updating rolls around just iterating through them. the changeSet would have to be applied to them each frame as well.

marty-oehme commented

2018-10-19 14:10:30 +00:00

(Migrated from gitlab.com)

It might also be useful to work with regions - whenever a cluster of cells (i.e. a region of, say, 10-15 cells) is either completely filled, completely empty, or stagnant for a while; it would be declared 'inactive' and not looked at for the neighboring cell counting function.

(Regions could even be removed from memory when not necessary for the timeline and just replaced with an enum describing their full or empty state when completely full or empty)

It might also be useful to work with regions - whenever a cluster of cells (i.e. a region of, say, 10-15 cells) is either completely filled, completely empty, or stagnant for a while; it would be declared 'inactive' and not looked at for the neighboring cell counting function. (Regions could even be removed from memory when not necessary for the timeline and just replaced with an enum describing their full or empty state when completely full or empty)

marty-oehme commented

2018-10-25 15:37:59 +00:00

(Migrated from gitlab.com)

changed milestone to %3

Sign in to join this conversation.