From: fv@nospam.tcenl.com   
      
   Bart schreef:   
   > Hi Femme,   
   >   
   > Op Sat, 13 Jan 2007 21:40:44 +0100 schreef Femme Verbeek   
   > :   
   >   
   >> I wrote a life game long ago. If it is of any use for you I can send it   
   >> by mail.   
   >   
   > I'd like that. My mail is in my signature (remove the obvious parts).   
   >   
   > I'm curious how other people implement the "world", that is, what kind   
   > of data structure do they use.   
   > In my first attempt I used a array[x,y] of byte (it was still 16 bit   
   > time). Now I use a structur that contains pointers to all neighbours.   
   > Setting up the board becomes more complicated, especially when   
   > implementing a wrapping strategy, but the advantage is that you, most   
   > of the time, have to do this only once in the game. Calculating   
   > neighbours becomes less complex and even a little bit faster.   
   >   
   > And how do they optimize the next-generation calculation?   
   > For example, if you look at a board ad see a large section with all   
   > celss dead, you immediately know that in the next generation these   
   > cells will be dead also. Yet in my current coed I still have to   
   > iterate all cells to determine their next status.   
   >   
   > I recently came across some life implementation (made apparantly in   
   > Delphi) that has a world occupying as much as 1 million by 1 million   
   > celss (I guess this one sees each cell as a bit, so 16 cells in a   
   > 2-byte integer value, this would easiliy allow for a world 64 times   
   > larger than mine, using the same memory footprint). Althoug this   
   > approaches an indefinite large world (as Conway intended it to be)   
   > more than my current one (max. 1280 x 1024), and so gives more   
   > opportunity to studie for example large methusalehs, given current   
   > screen sizes it does not seem very practical to actually see what's   
   > going on.   
   >   
   It has been 14 years since I worked on that game.   
   I used a bitwise memory representation. Calculation of the next   
   generation involved bitwise operations, which is pretty much faster than   
   addressing each neighboring pixel separately.   
      
   The bytes are stored in a one dimensional array. This solves the   
   left-right boundary problem in a very simple way, albeit that right an   
   leftside of the screen are shifted over one pixel. By adding a copy of   
   the last line in front and the first line at the end, the top and bottom   
   boundary problems are solved.   
      
   The use of MOVE for very fast bulk copying of information.   
      
   There are two complete screens in memory. Calculation of the next screen   
   involves swapping of their respective pointers.   
   The maximum screensize of 640x480 was standard at the time. Due to the   
   bitwise notation, the entire screen fits in 38400 bytes + 2 extra   
   boundary lines   
   An offset of 100 bytes for the first extra boundary line was used, but   
   perhaps numbering from -(one line) to (totalscreen + one line) would   
   have been more clear.   
      
   -- Femme   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)