optimization - Multithreading/Optimisation for Random Generation in Gamemaker

I have a FurGeneration() script in my game; when run, it randomly generates individual oFur objects in specified areas in the game's single Room. Each has a random depth and one of three sprites, and the script produces the impression of dense, layered fur. I've attached a screenshot.

At the moment, the script is working well, as I am using it on relatively small areas. However, my next challenge is to apply this across the single, 20,000 x 20,000 room of my game to produce a consistent field of fur.

My first attempt at this was to create a background sprite, a simple 1000x1000 grey square with its image_alpha set to 0. These would be generated in rows across the entire space of the room, and then each one would have the FurGeneration() script run on it to generate individual squares of fur flush with each other. I've applied this to one 'row' of my games' Room, and the game really slows down; it doesn't crash, but evidently there are just t0o many calculations going on at once.

My question is: is there a way to multi-thread in Gamemaker? Or does it already multi-thread, meaning that this plan is a foolish one? It would be interesting to hear your thoughts.

Answer

Yes, GM:S already does multi-threading programming on its own. Being a development framework, it would be a pain in the neck if it didn't so.

Instead of creating several objects with different sprite_indexes to create a seamless field of fur, you may want to draw them on a Surface first, and then draw it into your room.

What are Surfaces?
Surfaces are a special type of canvas on which you can draw whatever you want, at any moment, with any object, and in any way, and when you're done you can draw such surface in your room (or GUI as well) and see the results.

There are many possible applications of Surfaces, such as fake lighting effects, particles, several blending modes at once, and so on.

So, instead of generating oFur objects randomly, since they are to be drawn on the screen, you can create a Surface and draw random fur sprites on it at random position (using the same position algorithm to create your oFurs); when you're done, simply draw the Surface.

There ARE performance advantages. Assuming your early oFurs weren't supposed to be moving, you can draw on your Surface once only in a particular Event, and then draw your Surface into the room in the Draw Event. This is better than having n oFur instances, which must draw their sprite_index at their x and y position, each step. You draw the single sprites on the Surface once only, and finally draw the Surface at position (0, 0) so that it is able to fit your room.