Game of Life

[man]

Hi,

today I played around a little bit with the game of life:
http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

Then I thought, that it would be cool, to have this game implemented on my iPod.

What do you think about that?

man.

[Llorean]

The game needs 0 buttons. It is a 0-player game.

Assuming you wanted to be able to manually enter a pattern, it needs two buttons, "toggle square" and "go", plus 4 more to move up/down and left/right within the grid (this can be lessened to 1 if you want really slow grid traversal).

[piquadrat]

We just had cellular automatons and the Game of Life in a CS class, and as I'm trying to learn C and just installed Rockbox on my iAudio, this is the ideal little task for me

But don't expect anything fancy soon. I hacked up a console version of the game this afternoon and will port it to the X5 today or tomorrow, with a randomly filled world to begin with (editing and the like will come much later ).

BTW: how big do you think a cell should be? With the limited resolution of our players, 2x2 pixels is IMHO the most we can get without making the world to small...

[Llorean]

I think 2x2 pixels ought to be fine, with no borders between cells (for editing, later, the selected cell can simply blink).

[linuxstb]

We just had cellular automatons and the Game of Life in a CS class, and as I'm trying to learn C and just installed Rockbox on my iAudio, this is the ideal little task for me

But don't expect anything fancy soon. I hacked up a console version of the game this afternoon and will port it to the X5 today or tomorrow, with a randomly filled world to begin with (editing and the like will come much later ).

BTW: how big do you think a cell should be? With the limited resolution of our players, 2x2 pixels is IMHO the most we can get without making the world to small...

Remember that Rockbox works on many different LCDs - from 112x64 mono up to 320x240 full-colour.

So it's a good idea not to hard-code anything related to the display, but use #defines which can then be set based on the LCD of the target.

[piquadrat]

linuxstb: yeah, I already stumbled upon LCD_WIDTH and LCD_HEIGHT which come in handy


EDIT: Problem solved. "step" wasn't the luckiest choice for a function name since it seems to colide with another member... ignore anything below this line:

----------------------------------------------------------------

on a related note, I have a little problem "porting" my console-code. Following function works without a hitch on my computer, but causes a crash in the simulator:

Code: [Select]

#define XDIM LCD_WIDTH / 2
#define YDIM LCD_HEIGHT / 2

static bool last_gen[YDIM + 4][XDIM + 4];
static bool this_gen[YDIM + 4][XDIM + 4];

....

void step(void){
	int i, j;
	for(i = 1; i < (XDIM + 2); i++){
		for (j = 1; j < (YDIM + 2); j++){
			int n = count_neighbours(i, j);
			if ((last_gen[j][i] == false) && (n == 3)){
				this_gen[j][i] = true;
			}else if((last_gen[j][i] == true) && ((n < 2) || (n > 3))){
				this_gen[j][i] = false;
			}
		}
	}
	for(i = 0; i < (XDIM + 4); i++){
		for (j = 0; j < (YDIM + 4); j++){
			last_gen[j][i] = this_gen[j][i];
		}
	}
}

Is there any code in there that Rockbox doesn't like? I'm quite sure it isn't an "array index out of bounds" problem. I changed the bounds well into the array size and it still crashes. The error message from the simulator is here.

EDIT: after further investigation, I found out that replacing the function call with the function itself "solves" the problem - but looks ugly, of course. Here's my main function. Something wrong with the "step();" function call?

Code: [Select]

enum plugin_status plugin_start(struct plugin_api* api, void* parameter){
	(void)parameter;
	rb = api;
	init_world();
	display();
	rb->sleep(5*HZ);
	int i;
	for (i = 0; i < 5; i++){
		step();
		display();
		rb->sleep(HZ);
	}
	return PLUGIN_OK;
}

[piquadrat]

OK, here's a prelimenary version of the plugin. It just fills 40% of the screen randomly with cells and starts. So no glider guns yet Use the power button to exit.

BTW, is there a way to set the color of lcd_fillrect? I'd like to use colors to show the age of a particular cell.

[attachment deleted by admin, too old]

[Noxneo]

I was thinking recently about coding this.

Well, I'll let piquadrat do the thing

I'm gonna check your plugin, I'll give feedback later.

[mightybrick]

Use the power button to exit.

What about players without a dedicated power button, such as the iPods?

[piquadrat]

mightybrick: ok, I copied the button definitions from the sokoban plugin. But don't ask me what "BUTTON_SELECT | BUTTON_MENU" means "Up" and "Down" ("Menu" and "Play" for the iPod) now adjust simulation speed.

In the meantime, I wrote a reader for world-files like this (a glider):

Code: [Select]

010
001
111

Unfortunately, the glider dies instead of, well, gliding. Randomly appearing gliders behave like they should, so I'm pretty clueless...

[attachment deleted by admin, too old]

[Yotto]

A game of life program I wrote (a long long time ago) had a border problem when reading files.  Check for that.  Anythign on the border of the file I read wouldn't give birth off the border on the first iteration.  So your glider wouldn't create the dot below the bottom line, killing it.

Just a guess, may not be right.

[man]

very nice, that there is so much interest in it.
My thought of the UI structure was:
start the plugin:
- menu
  - edit mode
    (a little zoomed in (maybe 3x3 cells?) where the selected cell is always in the middle,
    so scrolling is done automatically by selecting another cell)
  - play mode
    (here the zoom and speed options apply, there is ony a need for play, pause,
    and return to menu. Maybe scrolling for infinite fields?)
  - import (rle and ascii-files)
  - speed
  - zoom
  - quit

man

[soap]

A game of life program I wrote (a long long time ago) had a border problem when reading files.  Check for that.  Anythign on the border of the file I read wouldn't give birth off the border on the first iteration.  So your glider wouldn't create the dot below the bottom line, killing it.

Just a guess, may not be right.

That is exactly what I was thinking, a test would be to import a world file such as:

Code: [Select]

00000
00100
00010
01110
00000

[piquadrat]

I already tried that. The glider dies even if it is right in the center of the world... well, I'll probably implement edit mode today, perhaps "edited" gliders behave more to their nature

[piquadrat]

Well, didn't quite make it to editor mode today. But zooming and and scrolling now works. Well, only for the iAudio X5, because I don't know how to set up a reasonable mapping for the other platforms. I'd appreciate suggestions from interested owners of other players As of now, the plugin needs buttons for scrolling in four directions, a quit button, a zoom button and a play/pause button. In the near future, a menu button will also be needed. Here's the iAudio X5 mapping:

Code: [Select]

#elif (CONFIG_KEYPAD == IAUDIO_X5_PAD)
#define GOL_UP BUTTON_UP
#define GOL_DOWN BUTTON_DOWN
#define GOL_RIGHT BUTTON_RIGHT
#define GOL_LEFT BUTTON_LEFT
#define GOL_QUIT BUTTON_POWER
#define GOL_PLAY BUTTON_PLAY
#define GOL_SELECT BUTTON_SELECT

man: good idea for the edit interface, I'll do it like that. Concerning infinite scrolling, I don't think that's possible. My X5 barely does 5 iterations per second with a bordered 160x128 world. Granted, my life-algorithm is the slowest imaginable and there are several much more efficient implementations with linked lists, bitvectors, lookup tables and whatnot, but that's just a little over my head right now


[attachment deleted by admin, too old]