Well development continues here at Syntaxbomb then thanks to Qube! Since Syntaxbomb topics have a page per 15 posts, I think it's better to post new issues with the wrapper in new topics now. Thanks.
For download links see Openb3d Roadmap (http://www.syntaxbomb.com/index.php/topic,102.0.html).
I'm hunting a nasty bug in OpenB3D, nasty because it only happens sometimes and within a Type. For my BSP Loader it is absolutely necessary to load AND unload entities and textures within a Type (and using a TMap, too for comparison reasons but that is not used in my example yet).
The following code crashes in OpenB3D after a few iterations while in miniB3D it works fine until the end. Can you please take a look at it? I've tested it with both versions of OpenB3D (Main Branch and DruggedBunny). I think it crashes either at FreeEntity or FreeTexture in the DeleteCandle Method, but its hard to track it.
SuperStrict
Framework openb3d.B3dglgraphics
'Framework sidesign.minib3d
Import brl.tgaloader
Import brl.Map
Graphics3D(1024, 600, 32, 2)
Global cam:TCamera = CreateCamera()
Global BSP:TBSP = New TBSP
Print "Start: " + GCMemAlloced()
Local ms:Int = MilliSecs()
For Local i:Int = 1 To 100
Print "Run #" + i
BSP.AddAll
BSP.DeleteAll
Next
Print MilliSecs() - ms
End
Type TBSP
Field pivot:TPivot
Field candle:TCandle
Field candlemap:TMap
Global candlelist:TList
Method New()
candlemap = CreateMap()
candlelist = CreateList()
End Method
Method AddAll()
Local num:Int = Rand(100, 1000)
For Local i:Int = 1 To num
BSP.AddCandle(i)
Next
GCCollect()
Print "Created " + num + " Candles"': " + GCMemAlloced() + " Bytes used"
End Method
Method DeleteAll()
Local num:Int
For Local c:TCandle = EachIn candlelist
DeleteCandle(c)
num:+1
Next
GCCollect()
Print "Deleted " + num + " Candles: " + GCMemAlloced() + " Bytes used"
End Method
Method AddCandle(id:Int)
Local c:TCandle = New TCandle
c.id = id
c.ent = CreateSprite()
c.tex = LoadTexture("candle.tga")
c.x = Rnd(-100, 100)
c.y = Rnd(-10, 10)
c.z = Rnd(-100, 100)
PositionEntity c.ent, c.x, c.y, c.z
MapInsert(candlemap, String(c.id), c)
End Method
Method DeleteCandle(c:TCandle)
MapRemove(candlemap, String(c.id))
ListRemove(candlelist, c)
c.ent.FreeEntity
'Print "ENT OK: " + c.id
c.tex.FreeTexture
'Print "TEX OK: " + c.id
c = Null
End Method
End Type
Type TCandle
Method New()
ListAddLast(TBSP.candlelist, Self)
End Method
Field id:Int
Field ent:TSprite
Field tex:TTexture
Field parent:TEntity
Field child:TEntity
Field x:Float
Field y:Float
Field z:Float
End Type
Edit: just to mention that the following code works flawlass in OpenB3D (and is much faster than in miniB3D). Hmmm it looks like if the texture object isn't available anymore sometimes when the execution reaches the freetexture section (you can check this if you add a print command AFTER each "free" command in the example above, in my runs I always see as last entry the print output after the Freeentity command, but never the print output after the FreeTexture command (I've edited the code above now and commented the lines), so I assume there lies the problem.
Print "Start: " + GCMemAlloced()
For Local i:Int = 1 To 10000
Local tex:TTexture = LoadTexture("candle.tga")
tex.FreeTexture
GCCollect()
Next
Print "Finish: " + GCMemAlloced()
Krischan, I've tested your code in win7 using Druggedbunny and my branch and Minib3d 0.54 and can't reproduce the crash. Openb3d was 2 to 3 times slower than Minib3d but always finished at 100.
Maybe the tga file your using is not properly supported by Openb3d, so try the file I was using examples/media/compressed.tga. I think FreeEntity and FreeTexture should be okay, I remember fixing all the free commands. It could also be a lib conflict due to your MinGW, sometimes that makes inexplicable things happen, I'm using TDM64-GCC 5.1.0-2.
I can't think of anything else.
Hmm the TGA is ok, I've tried it now with a complete new setup (NG: BlitzMax_win32_0.87.3.16.7z | DruggedBunny: openb3d.mod-master.zip) and only copied my BLIde to the folder, rebuilt all modules, restarted BLIde. It still compiles fine but the error stays, with both TGA's (attached my Candle TGA here). I must try your setup later, must go to work now.
Mark, I can't get your setup running and I'm confused how to do the setup correctly. I'm using Windows 10 (x64) fully patched with an nVidia GTX 780M (Driver 381.89) and did this:
1. already had an environment variable MinGW pointing to c:\Apps\Blitzmax\MinGW
2. installed BlitzMax150_win32x86.exe from here (https://nitrologic.itch.io/blitzmax) to c:\Apps\Blitzmax
3. installed tdm64-gcc-5.1.0-2.exe from here (http://tdm-gcc.tdragon.net/download) with standard Settings to c:\Apps\Blitzmax\MinGW
3. copied my (already installed) BLIde folder to c:\Apps\Blitzmax\BLIde
4. copied the "sidesign.mod" folder from this ZIP archive (https://github.com/si-design/minib3d) to c:\Apps\Blitzmax\mod
5. copied the "openb3d.mod" folder from this ZIP archive (https://github.com/DruggedBunny/openb3d.mod) to c:\Apps\Blitzmax\mod
6. run BLIde (MinGW path is already configured to c:\Apps\Blitzmax\MinGW there), checked this before
7. rebuilt all modules using BLIde's Advanced Module Builder (not threaded and miniB3d/OpenB3D modules are listed)
8. all modules were built without any errors ("84 modules built and 0 modules not built"), checked the mod subfolders and they are all populated with a lot of .a and .i files now
9. closed and reopened BLIde and executed my posted source above
MiniB3D compiles fine only in Debug mode while OpenB3D refuses compiling (see error message below). So I repeated the steps 5 to 9 with your version from here (https://github.com/markcwm/openb3d.mod), renamed the openb3d.mod-master to openb3d.mod and recompiled only this mod branch, this time with 2 errors ("5 modules built and 2 modules not built"), the b3dglsdlgraphics and openb3dsdl were the two modules. Same result, OpenB3D still not working.
Did I miss something? I can't remember how I did the setup a year ago but its still working when I copy my backup folder to the same location (the Readme says "GCC 4.6 & 4.7 Series", don't know which exact version I have there, the gcc.exe date is August 15, 2012 06:37).
Krischan, I was using OS Bmx (1.52) not NG so that could be the problem. I'll have a look later tonight.
I use OS BMax too and have no issue openb3d. Not sure if the older Bmax used the -m32 flag when compiling C. Which may mean your trying to mix x86 and x64. I also use the mingw that comes with the BmaxNG binary package.
Quote from: GW on June 13, 2017, 21:16:25I also use the mingw that comes with the BmaxNG binary package.
Hmm which package from where? I recently tried the 0.87 (BlitzMax_win32_0.87.3.16.7z) and I only noticed that the module built process was extremely slow and it won't compile miniB3D or OpenB3D. Guys, I'm really stuck and could need some help as this is a showstopper for my current project :-(
Or could you upload a working current BlitzMax+MinGW+OpenB3D+miniB3D development environment archive somewhere?
You can get Blitzmax OS here: https://github.com/blitz-research/blitzmax
If you downloaded BmaxNG 087 did you notice a directory inside called 'Mingw32'?
Quote from: GW on June 13, 2017, 22:58:01
You can get Blitzmax OS here: https://github.com/blitz-research/blitzmax
If you downloaded BmaxNG 087 did you notice a directory inside called 'Mingw32'?
Yes, and I did rename MinGW32 to MinGW to match my environment variable.
Ok, now I downloaded Blitzmax OS, installed the tdm64-gcc-5.1.0-2.exe and compiled the setup using the install.bat - worked. After that I copied sidesign and openb3d to the mod folder and compiled both - worked. Now, when I run my test script above BOTH mods crash, before that only OpenB3D crashed. I don't understand it anymore what's going wrong here.
Going to bed now, I'm depressed :-(
Yes it's not the TGA file, sorry that was a long shot. Thanks for uploading the file for me Krischan. :)
Okay, you're using the wrong version of MinGW with Bmx 1.50, it needs an older version. TDM gcc 4.8.1 is maximum. If you use OS Bmx you can (and should) use TDM gcc 5.1.0. This is possible because you can rebuild bcc exe with OS Bmx whereas Bmx 1.50 bcc was closed source (built with gcc 4.6.1 iirc).
Just a word about MinGW I realized this just yesterday. The official MinGW is on sourceforge, then there's the w64 fork which is 64 bit, then there's TDM which takes these two to provide it's 32/64 bit version and Nuwen which is 32 bit. Each have different build numbers and should work with Bmx if the build is compatible.
The problem with my branch of openb3d is the sdl/gles stuff is broken and I don't know how to fix it, for now you can remove/rename the two mod folders named sdl and it will build and run fine. [Removed in latest commit]
If you're using a TDM 64 bit MinGW you should be able to build 64 or 32 bit without issues. I think GW means the older Nuwen MinGW version which was 32 bit only.
I did have openb3d building with Bmx NG but I used v0.77 which I got from Dabz NG site (http://www.bmx-ng.com/main/downloads/) that's your best bet. There is a v0.70 on Brucey's NG git (https://github.com/bmx-ng/bmx-ng/releases) which might work and there's a v0.81 source there I'd like to try, dated july 2016. As a rule of thumb, if Minib3d doesn't work then it's a Bmx NG bug.
You don't have to rename the MinGW folder to match the MINGW env var name, the env var contains the path, I think the env var does need to be called "mingw".
The crash of both mods is strange, it must be something wrong with your setup. I don't have win10 to test unfortunately but make sure you set the right MinGW env var AND path, I have forget that a few times. Also always run an example to make sure it's working before tests. Also you must build OS Bmx with the same gcc you later build modules with.
Anyway I hope you can sort it out Krischan.
Btw, I use BmaxOS and NG I have only one copy of mingw installed and it's the one that comes with NG (5.1.0)
Openb3d works fine for me with both blitzmax' 32 and 64 bit. My openb3d mod is labeled as 1.0. not sure if that is the latest one.
My point is that people no longer have to to deal with different copies of mingw scattered all over their system like the past.
Drop bmax 1.50 official.. Use bmaxOS and bmaxNG and everything should be good for both 32 and 64 bit.
Okay, I built Bmax NG 0.77 and tried Minib3d but had to change a few source lines for type cast errors, I'm just going to list them here as I don't have a fork of Minib3d.
TDebug.bmx line 228,239.
'Text ProjectedX(),ProjectedY(),"X"
Text Int(ProjectedX()),Int(ProjectedY()),"X"
TCamera.bmx line 564
'accPerspective(ATan((1.0/(zoom#*ratio#)))*2.0,ratio#,range_near#,range_far#,jx#,jy#,0.0,0.0,1.0)
accPerspective(Float(ATan((1.0/(zoom#*ratio#)))*2.0),ratio#,range_near#,range_far#,jx#,jy#,0.0,0.0,1.0)
TMesh.bmx line 1886
'glTexEnvi(GL_TEXTURE_ENV, GL_RGB_SCALE, 2.0)
glTexEnvi(GL_TEXTURE_ENV, GL_RGB_SCALE, 2)
Openb3d didn't compile with NG but I fixed the errors which weren't too many and have a new commit on my git. I removed the sdl stuff and added a FindChild fix by DruggedBunny which I need to test yet.
I agree GW, no need for Bmax 1.50 when we have 1.52 which has some extra fixes and no lib conflict issues. The copy of MinGW in Bmx NG is the same as I use 5.1.0, I just prefer the TDM installer.
NG supports method overloading, so it will complain about mismatched types, even primitive types, so passing a float to a function that expects an int will error out.
If you use the BMK flag -w it will suppress these errors to warnings and everything should build fine.
Wow. Thanks guys, I must give it another try later. Perhaps we should add a new step-by-step installation instruction in the first post as it is very confusing.
Damn. I used now 0.77 (BlitzMaxNG_win32_Unoffical_0_77.7z), added minib3d and the fixed openb3d from marks repository, applied the changes to the minib3d files and recompiled everything without any errors. MinGW and Path environment settings points to c:\apps\Blitzmax\MinGW32 and c:\apps\Blitzmax\MinGW32\bin, BLIde is happy with MinGW and minib3d compiles and runs my test file without any problems while OpenB3D throws out an Exception at Debug with no further informations.
I've uploaded my whole C:\Apps\Blitzmax folder from this installation try here (http://www.christianhart.de/bmax/openb3d/Blitzmax.zip) (178MB ZIP), so please take a look at it and try it yourself if this setup is working or not on your system.
Are you using bmk to build the modules?
By your description, everything seems ok.
If you're interested, I've zipped up my openb3d.mod folder and you can try replacing yours with mine. everything is already built. Try out the samples in the samples dir and see if they work.
HERE (http://www.gutterbox.com/download/openb3d.mod.zip)
I'm using BLIde to rebuild the modules, and BLIde uses BMK afaik. Unfortunately, your MOD folder doesn't work here too but with a different result: it compiles much longer than in my old, working setup and then finally crashes.
you need to stop using blide to compile your modules and do it yourself where you have control.
bmk makemods -v -w -g x86 openb3d {if your using bmaxNG}
or
bmk makemods -a openb3d {if your using bmax OS}
Did you try the examples before you recompiled the mod?
i dont know why there is a dangling 'linepick' in the file
and for some reason GL_TRUE is not defined in pub.opengl. There is nothing else that could prevent a build
Thanks for the bmk tip GW, I think I'll leave the changes to make it easier for others to build.
Does Blide support 64 bit builds with NG? I couldn't find the option. I agree, use the commandline to build modules so you know what's going on.
I only tested openb3d with NG in 32 bit, I should have been building 64 bit.
Blide doesn't support 64bit builds because it hides away all the command line args to BMK. Ziggy really need to add that.
I've tweaked bmk give me the option of 64bit builds from blide. I'm not sure it works correctly.
I'll post a how-to later on how to get blide working with BmaxNG
Ok I stopped using BLIde to compile modules, promised :-X
I've deleted everything and started from the scratch installing BlitzmaxOS (https://github.com/blitz-research/blitzmax), TDM GCC 5.1 (http://tdm-gcc.tdragon.net/download), compiled for X86 using the _src/win32_x86/install.bat, copied Mark's fixed openb3d version (https://github.com/markcwm/openb3d.mod) to the mod folder and compiled both with the commandlines
bmk makemods -a openb3d
bmk makemods -a sidesign
Testing Mark's fixed version:
Result: now BOTH Mods (openb3d and minib3d) compile but the error in my test code still appears, openb3d crashes while minib3d runs through. And Mark, some posts earlier you stated that my test code is running fine on your system, did you run the source several times? In the first run there was no error here and from the second run it started always crashing after a few cycles, even if I delete all compiled files from the .bmx subfolder or change the source to force recompiling. I even used MaxIDE to compile it but it didn't work either.
Testing GW's version:
Your compiled examples work but when I recompile "your" mod it throws out an error, but deleting Line 174 (which is a lonely "LinePick" only which makes no sense there) it compiles, so you should check your source there, too.
Compile Error: Missing function parameter 'x'
[c:/Apps/BlitzMax/mod/openb3d.mod/openb3d.mod/inc/TPick.bmx;174;1]
Build Error: failed to compile c:/Apps/BlitzMax/mod/openb3d.mod/openb3d.mod/openb3d.bmx
Then I compiled the blitz3d/collisions.bmx example - works. And tried again my test source and - *drumroll* - it works! Then I recompiled my current project, which is quite complex, and it still works too, fine :-) Is this your own version? Mark's version has some additions and the shaders are in a separate subfolder as far as I can see. I really appreciate that it's working now with your version but would prefer that we all use the same OpenB3D version and IMHO should stay with Mark's repository or the forks will become too fragmented and it'll be confusing to new users.
So the question is: why is GW's version running and Mark's version doesn't? I tried to compare both version but couldn't find a difference in the FreeTexture Methods, but don't know how the algorithms behind work.
So Mark, could you please
- download my setup (http://www.christianhart.de/bmax/openb3d/Blitzmax.zip) (210MB ZIP) and compile my testsource with it and check if the error appears? here it does, always (the folder "openb3d.mod" contains your compiled mod while the "openb3d.mod.gw" folder contains GW's compiled version, both were compiled with this setup)
- if yes, check for possible differences between GW's and your version regarding the FreeTexture algorithms? perhaps there is a bug somewhere?
- I've prepared a testbed (http://www.christianhart.de/bmax/openb3d/OpenB3Dtest.zip) (2MB ZIP) where I precompiled the source once with GW's version and once with Mark's version. I only switched the openb3d versions for each compile, the source is the same
And I'm really curious about your results :-D
Okay, thanks Krischan, looks like you've got places. I've been having trouble getting my openb3d branch to run on 64 bit NG, I'm getting a MAV with examples and I can't see what I've done wrong. I'll have a look later on, I'm currently working on a Coor's Light. ;)
Quote from: markcwm on June 14, 2017, 22:42:28
Okay, thanks Krischan, looks like you've got places. I've been having trouble getting my openb3d branch to run on 64 bit NG, I'm getting a MAV with examples and I can't see what I've done wrong. I'll have a look later on, I'm currently working on a Coor's Light. ;)
Ahh ok, it's a beer. Funny, I'm currently working on a Paulaner (https://www.paulaner.de/sites/default/files/images/produkte/hwb_glas.png)
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fwww.christianhart.de%2FGIF%2Fbeer.gif&hash=574f2e012bec661333b84eef903d9164553bb480)
Oh, I like a good wiess bier! We don't have Paulaner here but I think Erdinger is the best, not too banana flavoured like so many others. I'll be brewing my own wheat beer soon, first time trying the wheat malt. Last time I made an ale it got a bacterial infection and I had to pour out 2.5 gallons! :(
Well, I found another problem. This time with GW's version and again with the candles, argh. My parser creates dozens of Sprites for the candles and torches. In GW's version they are all gone, compiling the same source with Mark's version they are still there.
I could isolate the problem to the mesh children - all my light models like candles or torches contain B3D bones titled "flame" or "flame1" to "flame8". I read them and add them to a TCandle or TTorch Type and create sprites at their relative positions to the light mesh. It looks like the Countchildren/Getchild works but the Entityname function returns only cryptic characters and so the algorithm can't decide if a child is a flame or not. Mark's version does it right, I must investigate this further now.
EDIT: I've made a small demo demonstrating the algorithm including the media:
OpenB3Dtest2.zip (http://www.christianhart.de/bmax/openb3d/OpenB3Dtest2.zip)
SuperStrict
Framework openb3d.B3dglgraphics
Import brl.tgaloader
Graphics3D(1024, 768)
Global candle:TCandle
Global candlelist:TList = CreateList()
Type TCandle
Field ent:TSprite
Field parent:TEntity
Field child:TEntity
Field x:Float
Field y:Float
Field z:Float
Field yaw:Float
Field scalex:Float
Field scaley:Float
Field anim:Float
End Type
' load chandelier mesh
Local piv:TPivot = CreatePivot()
Local cam:TCamera = CreateCamera()
Local mesh:TMesh = LoadAnimMesh("chandelier1.b3d", piv)
Local tex:TTexture = LoadAnimTexture("candle.tga", 1 + 2, 32, 64, 1, 64)
PositionEntity mesh, 0, 10, 100
EntityFX mesh, 1
' parse mesh's children
If CountChildren(mesh) Then
For Local c:Int = 1 To CountChildren(mesh)
If GetChild(mesh, c) Then
Local child:TEntity = GetChild(mesh, c)
Print "Child name: " + EntityName(child)
' the child bone has a flame?
'If Left(EntityName(child), 5) = "flame" Then
candle = New TCandle
candle.parent = mesh
candle.child = child
candle.x = EntityX(candle.child)
candle.y = EntityY(candle.child)
candle.z = -EntityZ(candle.child)
candle.yaw = EntityYaw(mesh)
candle.scalex = 3
candle.scaley = 5
candle.anim = Rnd(0, 63)
ListAddLast(candlelist, candle)
'End If
EndIf
Next
EndIf
' create candle sprites at child's positions
For candle = EachIn candlelist
candle.ent = CreateSprite(candle.parent)
PositionEntity candle.ent, candle.x, candle.y + candle.scaley, candle.z
ScaleSprite candle.ent, candle.scalex, candle.scaley
SpriteViewMode candle.ent, 4
EntityBlend candle.ent, 3
Next
MoveMouse GraphicsWidth() / 2, GraphicsHeight() / 2
While Not AppTerminate()
If KeyHit(KEY_ESCAPE) Then End
' mouse movement
RotateEntity mesh, 0, MouseX() / 5.0, 0
PositionEntity piv, 0, -MouseY() / 6.0+64, 0
' candle Texture Animation
For candle = EachIn candlelist
candle.anim:+Rnd(0.125, 0.333)
candle.anim = candle.anim Mod 63
If candle.ent Then EntityTexture candle.ent, tex, Int(candle.anim), 0
Next
RenderWorld
Flip
Wend
End
I just want to mention that I really appreciate all of your help, that I see a lot of potential in Blitzmax+OpenB3D and I'm confident that we all together can create an official stable and bugfree 1.0 version, preferred in the BlitzmaxNG/64bit variant to make it future-proof.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fwww.christianhart.de%2FGIF%2Fjump.gif&hash=6b0544fad650afd7fdd29e5f3437a86de045cf8f)
I really don't know how my version is different. I set it up a long time ago and I probably just kept deleting stuff until i stopped getting build errors. Imo, don't rely on the one I sent you build a game, it was just for testing, use the official version and get that working.
Quotei dont know why there is a dangling 'linepick' in the file
and for some reason GL_TRUE is not defined in pub.opengl. There is nothing else that could prevent a build
GW's openb3d version was dated 12 Apr 2016. That Linepick isn't there in TPick.bmx but it may be my bad searching for linepick. In BmxNG Pub.Opengl v1.02 GL_TRUE is defined. Thanks for uploading the zip GW, I was a bit stuck there, I still don't know what's wrong but at least it's working.
Krischan, thanks. I ran your test code several times and it was fine. I tried your Bmx setup and couldn't reproduce the crash but when I tried your testbed it crashed only once and with GW's version. Now I have a new commit which is basically GW's version with a few things reordered. When I ran your code with this it did crash about 3 times in a row but then I couldn't get it to crash again. I'll work on it and see if I can isolate it. You could try going into TSurface.bmx and commenting out FreeVBO from Delete and see what happens.
This commit reverts the library source to the non-GLES 1.12 source, openb3dex.mod is gone and openb3dstd is in, the docs have been split into standard B3d and extended commands to make it clearer, the Text and Graphics commands were moved to b3dglgraphics, type casts from the last commit were taken out so you must use -w overload warnings when building.
Krischan, I tried your candle test and candles in both GW's and mine worked fine and I ran them several times. You should look at TEntity.bmx there's a fix for EntityName EntityClass by DruggedBunny, that may be related to it.
I applied the fix to TEntity.bmx, Line 662 commented and added this, works now:
Return String.FromCString (EntityString_ (GetInstance(Self),ENTITY_name))
Then I tried again the BlitzmaxNG 0.77 and 0.87 with DruggedBunny's version, recompiled all modules for x86 and x64 from the commandline and ran my Chandelier example - works like expected in x86 and x64. But my testcode with the FreeTexture command still crashes there.
Finally I tried your fixed version from yesterday in my BlitzmaxOS x86 setup. Still crashes and some OpenB3D examples run, some not (but that's because the gfx loaders are missing in the b3dglgraphics.bmx).
Commenting out the FreeVBO command (Line 363) in the TSurface.bmx didn't do anything in all cases. So the most "stable" version to me is now GW's version with the Entityname fix applied. But I know why it isn't crashing: the memory doesn't get freed, so its not usable, too (it starts around 320KB RAM used and the run ends with 320MB! RAM used while the miniB3D run always used max. about 50KB)
So currently none of the available OpenB3D versions can unload textures without an error, what a pity...
Thanks for the tests Krischan, I hope we can sort this bug out. I'll probably remove the TTexture pointers first, to see if it's the wrapper or library.
The TEntity.bmx fixes are in the latest commit, I just added them after I posted my last reply, which seems to be after you downloaded it.
My current version is quite close to DruggedBunny's now, although his readme says it doesn't work with vanilla Bmx getting "load of undefined reference errors" on compiles but I tested a few examples and both versions worked.
Yes, I removed the image loaders from b3dglgraphics without testing. I will put them back in.
Good to hear Mark, and I really hope that OpenB3D becomes the real successor to miniB3D which has been never finished - if you have time for it. I'm not very familar with the C++ subroutines to help finding the deeper bugs but I can do the testing, and my current project already uses a lot of the OpenB3D functions.
Umm Mark, I'm not sure but I think I've found the solution for our problem. Your version could be ok if you can confirm this: just switch the FreeEntity/FreeTexture order in my demo and it'll run fine, I only had one (!) crash and I couldn't reproduce this one again. But I don't trust this solution so please try it yourself.
If it works I can't believe I've overseen this the last days as it makes sense to clear the texture first and then free the entity (to which the texture has been assigned!). I don't know why this worked flawless in miniB3D. (https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fwww.christianhart.de%2FGIF%2Fbash.gif&hash=f9db3b2812c44192c4deba5b49701fed27e61ce0)
Wrong:
c.ent.FreeEntity
c.tex.FreeTexture
Right:
c.tex.FreeTexture
c.ent.FreeEntity
or to make sure the texture will be cleared from VRAM, see below:
c.tex.FreeTexture
glDeleteTextures 1, TTexture(c.tex).texture
c.ent.FreeEntity
Just one thing: my VRAM usage in the Open Hardware Monitor (http://openhardwaremonitor.org) stays constant at 14,7% (I have 4GB VRAM) which is 0,6% more than before if I add the glDeleteTextures command. If I don't add it, the usage climbs up to 16.7% (see attached image). Perhaps you should add this command to the Freetexture routine to really free up the VRAM from all deleted textures?
Here's the complete test source I've used (with the glDeleteTextures command disabled)
SuperStrict
Framework openb3d.B3dglgraphics
'Framework sidesign.minib3d
Import brl.tgaloader
Import brl.Map
Graphics3D(1024, 600)
Global cam:TCamera = CreateCamera()
Global BSP:TBSP = New TBSP
Print "Start: " + GCMemAlloced()
Local ms:Int = MilliSecs()
For Local i:Int = 1 To 100
Print "Run #" + i
BSP.AddAll
BSP.DeleteAll
Next
Print MilliSecs() - ms
End
Type TBSP
Field pivot:TPivot
Field candle:TCandle
Field candlemap:TMap
Global candlelist:TList
Method New()
candlemap = CreateMap()
candlelist = CreateList()
End Method
Method AddAll()
Local num:Int = Rand(100, 1000)
For Local i:Int = 1 To num
BSP.AddCandle(i)
Next
GCCollect()
Print "Created " + num + " Candles"': " + GCMemAlloced() + " Bytes used"
End Method
Method DeleteAll()
Local num:Int
For Local c:TCandle = EachIn candlelist
DeleteCandle(c)
num:+1
Next
GCCollect()
Print "Deleted " + num + " Candles: " + GCMemAlloced() + " Bytes used"
End Method
Method AddCandle(id:Int)
Local c:TCandle = New TCandle
c.id = id
c.ent = CreateSprite()
c.tex = LoadTexture("candle.tga")
c.x = Rnd(-100, 100)
c.y = Rnd(-10, 10)
c.z = Rnd(-100, 100)
PositionEntity c.ent, c.x, c.y, c.z
MapInsert(candlemap, String(c.id), c)
End Method
Method DeleteCandle(c:TCandle)
MapRemove(candlemap, String(c.id))
ListRemove(candlelist, c)
c.tex.FreeTexture
'glDeleteTextures 1, TTexture(c.tex).texture
c.ent.FreeEntity
c = Null
End Method
End Type
Type TCandle
Method New()
ListAddLast(TBSP.candlelist, Self)
End Method
Field id:Int
Field ent:TSprite
Field tex:TTexture
Field parent:TEntity
Field child:TEntity
Field x:Float
Field y:Float
Field z:Float
End Type
and the fixed Method in TTexture.bmx:
' SMALLFIXES New function from www.blitzbasic.com/Community/posts.php?topic=88263#1002039
Method FreeTexture()
If exists
ListRemove( tex_list,Self ) ; tex_list_id:-1
FreeTexture_( GetInstance(Self) )
FreeObject( GetInstance(Self) )
glDeleteTextures 1, texture
exists=0
EndIf
End Method
No I tried FreeTexture before FreeEntity and it's not a solution, also you don't want to have to do this as like you say, it makes no sense as entity and texture are different types.
I do have a solution though, the problem is in the c++, the textures are stored in tex_list and repeated entries of texture objects are prevented. So if you load the same texture again and then delete that reference, the second texture needs this reference so it crashes. When I removed this feature it stopped crashing, and I've been able to make it crash consistently. This doesn't happen in Minib3d because Tlist is more stable than c++ lists. So the fix is to have an extra list for repeat textures so it knows how many there are to delete.
Also, yes I think we need glDeleteTextures in there as it is in Minib3d and you have proved it does something, so thanks. I just need to get a commit out now.
Sounds good, looking forward to a fixed version to play with :-D
It's out, have fun. Hope it works, it did seem to on my initial test.
It has glDeleteTextures in FreeTexture and is managed by a new list named tex_list_all to check for repeat texture entries.
If you wonder how this relates to shader material textures, they don't get added to a list and can't be deleted other than with FreeShader.
Edit: oops, it still crashes.
I really think I've nailed this bug down now Krischan! I forgot to add to FreeTexture in TTexture.bmx and I made a mistake in how to add tex_list_all in texture.cpp. Other than that I believe my theory was correct! Tested it well and it runs nicely.
It's inspiring to know I can come back after a year and get into coding again quite easily, it's all still there in the mind, I suppose you could say it is "lurking". I was lurking quite often last year. lol
Good job Mark, it seems to work now! Unfortunately I've got a lot of work this week so I only can take a deeper look at the weekend to continue working on my Legend of Faerghail project and finish the media and level loader/unloader.
..guys..which version i have to download?? Im using BMX vanilla 1.5 .. i did try https://github.com/markcwm/openb3d.mod ,
but it just doesnt work and i cant compile modules(using blide)..can you point me at proper version, please..
I'm using BlitzMax OS 1.52 (https://github.com/blitz-research/blitzmax) with Mark's latest OpenB3D version (https://github.com/markcwm/openb3d.mod), TDM GCC 5.102 (MinGW) (http://tdm-gcc.tdragon.net/download). This is the latest "Non-BlitzmaxNG" setup. As BLIde is not 100% compatible to Blitzmax NG yet you should use try this setup first unless you need 64bit support.
You can download my precompiled Blitzmax Installation (http://www.christianhart.de/bmax/openb3d/Blitzmax.zip) for Windows, don't forget to set the MinGW environment variable/path to the MinGW subfolder. It includes a batch in the "bin" folder to recompile a new version from Mark and works with BLIde's latest version under Windows 10 (but you shouldn't (re)compile modules using BLIde anymore).
..i did exactly as you suggested, and this is error im having now..
(https://s22.postimg.org/nk6a8f3ap/error.png)
The 11th commandment: Thou shalt not build modules with BLIde anymore (unless there is a new patch, if ever).
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2F68.media.tumblr.com%2Ff967240dec78d7bf3fff400406599914%2Ftumblr_mn1jxqTFOm1r7w8cbo1_250.gif&hash=90580b85e549e45a5b2de6bb900fc9e1fea60d60)
And make sure your environment settings match the MinGW path (press Win+Pause, in my setup it is for example c:\Apps\Blitzmax\MinGW):
..that is fine, i have set environment variable...now what would be 'manual' way of compiling mod which should do job?
Go to the BIN subfolder, open a commandline window and type (or create a Batch file and execute it)
bmk makemods -a openb3d
Beside that I tried again building modules in BLIde using my setup I've uploaded (see previous posts) and it still worked, so there must be something wrong with your setup. If it still doesn't work you can try my setup. But compiling modules in BLIde won't work correct if you're using Blitzmax NG (and BLIde has no option to build x64 yet).
You can use BLIde to check if your MinGW setup is correct (Tools > Configure the MinGW compiler):
..okay..now, modules are built without error, however, i cant run example as im getting this error..
(https://s18.postimg.org/yi48hdayh/error.png)
There is still something wrong with your setup. Did you try my Blitzmax installation?
..okay..got it working now..it was related to installed version of BMX..very nice :) .. thank you for kind assistance man..
I haven't tried building openb3d with Blide yet but as Krischan wrote, it should work except with 64 bit NG. You should be able to build with Maxide NG but I just use command line.
Naughty, I don't really know what was going on there but maybe you had brl mods built with another MinGW version. Also I see you're testing the Action sample. Well there's a bug with that, it crashes when deleting them but I will try to fix it.
its working now very nice..im just wondering, how can i enable syntax coloring for OpenB3D commands inside BLIDE ?
Goto Tools > Preferences > Advanced > Use complete BlitzMax module highlighting and restart Blide.
...thank you very much...this is now something nice to work with.. :)
..what 3d file formats are supported ?? B3D only ??
I think it's the same as bb. b3d and static X. probably no md2 or 3ds
..ahh..thats not so good..im wondering is there any roadmap to integrate FBX ? Anyway, regarding animation, is it hardware skinning or same as bb had, which was really FPS killer ? And, what would be proper way to export B3D (static or animated) from 3dsmax (2014+)
No roadmap but I'll make one as it will help.
There is an assimp module but it only loads static models, Brucey tried to add animation but I don't think he succeeded. This might be the easiest option but assimp is a big library, it adds something like 30MB to the exe. I shelved my assimp branch as I intend to port at least one good animation format. I chose ms3d as it is well supported but haven't got any progress with it, I think I found fbx too complex.
Animation formats are b3d and md2 (in md2 textures are applied manually). I don't use 3dsmax.
Angros answered a question about hardware skinning so I'll quote. I'll try to get a demo of this hardware mode in use.
QuoteAnimations use software skinning (maybe it's slower, but works everywhere), plus a special hardware mode taken from the MiniB3D Monkey port: all frames are pre-calculated in software, then loaded in the video memory: it's less smooth, since there is no tweening, but it requires almost no computation neither from the CPU, nor from the GPU; it uses more video memory, but makes instancing possible, so if you have many copies of the same mesh, it could actually use less memory)
..i see..i hope file format will be upgraded as FBX seems to be considered as a standard today, and it does offer a lot more than B3D, so i thought that should be proper direction in development, which includes hardware skinning, because, it is somewhat important actually, if you happen to have certain amount of characters on scene..
I've uploaded a fix for FreeAction crashing. So the actions.bmx example doesn't crash any more when you press Space. I had to edit actions.cpp as well. I added a new function EndAction to manually end actions, as this wasn't possible but it has the drawback of having to wait a second before freeing them or it will crash, if I wait about under 5ms it crashes. I don't see any way round it other than to wait.
Krischan, could I ask you to remove the "fixed" version of Minib3d please? As all I did was change a few overloading types as I didn't know about the NG -w option. So it's just confusing. ::)
QuoteI don't see any way round it other than to wait.
Okay, I think I fixed it. No need for timer hacks now. I used ironically, a timer to check if it was still active.
Quote from: markcwm on June 26, 2017, 00:52:22
Krischan, could I ask you to remove the "fixed" version of Minib3d please? As all I did was change a few overloading types as I didn't know about the NG -w option. So it's just confusing. ::)
Ok, I've removed the links to it from this thread.
Which is better, miniB3D or OpenB3D?
What is the difference between these two modules?
The main difference is Minib3d Legacy/vanilla and Warner Engine are OGL 1, whereas Minib3d Extended, Minib3d+ and Openb3d are OGL 2, this is because of shaders so you can't run these versions in OGL 1. There's also a version of Minib3d combined with Warner engine features, quaternions and terrains and I think it also has shaders, stencil shadows and MD2 which are the main features in Minib3d Extended. Minib3d+ has a few advanced shaders like SSAO, I'm not sure what else as I couldn't run it (due to the updated GLEW version). I don't know how stable these versions are. Openb3d has all those features except not advanced shaders but things like bumpmap, toon shading, pixel fog and is stable and easier to use. There's also code sitting on the forum where features were added to Minib3d Legacy like batch sprites, Openb3d has this too plus examples, which most other Minib3d versions are lacking. Openb3d also has the same syntax as Minib3d, it uses pointers internally but porting code is quite easy.
I decided to make this wrapper because Angros had already taken all the best features in the different Minib3d versions and put them together, this requires you to know OGL really well and I didn't.