• Hey! Guest! The 40th (!!!) GMC Jam will take place between February 25th, 12:00 UTC to March 1st 12:00 UTC. Why not join in this very special anniversary jam! Click here to find out more!

SOLVED Sprite Parts as Particles?

Dreary

Member
I have created a disintegration effect that breaks the sprite down into a bunch of objects containing part of the sprite. It works as intended, but is incredibly inefficient. What I want to do is to find a way to make it so that I can disintegrate multiple enemies at a time without taking the frame rate with them. Is there any way to create a particle that contains only part of the sprite (similar to draw_sprite_part)?
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
Not really... you COULD create a new sprite from each part, but that alone would be a huge overhead and not worth it. The only real optimisation you could do would be to have a single instance that draws all the parts rather than multiple instances drawing each part. This would be harder to set up initially, but once down it should be more efficient. You could possibly even have a single "master" controller and then use a combination of structs and functions to track all the different "objects" and "sprites" required for the effect...
 
Quite a while ago I experimented trying to create a generic disintegration effect, also using sprite parts and individual instances. I cant remember if I tried the approach Nocturne is suggesting, but I would definitely start there. My only other suggestion, which I'm not entirely sure is plausible, is to look into using shaders, which I dont have knowledge of myself.
 

Yal

🍋 *lemon noises*
GMC Elder
I'm thinking an approach like this would work:
  • Make a list containing (x, y, u, v, xspeed, yspeed) tuples and fill it with parts of the sprite (just use a dual for loop to loop over the entire thing, like you're probably already doing)
  • For each entry in the list, add xspeed to x, yspeed to y, and potentially a shared gravity to yspeed each step.
  • Make a vertex buffer and for each list entry, add two triangles (i.e. 6 vertices in total) where one vertex is the list data as-is, and the other are one "chunk" to the right / down, with the size being another shared parameter for the entire list. The U/V coordinates also should be stepped accordingly.
  • Draw the vertex buffer using the "triangle list" mode.
You shouldn't even need shaders for this, but you need to define a vertex format for the buffer.

To optimize it further with a shader, you could put all the data in a vertex buffer at once when first creating the effect, and modify the vertex format so you pass in the intial speeds as a new vertex component; then freeze the buffer for more speed. Then, also pass in a "time" uniform into the shader and you can move the vertices' positions (in the vertex shader) by time * initial speed (+ gravity component), which means you don't need to loop over the list in GML. (Just use a passthrough fragment shader if you pick this approach)
 

Dreary

Member
Not really... you COULD create a new sprite from each part, but that alone would be a huge overhead and not worth it. The only real optimisation you could do would be to have a single instance that draws all the parts rather than multiple instances drawing each part. This would be harder to set up initially, but once down it should be more efficient. You could possibly even have a single "master" controller and then use a combination of structs and functions to track all the different "objects" and "sprites" required for the effect...
Thanks! I tried this out and it does seem to be a bit less taxing, still getting frame rate drops, but not quite as severe. I guess in the end I'll just have to tone down the effect and split the sprite into fewer parts. Or do some research on vertex buffers as Yal suggested. Appreciate the replies everyone ^^!
 
Top