Split out Renderer from Simulation Class #60

New issue

Open

opened 2018-10-25 14:46:51 +00:00 by marty-oehme · 4 comments

marty-oehme commented

2018-10-25 14:46:51 +00:00

(Migrated from gitlab.com)

they carry out different functions, to increase orthogonality they should thus not be on one class

marty-oehme commented

2018-10-25 14:47:01 +00:00

(Migrated from gitlab.com)

created branch 60-split-out-renderer-from-simulation-class

created branch [`60-split-out-renderer-from-simulation-class`](https://gitlab.com/marty.oehme/cellular-automata/compare/master...60-split-out-renderer-from-simulation-class)

marty-oehme commented

2018-10-25 14:47:05 +00:00

(Migrated from gitlab.com)

mentioned in merge request !19

marty-oehme commented

2018-10-25 15:18:27 +00:00

(Migrated from gitlab.com)

Stumbling Stones -- or: Things to fix before attempting this:

either we need to expose the map from the simulation and pass that around each turn, or we implement a renderer which only re-renders according to the 'changeSet' which is already passed around (preferable)
going along with that, 'changeSet' needs to be an implementation of 'Grid', so the renderer has access to the various methods of going from the list of id's that is passed around to the actual x and y values (such as 'grid.toCoordinates' etc)
Find out what the best implementation for merging a lot of changes (what the current 'Grid' implementation of the map in the Simulation has to do) and accessing a lot of values is (what the changeSet implementation of the interface would have to do)
expose a way in the renderer to be set to dirty (though this would implicitly be taken care of when passing around changeSets. changeset empty? not dirty.)

Stumbling Stones -- or: Things to fix before attempting this: * [ ] either we need to expose the map from the simulation and pass that around each turn, or we implement a renderer which only re-renders according to the 'changeSet' which is *already* passed around (preferable) * [ ] going along with that, 'changeSet' *needs* to be an implementation of 'Grid', so the renderer has access to the various methods of going from the list of id's that is passed around to the actual x and y values (such as 'grid.toCoordinates' etc) * [ ] Find out what the best implementation for merging a lot of *changes* (what the current 'Grid' implementation of the map in the Simulation has to do) and *accessing* a lot of values is (what the changeSet implementation of the interface would have to do) * [ ] expose a way in the renderer to be set to dirty (though this would implicitly be taken care of when passing around changeSets. changeset empty? not dirty.)

marty-oehme commented

2018-10-25 15:26:22 +00:00

(Migrated from gitlab.com)

changed milestone to %2