SyntaxBomb - Indie Coders

Languages & Coding => BlitzMax / BlitzMax NG => MiniB3D => Topic started by: angros47 on July 08, 2021, 01:01:56

Title: Version 1.26 is online
Post by: angros47 on July 08, 2021, 01:01:56 (

I added the command FreeShader, and some minor fixes. It is also the version currently used in the online interpreter
Title: Re: Version 1.26 is online
Post by: markcwm on July 08, 2021, 22:36:23
Thanks very much, Angros!

Kippykip found a CreateSprite memory leak (see here ( but he was also getting a memory leak from GetSurfaceBrush which confused things, so I'm not sure it actually ever got fixed. I've looked at your fix but still none the wiser, can you explain please?

Title: Re: Version 1.26 is online
Post by: angros47 on July 09, 2021, 01:05:31
About GetSurfaceBrush, it doesn't return a reference to the entity brush, but it duplicates the brush itself. The same thing happened in Blitz3D, and it was clearly documented: (

Remember, GetSurfaceBrush actually creates a new brush so don't forget to free it afterwards using FreeBrush to prevent memory leaks.

The CreateSprite memory leak is caused by the fact that FreeEntity doesn't delete the surface of a sprite (while it deletes the surface(s) of a regular mesh). It cannot delete the surface, because CopyEntity doesn't duplicate it, it just uses a reference to the surface of another sprite, so if you deleted a surface of a copied sprite you would also deleted it in the original one. As long as sprites are created by CopyEntity (as it happens in a particle system) there was no issue, but if the sprite was loaded or created manually freeing that would have left the surface in memory. In the original MiniB3D that wasn't an issue, since the garbage collector would have taken care of that, but in C++ it is.

The simplest fix would be to add a line to delete the surface in FreeEntity, and to create new surfaces in copied sprites (as already happens for meshes). But that would have increased memory usage in particle systems. So, I used another solution: creating the sprite surface only once, putting it into a static member, and using it for all sprites. The only issue could happen if someone tried to apply a shader to a sprite (it would affect all sprites), but I don't think there is any reason to do such a thing
Title: Re: Version 1.26 is online
Post by: markcwm on July 10, 2021, 01:00:20
Cool, thanks Angros, that answers my question completely. So the memory leak happens with CreateSprite (which LoadSprite uses) because it creates a new surface that doesn't get freed by FreeEntity which would slow down the particle system.

I managed to port Adam Redwoods batch sprites code from Minib3d-Monkey to Openb3d, I put it in sprite_batch.cpp and it was about twice as fast than the same code ported to Minib3d-Blitzmax. The example usage is in samples/mak/firepaint3d.bmx.
Title: Re: Version 1.26 is online
Post by: angros47 on July 10, 2021, 18:26:38
Yes. May I ask why you needed to integrate batch sprites from Adam Redwoods? OpenB3D already supported batch sprites through SpriteRenderMode sprite,2 (the code is in camera.cpp). What is the difference with the method you added?
Title: Re: Version 1.26 is online
Post by: markcwm on July 11, 2021, 00:13:55
Mainly because it was easier to understand, the particle_callback.bmx code I ended up with required me to expose the ugly wrapper methods like TSprite.CreateObject(inst) whereas Adam Redwood's code looks very similar to Blitz3d, I was never happy with having to write it like that and I still don't even know if I could hide those methods.
Title: Re: Version 1.26 is online
Post by: markcwm on July 17, 2021, 13:55:26
Well I updated the Openb3dmax wrapper to the 1.26 update. Thanks again Angelo... sorry if I sounded like I was complaining about your code. It's good code! I tested the sprite memory leak with ResMon in Windows and can confirm it does fix it both for sprites and particles

[edit: oops, I have now found that the fix doesn't apply to particles and there is no memory leak with particles]

I found a problem with Adam Redwood's batch sprites, they have major memory leaks and my first attempt to fix it did not have any luck. This is probably because it was written in a language with a GC. So I'm going to work with the official particle code and see about getting something similar to the firepaint3d sample with it.

[edit: the firepaint3d sample now doesn't have a memory leak as I've switched to use sprites (which are now a single surface) instead of batch sprites]
SimplePortal 2.3.6 © 2008-2014, SimplePortal