# GMLscripts.com

Discuss and collaborate on GML scripts

You are not logged in.

## #41 2011-04-29 18:41:58

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

### Re: CHALLENGE: Conway's Game of Life

Tilt. I would never have figured out the proper sequence myself. Genius guys.

Last edited by icuurd12b42 (2011-04-29 18:42:20)

Offline

## #42 2011-05-03 05:09:12

~Dannyboy~
~hoqhuue(|~
From: Melbourne, Australia
Registered: 2009-10-02
Posts: 21
Website

### Re: CHALLENGE: Conway's Game of Life

Today I received my c++ assignment for this semester, would you believe it's "Conway's Game of Life"? lol

Offline

## #43 2011-05-03 05:21:18

Manuel777
Registered: 2011-04-25
Posts: 4
Website

### Re: CHALLENGE: Conway's Game of Life

Darn surfaces and its colours! haha

I would of never figured it out that way, you guys are genius!

Offline

## #44 2011-05-03 10:19:54

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

### Re: CHALLENGE: Conway's Game of Life

Sorry this is a bit off topic but does anyone know why the draw_clear and draw_clear_alpha() functions break xot's method? I tried to replace the primitive code because it was after all just drawing a rectangle over the whole scene but yeah, draw_clear doesn't work. Does it not respond to blend modes?

Offline

## #45 2011-05-03 16:04:30

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

Welcome to the forums, Rani.

Your guess is correct. Blending mode settings do not affect draw_clear() or draw_clear_alpha().

Abusing forum power since 1986.

Offline

## #46 2011-05-03 18:23:54

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

### Re: CHALLENGE: Conway's Game of Life

~Dannyboy~ wrote:

Today I received my c++ assignment for this semester, would you believe it's "Conway's Game of Life"? lol

Maybe you can blow your teacher mind with the surface method lol

Offline

## #47 2011-05-03 20:25:35

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

### Re: CHALLENGE: Conway's Game of Life

Cheers for clearing that up xot. Is there any reason for that? it seems not so sensible to me...

Apologies for my impending stupid, I promise I'm smart! I'm sure one day I'll contribute something valuable to the forums.
Today is not that day, today I make naive suggestions:

I see how you run three channels seperately and that makes me think that couldn't that be used to reduce memory footprint?
Idea - Use them on the same grid?
What I'm thinking is that the red channel simulates the top half of the room the green channel the bottom half. Ideally (though I can't think of how this could be posible in Game Maker), we'd have four channels RGBA and divide the grid into quarters. Now I know that getting the RG top-bottom sim to work is possible, xot proved that, but what I can't work out is how to seperate them so that they are drawn in two seperate places. My questions are these...

1 - Manipulating alpha channel in Game Maker? Comments? Suggestions? (Nice broad one to start off with)
2 - Is my suggested change worth it? Say we were porting to an iOS device and we need all the memory we can get, will this change slow down the engine too much? I know it will slow it down a tiny bit at least. Actually, will you need to add another surface for this? hmm only just thought of that...
3 - ... Oh I only had two questions.

Sorry for the onslought of requests but you allnknow so much, I MUST LEARN.... *twitch

Offline

## #48 2011-05-03 20:56:29

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

If I understand what you are asking, you want to know if color depth can be converted to spatial area.  While it is certainly easy to draw one color channel on the top half of the screen, and the other channel on the bottom half, there are some important limitations. (Although it is possible to use the Alpha channel as a fourth simulation, and devote the channels to quadrants, it would complicate things significantly.)

First, the two halves of the display would necessarily be different colors. This can be worked around, but it is slow (see next point).

Second, the simulations on each channel are decoupled. As it is, there would be no communication of information from the top half to the bottom half. A glider would get the middle of the screen and vanish. You'll need to find a way of communicating the information between color channels. The fastest way I know of to do this is to use them as an alpha mask. Game Maker supplies this with the sprite/background_create_from_screen/surface() functions. As fast as it is, it is still quite slow. However, you could get by with only operating on the boundary rows of pixels, which would improve speed greatly. That said, this is also the same function you would need to draw the separate colors channels as a single unified color. Since you would be operating on the entire display (or at least half of it) you would lose the gains of operating only on the boundary rows.

It still might be pretty fast, but I'm not sure it would be worth the effort.

As for iOS devices, at the moment they do not support surfaces at all. Based on comments made by Mike Dailly, this may change in the near future.

If you are wanting to do this more smartly on an iOS device, the truly smart thing to do is use a different API and program this as a pixel shader. It would be much faster and simpler.

Abusing forum power since 1986.

Offline

## #49 2011-05-04 20:53:14

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

### Re: CHALLENGE: Conway's Game of Life

Hmm, but if you made a two surfaces (room_width,room_height/2+1) then couldn't you have the same row, on each surface stored in the seperate colours to prevent slow downs?

But don't get me wrong, I don't think it's worth the effort any more at all, I am merely curious. I just read your draw_set_blend_mode topic and I finally understand blend modes! So hopefully I can now have a bit of a play around. Cheers xot!

Offline

## #50 2011-05-04 21:49:07

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

Simply stitching two surfaces together could be very fast, but I thought the idea was to use one surface and split the color channels across multiple screen spaces. The slowdown comes from transferring the information between color channels. No blend mode allows the color channels to influence each other. That requires getting the CPU involved by reading the texture into conventional memory, manipulating the data, and sending it back to the GPU, which is much slower than doing everything on the GPU.

I'm pleased you found my topic on blend modes helpful and look forward to someday seeing what you do with them.

Abusing forum power since 1986.

Offline

## #51 2011-06-07 05:26:13

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

I was playing around with this again today and have implemented a couple of new CAs using the same surface blending technique.

The first up is Gérard Vichniac's Vote, which you can read about here. The gist is, a cell will take on the value most popular in its neighborhood. The twist is, if the margin of favor is narrow, it "votes" the other way.

I think this could make a good basis for a procedural cave generator. Replace the code in the Step Event of my demo with this to try it out. Works best when the default random pattern is used (press 0), but I could see adding a simple network of lines to help guide its development.

{
//  Vote : sum of neighborhood and self {4,6,7,8,9 => 1, else 0}
//      new  = band pass 4 (cells with exactly 4 living neighbors/self are alive)
//      new += high pass 5 (cells with more than 5 living neighbors/self are alive)

//  NineSum of Neighbors/Self
surface_set_target(sum);
draw_clear_alpha(c_black,1);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_surface_ext(surf,-1,-1, 1,1,0,$010101,1); draw_surface_ext(surf, 0,-1, 1,1,0,$010101,1);
draw_surface_ext(surf, 1,-1, 1,1,0,$010101,1); draw_surface_ext(surf,-1, 0, 1,1,0,$010101,1);
draw_surface_ext(surf, 0, 0, 1,1,0,$010101,1); draw_surface_ext(surf, 1, 0, 1,1,0,$010101,1);
draw_surface_ext(surf,-1, 1, 1,1,0,$010101,1); draw_surface_ext(surf, 0, 1, 1,1,0,$010101,1);
draw_surface_ext(surf, 1, 1, 1,1,0,$010101,1); // Band Pass Mask - High Pass * Low Pass // High Pass Mask - keep everything > hi hi =$030303;
surface_set_target(surf);
draw_clear_alpha(c_white,1);
draw_set_blend_mode_ext(bm_zero,bm_inv_src_color);
draw_surface_ext(sum,0,0,1,1,0,c_white,0);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_rectangle_color(0,0,w,h,hi,hi,hi,hi,false);
draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
draw_set_blend_mode_ext(bm_one,bm_one);

//  ... followed by low pass to create band pass filter ...
//  Low Pass Mask - keep everything < lo
lo = $050505; lo =$ffffff - lo;
surface_set_target(temp);
draw_clear_alpha(c_white,0);
draw_set_blend_mode_ext(bm_zero,bm_src_color);
draw_surface_ext(sum,0,0,1,1,0,c_white,0);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_rectangle_color(0,0,w,h,lo,lo,lo,lo,false);
draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
draw_set_blend_mode_ext(bm_one,bm_one);
repeat (8) draw_surface(temp,0,0);

//  ... High * Low = Band Pass
surface_set_target(surf);
draw_set_blend_mode_ext(bm_dest_color,bm_zero);
draw_surface(temp,0,0);

//  High Pass Mask - keep everything > hi
hi = $050505; surface_set_target(temp); draw_clear_alpha(c_white,1); draw_set_blend_mode_ext(bm_zero,bm_inv_src_color); draw_surface_ext(sum,0,0,1,1,0,c_white,1); draw_set_blend_mode_ext(bm_one,bm_one); draw_set_alpha(0); draw_rectangle_color(0,0,w,h,hi,hi,hi,hi,false); draw_set_alpha(1); draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero); draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false); draw_set_blend_mode_ext(bm_one,bm_one); // Add to existing surface_set_target(surf); draw_surface(temp,0,0); repeat (8) draw_surface(surf,0,0); // Normally this would be done after each pass, // but we can skip one by doing this down here. surface_reset_target(); draw_set_blend_mode(bm_normal); } The other is Fredkin, named for its inventor (an interesting chap) Edward Fredkin. It has the distinction of being the simplest self-replicating Moore neighborhood CA. What this means is, the initial pattern will be replicated multiple times in succeeding generations. Basically the way it works is, a cell lives if the number of living neighbors is odd. This is why the Fredkin CA is sometimes called the parity rule. As you can see below, it is very simple to implement using XOR like blending modes. Again, replace the code in the Step Event to try it out. It's all a bit crazy looking at the speeds the demo runs at. You'll probably want to slow the demo down to one or two frames per second and supply it with some interesting patterns to work from. It can also produce some interesting variations on the initial pattern if you let it run a while. They might spark your imagination or be good sources for game sprites. { // Fredkin : parity of neighborhood and self {1,3,5,7,9 => 1, else 0} // new = C ^ NW ^ N ^ NE ^ E ^ SE ^ S ^ SW ^ W // // There exists a blend mode which mimics XOR when drawing with Black & White. // Parity of Neighbors/Self surface_set_target(sum); draw_clear_alpha(c_black,0); draw_set_blend_mode_ext(bm_inv_dest_color,bm_inv_src_color); draw_surface_ext(surf,-1,-1, 1,1,0,$ffffff,1);
draw_surface_ext(surf, 0,-1, 1,1,0,$ffffff,1); draw_surface_ext(surf, 1,-1, 1,1,0,$ffffff,1);
draw_surface_ext(surf,-1, 0, 1,1,0,$ffffff,1); draw_surface_ext(surf, 0, 0, 1,1,0,$ffffff,1);
draw_surface_ext(surf, 1, 0, 1,1,0,$ffffff,1); draw_surface_ext(surf,-1, 1, 1,1,0,$ffffff,1);
draw_surface_ext(surf, 0, 1, 1,1,0,$ffffff,1); draw_surface_ext(surf, 1, 1, 1,1,0,$ffffff,1);

surface_set_target(surf);
draw_clear_alpha(c_black,1);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_surface(sum,0,0);
draw_set_blend_mode(bm_normal);
surface_reset_target();
}

I may take on Wireworld next. It's a little bit more tricky because it is a CA with four states, rather that the 1-bit CAs thus far explored, but I'm fairly certain it can be done using the same methods.

Abusing forum power since 1986.

Offline

## #52 2011-07-04 14:27:50

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

I was glancing through some old Amiga magazines and stumbled across an interesting series of articles. In it the author describes creating a Life engine using the blitter chip of the Amiga. A "blitter" is a system (usually hardware) that is optimized to handle and manipulate bit-mapped images, for instance scaling, rotation, and (raises flag) Boolean logic operations intended for the masking and blending of software sprites. To move or erase or draw a rectangular section of a bitmap requires several memory moves, at least one per scan line. Calculating all of those memory moves takes time and memory. The blitter's purpose is to do these calculations and memory moves automatically from a single "bit blit" command, freeing the CPU to do more interesting things.

An early example of a hardware blitter is the graphics coprocessor used for Eugene Jarvis's Robotron: 2084. According to Jarvis, some of the (amazing) designers of the Amiga worked at Williams at the time of Robotron's creation and it was on the Amiga that the concept and terms "bit blit" and "blitter" were popularized. Many computers that were created in the late 80s and earlier 90s (especially arcade and home video game systems) relied heavily on blitters to perform a lot of the graphical grunt work. The Commodore Amiga and Atari ST lines of computers and the SNES, Sega CD, and Atari Jaguar all made extensive use of hardware blitters. By the time the Sega Saturn was released, blitters had become so powerful and feature rich that they began to resemble today's GPUs. A GPU is just a very advanced blitter with a powerful vector calculator.

One can begin to see that the blitter-based Life algorithm described in the December 1987 issue of Amazing Computing is truly cut from the same cloth as the surface blending methods discussed in this topic.

So without further delay, here is the series of articles about running Life with the aid of an Amiga blitter chip.
Download PDF from Host-A: Life (with Amiga blitter) by Gerard Hull, Amazing Computing, Dec 87, Jan 88, Feb 88

Among the cited works is this one from January 1979 that appeared in BYTE magazine. It describes running Life based on Boolean logic and served as the primary inspiration for the blitter method.
Download PDF from Host-A: Life Algorithms by Mark D. Niemiec, BYTE Magazine, Jan 79

Here also is a reprint of Martin Gardner's truly foundational writings about Life within the pages of Scientific American. Like so many other Life junkies, it was one of these articles that inspired me to pursue cellular automata in the first place.
Download PDF from Host-A: Game of Life by Martin Gardner, Scientific American

If you desire some more historical morsels, here you'll find an article on Life that appeared in the very first issue of BYTE magazine from January 1975. As one can imagine, it would have been running on the computing equivalent of stone knives and bear skins.
Download PDF from Host-A: Life Line by Carl Helmers, BYTE Magazine, Jan 75, Feb 75

Last edited by xot (2011-07-07 11:06:50)

Abusing forum power since 1986.

Offline

## #53 2011-07-07 00:32:32

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

### Re: CHALLENGE: Conway's Game of Life

LOL: bitter-based Life

Offline

## #54 2011-07-07 11:06:26

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

icuurd12b42 wrote:

LOL: bitter-based Life

Whoops, I must have been thinking of my own life when I typed that.

Abusing forum power since 1986.

Offline

## #55 2011-07-14 16:33:10

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

I've got Wireworld running now. On my machine, it can iterate Mark Owen's Wireworld computer (shown below) at almost 60 fps. This complex circuit is built of several parts and together they calculate prime numbers of up to 16-bits and show them on a 7-segment display. I'm hoping with some code changes I can get it going 20-40% faster.

Below is the code and the support functions. There are couple of reasons it is so much slower than the other demos. First, it is a much larger pattern with over three times as many pixels. There is a variation of this pattern that is about 15% smaller. It should run a bit faster, but it is "in-progress" and already at prime number 19. Second, I'm using scripts to perform most of the grunt work and creating and destroying several surfaces each step to accommodate the generality of the scripts. By reusing surfaces and refactoring the code to be inline, I expect a good speed boost. I'll post the results later.

{
/*

//  Wireworld :
//      Empty -> Empty
//      Tail -> Conductor
//      Conductor -> Conductor, or Head if exactly 1 or 2 Heads in neighborhood,

//  0: empty     === ($000000) === ($000000)
//  1: conductor === ($010101) === ($404040)
//  2: tail      === ($020202) === ($808080)
//  4: head      === ($040404) === ($FFFFFF)

//  Non-traditional state values allow integer division to perform
//  almost all state transitions with a single operation. Rounding
//  of (1 div 2) == 1 is especially useful. These values also look
//  much nicer as a display when scaled to full brightness.

//  empty -> empty (0 -> 0)
//  conductor -> conductor (1 -> 1)
//  tail -> conductor (2 -> 1)
//  head -> tail (4 -> 2)
//  conductor -> head {1 -> 4} if it has exactly 1 or 2 head neighbors

surf *= (4/255)                     //  transforms color from display {0,64,128,255} to calc {0,1,2,4} ranges
sum = sum8(temp,(1/255));           //  sum = number of head neighbors for each cell
temp = bandpass_mask(sum,0,3);      //  temp = cells with exactly 1 or 2 neighboring heads
temp2 = bandpass_mask(surf,0,2);    //  {0,255,0,0}  temp2 = conductor only
temp *= temp2;                      //  temp = conductors with exactly 1 or 2 head neighbors
temp *= (3/255);                    //  temp scaled to calc range
surf *= (128/255)                   //  divides by ~two {0,1,2,4} -> {0,1,1,2} for primary state transitions
surf += temp;                       //  surf = surf with new heads added   [ conductor -> head {1 -> 4} ]
repeat (6) surf += surf;            //  {0,1,2,4} -> {0,64,128,255} [ calc range -> display range ]

*/

surface_set_target(surf);
draw_set_blend_mode_ext(bm_zero,bm_src_color);
draw_rectangle_color(0,0,w,h,$040404,$040404,$040404,$040404,false);

if (surface_exists(temp)) surface_free(temp);
temp = surface_highpass_mask(surf,$030303); if (surface_exists(sum)) surface_free(sum); sum = surface_sum8(temp,$010101);

if (surface_exists(temp)) surface_free(temp);
temp = surface_bandpass_mask(sum,$000000,$030303);

if (surface_exists(temp2)) surface_free(temp2);
temp2 = surface_bandpass_mask(surf,$000000,$020202);

surface_set_target(temp);
draw_set_blend_mode_ext(bm_zero,bm_src_color);
draw_surface(temp2,0,0);
draw_rectangle_color(0,0,w,h,$030303,$030303,$030303,$030303,false);

surface_set_target(surf);
draw_rectangle_color(0,0,w,h,$808080,$808080,$808080,$808080,false);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_surface(temp,0,0);
repeat (6) draw_surface(surf,0,0);

draw_set_blend_mode(bm_normal);
surface_reset_target();
}
//  surface_bandpass_mask(source,high,low)
//      source      surface to be masked with filter
//      high        colors brighter than high and
//      low         darker than low will pass
//  returns a surface that is white where colors pass, black elsewhere
{
var a,b;
surface_set_target(a);
draw_set_blend_mode_ext(bm_zero,bm_src_color);
draw_surface(b,0,0);
draw_set_blend_mode(bm_normal);
surface_reset_target();
surface_free(b);
return a;
}
//  surface_highpass_mask(surface,high)
//      source      surface to be masked with filter
//      high        colors brighter than high will pass
//  returns a surface that is white where colors pass, black elsewhere
{
var src,hi,w,h,tmp;
src = argument0;
hi = argument1;
w = surface_get_width(src);
h = surface_get_height(src);
tmp = surface_create(w,h);
surface_copy(tmp,0,0,src);
surface_set_target(tmp);
draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_rectangle_color(0,0,w,h,hi,hi,hi,hi,false);
draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
draw_set_blend_mode_ext(bm_one,bm_one);
repeat (8) draw_surface(tmp,0,0);
draw_set_blend_mode(bm_normal);
surface_reset_target();
return tmp;
}
//  surface_lowpass_mask(surface,low)
//      source      surface to be masked with filter
//      low         colors darker than low with pass
//  returns a surface that is white where colors pass, black elsewhere
{
var src,lo,w,h,tmp;
src = argument0;
lo = c_white ^ argument1;
w = surface_get_width(src);
h = surface_get_height(src);
tmp = surface_create(w,h);
surface_copy(tmp,0,0,src);
surface_set_target(tmp);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_rectangle_color(0,0,w,h,lo,lo,lo,lo,false);
draw_set_blend_mode_ext(bm_inv_dest_color,bm_zero);
draw_rectangle_color(0,0,w,h,c_white,c_white,c_white,c_white,false);
draw_set_blend_mode_ext(bm_one,bm_one);
repeat (8) draw_surface(tmp,0,0);
draw_set_blend_mode(bm_normal);
surface_reset_target();
return tmp;
//  surface_sum8(source,color)
//      source      surface to be summed
//      color       color scalar, ie. \$010101
//  returns a surface where each pixel is the scaled sum of the eight
//      neighbors of the corresponding pixel in the source image
{
var tmp;
tmp = surface_create(surface_get_width(argument0),surface_get_height(argument0));
surface_set_target(tmp);
draw_clear_alpha(c_black,1);
draw_set_blend_mode_ext(bm_one,bm_one);
draw_surface_ext(argument0,-1,-1, 1,1,0,argument1,1);
draw_surface_ext(argument0, 0,-1, 1,1,0,argument1,1);
draw_surface_ext(argument0, 1,-1, 1,1,0,argument1,1);
draw_surface_ext(argument0,-1, 0, 1,1,0,argument1,1);
draw_surface_ext(argument0, 1, 0, 1,1,0,argument1,1);
draw_surface_ext(argument0,-1, 1, 1,1,0,argument1,1);
draw_surface_ext(argument0, 0, 1, 1,1,0,argument1,1);
draw_surface_ext(argument0, 1, 1, 1,1,0,argument1,1);
surface_reset_target();
return tmp;
}

Last edited by xot (2011-07-14 23:11:02)

Abusing forum power since 1986.

Offline

## #56 2011-07-18 19:27:41

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

Here is a demonstration of this implementation of Wireworld. The zip includes a GM8 project file and executable.

After mucking about with the code and making it way less readable, I think I'm going abandon any further attempts to increase execution speed.

Abusing forum power since 1986.

Offline

## #57 2011-07-19 13:54:51

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

I was checking out OldSkool.org today and ran across an interesting comment from a reader. The topic is 'bare metal' programming, which means coding directly to the hardware without an OS or API getting in the way, something almost unheard of today in popular computing. The reader-submitted stories revolve around the various abuses they have put older hardware through to get them to do unexpected things.

One of the comments was about the Atari ST and Conway's Game of Life. I quote it in part here:

Fred Butzen wrote:

Anyway, as a programming exercise I wrote a version of the game of life for this machine. It ran fine; however, I made one mistake: I forgot to set the clipping rectangle around the screen. So, the first time I built a glider gun, the glider went creeping off the screen, and just kept on going, crashing through memory. Mind you, there's no MMU, so the machine is still running while the glider is rampaging through memory. Because the 68000 used memory-mapped ports for its hardware, you could see where the glider was going because the disk drives starting running, the lights flashed on the keyboard, the tube blinked, and so on. Finally, the glider hit something really vital and the machine died with "streaky bombs" -- a sign that the operating system was really, really sick.

If you've never worked with memory-mapped hardware, the story might fall a little flat, but it made me smile imagining the Tron-like escape of this wayward glider into the inner reaches of the computer.

Abusing forum power since 1986.

Offline

## #58 2011-07-26 22:07:24

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

### Re: CHALLENGE: Conway's Game of Life

OMG... That is completely mental!!!

I'm impressed. man oh man. It's like those people in minecraft making those emulators.

Offline

## #59 2011-07-27 14:33:08

xot
Registered: 2007-08-18
Posts: 1,201

### Re: CHALLENGE: Conway's Game of Life

Yeah, it's very impressive work. I spent a while looking for interesting circuits that were smaller, but that is really the only interesting one I've found -- and it's a doozy. I thought I might be able to use Photoshop to adapt it to the shape of the smaller version, but it soon became clear that correctly adjusting the circuit timings would be a Herculean task. The notion that someone had the patience and technical ability to create this circuit in the first place is truly humbling.

On another topic, I noticed something weird as I worked on this implementation. Earlier I said it ran at almost 60 FPS for me. What I didn't notice right away is that it is capable of running faster than that under the right conditions. If I set the room speed to 60 FPS, it runs at a rock-steady 60 FPS. If I set the room speed higher, it drops to about 50 FPS which was my initial observation. If that wasn't strange enough, if I cause Windows (or an application) to display a pop-up graphic (such as opening the Start menu, or a context menu, or displaying ToolTip text when I mouse over something, or almost anything else), it runs at about 70 FPS. When the pop-up image is closed or removed, the frame rate drops back down to 50 FPS. I don't understand what's going on here and I'm wondering if anyone else experiences the same thing. Oh, and one more weird thing. My Conway's Life demo shows the opposite behavior. It peaks at around 248 FPS and when a pop-up is displayed, it drops to under 210 FPS. And sometimes I can't coax it to go faster then 205 FPS without shuffling my windows or their contents around. And other times, none of these things affect the frame rate. I'm running Windows XP.

Abusing forum power since 1986.

Offline

## #60 2011-07-27 21:28:10

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

### Re: CHALLENGE: Conway's Game of Life

It's probably due to the clipping region a menu or another window creates. Not happening here.

As for the machine... are there any templates for simple gates? There must be. Assembling a circuit would be as simple as copy and pasting the images on the main picture

Offline