Hi all,
today was submitted support for “real”(realtime visual) renderer on iOS. As this is first public release lots of features might not work and some might be buggy. VBO’s definitely broken now and textures are in RGBA format.
Example screen:
Project configured for XCode 5 and iOS.
Also Sound and Input on iOS still unexplored.
Regards,
Kostyantyn
Already thanks! Keep up the good work! =D
For a little bit of background, Kostyantyn here sent us a mail a few days ago about how he had made great progress with what @normen started a year ago. After some quick back and forth we found that Kostyantyn’s approach was very much in line with the “jME vision” for iOS export. This is basically the missing piece of the puzzle.
So, sound the apple fanboy trumpets and let’s get some eyes on this code!
https://code.google.com/p/jmonkeyengine/source/browse/#svn%2Ftrunk%2Fengine%2Fsrc%2Fios
https://code.google.com/p/jmonkeyengine/source/detail?r=11033
https://code.google.com/p/jmonkeyengine/source/detail?r=11034
https://code.google.com/p/jmonkeyplatform-contributions/source/detail?r=1332
Note that the “other half” of the code is currently here: https://code.google.com/p/jmonkeyplatform-contributions/source/detail?r=1332
Great work Kostyantyn! This renderer is actually a great base for using avian or a similar technology for other platforms like PS3/4, XBOX, PS Vita etc. in the future.
Enabled VBO’s though some demos crashes, might be related to terrain.
So I tried out the VBO option on an iPad 3 and it seems to basically work 
But no matter if its enabled or not, rendering apparently results in only one of the GPUs of the retina display being used, I only see things rendered in the bottom left part of the screen, I guess this is an initialization issue that can be solved in the XCode project. This is (was) also true for the simple unshaded box example, I just didn’t realize because its just a blue square 
I also had to extend the avian compiler with some com.sun classes that I left out because of license issues earlier, they were needed to load xml files. Added that to the contrib repo.
j3o loading is completely broken atm, the app crashes with a hard memory fault when trying to load j3o files 
awesome! cheers for the hard work and contribution
Will it be possible to code in the JME SDK? Or we should move to XCode IDE for IOS?
@mifth said: Will it be possible to code in the JME SDK? Or we should move to XCode IDE for IOS?
You write your jme app like normal in the SDK and similar to android theres a separate project that builds the executable for the actual platform. That project is an XCode project so you can deploy to a device or the app store.
@mifth said: Will it be possible to code in the JME SDK?
Of course and that’s main idea behind jME - write once play, play everywhere.
@mifth said: Or we should move to XCode IDE for IOS?jME3 SDK only generates code related to core features - graphics, sound and event handling, which should be the same on all platforms. But to deploy on iOS platform you still need to compile it via apple provided IDE. And this has few advantages, so you can extend app with Game Centre Support(Achievements, Leader Boards, Players, etc), In-App Purchasement, statistics, etc
Same logic is behind Android part too. So you can extend your project with additional features available only on this platform or provided by some library, etc
Wee, we fixed the problem with the scaling, I now have a full screen, fully lighted Sinbad (Lighting.j3md) at 15fps 
You all are so cool.
Seriously…
Added an audio renderer based on Eric’s new native android OpenAL renderer. The gunshot example works great
It still needs a bit of cleanup, the classes are still named AndroidAudioRenderer etc… We’ll have to unify these native renderers in the future, at the moment the iOS audio renderer is basically just a copy of the native android renderer.
(@iwgeric) I changed the native code to plain C instead of C++ and removed the android logging code (see here), maybe we can make a unified native openal renderer from this somehow.
HOLY FREAKIN SH** !! This is so awesome guys! Good job!!! I’ve been busy but when I saw that I nearly fell off of my chair 
Quick status update:
Another update:
@Kostya: Not even the “debug” compiled avian gave more clues about the j3o issue, apart from that the crash happened earlier. This made me think it might be a race condition style issue where the renderer tries to update while the app isn’t fully initialized yet because the j3o takes longer to load? Like maybe appRender is called again when the engine is not yet through the initialization or something, I’ll experiment with that.
I tested some of my apps on an iOS device and it works already quite good, but I have one question after reading https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:ios#creating_native_and_java_code_for_ios :
Can I create some native code which constantly passes the sensor values to the JME application via some interface, so that I can rotate for example the JMECamera ? I dont get the concept how the native iOS code and the Java code can work together. Thanks in advance 
Wow… this is really cool. I really did not think we would see JME working on iOS so soon. This is amazing work
@simon.heinen said: I tested some of my apps on an iOS device and it works already quite good, but I have one question after reading https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:ios#creating_native_and_java_code_for_ios :Can I create some native code which constantly passes the sensor values to the JME application via some interface, so that I can rotate for example the JMECamera ? I dont get the concept how the native iOS code and the Java code can work together. Thanks in advance
The XCode project already calls the application harness, you just need to look at the existing code. Remember to enqueue calls that modify the scene though.
@normen said: The XCode project already calls the application harness, you just need to look at the existing code. Remember to enqueue calls that modify the scene though.
Ok thanks, that sounds good, I will take a look at it