Great Game Maker Wall Optimization Script

[Koh]

After reading about how to optimize Game Maker games to make them run faster, I decided to try out one method mentioned before, to combine all of the Wall objects into one sprite using a surface, then deleting them all, and creating one big wall, it worked out TREMENDOUSLY. So I thought it would be useful for me to share my script with everyone. It's not hard to do of course, but it could save time, and I recommend using it with every game that's bound to have a lot of Wall objects. You call this script in the Room Creation Code.

Code:

var; wallsurface=0; w=0;  //Variables for the Surface on which all the wall sprites will be put on, and the New Wall object that will be made.
wallsurface=surface_create(room_width,room_height+1);  //Prepare a surface as big as the room, adding an extra pixel vertically so we can have transparency.

surface_set_target(wallsurface);  //Prepare to draw on the surface.
draw_clear(c_white);  //Clear the entire surface with the desired transparent color.
with objWall{  //With all of the walls in the room...
    if object_index==objWall{  //If it's not inheriting from anything (you may want to handle slopes with their own combined slope object, for example...
        draw_sprite(sprite_index,-1,x,y);  //Draw their sprite on the surface at their location.
        instance_destroy();  //Then delete theirself.
    }
}
if sprite_exists(global.wallopsprite){sprite_delete(global.wallopsprite);}  //If there was a combined wall surface sprite made before, get rid of it.  This is crucial you store this, as these will build up if you don't get rid of them, and can crash the game.
global.wallopsprite=sprite_create_from_surface(wallsurface,0,0,surface_get_width(wallsurface),surface_get_height(wallsurface),true,false,0,0);  //Make a new sprite from the surface made of all the Wall objects.
w=instance_create(0,0,objWall);  //Make a brand new Wall object at the top left of the room;
w.sprite_index=global.wallopsprite;  //Set its sprite to the sprite made from the surface.
w.mask_index=w.sprite_index;  //Set its mask to its sprite.
surface_free(wallsurface);  //Free up the memory from that surface.
surface_reset_target();  //Reset the drawing location.

It's not much, but it's effect on a game with a lot of Wall objects like my game is TREMENDOUS. I have no lag whatsoever now. You are all free to use this .

[Previous]

[spoiler=Excursion on coding style]
I'm sorry but I want to go a little bit off-topic here to have a word on coding standards. If you ever happen to get to work together with other programmers on code that is not your own and which others will have to work with, you'll need them (and trust me, you'll expect your partners to follow them, too, as you all will have to work with the code and it needs some consistency). Of course, code style may vary between companies (the worse ones may not care at all), but there are a few things that are pretty much consistent.
It's never to early to start coding with proper style, the longer you drag it out, the harder it will be to learn.
It's nothing major, but I'd like to address a thing or two. Or maybe three.

Whitespace. Use them, it doesn't cost much, but makes your code look less stuffed.

Code:

wallsurface=0;  // okay
wallsurface = 0;  // better

draw_sprite(sprite_index,-1,x,y);  // okay
draw_sprite(sprite_index, -1, x, y);  // better

I see you already use two whitespaces before comments after the line end, which is great (Google standard, even), but you should also have one after the double slash.

Braces around conditions. Many languages require them and I don't think they'd hurt GM (if they do, that'd be dumb).

Code:

with (objWall) {  // With all of the walls in the room...
    if (object_index == objWall) {  // If it's not inheriting from anything (you may want to handle slopes with their own combined slope object, for example...
        // ...
    }
}

This will make it easier adjusting to C++, C#, Java and the like later.

A last thing that may be worth considering is line length. A common limit is 80 characters per line (don't as me why, something about old consoles / terminals only having that much), it may not be neccessary today, but many code style standards still require it.

If you'd write code for Google, for example, they have a strict coding style guide. We had to abide by their C++ style for our C++ course last semester (we were given a style checking python script which was required to run through our code files without finding any style errors).
[/spoiler]

Aside from that, I'd assume your code - if not just the idea - may come in handy for other GM users. Being an interpreted script language, GML tends to have performance issuesm and any larger game is prone to lag without such optimisation tricks.

[Phaze]

Call it a nitpick but I love the Allman style of indentation, easier for me to keep track of braces

[puggsoy]

Same here. When I began coding I opened braces on the same line as their statements, but when I started using FlashDevelop it's automatic code generation did it Allman style, so I adjusted to that. Now I favour it greatly, since as Phaze says it makes it easier to keep track of code blocks and such.
In fact, a lot of my coding style is from FlashDevelop, so that code that I've written stays consistent with generated code. And since FlashDevelop does it how most people do it that also helps me use other peoples' code, and (eventually) share my own code.

Also I use lots of empty lines