jMiniB3D (MiniB3D for Java)

BlitzMax Forums/MiniB3D Module/jMiniB3D (MiniB3D for Java)

ima747(Posted 2011) [#1]
As mentioned in the aMiniB3D thread, I've started porting aMiniB3D to standard Java using JOGL. So far it seems to be on par with aMiniB3D and the conversion process is quite smooth, so it should be very easy to maintain it as a derivative of aMiniB3D. By extension adding features to aMiniB3D to bring it in line with the official iMiniB3D should be easy to then continue on to jMiniB3D, or vice versa. The biggest differences between "j" and "a" are:
Android uses an OpenGL view within the standard view structure, Java uses a JOGL GLCanvas event handler extension. This allows it to run inside a frame for a Java application, or within an Applet display. Should work inside other Java display control top levels as well like JApplet...
Texture has had to be renamed MiniTexture in "j" to prevent a name conflict with the JOGL Texture class.
Since Android runs on GLES (being mobile) and JOGL runs on desktop OpenGL, the GL type has been changed from GL11 on android (which is OpenGL ES 1.1) to just GL (which is OpenGL 1.x). GLES 1.1 is basically equivalent to OpenGL 1.5 so there are no expected short falls in future.

Nothing has been implemented in j that is NOT implemented in a. This means j is still bound by the very limited feature set I need, and as such would love some community attention if anyone is interested to bring it up to par with the official releases. Basically it needs more stuff like mesh loading, lights, etc. to be ported from C++ in iMiniB3D to Java.

I've currently got it working in applet and application form. Haven't done speed tests but it seems perfectly fine in my poking. Have not gotten to the picking implementation yet, but that's next on my list.

As with aMiniB3D if anyone would like to toy with it or have a go at adding some more functionality just let me know, I would love to see it move beyond my currently limited needs. Ultimately if it were flushed out MiniB3D would be a very simple 3D engine for any platform (Mac/Win/Linux via Bmax, Mac/Win/Linux/Other via jMiniB3D Applications, iOS via iMiniB3D, Android via aMiniB3D, and web embeddable via jMiniB3D Applet) which should make it relatively easy to take a project anywhere you want to go...


jkrankie(Posted 2011) [#2]
sounds cool!


Yasha(Posted 2011) [#3]
Hmm, sounds like a good time to jump in...

A few weeks ago I decided to try porting miniB3D to C# (going from the BlitzMax version, not iMiniB3D). 95% of the port was complete, but I got stuck on the OpenGL bits as I don't know the first thing about OpenGL (kinda hoped I could just copy the commands "in place" and have them just work with the changed language. Well, that failed!). All of the non-graphical stuff was ported successfully though, so great news for anyone needing a 3D engine for a text-based game I guess. (It compiled happily enough, but wouldn't draw anything to screen. This is probably because I tried to use OpenTK - which is practically a game engine in its own right - as the GL base rather than something more basic like Tao Framework.)

Anyway I thought I should mention this in case it's in any way helpful to you to know that large tracts of another C-like-syntax version exist, and that they're much more similar to Java than iMiniB3D. I would be delighted to share everything I've got so far if it can be of use to you.

EDIT: In fact, let's be honest - most of the "work" was just running miniB3D through this Code Archives entry, which is in fact what I wrote that little converter for, and then correcting the (thousands of) minor syntax errors detected by Visual Studio. The result is BlitzMax code with C# syntax, but it reduced the workload considerably to not have to replace every End Method with } by hand. On the flipside, that also means nothing's been changed structurally to take advantage of the more advanced language, and it's almost line-for-line identical to the Max version. Still divided into the same files for the most part and so on.

EDIT2: I've actually changed tack altogether and am converting the C# code to a mixture of Vala and C99, which I expect will be a lot more useful in general (and probably more cross-platform than C# in most of the ways that matter). Going to actually rewrite slowly too so it's more optimised where possible.

Last edited 2011


ima747(Posted 2011) [#4]
Yasha: Very interesting, hope you can keep moving that forwards!

I'm by no means an openGL expert either but if you get exposed openGL access you can go error by error and figure out what it's supposed to do and how to match it to the language's library. Porting the opengl from C++ (iminib3d) to Java for Android was pretty much copy/paste followed by getting the syntax to play nice. The biggest problem was the math optimizations using operator overloads that Java doesn't support. The openGL struggles were almost all converting from C buffers to Java buffers that do the same thing. The picking code was a struggle because of the broken GLU implementation with Android, but porting it JOGL was a snap (just had to flip the vertical input for the display anchor).

Project Update:
Everything that works on aMiniB3D works on jMiniB3d. Picking, textures, etc. again, nothing new has been added so it's still an incomplete implementation (no lighting for example...) but what's there seems to work great.

It can run as an application or an applet, tested on Mac and windows (even under parallels where the opengl is sketchy...). There is a snag with applets I'm trying to figure out. It's not a miniB3d, but rather a JOGL thing. There are security permission headaches with JOGL applets related to the JOGL jars being signed when properly referenced and mixing that with an unsigned applet (so there's no security warnings) or even with a self signed applet (and dealing with security warnings). Trying to figure out how to properly implement it. I believe the solution is to build JOGL and all it's natives and then compile off of that, and link to the local copies so everything is unsigned, however I can't get it to build. I have a web distributable bundle but its not the same as the one I've been building with (I think it's JOGL 2 based, and therefore openGL 2, and therefore not compatible) so I can't use it either. This is where my inexperience with Java comes a hassle.

But again, that's a Java applet thing, and not a functionality thing.


Leto(Posted 2011) [#5]
I haven't dropped by the forums for some time but am impressed to see you still working on this stuff, ima747. Do you have the code in an SCM online someplace for others to grab and work on?


ima747(Posted 2011) [#6]
Not posted anywhere but contact me through email and I'll be happy to send over what I've got (adam just requested aMiniB3D last night...). Would love to see it all keep moving forwards, wish I had the time to make it happen :0)


Leon Drake(Posted 2011) [#7]
now that is cool!


ICECAP(Posted 2011) [#8]
I'll definatly be interested when this is near to being finished! :D