GameMaker Sprite-Based Level Generation (video [15:00] + text versions)

[Zack]

GM Version: GameMaker Studio 2
Target Platform: All
Download: zackbanack.com
Links: Video Link

Summary:
You may know how to design levels in the YoYo Games’ GameMaker Studio Room Editor. But, what about in its Sprite Editor? This Step Event tutorial will show you an artsy, unconventional approach to designing levels in your GameMaker games using little more than the Sprite Editor.

Tutorial:

 

[the_dude_abides]

This is an interesting idea, and you present it in an easy to understand manner. I wondered about two things though.

In GMS 1.4 there is the function to get colour data from a surface itself, though they don't advise using the function because it is very slow. I imagine using a scaled sprite cuts down much of the effort anyway, but using the buffer also makes a speed difference?

And lastly: this is a bit more of a noob question - does using var in the for loops make any difference to performance? I imagined it constantly having to define the variable in the second loop, which is repeated often, as being unnecessary, but haven't a clue about the workings of loops.

 

[Zack]

Thanks for the kind words! In regards to your questions:

1. Converting a surface into a buffer, and then reading the buffer, is significantly (~100x) faster than using the function you referenced, surface_get_pixel. Mordwaith, the person I credit in the video as the author behind some of the buffer code, ran a test. A 64x64 image parsed using surface_get_pixel yielded around 5fps, whereas looping through the values using buffer_peek yielded over 500fps. And, as anecdotal evidence, I can visibly see better performance when comparing the two methods.

2. Declaring variables in a confined scope, like a for loop, is an acceptable practice when there's a unique assignment to the variable. If I had something redundant like "var foo = 4" inside the loop, it's probably better left declared outside the loop. But, because our variables offset, red, green, blue, color, etc. are different values each iteration of the loop, what I did is okay. Further, we don't reference those variables outside the scope of the loop, so they don't need to be defined outside the scope of the loop.

 

[the_dude_abides]

Thanks for the reply.

I did see an improvement when done this way, but it isn't something I could use. At various points I've tried turning a surface into a precise sprite, so it can be put into an mp grid. Adding it as an instance is quite costly, so I wanted to see if this was better. The thing is, my surface is 500 x 500, and whilst this buffer method cut off about two thirds of the time it takes surface_get_pixel, it's still too costly to read and then manually set the grid cells.

I was unaware of this function though, so it's good to learn something new.