Yes, this does not explain what a pivot node is. Maybe there should be a next page explaining that.
Users will notice more artifacts than just rotation - for example when putting a Jaime monkey on the guiNode, it will look broken due to some problems with 3D models on guiNode.
Yes!!! 
How much? Full iOS support for jME and any .jar?
I’ll be making a post about such “exotic platforms” (I’m interested in a PS4-Monkey too).
Currently that’s what worries me most - not getting my game to other than desktop and Android.
Fantastic work, man
I added the shop and many type of “characters” for Karma Siege:
https://s10.postimg.org/dhhpqa27d/Screenshot_2016_08_24_23_53_18.png
Hope i can push the update on Play Store tomorrow.
what GUI do you use for Android?
So I finally got compound glyphs working. For the uninitiated some glyphs are actually a combination of two or more glyphs, usually these are accented characters, and in the font file it just gives you a reference to the other glyphs being used and some information on how to scale/rotate/position them in relation to each other.
While positioning them was no big deal, scaling, skewing and rotating was a little confusing since the documentation wasn’t terribly descriptive about the format the information was stored in. You might get a single short for the x/y axis, one for each or a two by two matrix. The docs from apple simply said “The numbers stored as shorts are treated as signed fixed binary point numbers with one bit to the left of the binary point and 14 to the right.” While the docs on Microsoft’s website stated “If the bit WE_HAVE_A_SCALE is set, the scale value is read in 2.14 format-the value can be between -2 to almost +2.”
So I looked up 2.14 format and came up with something called Fixed Point Maths which is a method to describe real numbers, floating point, using only integer values, however, this turned out to be a dead end. My next thought was, well maybe they’re simply storing the integral part in the first two bits of the 16 bit short, one bit for sign and then the integral part could be either 0 or 1 which fits in with Microsoft’s description. So I used some bitwise operations and bit shifting to part out the first two and last 14 bits then combine them with a decimal point in between, but unfortunately this was also a dead end.
At this point I was starting to think maybe there was a bug in Sfntly, I have enountered one elsewhere in Sfntly, and perhaps it was just reading the wrong data from the file, maybe the offset was off by a bit or two. I went through Sfntly and compared it to the docs and everything seemed to be lined up correctly. Although I did find the following in Sfntly:
/**
* Reads the F2DOT14 at the given index.
*
* @param index index into the font data
* @return the F2DOT14
* @throws IndexOutOfBoundsException if index is outside the FontData's range
*/
public BigDecimal readF2Dot14(int index) {
throw new UnsupportedOperationException();
}
After doing a bunch more searching I found a single Wikipedia article about a format called Q, that’s right just Q, which is a fixed point format for storing floating point values on systems that don’t support floating point. Apparently I just needed to multiply the stored short by 2^-14. I feel like the docs could’ve just mentioned that haha. 
P.S. I downloaded a free font creator called FontForge so I could make that sweet looking piece of awesomeness you see on the screen just to test compound glyphs.
First I have to state that this is the awesome work of @normen and others because it used to work in 3.0
All I did was making Avian build again and fixing a few problems in the native code.
In theory we have plenty of all java classes, but it could happen that e.g. java.net isn’t available.
So your internal software will run 100%, it’s only the bindings.
This brings me to jme: The Interface for openGLES isn’t quite complete, so it could be that advanced features don’t behave like they should.
It’s nothing unfixable, but it has to be done.
Forget about that. The reason is that the PS4 is a whole own architecture.
While in theory you could simply compile the openJDK’s jre and adopt avian for another architecture, trouble starts that you can’t use gcc for that. You might not even have a compiler for their CPU.
Using openGL is even harder there. On iOS it’s simply something like #include <openGL.h>, but if the PS4 even supports openGL?
The only way would be a complete rewrite of jme in c++? and then running it using the PS4’s expensive SDK.
The good thing is that you can actually simply refactor your code to, say Unity, without much hassle since the important stuff is the logic you do in your update routines.
If you’d really need PS4 and XBox One, then I’d not use JME. On the other hand, you can’t simply release a PS4 game. You need some publisher and whatnot which means many contracts and business trouble, they get most of the cash you’d earn. IF that really bothers you, you can make an awesome game in JME and when the time comes, add a PS4 version afterwards.
Though, maintaining a PS4 game might be a nightmare, if you’re alone.
Well, I’ve read they opened for indie devs in 2013/2014. Just like XBox allows that now.
The old PS3 used OpenGL but I don’t know about the new one.
In theory all I really need is a LWJGL binding and a JVM for their platform and perhaps a little starter written in C++.
Since both consoles PS4 and XBoxOne use a modern standard PC architecture hardware-wise it seems doable.
Don’t know about the price of a PS4 Devkit, but have read they sometimes give them away for free. Maybe even a standard PS4 can be used as Devkit now?
The same i use for PC. I built it from scratch,it doesn’t even have a name yet.
Steam console mounts SteamOS as far as i know,and that’s simply a linux distro. I don’t think we’ll have so many issues porting JME to that 
Maybe we don’t have even have to work on it.
Yes, I meant that.
It is based on Debian 8 and let you have access to console and can install Java and run JME.
Unlike PS4 which do not give access to console, so you can not install Java and no JME.
Few months ago some guys hacked PS4 due to a bug and could bring Linux up with full access to bash. And installed a game from 2000 on it.
I wish I could tell them to test my JME App on it 
but if you guys are aware of trend, the number of PC gamers are growing more than console gamers . And it can be a good news for JME developers
Some progress on the interface. Quests now work through these window boxes that represent the current goal. Oh and I made a few hardcoded variations of spacestation configurations since I can’t get it to work procedurally yet. Some texts need some vertical allignment fixing but that’ll be taken care of shortly.
So the current way which puts the quest status icon in the middle of the description box doesn’t look good to me and I’m looking at some alternatives.
So which one do you guys think would be the best combo of looks/efficiency/leastannoyance? I’m open to other suggestions too. 
Option 1:
Option 2:
Option 3:
0 voters
FYI these are the icons I’ll be using for the quest status indicator:
Regular tracking.
Active quest, shows markers.
Quest finished, click to delete quest.
They’re from Google’s open source material design icon pack. These are also the ones I’m using for all other icons on the HUD. Under the Apache licence.
Hi. The marker for “Active quest” looks strange too me. I know it should be an exclamation mark, but it looks different because my mind tries to combine it with the little dot above which has roughly the same size. Maybe use some other symbol or use an exclamation mark that begins thick at the top and goes thinner to the bottom. Maybe use three exclamation marks side-by-side could work too.
Any better?
This is klingon-ish.
Not much. Maybe use a trapezoid instead of a triangle? Don’t know.
I can’t tell what it should look like or what others will like to see.
I just tell you what looks odd to me - which is the easiest job in the world! :chimpanzee_closedlaugh:
Hi want a pamphlet! 
