Skip to main content

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

That's good to hear.

So, this does mean that the default draw_sprite_pos does not include vertex color information.

There are things you can do to optimize a bit and I'll write a better function at some point as well. 

One thing that is important to check first though, is that you do not seem to be destroying the vertex buffer which will lead to a memory leak for sure.  You can destroy it and create a new one, or if the object is not moving or anything you can create the vertex buffer on create only once and then submit it in the user event like you have.  Then add some code to destroy the vertex buffer on the clean-up event.

Another thing is the macro LE_NORMAL_ANGLE performs some calculations, so instead of calling it for each vertex you should declare a local variable like "var _angle = LE_NORMAL_ANGLE;" and then use that local for the argument.

I can make the whole thing into a new object or function in the future with other optimizations.

Are you also having this cast shadow too?  Given the shape I would assume you need to use something like the shadow path object to get the correct polygon shape.  This might be a new object I should add that also is a shadow caster.  The shadow path object type is for more complex polygon shapes, and I never considered just a skewed/stretched rectangle which is more simple.

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.