GMLscripts.com

Wow! I think I would have got somewhere near there eventually but it's a lot more work than I expected (and I quickly gave up because I'm lazy ). I would have done a few parts differently.

1) Creating the neighbour surface: you're current solution uses 1 clear and 8 draws, my proposed solution uses 2 clears and 6 draws (which is faster in my mind...). It works by summing the surfaces horizontally first than summing the result vertically. Note that the sum will now contain the centre cell also, but that's not an issue if you account for it when picking your upper and lower bounds for living cells.

Expand// xot's code
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, 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);

// Suggested optimisation, maybe...
surface_set_target(sum_horizontal);
draw_clear_alpha(c_black,1);
draw_set_blend_mode_ext(bm_one,bm_one);
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);
surface_set_target(sum);
draw_clear_alpha(c_black,1);
draw_surface(sum_horizontal,0,-1);
draw_surface(sum_horizontal,0, 0);
draw_surface(sum_horizontal,0, 1);

2) Filtering: Using the "removeback" feature of "background_create_from_surface" may be faster than your feedback method, I'm unsure whether the resource allocation will cost more or less than the drawing saved. I'm thinking something like:

• use background_create_from_surface making all white into transparent

• draw the background to a white surface with draw_background_ext(back, 0, 0, 1, 1, 0, c_black, 1)

• now everything which wasn't white is black. I think (?)

3) I'm a little confused, dare I ask...

Expand// Why this...
draw_primitive_begin(pr_trianglefan);
draw_vertex_color(0,0,lo,0);
draw_vertex_color(w,0,lo,0);
draw_vertex_color(w,h,lo,0);
draw_vertex_color(0,h,lo,0);
draw_primitive_end();

// ... instead of this?
draw_set_color(lo);
draw_set_alpha(0);
draw_rectangle(0, 0, w, h, false);

Seems like 3 extra function calls to me, and surely it's not faster (?), or more obvious as to what it's doing (?), or does something different (?).

Funny isn't it! Focusing on reducing the amount of work needed to be done in the parts of code that are run the most can make a huge difference!

I haven't used GM for quite a while, but I just remembered another quirk to abuse. The repeat loop is noticeably faster than a for loop when the length of the loop is known at the start (as the condition is checked in compiled code). +9%fps get!

https://docs.google.com/leaf?id=0Byhdbm … y=CM7h6_EC

EDIT: Terribly sorry about the spam with all my different versions, but I'm excited!

I noticed that as I was caching the number of living neighbours a cell had, I no longer needed two copies of the state of the grid, therefore I no longer needed to clone the grid, therefore I could use an array instead of a grid and therefore I gained another 20%fps boost!

https://docs.google.com/leaf?id=0Byhdbm … y=CNmx5dgB

Just so I have a rough idea of where I'm at, how fast does this simple solution run on your machine?
https://docs.google.com/leaf?id=0Byhdbm … y=CNrEwNsE (EDIT: Look down.)
For anyone interested this is the algorithm, it seems to be the most obvious way to do it. I have a few ideas but I'm unsure as to how much they will improve it, I'll get back to you when (if) I've tried them.

Expand/// Apply Rules of Life
{
    var next, sum, i, j;
    next = ds_grid_create(40, 40);
    ds_grid_copy(next, grid);
    
    surface_set_target(surface);
    draw_primitive_begin(pr_pointlist);
    
    for (j = 0; j < 40; j +=1) {
        for (i = 0; i < 40; i += 1) {
            sum = ds_grid_get_sum(grid, i - 1, j - 1, i + 1, j + 1);
            if (ds_grid_get(grid, i, j)) {
                // Currently alive
                if (sum < 3 or sum > 4) {
                    ds_grid_set(next, i, j, 0);
                    draw_vertex_color(i, j, 0, 1);
                }
            } else {
                // Currently dead
                if (sum == 3) {
                    ds_grid_set(next, i, j, 1);
                    draw_vertex_color(i, j, 16777215, 1);
                }
            }
        }
    }
    
    draw_primitive_end();
    surface_reset_target();
    
    ds_grid_destroy(grid);
    grid = next;
}

EDIT: Don't look if you don't want to know xot's method.

EDIT2: I noticed that I had forgotten to make i and j script local variables, fixing this gives a 4% fps boost on my machine... Why can't that be the default!
https://docs.google.com/leaf?id=0Byhdbm … y=CJaEwtIC

That sounds an awful lot like my first (somewhat cheesy) idea... does you're solution use surface_save by any chance?

Because I thought that would be too easy, I think I'm going to have a shot at implementing Huffman coding in GML. I doubt my implementation will come close to the efficiency of DEFLATE (the compression used in PNG and gzip).

Wow, that's really awesome jalb! Go jumpy blue ball!

EDIT: In the latest version it seems that the results are backward for places 2-5. In the final round it was yellow (jalb) vs blue (Dannyboy) but the results came out as:

Here's mine. It's GM8, should run on lite no problems.

https://docs.google.com/leaf?id=0Byhdbm … y=CK6W_qAE

And here's a version of it with some tacked on overlay stuff I used for debugging, just in case you're interested.

https://docs.google.com/leaf?id=0Byhdbm … y=CMvV--YN

That's sounds really close to one of my ideas... I just couldn't be bothered trying to make it work, I'm glad someone did!

Don't miss out on the deadline xot!

Alright, I've now made a more accurate threat-o-meter to detect which enemy is the greatest threat, also I've made the evasive action to move away from the point of closest approach rather directly away from the enemy. With these improvements I ran the test for 3 minutes, 6 collisions for the first minute, 3 for the second and 4 for the third... I've got a long way to go yet!

Now that I have a decent method of detecting and avoiding threats I think I might try a weighted average rather than just focusing on a single threat, I'll let you know how it goes.

EDIT: Weighted average results so far: 7 collisions in 5 minutes. I'm catching up!

I saw this today and thought some of you might also find it interesting: http://chrishecker.com/Please_Finish_Your_Game

Hmm, that script looks somehow familiar