SyntaxBomb - Indie Coders

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 (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

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

I've deleted everything and started from the scratch installing BlitzmaxOS, TDM GCC 5.1, compiled for X86 using the _src/win32_x86/install.bat, copied Mark's fixed openb3d version 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 (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 (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

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

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.

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.