Hi Guys,
Simple question, why does JME offer different versions of the engine (for Windows, OSX, Linux)?
What native code is written into the engine, and does thus mean I have to compile and ship different versions of my software, depending on the OS of my users?
Cheers,
Sam
There are some native libraries used (remember that OpenGL is C so at some point JME3 needs to wrap a C library). Also it offers different distribution etc options for each platform. For example windows offers a .exe launcher that checks java is installed etc.
So in other words yes, you need to offer different download packages…however the different packages are built for you by the SDK when you tick the option so it’s just a matter of uploading and linking to them all.
Wait… jme is portable, it extracts the needed natives on demand of the platoform on start. All natives are included with jme.
What the sdk or whatever else builds is another matter, but it is certainly possible to make a build that results in one application that works on linux windows and mac without further changes.
Stuff like the exe dummy for windows users (or more the exe for dummy windows users ^^) is of course platform specific, but it is optional, you can of course also just use java -cp * myapp.main on windows.
Just out of interest, what do you consider “portable”? For jme nothing has to be ported, its java code and existing binaries with only few platform-independent code which is available for most platforms. I think the porting work has already been done for you 
Fantastic guys - I figured as much. I haven’t touched the SDK so don’t know about that… I’m just building upon the JME engine which suits me better.
I checked that the whole library was in java, and saw that JME came packaged with native bindings for all the major platforms where it was appropriate - and hence I was curious as to why there were options for Windows, Mac, Linux on the downloads page.
I really recommend you give the SDK a try (even if you prefer to develop another way). There are a lot of good stuff in there that can help you or give you ideas. Like packaging launchers for the final game, trying out things in the scene composer, playing with the filter chain visualizer, seeing the contribution plug-ins and other goodies. Maybe you’ll even like it enough to actually code in it 
I had a very very quick look at the SDK, and it wasn’t for me unfortunately.
I’m not actually a building a game, but using JME as the 3d engine for some engineering/modelling tools I’m building for the renewable energy industry. It has to sit inside all the engineering code I’ve built (which makes up 90% of the codebase). it just made more sense to have JME as a linked library with more direct programatic access to my computational code. I dunno, do you know of any non-game sort of projects that have found value in the SDK?
1 Like
Well, 3d is 3d really. Things like importing models etc is made much easier by the SDK.
It’s certainly not a requirement but you may well find that the answer to quite a few of your questions is “use the SDK”.
If your existing development is netbeans based you might as well just put it all in the SDK (Which is netbeans under the hood after all). If it’s eclipse/whatever then I agree it is most likely not worth moving over…
However it is still worth having the SDK to use for converting models, checking out ideas, looking at the test cases, etc.
@zarch said:
However it is still worth having the SDK to use for converting models, checking out ideas, looking at the test cases, etc.
this ...........and I use eclipse mainly
Exactly thats the point <3
Game development is a different kind of horse, 90% of your standard IDE tools won’t help you much with that. Editing particles, tweaking filters, adapting materials etc. All that has to be done visually and exactly because I saw every large jME2 project do these tools for themselves time and again I decided they should have a place in one central application.
Then ofc. theres the other more IDE-ish things that are special with games like asset handling and deployment which also caused major headaches in about every jME2 project. Tackling this one requires having a standard project format. Perfect fit for a complete IDE as an SDK for the engine…
As stated in the manual, its probably best to use a SDK-created project, this way you’ll also be able to enjoy the work thats being put in “around” the engine (deployment to Android and iOS in the future, managing of assets etc).
1 Like