Version 1.26 is online

Started by angros47, July 08, 2021, 01:01:56

Previous topic - Next topic

angros47

https://sourceforge.net/projects/minib3d/files/

I added the command FreeShader, and some minor fixes. It is also the version currently used in the online interpreter

markcwm

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?


angros47

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: https://kippykip.com/b3ddocs/commands/3d_commands/GetSurfaceBrush.htm

QuoteRemember, 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

markcwm

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.

angros47

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?

markcwm

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.

markcwm

#6
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]

Petimat

Mark,something went wrong...

C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.cpp: In function 'float* TerrainFloat_(Terrain*, int)':
C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.cpp:1776:42: error: 'float* Terrain::NormalsMap' is private within this context
   case TERRAIN_NormalsMap : return &obj->NormalsMap[0];
In file included from C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/openb3d/src/pick.h:21,
                 from C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.h:5,
                 from C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.cpp:3:
C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/openb3d/src/terrain.h:25:9: note: declared private here
  float* NormalsMap;
[ 71%] Compiling:openb3dstd.bmx.debug.win32.x64.c
Build Error: failed to compile (1) C:/BlitzMaxNG/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.cpp

markcwm

Hi Petimat!

Thanks. Yes, I've been working on Terrains without commiting the changes so I left a conflict in data.cpp without realizing. Fixed now. I'm just working on having access to vertex, normals and texcoords.

Petimat

Thanks Mark!
It works flawlessly.
I'm glad you guys are still working on it.Angros's library is still one of the most useable engine out there.
Great job Angros.

markcwm

#10
Hi Petimat,

I'm glad you're still using it.

I've added new functions to the particle engine, this makes it much easier to control particles without too much code, see particle.bmx.

The new functions are EmitterParticleAlpha, EmitterParticleScale, EmitterParticleColor, EmitterParticleRotate there's also extra parameters added to existing functions like EmitterParticleLife(startlife,endlife,randlife), startlife is when the particle is first visible, randlife is how much random is added to endlife. The new functions all work the same (start,end,mid,midlife) the mid allows for non-linear effects, so for example alpha start/end almost zero, mid 0.5 creates a fade in/fade out effect, then midlife is the position of mid, for example halfway. Scale has x/y and Color has r/g/b for start/end/mid parameters, if mid is zero then it's just linear with start/end parameters. The demo also uses TFormVector to create a wind direction with EmitterVector, this also has start and end vectors so you can have more realistic wind.

angros47

Version 1.262:

-CreateCone added one triangle in the base that was unnecessary and disturbed the collision checking
-Updated the image loader
-EntityType didn't work correctly when used a second time on the same entity

William

@angros47 can you tell me will that version's changes be added to openb3d, what the difference is should i use openb3d to minib3d for best performance/updates/features and fixes?
im still interested in oldschool app/gamedev

William

https://github.com/markcwm/openb3d.mod/issues/29 i've created an issue, using openb3d Graphics3D depth 32 mode 1 fullscreen it segmentation faults.

@markcwm
im still interested in oldschool app/gamedev

Midimaster

#14
Quote from: William on January 01, 2024, 17:46:19https://github.com/markcwm/openb3d.mod/issues/29
I had a look at the source code you offer here... There are some bugs in your code.

1st
The KEYCODES 1, 205...208 do not work on BlitzMax. If you mean the <ESC> key you should use KEY_ESCAPE

While Not KeyDown( KEY_ESCAPE )
    If KeyDown( KEY_LEFT )=True Then TurnEntity camera,0,-1,0
    If KeyDown( KEY_RIGHT)=True Then TurnEntity camera,0,1,0
    If KeyDown( KEY_DOWN )=True Then MoveEntity camera,0,0,-0.05
    If KeyDown( KEY_UP )=True Then MoveEntity camera,0,0,0.05 
...

2nd
Your code needs the file grass.jpg to run. But you did not add it. And it is not part of the OpenB3D module.

3rd
the camera position should be 64 , 1 , -64 to see something at the beginning

If I change the key code and add any grass.jpg file to the source dir, the code runs fine on Windows:

Import openb3d.b3dglgraphics
Graphics3D 640,480,32,1

Local camera:TCamera=CreateCamera()
PositionEntity camera, 64,1, -64

Local light:TLight=CreateLight()
RotateEntity light,90,0,0

'; Create terrain
Local terrain:TTerrain=CreateTerrain(128)

'; Texture terrain
Local grass_tex:TTexture=LoadTexture( "grass.jpg" )
EntityTexture terrain,grass_tex
While Not KeyDown( KEY_ESCAPE )
    If KeyDown( KEY_LEFT )=True Then TurnEntity camera,0,-1,0
    If KeyDown( KEY_RIGHT)=True Then TurnEntity camera,0,1,0
    If KeyDown( KEY_DOWN )=True Then MoveEntity camera,0,0,-0.05
    If KeyDown( KEY_UP )=True Then MoveEntity camera,0,0,0.05
    RenderWorld
    Text 0,0,"Use cursor keys to move about the terrain"
    Flip
Wend
End
...on the way to Egypt