aMiniB3D (MiniB3D for Android)
BlitzMax Forums/MiniB3D Module/aMiniB3D (MiniB3D for Android)
| ||
| This is just a sort of heads up/public query regarding getting MiniB3D running in Android. I've started porting iMiniB3D to and Android native Java version for a multi-platform project I've been working on for quite some time. The initial goal is to just get it up and running as minimally as possible for my needs (i.e. dropping a LOT of features) due to time constraints of my project and some goals I need to reach. However once that is accomplished I would (hopefully time permitting) like to revisit the engine and make it feature complete (on parity with iMiniB3D). A couple of bullet points: • It requires OpenGL ES 1.1 on Android. This means it is not compatible with the android simulator, you need a real device to run it, and the device's graphics chipset must be fully 1.1 compliant. OpenGL ES besides 1.0 and 2.0 on Android is a mess of fragmentation and partial implementations, but I don't have the openGL skill to back port from ES 1.1 (which is the base for iPhone) to 1.0 so I'm working with what I've got. Ultimately I think it would be great if either the 1.1 implementation could be back ported to 1.0 for better availability and easier testing through the simulator, OR alternatively if everything could be written under 2.0 for newer iOS and Android flavors just to tie things together... but that's a huge bucket of trouble all by itself. • I am targeting Android 2.2 for my project, currently developing under 2.1 however. I see no reason why the engine couldn't run on any android device provided it either a) has full ES 1.1 compliance or b) the engine gets back ported to ES 1.0 • I am lopping out HUGE swaths of the engine in this initial run. I really only need flat shaded quads with mip mapped textures and all of the position and rotation tools. However once it's up and running it shouldn't be too hard to add the missing things back in. • I am porting it to Android SDK java rather than C++ through the NDK for 3 reasons. First the NDK gets meshed through a java over layer anyway, so the implementation just gets cumbersome to use. I hate the android tools so getting the NDK working would just make me that much more annoyed. But most importantly following the Android implementation I would like to investigate getting MiniB3D running through JOGL, not because I like Java (I hate it) but because it could then theoretically be implemented through Applets, which would allows for relatively easy embedding in web apps... being able to write a program and with minimal porting be able to get it natively running on Mac/Win/Linux/iOS/Android/Web means MiniB3D becomes a great middleware solution for 3D, and unlike other middleware solutions with tons of platforms it's always raw native code, so you can leverage each platform uniquely. Why I'm posting this: • I'm very new to Android, and almost just as new to Java. If anyone has any experience with either I would love to get their input as I run across problems, native organization, etc. • I would love any feedback that may push my focus to/from features beyond what I need on a basic level. Once my features are implemented what are the highest priority for other people to be able to make use of a rough engine (animated meshes etc.) this is really down to each project what one uses or ignores, but if everyone screams "I can't use it without animated mesh support" then that obviously goes high on the list of things to implement. • Just gaging general interest. I know iMiniB3D has a smattering of heavy users compared to the BlitzBasic master version. I'm wondering if there's more/less/similar levels of interest in the Android version (i.e. beyond simply wanting to do it, and wanting to save Simon some time getting it going on Android, does anyone else see this as something they would use?) Finally where it's at so far: I spent about a week an a half porting the elements I think I need, in hacked to hell versions from C++ to Java until Eclipse stopped telling me I had syntax errors. Then I discovered the simulator has no 1.1 support, so I had to shop around for a development device which I got this morning (Using a Samsung Galaxy S from Sprint which they call the Epic 4G). I've silenced a few crashes from uninitialized lists, and am starting to work on getting a cube and a camera to play nice so there's something visible besides just the clear color. Thanks to iMiniB3D as a base and the overall syntax similarities between C++ and Java it's really just a matter of fixing 1 problem at a time until it works at this point. So there we are, looking forward to any feedback there may be. P.S. I pestered and tried to find a way to bribe Simon to do the Android port, but he's smart enough to let me dig my own hole ;0) also he has a life... Ultimately if I can get this in line with the iOS version hopefully I can hand it back to him for official upkeep, but if he's not interested and I can get it that far I will try to keep it in line with it's older brother in iMiniB3D which seems to be keeping in line with it's daddy MiniB3D... |
| ||
| Good luck with the project, keep us posted! while I am not as suicidal I do support it :-) |
| ||
| Glad to have the support and the confirmation of my insanity, atleast I'm sane about knowing how crazy I am... |
| ||
| Thank you for this. Looking forward to your progress. |
| ||
| First update: It lives (insert mad scientist laugh here)! Here's some terrible footage of a cube running MoveEntity and TurnEntity every frame... http://dl.dropbox.com/u/6768888/IMG_0072.MOV |
| ||
| Well that went well! Entity colors (probably vertex colors haven't played with them) ambient light coloration and *drum roll* textures now work! At this point I *think* all the major component besides camera projection that I need are in and aMiniB3D will take a back seat to my real project (time constraints and all...) so probably won't be any more info for a while unless you give me a poke for a status update. Again, if anyone is interested in taking a stab at moving the engine forwards just let me know. Last edited 2010 |
| ||
| I'd be interested a Max2D-style commandset for Android. :-? |
| ||
| xlsior: you could look into cocos2d, it's got an iOS and I believe Android variant, and I think it's based off of a desktop OS project... not the same (or as nice IMO) but at least it's a unified base... |
| ||
| Real update on android: CameraPick (for box collision) works... this means other picks and EntityVisible should work as well... this also means that the core of the whole collision system should, in theory, work... the collision system for meshes needs to be added back in and UpdateWorld and whatever voodoo lies under it need to be implemented but those are comparatively minor since the guts are all in place... There seems to be a bug with changing an entity's parent, it's matrix seems to jump a bit, but besides that everything implemented so far seems to be working! This is likely (besides bug fixes as I go) the last of the Android implementation until I have more time to flesh it out as it now implements everything I currently need. I really want to get it on par with iOS but it's a matter of time and obligations... Again the door is open if anyone else would like to help push the coffee drenched robot towards completion, just let me know! |
| ||
| This sounds great. |
| ||
| Turns out I was defaulting the global flag off instead of on when parenting... problem solved. Since it will likely be a while before I can get back to MiniB3D proper here's a status report: Entitys: work including parenting, movement, translation, rotation, etc. pivots: work meshes: work via create cube and create quad. lights: don't exist cameras: work however not all entity FX work properly currently everything is fullbright due to lack of lighting. Entity order however does work. textures: work, including "hack" (I've also implemented on iOS if anyone is interested) to allow for multithreaded loading. brushes: works surface: works collision: doesn't work however all the heavy stuff is translated so this *shoudl* be very easy to get running picking: works, including camera pick (very required on a touch screen...) Graphics: starting works (kinda has to to get anywhere...). Ending seems to leave stuff behind which on android can be a problem, working on this still. You can also override the sizes etc. later like you can on iOS to support changing orientations if that's how you want to do it. Touch (iOS specific): not implemented Accelerometer (iOS specific): not implemented Examples: haven't translated them yet (everything has been developed inside my work in progress app so it's ugly on the top layer. OS Specific stuff: Implemented a MiniB3DSurfaceView and associated MiniB3DRenderer. These comprise the visual elements you implement in your app to create the 3D space. Similar to the openGLView and GLViewController in iOS. They're set up to be extended for your given app, just override the existing methods and either tell them to call their super form for normal behavior or you can skip that and implement the engine calls however you see fit. An important thing to remember in android is that input doesn't happen on the same thread as drawing, so to handle input and not have multithreading issues explode in your face you have to either force your "action" to happen on the drawing thread, or setup a thread safe que of some sort to handle the input. Once the touch handler from iOS is implemented this will be a non issue as it will take care of the thread jumping as well, but as it stands what I do is have input events create an action on the draw thread that then adds the event to a que to process when I'm actually in the draw cycle (this keeps the program layout the same as on iOS for me). |
| ||
| Not to sound negative as this seems like a nice project. But I really think you should find a way to port the existing codebase to the NDK. Simon has hinted at wanting to provide the ability to use MacOS support to iminiB3D as well. A solid c++ middle ware is very portable. With a few platform definitions you can support a heap of different devices and platforms. In fact besides the textures I believe the only other major difference is how to create the OpenGL context. If this is the case and we can stream line this, you would only be updating one code base for every platform rather than simon releasing a 0.5 and a 0.52 revision, and then having to update the java version accordingly. Maybe Im crazy... just thinking about porting over my latest iphone game to android, and having to convert EVERYTHING ive done in c++ to java seems scary. Last edited 2010 |
| ||
| Using the NDK was my initial plan, but I abandoned it very quickly for the following reasons: A java code base means that it is not architecture dependent. so x86 or arm based Android devices will work without having to re-compile. A java code base means that it can theoretically be adapted for desktop java, and more interestingly, java applets for web embedding. The NDK is terrible. It's an absolute nightmare to work with, and has virtually no documentation, on top of the already horrid Android documentation... An extension of this is you have to manually run a build script to compile your NDK code, and then build and deploy a java over layer to control it. To use the NDK you have to heavily modify any entry point functions to be JRE compliant. This basically means renaming lots and lots of stuff. You can't access C++ objects from java, meaning it would have to be written with non OO access (like bmax has, but iMiniB3D doesn't), OR you would have to create all the objects in Java anyway... It also makes debugging very very difficult, and I'm already not a fan of the Java debugger and logging systems... To break that all down, I found it was actually easier to re-write the whole thing in a language I had never used before on a platform I had never used before rather than use the NDK... sorta speaks to how not-so-great the NDK is IMO. I'm sure someone with extensive android and NDK experience could do much better, but even then there are some significant advantages to sticking with pure Java (you're going to have to mix on some level, just like you have to mix Obj C in on iOS...) Basically NDK is really designed for 2 things. Strait ports of an entire project written in C/C++ that doesn't require too much from the OS's library (native UI for example...), not modules/libs/etc. OR highly optimized code snippets that will be discreetly called, such as very math heavy functions. If/When someone ports MiniB3D to a platform independent C/C++ code base I would HIGHLY recommend keeping it C/C++ and starting with iMiniB3D. Just create an OS Specific context and texture loading mechanism (Texture2D.m/.h), trim out the Obj C dependencies for iOS and you're basically set. However Android is a mess IMO, and Java is really the only viable way to make something OO that can be built on top of. Additionally something web embedded is going to be my next target platform going through Java *should* make converting to Applet form comparatively easy... Regarding actual progress, the engine is running very fast and stably on Android with the limited feature set on compatible hardware. I have a hardware partner (damn NDAs!) putting my actual project through it's paces on multiple devices and the only problems they're hitting are from memory overloading by feeding it too many textures at once (garbage collection, multithreading and very limited resources don't mix...) which we're working out with some throttling. The biggest headache is that MiniB3D is targeted at OpenGL ES 1.1, which is not officially fully supported in Android... 1.0 is, and 2.0 is on newer OS revisions, but 1.1 is up to the manufacturer. Some devices have partial 1.1 support, some have none, some have none or partial despite having 2.0 support... it messy, and I don't have the OpenGL experience to be able to drop it down to 1.0 or re-write the whole thing for 2.0. Not sure how far the compatibility will go but in theory any mid/high range device should work (anything with a snapdragon, hummingbird, etc. type board will have a 3D chip that's 1.1 compliant). I've tagged the manifest as requiring opengl es 1.1 but again because support is spotty some devices with partial might claim to work when they won't... Last edited 2010 |
| ||
| Why no lights opengl es 1.1 has them |
| ||
| Because I haven't ported the code yet :0) The engine *will* work 100%, but I don't have the time at the moment to port anything beyond the features I need for my current project. |
| ||
| Looking forward to this :) Jason |
| ||
| Any news on this one? |
| ||
| Still running strong in my project (tested on a Galaxy S phone, a Galaxy tablet, a droid X and the prototype microvision Arrow) but have not had time to push minib3d past my requirements. If there's interest in it as is for further development etc. I'll bundle something up to play with, but if people would rather wait for something more practical it will be some time before I can get back to it I'm afraid. |
| ||
| Hello, I may be interested in this in upcoming months. Is this a public domain project or are you looking for monetary compensation? If it's public domain, I'd like to help. Let me know. If it's monetary compensation, I may still be interested. |
| ||
| Public, but currently unpublished (2 startups, my own work and getting married... Need to figure out how to manufacture time... But that takes time...). Contact me directly if you'd like to play with it, contributions would be much appreciated. The project this is built for (limited functional requirements as noted above) is going strong, it works on everything I can get my hands on that supports ES 1.1 such as galaxy s phone and tablet, droid x, xoom, etc. and runs well for my (again very limited) needs. I have no doubts with time and interest the full engine could be made available. My current focus related to this is actually porting what I have to java in applet form for web embeddable minib3d... Just starting this and I still hate java with a passion so no real details besides it should be possible and I'm mandated to try... If all goes well it would be pretty great though :0) |
| ||
| Just a little update to the above post: I've started a java (JOGL based) port of the aMiniB3D framework. So far so good in that it can render and run. My inexperience with java in general let alone applet and application build structures is the biggest hindrance at the moment, but from what I'm seeing and what I've read it should slide into a web page quite smoothly once I get my head around how. |
| ||
| Been a while, but continued work on my projects means continued work on aMiniB3D from time to time... Newest update: * Fixed a bug relating to entity orders, you can now set entityorder and it will draw as expected * Implemented ScaleMesh,FitMesh,MeshHeigh,MeshWidth,MeshDepth and possibly some other mesh manipulation stuff... copy mesh should be easy to extrapolate from the new code but I haven't done it yet. * a few tweaks to the camera to trim comment out a few things that currently aren't used since sprites aren't implemented (this was just a side effect from fixing the entity order problem. but since the code is still in place, and runs faster commented out...) If anyone wants to play with/work on the current build, as always, just send me an email. |
| ||
| Just to tell you i'm really interested in your porting. Are there any news? |
| ||
| A few little tweaks and corrections since the last post, but no more features added as I don't really have time to focus on it. As always send me an email if anyone is interested in picking it up. |
| ||
| Is this still in development :< |
| ||
| Appears not, which is a real pitty I think, especially cos there's definitely a (growing)market for it. |
| ||
| If you are interested in getting miniB3D on android, ouya, ios, html5, flash, xbox, and pc: http://monkeycoder.co.nz/Community/posts.php?topic=6206 one code, all targets! |
| ||
| Yeah thanks, discovered that, to my shame, after my posted here. Fantastic if it's working. For it to be useable for me, some things from the To Do list need to be finisher first: - bones to quat/matrix internals - glow shaders, shadows - physics - terrain So I keep my fingers x-ed and eagerly wait(this would actually make me buy Monkey). |
| ||
| it works. and those other things everyone else is waiting for as well. |
| ||
| That would be major league cool Adam! Can hardly wait. |
   |