Monkey Forums/User Modules/miniB3D

AdamRedwoods(Posted 2012) [#1]

big note:
- turn on config.h depth_buffer_bits = 32
- tested on glfw, android, macos, ios

- normals work
- textures, mipmaps work
- android, works
- vbos and non-vbo fallback works
- sprites
- batch sprites
- context handling for mobile devices
- pick (optimized)
- collisions
- binary load for b3d files (base64)
- animation, bone & vertex
- Load OBJ
- animated textures

to do:
- fix bugs
- MDD, 3DS
- thardware
- loading progress bar (?)

- opengl2.0 for webGL target
- TShader, TShaderBrush
- terrain
- object occlusion

Most documentation can be found here:

Xaron(Posted 2012) [#2]
Wohoo! Great!

Difference(Posted 2012) [#3]
Great !

- binary load for b3d files (will require a hack)

Maybe the b3d xml translation I wrote many moons ago could be of use:

It could be ported or rewritten to BlitzMax (or GLFW?) to create a standalone converter.
iMonkeyMiniB3d could read the b3d xml it produces.

There is a description of the format here:

CodeGit(Posted 2012) [#4]

simonh(Posted 2012) [#5]
Nice, saves me a job!

ziggy(Posted 2012) [#6]
That's awesome! Any sources available?

therevills(Posted 2012) [#7]
Whoah! How did I miss this thread?!?!

Rob Pearmain(Posted 2012) [#8]
Cant wait to use this, Currently using iMiniB3D (iOS/C++) but would love to use MiniB3D in Monkey

AdamRedwoods(Posted 2012) [#9]
firepaint from the minib3d demos! almost a straight port.
sprites work:

...but it's slow on android:
- i'm manually creating mipmaps, may have to send it to hardware.
- particles are slow. I even tried an array version versus New Object creation, no speed improvement. :\
- need a routine to reload textures when device is paused/resumed (from a call or something).

I'll do Pick, Collision and then upload the source.

bradford6(Posted 2012) [#10]

charlie(Posted 2012) [#11]
Sprites/particles were pretty slow in MiniB3D anyway. I think iminib3d had a batched version which was quicker.


AdamRedwoods(Posted 2012) [#12]
I did some texture state optimizing and it now runs faster on Android.
On to TText-- I don't have a way to DrawText(), couldn't get it to switch back to Mojo for some reason. This will test my cameraProject and unProject since I had to rewrite these anyways.

matty(Posted 2012) [#13]
Are you going to add "md2" animation - I'd imagine it would be worth it for mobile platforms, though I'm speaking from no experience with 3d on mobile platforms...

AdamRedwoods(Posted 2012) [#14]
I'll probably leave other extensions to the community, as it should be possible to port these over from blitzmax. That said, I'll make sure the obj and b3d loaders work.

Rob Pearmain(Posted 2012) [#15]
Any chance of a demo? How is it progressing, will happily assist with testing

AdamRedwoods(Posted 2012) [#16]
Ok, just spent a lot of time on making TBatchSprite class, and no difference of speed on Android (200 sprite particles at 6-7 fps)... blah... this can be improved with opengl 2.0.

It did improve particle speed on the PC side though. My guess is all the float multiplies slow things down since static meshes are still relatively fast.

charlie(Posted 2012) [#17]
Are you intending to do this with GLES 2? That would be much more interesting...


AdamRedwoods(Posted 2012) [#18]
Yes, but the community may need to help out. I want to get the GL20 framing in for minib3d+monkey and then pass it off, as it may be too time consuming for just me at that point.

Paul - Taiphoz(Posted 2012) [#19]
Keep up the good work , sounding real cool.

AdamRedwoods(Posted 2012) [#20]
Note on minib3d:

Binary files don't load natively in Javascript.
And I think it may be too much work for me to port Difference's b3d->xml converter for blitzmax, and then back again as a loader in monkey.

My other thought is B3D->Base64 ascii files, then back to binary.
The zombie.b3d file is about 59k and in base64 is 80k. There are online Base64 encoders.


JIM(Posted 2012) [#21]
Definitely base64. xml is slow to parse and it's large. The only advantage is human readability, which is not really important unless people actually model using Notepad.

Right now I'm experimenting with my own format, because the compact ascii formats are either horrible or way too complex for my needs. The other ascii format (obj) is almost useless (no hierarchy, no animations, no proper materials/shaders - .mtls suck). Will see how this goes. I'm also thinking of making a binary version of my format then turn it to base64.

Cheese(Posted 2012) [#22]
Very cool.

I'm looking forward to testing this port extensively with Android!

AdamRedwoods(Posted 2012) [#23]

TPick works, including triangle on a surface pick. Pretty nice. This took forever.

TText works, so now I have 3d text.
TBatchSprites works, increasing performance of sprites significantly (with matrix optimizations).

What next?
- TCollisions, which I will NOT optimize since the code is a mess. I will only get it to a working condition.
- TAnimation, reading B3D files from base64. Should be fun.
- then I'll release it on github

simonh(Posted 2012) [#24]
Good work. I don't envy the task of converting all the collision, er...stuff to Monkey. It was bad enough getting it working in BlitzMax!

matty(Posted 2012) [#25]
What is the lowest version of Monkey this will work on?
Lowest version of Android it will work on too?

AdamRedwoods(Posted 2012) [#26]
I'm not using relfections so around monkey52e-53.
Android 2.2, using only opengl es 1.1 at the moment. i may plug opengl2.0 later but will always be backward compatible.

AdamRedwoods(Posted 2012) [#27]
Collisions and collision response works.
It's very slow on android, so i will look into optimizations after the initial release.

Difference(Posted 2012) [#28]
Sounds great!

I still like the xml idea, so maybe I can work on that when your source goes online.

AdamRedwoods(Posted 2012) [#29]
A familiar face...

This means my Base64 loader works for B3D binary files. Animation works, too. Verrrry nice.
(in theory you could encapsulate all your files into ONE Base64 file and parse it. Good for HTML5-- when we get to that point)

XML would be good too, but I worry about speed. My experiences with XML is that it is slow to parse a hundred-thousand vertices and this would be slow on Android/Java.

So i'm almost done. I found a few deep errors, and will need to fix those up.
I'm thinking about an MD2 loader (or should I go .X?) to use vertex animation rather than boned animation. This would help on mobile targets.

Rob Pearmain(Posted 2012) [#30]
Cannot wait to start using this Adam, thanks for all your hard work

Is it on GITHUB yet, guess not

CopperCircle(Posted 2012) [#31]
Great work, the HTML5 version in the future will be awesome...

NoOdle(Posted 2012) [#32]
wow, excellent, great job. I totally stopped on my own engine because I knew this would knock it out the water. Looking forward to messing about with it.

What 2D support is there? Have you managed to get Mojo working?

What has more support for users to create models with .x or md2? I have never attempted to make an md2 mesh so I would vote for .x but that could be an ill informed choice.

AdamRedwoods(Posted 2012) [#33]
What 2D support is there? Have you managed to get Mojo working?

no, but I'm sure Mark will point some things out once miniB3D is released.

in the meantime, I set up a switch (EntityFX (n=64) ) that will enable sprites to render without depth testing, which is just as effective. Plus, CameraUnProject works fine (screen -> world), and I've set up a CameraLayer system to render only certain object with certain cameras... this allows for many possibilities, and I put this in to prepare for a shader or fx system to be easily added.

NoOdle(Posted 2012) [#34]
Ah nice! That all sounds very useful! Great job.

EdzUp(Posted 2012) [#35]
Excellent stuff :D

AdamRedwoods(Posted 2012) [#36]
10 zombies at 3fps, Android + vertex animation..... NOT GOOD ENOUGH!

One more trick i'll try, but otherwise will have to wait until gl20+monkey+minib3d to speed this up.

on GLFW, 100 zombies + vertex animation at about 9-10fps: 18fps: v0.12 = 30fps easy

AdamRedwoods(Posted 2012) [#37]
10 animated zombies at 30fps on Android! ( I actually manged 20+ at 30fps)

Get your beta-testing hats on, I'm gonna release this beast hopefully within the week. EXCITING!!!!

Difference(Posted 2012) [#38]
Looking forward to trying it out!

NoOdle(Posted 2012) [#39]
yeah same, can't wait!

chrisc2977(Posted 2012) [#40]
This will be completly awsum :)

Beaker(Posted 2012) [#41]
Looks great. Really looking forward to 3d in html5 when that gets added.

DruggedBunny(Posted 2012) [#42]

slenkar(Posted 2012) [#43]
Do you think it would be easy to do a software renderer?

There are a few engines available:

AdamRedwoods(Posted 2012) [#44]
Do you think it would be easy to do a software renderer?

One of my goals that I wanted (but haven't sufficiently had time) is to pull the render hardware layer into it's own class (TRender) without performance penalties and keep backward compatibility with miniB3D. I got to a point, then realized textures were well entwined. This will have to be revisited, especially for Flash11 and XNA.

That said, it wouldn't be hard to replace TTexture with a custom TTexture build using ?target or #config flags.

With the TRender class, you should be able to TSoftwareRender extends TRender relatively easily (knock on wood) since no new hardware commands would be needed. This is my preparation for OpenGL20/WebGL. There will be holes, but we'll fill them when we get there.

Shinkiro1(Posted 2012) [#45]
Can't wait for this.

Rob Pearmain(Posted 2012) [#46]
BETA TESTER Standing By ;-)

Can't wait too

Rob Pearmain(Posted 2012) [#47]

Cheese(Posted 2012) [#48]
Ack! That bump got me excited; I've been waiting so patiently for this and I thought just for a moment there that the first release must have been posted. >.<

AdamRedwoods(Posted 2012) [#49]
two more bugs need to be squished! hopefully tomorrow, sorry for the delay.

UPDATE (march 31):
found the bugs! wow, nasty vbo problem i made. but solved and working great.
will upload soon.

victory song:

AdamRedwoods(Posted 2012) [#50]

big note:
- turn on config.h depth_buffer_bits = 32
- test on glfw, android, should work on macos, ios ( i can test it tomorrow)

3 examples included:
- animation test: 4 zombies, converted from bone animation to vertex animation running at different speeds while aligned to a red cube. you can turn it back to bone animation if you want. zombies in a array so you can go to 999 (slow). on mobile, use two fingers to zoom in/out. try flicking cube.
- firepaint 3d: sparks using TBatchSprite, 3d text floating. should reload surfaces on mobile or tablet pause.
- pick collision test: paints a sphere red by clicking on its triangles

enjoy. i'll list documentation and to dos later. there's a lot in there (like TText, CameraLayers, TPixmap). TRender is now separate so in theory you can create your own software renderer.
victory song:

NoOdle(Posted 2012) [#51]
thank you and good job! I'll test this today :)

firepaint needs the first line in the OnCreate method to be changed to this to run:
SetRender(New OpenglES11)

slenkar(Posted 2012) [#52]

BTW how do you turn on the config.h buffer thingy

In GLFW the examples crash on:
in TRender.monkey

does that mean my hardware isnt good enough?

AdamRedwoods(Posted 2012) [#53]
firepaint needs the first line in the OnCreate method to be changed to this to run
Thanks, fixed.

does that mean my hardware isnt good enough?

under the file minib3d.monkey, turn off VBOs: "USE_VBO=false"
i haven't finished the THardwareinfo which would be needed to check opengl abilities.

Amon(Posted 2012) [#54]
This is good stuff dude! :)

DruggedBunny(Posted 2012) [#55]
Brilliant! Just tried all the examples on GLFW (worked fine) and my Android phone (Orange San Francisco aka. ZTE Blade).

Quick phone tests...

Firepaint gets crippled by new object allocation here, but it seems to animate the sprites just fine when I stop firing, and the 'world' turns smoothly if I disable firing, so I think it should be possible to get it working better with pre-allocated objects.

The pick demo is very slow indeed on my phone, but I haven't looked into it much so far.

The animation test was a surprise as that keeps near-enough a constant 30 FPS! However, I made it crash with an array index error while trying to pinch-zoom, then it crashed right away when I tried to re-run (same problem), then it crashed after displaying a frame or so... will have to investigate.

Still, it really is great to have a new Blitz3D for Monkey, and I look forward to seeing what I can get away with on my phone.

Many thanks for all your hard work on this!

AdamRedwoods(Posted 2012) [#56]
so I think it should be possible to get it working better with pre-allocated objects.
also try to use just 'tsprite' and 'tmesh' instead of tbatchsprite. i don't know if that would make a difference.
The pick demo is very slow indeed on my phone
collisions and pick are VERY SLOW. this is a future 'to do' to optimize it. (tech info: i believe this is because Java's JIT does not inline).

Also-- be aware that android 2.1 will be slow since it does not have android 2.2 JIT compiler, which improves overall speed.

I made it crash with an array index error while trying to pinch-zoom, then it crashed right away when I tried to re-run (same problem)

i will look into this too. bugs bugs bugs bugs

DruggedBunny(Posted 2012) [#57]
Been playing since... excuse my 'personal preference' tweaks, but I've butchered your demos to create a bare-bones template to work from, plus a really simple demo...


Simple demo...

Fun, though... feels just like the old days of Blitz3D!

DruggedBunny(Posted 2012) [#58]
Ooh, above demo with update rate set to 60 is silky smooth on my phone... not that it's doing much, but it's very nice!

bruZard(Posted 2012) [#59]
all samples run nice and smooth at 30fps on my Motorola Milestone 2


Cheese(Posted 2012) [#60]
Yes! All of the included examples run on my Droid X without crashing, though the touch controls seem to be sporadic and unpredictable and the zombie example takes approximately 40 seconds to finish initializing.

No matter, now's my chance to experiment..

So I refactored DruggedBunny's example to try and switch between MiniB3D/Mojo's graphics using Diddy.. it's a pretty bad hack.

It seems to run perfectly fine when using GLFW as a target, but the same isn't true for Android; it crashes without a stack trace!

I'd love to use Diddy and MiniB3D together!

bruZard(Posted 2012) [#61]
some issues:

1. i can not use *.b3d, i've exported a *.x out of Blender (2.62) and convert it with DeleD to *.b3d. Then i create a Base64 file with this encoder:

2. 2000 vertices per mesh is'nt enough, i've set it to 4000

3. *.obj exported from Blender is'nt textured correctly. No idea why, i've checked many configurations at export but nothing will. I know that it is just a 8 vertices cube, but Blender can show it correctly, also Blitz3D if i export it as *.x

hope this will help....

Rob Pearmain(Posted 2012) [#62]
Awesome work Adam.

The animation demo works fine in the iOS emulator, with the others it hangs on:

UIApplicationMain( argc,argv,nil,nil );

Giving a SIGABIT error.

I think it might be my environment, but will persevere


slenkar(Posted 2012) [#63]
ok I turned off VBO's
the zombies work great except their right arm is drawn so that it overlaps the torso, like the drawing order is wrong or something

firepaint crashes on SetBlend for some reason (from TText.monkey)

Picking demo worked fine (if Im sposed to be seeing a white sphere)

AdamRedwoods(Posted 2012) [#64]

1. i can not use *.b3d, i've exported a *.x out of Blender (2.62) and convert it with DeleD to *.b3d.


3. *.obj exported from Blender is'nt textured correctly. No idea why, i've checked many configurations at export but nothing will. I know that it is just a 8 vertices cube, but Blender can show it correctly, also Blitz3D if i export it as *.x

if you have examples of files that are not working and can send me the file, send to awpiette AT yahoo DOT com. i want compatibility to be priority.

AdamRedwoods(Posted 2012) [#65]
the zombies work great except their right arm is drawn so that it overlaps the torso, like the drawing order is wrong or something

turn depth buffer on, in your local .build folder (glfw):
config.h: #define depth_buffer_bits = 32

firepaint crashes on SetBlend for some reason (from TText.monkey)
---- edit: thank you! that is a bug. should be:

i will update github
Picking demo worked fine

click the sphere, should turn triangles red.

NoOdle(Posted 2012) [#66]
On a Mac you will need to change the config.txt in the GLFW build folder. The line that needs altering is:

Must say it is very fun playing around with this!

AdamRedwoods(Posted 2012) [#67]
Updated on GitHub:
-- (TModelObj) blender texture fix from OBJ file LoadMesh(). should load texture files now

slenkar(Posted 2012) [#68]
yep all the demos work now.

AdamRedwoods(Posted 2012) [#69]

The animation demo works fine in the iOS emulator, with the others it hangs on:

UIApplicationMain( argc,argv,nil,nil );

Giving a SIGABIT error.

I think it might be my environment, but will persevere

Everything worked here on MacOS, iOS iphone simulator (latest files, monkey 56b). let me know if you still have problems.

outsider(Posted 2012) [#70]
this generally looks very well, great job :), but I have a problem: models still looks weird. I have Monkey56b but there is no config.h file to set the #define depth_buffer_bits = 32. I turned in config.txt: OPENGL_DEPTH_BUFFER_ENABLED = true, but it still does not work.

slenkar(Posted 2012) [#71]
worked for me,

AdamRedwoods(Posted 2012) [#72]
but I have a problem: models still looks weird.

which models? do the examples work? how do they look weird, like the zombie arms are on the wrong side (which means depth buffer disabled)?

if you're loading your own models, there is still a problem with OBJs, and B3Ds from blender->deled3d->B3D which i'm working on. (please share any models you can giving problems)

outsider(Posted 2012) [#73]
yes, exactly the zombie arms are on the wrong side. Unfortunately OPENGL_DEPTH_BUFFER_ENABLED = true does not work for me (GLFW). My graphics is a GF7300 GT, OpenGL 2.0

AdamRedwoods(Posted 2012) [#74]
if you're working on the animation_test.monkey example, make sure to change the file.

you can also brute-force it in the main.cpp file and compile using the xcode.project.

or you can find the monkey/targets/glfw/main.cpp file and make sure it has the !glfwWindow(w,h,0,0,0,0, CFG_DEPTH_BUFFER_DEPTH ? 32 ...etc...) in it. try brute forcing that file, too, if you have to (may slow down 2d mojo so not a good idea to hardwire it for everything).

Difference(Posted 2012) [#75]
Great work!

Animation_test gives this error on my 4'th gen iPod Touch running iOS 4.3.5

Both examples runs fine on iOS 5.1 simulator.


Cheese(Posted 2012) [#76]
Be sure to check and report on the GitHub issues section:

I submitted an issue yesterday:
"TRender.ClearWorld() and TTexture.FreeTexture() contain erroneous code."

AdamRedwoods(Posted 2012) [#77]
my guess is memory alignment issues.

I wonder if I should just unpack Base64 with INTs to keep the 4byte alignment? This might be a good initial test to see if its the problem.
Mark or anyone have recommendations?

AdamRedwoods(Posted 2012) [#78]
I submitted an issue yesterday:
"TRender.ClearWorld() and TTexture.FreeTexture() contain erroneous code."

yes, I have that fixed, just trying to finish up one more bug then I'll make a git push.

AdamRedwoods(Posted 2012) [#79]
Difference, could you try replacing this Base64 class in moneyutilities.monkey and testing on iOS (not simulator)?
Many thanks.

Difference(Posted 2012) [#80]
@Adam: Success- Deleting the build directory and replacing Base64 class with the one above makes animation_test run on the iPod. :-)

AdamRedwoods(Posted 2012) [#81]
@Difference - thank you!

Updated v0.11

- faster TPick (much faster on android now)
- ClearWorld() fix
- LoadMesh() for OBJ fixed-- works now with one vertex with multiple tex coords or multiple normals
- TText() has a ALIGN_CENTER flag now
- Base64 alignment fixed-- works on iPhone, iPad now with ARM alignment issues

NoOdle(Posted 2012) [#82]
nice good job! :)

Cheese(Posted 2012) [#83]
Just to update; it appears as though ClearWorld() is working perfectly fine now!

Here's a little example of Minib3d managed by Diddy screens (DiddyApp3D/Screen3D):

Cheese(Posted 2012) [#84]
Okay, so perhaps my Diddy example above doesn't quite work right.. if you hold down the mouse on transition: memory access violation. No idea why; trying to figure it out..

Also, I figured that the parent parameter determined which entity a newly created object would always be rendered relative to, but the results seem contradictory to this; The 'fadeSprite' doesn't change position when the camera does.

Cheese(Posted 2012) [#85]
Actually, a quick glimpse at the module reveals evidence that a child's position should update when a parent moves.. This doesn't appear to be happening with sprites.. I'll test this out.

AdamRedwoods(Posted 2012) [#86]
Actually, a quick glimpse at the module reveals evidence that a child's position should update when a parent moves.. This doesn't appear to be happening with sprites.

Should be. simple tests work here. I'll try your example after "Game Of Thrones" is over.

Cheese(Posted 2012) [#87]
After some testing it does appear to work! The problem was a bit different than I initially thought.

To emulate Diddy's transition fade, I threw a sprite directly in front of the camera (Z: 1.0) which is a child of the camera. When moving the camera back and forth, it was flickering unpredictably. Changing the Z distance from 1.0 to 1.00001 seems to completely fix the problem:

Also, I think the unpredictable crash on transition while the mouse is held down may be a problem with Diddy (though I haven't been able to replicate the issue on another project yet). Will test further.

AdamRedwoods(Posted 2012) [#88]
Changing the Z distance from 1.0 to 1.00001 seems to completely fix the problem

The default camera depth is set to 1.0 to 1000.0, so i can see how 1.0 would cause z-fighting. also try changing the depeth if needed:

Xaron(Posted 2012) [#89]
Wow, this is really, really cool stuff! Thanks for that!

JaviCervera(Posted 2012) [#90]
Amazing! Thank you very much! OpenGL is probably the best thing that has happened to Monkey since its release.

bruZard(Posted 2012) [#91]
thanks for the update Adam!

Wavefront Obj now works with GLFW, but not on Android. B3D works nowhere. I've tried the Base64-Encoder from

Here is the model as *.obj, *.b3d and base64 in a zip:

and here the source:



Import mojo
Import minib3d

Class Game extends App
	Field cam:TCamera
	Field light01:TLight
	Field table01:TMesh

	Method OnCreate:Int()
		SetRender(New OpenglES11)		= CreateCamera()
		Self.light01	= CreateLight(1)
		Self.table01	= LoadMesh("table01.base64.b3d.txt")
		cam.PositionEntity(0.0, 6.0, -6.0)
		cam.RotateEntity(45.0, 0.0, 0.0)
		light01.PositionEntity(0.0, 6.0, -6.0)
		AmbientLight(30, 20, 0)
		Return 0
	Method OnUpdate:Int()
		Return 0
	Method OnRender:Int()
		Return 0

Function Main:Int()
	New Game()
	Return 0

bruZard(Posted 2012) [#92]
ok, i've tried this with several objects. The Object Loader doesn't work on Android

AdamRedwoods(Posted 2012) [#93]
ok updated the OBJ loader for android, but i'm still working on the B3D loader error and a couple other problems.

bruZard(Posted 2012) [#94]
woohoo! Thank you!

AdamRedwoods(Posted 2012) [#95]
the LoadB3D bug was nasty, but it's squished. B3D files should work now, tested on glfw, android.
I'm getting my OSX Lion upgrade in the next week so will be able to test iPad soon, but should work regardless.

UPDATE: the bug was nasty, so it may help fix other crash issues.

bruZard(Posted 2012) [#96]
currently i write a Blender 2.6.x export plugin for *b3d files with the option for an export as a Base64 encoded text file ... wish me luck ;)

fsoft(Posted 2012) [#97]
bruZard, GOOD LUCK!

I am really looking forward for this kind of export plugin ;-)

visionastral(Posted 2012) [#98]

Thank you for doing this module!
As an early Blitz3D user I can't be more happy now! :D

AdamRedwoods(Posted 2012) [#99]
You're welcome, glad you're interested!

UPDATE v0.14:
Animated textures, a few texture fixes.
Added: TBrush.LoadAnimBrush(file,flags,frame width,frame height)
Added: TEntity.AnimateTexture(frame:int,loop:bool,index:int=0)

bru_explo:TBrush = LoadAnimBrush("explosion_rgb_sheet.png",9+2,100,100)
sprite_explo:TSprite = CreateSprite() 'could also use TBatchSprite

frame += 0.5

I also modified TTexture frames so they would not create new textures but rather animate using texture position and scale. This is handled automatically, just a behind the scenes change.
AnimateTexture() is a shortcut to animate the current brush texture if frames are present. Option for looping.

I also added uv alteration info to brushes, which deprecates uv alteration in TTexture (but it still can be done), so that EACH brush/surface/entity will have independent animation for textures. THIS IS DIFFERENT from the Blitzmax version, but in my opinion makes Brushes more powerful. I added a command "PaintEntityGlobal(bru:TBrush)" just in case someone needed to animate or change textures on a global brush level.

Added TRender.GetVersion(). Returns Float value for render (opengl) version checking.

Tested on PC, Android, will make sure Mac, iOS work later.
I'm sure these changes will cause new bugs, let me know when you encounter them. Also, if you think these changes are too extreme, please let me know for discussion.

bruZard(Posted 2012) [#100]

visionastral(Posted 2012) [#101]
I'm glad to see this project is up and alive! OpenGL is not the kind of language fitted to everyday programming!
I was asking myself if the blitz 2D functions could be ported too, since opengl allows us to access custom buffers and I suppose we have full access to opengl buffers, doesn't it?
however I don't know how fast would it be...
What do you think? is it realistic?
Making a full blitz3D port to monkey would be amazing! :)

AdamRedwoods(Posted 2012) [#102]
What do you think? is it realistic?

You are welcome to add to this module, but for me I'd rather get mojo working on top of miniB3D for 2D needs, since remaking blitz2d would take me forever.

visionastral(Posted 2012) [#103]
Mojo is ok for me, but since miniB3D is using OpenGL I thought it was problematic to use mojo at the same time. I don't really have tried much, but when I did (a few days ago), using mojo and opengl together would make each other frame buffers to be deleted and ultimately causing crashes. (that was my experience, perhaps I wasn't doing things correctly?)

That's why I thought about making a B2D extension, in order to make it work nicely with opengl mode. But if I can make mojo work well along with opengl, then this is the best way to go, of course.


BTW, is the monkey miniB3D fully compatible with the BlitzMax version?
I would be interested in making my level editor in bmx but since the engine would be made in monkey, it would be nice if I just could copy-paste the engine's code from monkey to bmx (as the code is very very close from monkey to bmx as long as you don't use functions not present in bmx)

AdamRedwoods(Posted 2012) [#104]
Mojo & miniB3D:

my hack "RestoreMojo2D()" works for glfw, but not for android so far.

'' in OnRender()
glBindBuffer(GL_ARRAY_BUFFER,0) ' this helps reduce crashes

SetColor 255,0,0
DrawOval( 100, 100, 200, 200 )

SetColor 255,255,255

BTW, is the monkey miniB3D fully compatible with the BlitzMax version?

no. i've deviated from minib3d, but they are compatible with a couple of minor adjustments. since minib3d+monkey had to be multi-platform, this brought up a whole slew of restrictions.

visionastral(Posted 2012) [#105]
works for glfw, but not for android so far.

At least I can use the ChallengerGUI with OpenGL on windows, mac and linux with your hack. Thanks!

By the way, why is this happening anyway?
I mean, mojo is using opengl too (except in flash and xna) so why is this happening?

Xaron(Posted 2012) [#106]
Thanks Adam for your continuous work! :) Having the mojo 2d set would be great!

visionastral(Posted 2012) [#107]
I noticed something weird:
In your examples, this line is making the app crash 50% of the time:

txt.SetText(fps+" fps ~nhow are you",0,0)

I have noticed it's because of the "~n" new line character. If I delete it, then it never crashes.
That's very weird, specially because it doesn't crash every time, but only 50% of the times or so...
Perhaps it has something to do with the fps counter, I don't know.

- edit: By the way, I'm compiling for GLFW when this happens -

DruggedBunny(Posted 2012) [#108]
It's that time again...

Continued here!