It’s gone quite in here… is this still progressing? I have an iOS project coming up… would love to use JME for it, but I guess this isn’t ready for prime time yet?
1 Like
@monkeychops said: It's gone quite in here... is this still progressing? I have an iOS project coming up... would love to use JME for it, but I guess this isn't ready for prime time yet?
It mostly is done, the input is working in master, theres only a few issues left with crashes when using certain assets. The input system will most probably be added with the next jme update.
Will a mac be required to compile mobile applications for IOS?
@normen :
It mostly is done, the input is working in master, theres only a few issues left with crashes when using certain assets. The input system will most probably be added with the next jme update.Do you think the input system will be added with a 3.0.x or a 3.1.x update?
@BigBob :
Will a mac be required to compile mobile applications for IOS?Yes, you need a mac. Have you found this page? https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:ios?s[]=ios
@Vortex said: @normen :Do you think the input system will be added with a 3.0.x or a 3.1.x update?
The next update, isn’t that specific enough?
This guy is offering a (seemingly) working iOS build chain for PC now: http://www.pmbaty.com/iosbuildenv/
I haven’t had a chance to look into it properly but would be cool if this works… he only asks €30 for it, which is a whole lot cheaper than a Mac - and for stuff like this I think a small fee is probably better than free, as he’ll have an incentive to maintain it as Apple are sure to break it every few weeks 
@normen said: It mostly is done, the input is working in master, theres only a few issues left with crashes when using certain assets. The input system will most probably be added with the next jme update.
So we should be expecting to have some iOS apps up and running soon? Awesome!
What else besides input is left?
When do you think the “next update” will be, time wise?
Thanks for everything everyone!
@KonradZuse said: So we should be expecting to have some iOS apps up and running soon? Awesome!What else besides input is left?
When do you think the “next update” will be, time wise?
Thanks for everything everyone!
Its out already, iOS works with input now.
@normen said: Its out already, iOS works with input now.
oh… Awesome… so what else is left, or what else could there be “improvements” on? I have been looking at other java iOS ports just to see how it all is going, but I rather stick with JME and the port we have here, specifically not having to rewrite code for no reason :P.
If you think it’s good to go, then I will check out my app and see how it goes!
@KonradZuse said: oh... Awesome... so what else is left, or what else could there be "improvements" on? I have been looking at other java iOS ports just to see how it all is going, but I rather stick with JME and the port we have here, specifically not having to rewrite code for no reason :P.If you think it’s good to go, then I will check out my app and see how it goes!
The way this works is that you tell me what works and what doesn’t.
@normen said: The way this works is that you tell me what works and what doesn't.
Really? And then you’ll fix it asap? 
I guess you know much better what’s working and what doesn’t, so my humble experience is that input works fine:
I tried the default flyCam, AnalogListener and a TouchListener. All separate tests.
I just had to workaround that the events are consumed “somehow”: currently onAnalog() gets and consumes the event and onTouch() gets nothing.
So currently I disabled looking around in my game.
The adaptations to control my character would be harder, because the images don’t appear at the expected coordinates or off screen.
I guess this is an iOS renderer issue.
This will force me to do a trial and error investigation to place the images correctly and then write down the touch coordinates which seem to be different.
(For all other platforms I’m using nifty gui.)
Is it worth trying or will there be an update soon? Or am I doing something wrong?
@revv said: Really? And then you'll fix it asap? ;-)I guess you know much better what’s working and what doesn’t, so my humble experience is that input works fine:
I tried the default flyCam, AnalogListener and a TouchListener. All separate tests.I just had to workaround that the events are consumed “somehow”: currently onAnalog() gets and consumes the event and onTouch() gets nothing.
So currently I disabled looking around in my game.The adaptations to control my character would be harder, because the images don’t appear at the expected coordinates or off screen.
I guess this is an iOS renderer issue.This will force me to do a trial and error investigation to place the images correctly and then write down the touch coordinates which seem to be different.
(For all other platforms I’m using nifty gui.)Is it worth trying or will there be an update soon? Or am I doing something wrong?
How are you currently accounting for different resolutions?
@normen said: The way this works is that you tell me what works and what doesn't.
Seems legit… :P.
Will do Normen, I’ll find lots of bugs for you :).
@t0neg0d said: How are you currently accounting for different resolutions?
My game has no special code. I rely on nifty gui.
For my other tests, I start at (0, 0) which is at the bottom-left of the screen for com.jme3.ui.Picture.Picture.
@revv said: My game has no special code. I rely on nifty gui. For my other tests, I start at (0, 0) which is at the bottom-left of the screen for com.jme3.ui.Picture.Picture.
More importantly, how are you accounting for differences in width & height… there are several approaches, but at least one of them needs to be implemented to ensure that something that works at 1024 width will still display at 800 width.
The approaches I have had success with are:
screen size (dominate axis for determining scale)
texture image size
Both have there uses and can be used together in the same app depending on your needs.
@t0neg0d said: More importantly, how are you accounting for differences in width & height...
For the menu items I specify the percentages (e.g. width=25%, height=10%)
and for the HUD I use icons of fixed size and spacers / fillers (e.g. width=*).
But the menu fonts are currently invisible on iOS and don’t react. 
@revv said: For the menu items I specify the percentages (e.g. width=25%, height=10%) and for the HUD I use icons of fixed size and spacers / fillers (e.g. width=*).But the menu fonts are currently invisible on iOS and don’t react.
I haven’t had a chance to port anything to iOS yet, but how are you handling font scaling? I ended up using a method to measure the a line width and increase font size until the width matched my reference width. It’s a semi-expensive one-time process but once the scale is determined for the test string, it can be used to globally adjust all fonts to display properly.
When you say that the font is invisible, is it a render size issue? Or are they just not displaying?
@t0neg0d said: I haven't had a chance to port anything to iOS yet, but how are you handling font scaling? I ended up using a method to measure the a line width and increase font size until the width matched my reference width. It's a semi-expensive one-time process but once the scale is determined for the test string, it can be used to globally adjust all fonts to display properly.When you say that the font is invisible, is it a render size issue? Or are they just not displaying?
I simply don’t do font scaling. I think nifty does not try to scale the fonts.
On iOS no letters are visible. If I turn on setDebugOptionPanelColors() the items look misplaced, but I have to admit that I didn’t compare it side by side with the desktop version. I just wanted to be sure that I touch the hotspots, but it’s not reacting.
@t0neg0d said: How are you currently accounting for different resolutions?
Nifty has an option where you can set the “render resolution” and the “final resolution” so that your code “sees” say a 800x600 UI and the nifty renderer displays it at say 1024x768 on the screen.
1 Like
@normen said: Nifty has an option where you can set the "render resolution" and the "final resolution" so that your code "sees" say a 800x600 UI and the nifty renderer displays it at say 1024x768 on the screen.
Awesome… does this adjust font size for you as well? It probably does… I just hadn’t considered this until a recent project of mine.