Subject: [stella] My next program... From: jvmatthe@xxxxxxxxxxxxx Date: Wed, 16 Oct 1996 12:15:12 -0400 (EDT) |
Well, after about 6 hrs of hard work, I have a nearly working version of my next program. Assuming I can fix the one known bug in it, I may post it in the next day or so. Anyway, it is only a very early form of what I plan to have as my big project. This idea occurred to me while I was reading the article in Next Generation magazine about artificial life. Here's the plan: Implement Conway's Game of Life on the Atari 2600 with: 1) Several starting arrangements available via the select switch 2) A mode to allow you to set up an initial arrangement via the joystick 3) Speed adjustable via a paddle in port 2 4) Maybe a two player game based on this (iffy) So far, I have an 8x8 grid implemented and it is very easy to expand to 8xY where Y is whatever value you want under 16. The tough part is moving from that size grid to a 16x16. This will only (as far as I can tell) take less than 40 bytes of the available RAM on the 2600 and should run fairly quickly. Right now, it updates the displayed matrix about every 1/20 of a second, but with quadrupling the grid size it will be slower, but still under a second, I hope. Anyway, if anyone wants to suggest a faster algorithm for updating the matrix, I am all ears. Here is how it works right now: Assume only doing an 8x8 grid. Then there are 10 bytes stored to hold the grid, numbered A,0,1,2,3,4,5,6,7,B. A second array is kept on which to do changes based on the first grid. The ones that are 0-7 are really the grid and A and B are empty 'buffer' zones to cut down on the amount of code necessary for 'boundary' cells. The cells are divided into two groups: middle, left-edge and right-edge. Each bit of each byte represents a cell with 1=alive and 0=dead. The algorithm picks a bit (column) and works down the bytes (rows). Here is the setup: 76543210 <- bits ArrayA 00000000 Array1 00000000 Array2 00000000 Array3 00000000 Array4 00000000 Array5 00000000 Array6 00000000 Array7 00000000 ArrayB 00000000 So if we are working with bits 1 (a middle bit) in Array1 then we count its live neighbors by first counting the ones directly above and directly below (six cells there) and then the two on each side (for a total of 8 neighboring cells). Then the status of that cell is determined by the following: 2 live neighbors --> same status 3 live neighbors --> alive next round else --> dead next round This new status is then changed in NArray1. A special routine counts neighbors for bits 0 and 7. ArrayA and ArrayB are empty and only used as a 'buffer' zone; they never change. Once changes have been made in all the NArray# bytes, they are copied over the old values of Array# and the process starts all over again. I haven't finished the timing, but it looks like the process can be done in the following pieces: 1) do columns 6-4 2) do columns 3-1 3) do columns 0,7 and update new matrix. Since this will repeat every 3 screens, that makes the total cycle 1/20th of a second. So if you have an idea on how to make a quick algorithm for doing these calculations, let me know. Also, if you have some easy code for working with the joysticks and maybe moving a player graphic cursor around the screen, that would be nice to have. Thanks! matt =========================================================================== ||| John V. Matthews, III | PO Box 50355 ||| NCSU Mathematics Graduate Student | Raleigh, NC 27650 / | \ http://www4.ncsu.edu/~jvmatthe/www/ | (919) 515 7324 ===========================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[stella] Latest program..., jvmatthe | Thread | [stella] Sorry about the double pos, jvmatthe |
[stella] Latest program..., jvmatthe | Date | [stella] Sorry about the double pos, jvmatthe |
Month |