bertrand-caron / cocoa-game-of-life Goto Github PK

Mathematically speaking

A sufficient condition to know whether we have reached a stationary state is the equality of two frames population. The periodicity if then defined as the distance between the two closest identical frames.

Implementation

We can't check at every step that the frame is different to every over frame ever generated (which implies logging the whole trajectory). We can work with a periodicity cut-off of nFrames which are kept in memory, and find a necessary condition which is way less computer-intensive than checking the exact equality of two frames.
First idea would be checking numberOfLiveCells:

Context

When reaching a gridSize greater than a few thousands, the display gets really bad and the frame rate drops.

Question

Is the display limiting, or is the engine ? Can a OpenCL/GPU Rendered game of life engine give us better scalability ? Or it is just a matter of improving/changing the display engine ?

Source :

• http://ptgmedia.pearsoncmg.com/images/art_chisnall_opencl/elementLinks/opencl.c.html

Time Profiling

(Not accounting for __CFRunLoopDoTimers 11.5%)

• The drawing is the limiting factor : [CellView drawRect:] takes more than 90% of computing power (which is furthermore limited to a single core).
  • Just disabling grid drawing seems to double frame rate
  • Why is the grid redrawn at every step ?
• Maybe only readrawing cells that have changed (requires a memory of the system, which we were gonna implement anyway [#1]).

Idea

http://en.wikipedia.org/wiki/Conway's_Game_of_Life#Examples_of_patterns