Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

I was destroying the buffer in the clean-up, but then I switched to creating the buffer as a temporary var which I assumed wouldn't work in a separate event. I switched to a local variable for the buffer, so I don't have to keep creating and destroying it every draw event (which I assume is not efficient). I also used the var _angle suggestion for normal events. Still seeing a frame drop even with these modifications, but it seems better. There is a frame dip from 60 to 50 if I make the scale of the object bigger or place 6 of them on screen at once.

Yes! I plan on utilizing shadows if possible. A shadow path object that has the functionality of draw_sprite_pos would be incredibly helpful.

Creating a buffer with "var" does not matter, it is still a memory leak if you do not destroy it.  Having it created every single frame in the draw event is going to be much slower.  If it does not move then create it once and freeze the buffer.  If it moves you can create it, use and then destroy it.  Or use primitive drawing if it provides the right format for the vertex...I'd have to check.  

When you create any type of dynamic memory such as buffers, ds_lists, other ds structures, or surfaces, they are in memory until you destroy them manually.  Declaring a local variable with "var" only holds a reference to the memory, it still exists and still needs to be managed or you'll have a memory leak.  Even vertex formats can be destroyed, but those usually are very tiny and you make a couple that never need deleted until the game closes.

Note, that if something uses memory that will always persist until the game closes then you really do not have to destroy it.  When the game closes the entire heap will be freed by the OS.

Thanks for the clarification! I moved the vertex_position() code into the step event from the draw event, and it all runs smoothly at 60 fps now.