https://sourceforge.net/projects/minib3d/files/ (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
Thanks very much, Angros!
Kippykip found a CreateSprite memory leak (see here (https://github.com/markcwm/openb3dmax.mod/issues/19)) 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?
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 (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
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.
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?
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.
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]
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
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.
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.
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 (https://github.com/markcwm/openb3d.docs/blob/master/extended/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.
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
@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?
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
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
Quote from: Midimaster on January 02, 2024, 00:23:24Quote 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 2 bugs in your code.
1st
The KEYCODE 1 does not work on BlitzMax. If you mean the <ESC> key you should use KEY_ESCAPE
While Not KeyDown( KEY_ESCAPE )
...
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.
If I change the key code and add any grass.jpg file to the source dir, the code runs fine on Windows.
okay. . it segment faults on line graphics3d mode fullscreen on ubuntu, i may dig deeper to find the line in debug mode. maybe this issue is known? i remember the issue may have been talked about before 6 months ago.
Yes, this is a known issue, not just with Openb3d but Minib3d too, fullscreen in Linux causes crashes, I don't know why it happens but I used to get fullscreen works but on exiting then a complete hang and resolution would not revert to desktop again. I don't know how to fix it, must be a Linux system issue, my workaround is to do fake fullscreen by maximizing the window to desktop resolution, all my examples follow this workaround. I'm not sure if Max2D can handle fullscreen in Linux. There are no issues in fullscreen on Mac or Windows.
Quote from: William on January 01, 2024, 17:27:36@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?
The most important change is how rotations are implemented: MiniB3D used Euler's rotations, OpenB3D use quaternion-based rotations, to prevent gimbal lock (in a similar way to Blitz3D). As result, even if commands have the same syntax, they can produce different results, and porting code from MiniB3D to OpenB3D could lead to unexpected results. That's why I changed the name, and consider OpenB3D a different product, and not a port of MiniB3D.
Then, I added many other features that on MiniB3D were available as extensions (LOD terrains, shadows, shaders), and added some extra features like isosurfaces, metaballs, Constructive Solid Geometry, postprocessing, Verlet baset physics, and more
im thinking i should consider a alternative graphics engine/lib if i want collision of child entities to be reported to register hits and other reasons like working as intended.
@angros47 should i look at using your minib3d/openb3d and could you help me to make a blitzmax wrapper? first of all im not very proficient in blitzmax to program a wrapper that interfaces with C functions. but i had noticed a PBR repository that may be included in one of the openb3d's, i think yours.
some bugs i found, using openb3d from mark is that once (has happened a couple times but may be OS related) the fullscreen mode it was a black screen (ubuntu 22.04.3) i could not alt tab and exit out, also now (after reinstalling from ubuntu 18 to the latest lts is that i cannot move the camera with the mouse and move and jump at the same time and i dont know why.
Unfortunately I don't have much experience with BlitzMax, although there is the wrapper made by markcwm (he stated he hasn't worked on it in a while, but the API of OpenB3D haven't changed much in the latest versions, so I think you could just replace the source code of OpenB3D with the new one and recompile it.
Regarding the issues in full screen mode, it's not related with OpenB3D: in fact, OpenB3D requires an OpenGL context to work, and such a context is not created by OpenB3D, but by a third party library. So, if you get 3d graphics working correctly in windowed mode, it means that OpenB3D is working correctly, and any issue you get in full screen mode is caused by the library used to create the context.
Keep in mind that the library used to create the context is usually also in charge of controlling the inputs (keyboard, mouse, controllers). It should be possible to create a context using SDL, too, for example.
I am not aware of any concurrent input handling issues - neither with blitzmax NG's "brl.system" nor "sdl.sdlsystem".
currently trying to investigate it within discord.
bye
Ron
@everyone and @angros i had googled the issue and it is a ubuntu setting in ubuntu 22.04 that i had not known about which locks the mouse of the touchpad when keys are held down.
thanks for your support.
https://askubuntu.com/questions/1263698/cant-use-both-mouse-and-keyboard-at-the-same-time