The key is to use sizes without scaling… but yeah, it’s a pain. But alternatives have their trade-offs, too.
1 Like
You are definatly right about the scaling. But in my experience depending on the position of a label on the screen sometimes the text is just blurry.
I mean… Lemur is really good. I use it. I have no problem with it, but there is JavaFx… It comes with an editor and everything. I like both equally - and make my own controls too (like shader progress bars, shader minimaps, etc). I just use whichever makes the most sense to me.
It’s not exactly the same, but there is an awesome ttf alternative called jme-ttf that might work for you. jttf
1 Like
You’re right; increasing the number of active users would likely help me get what I want.
Rebuilding the community will take time. Software, assets, and documentation can help with this, as can publicity. But I believe the key is how we treat newcomers and each other: ideally, with courtesy, respect, and meaningful praise.
6 Likes
I have a laundry list of things… But to keep it short, this is what I want most 
- A whole new network serialization system (It would fix so many things)
- A bunch more PBR shaders, and better documentation on how to use them. The PBR we have now is a great start, but it would be awesome if we had more in the wiki on how to use them, and if we had more shaders
- The entire source of JME to get a massive formatting overhaul with the netbeans formatter.
2 Likes
I bet this is what happens to many new users
- Get the engine
- Want to import a model
- See that there are 900 importers
- Pick one random
- The model doesn’t import properly
- ??? ¿¿¿
- Change engine.
8 Likes
I think one of the biggest problems with jmonkey is its lack of cohesion. It’s great that things like zay-es and minie can be updated more frequently than the current release schedule, but at the same time it also means there isn’t anything unifying the engine together either. It makes it hard to have a complete story of starting a game → finishing a game. I mean for spoxel it felt like I had to spend several years making a game engine before I was able to actually even start the game itself. Ultimately it left me with the impression that jmonkey is more to tinker around than to actually make a game. I mean there is what… 5 different gui libs at the moment all with a variety of strengths and drawbacks? It makes it pretty daunting to a new user when you evaluate jmonkey. I think this is mostly because there doesn’t feel like there has been some sort of unifying vision for where jmonkey should go for a long time now. So my list off the top of my head…
- A project / program manager
- Some sort of vision / plan for refactoring the graphics system to prepare for stuff like vulcan / metal / other. This leads into better multiplatform support long term. There is a lot of business on console that you pretty much can’t go after using jmonkey at the moment.
- The SDK was pretty hard to work with over the life of Spoxel. This is especially true due to its poor gradle support. Since we are expected to include different plugins to make jme usuable it makes it especially hard. Frankly, I was hoping jmb would get more traction so we could decouple the ide from building jme assets.
- There is a lot of boilerplate code required to start a new project. This could be as easy as better default project generation.
- The existing particle system needs some serious work
- There isn’t a great story for how to handle different resolutions / screen sizes / scaling for gui controls at the moment.
4 Likes
seems this will be one of popular topics. this is not a topic about future of jme trully, but seems it go this way.
JME is very elastic, i think this is good, not bad. but i agree, it need some plans for future. Also agree its hard for new developers. (but if someone like Java and see JME is great, will learn anyway) We also already know some future plans, like using gltf as default import format.
Some people use android, some not.
Some people use lemur, others Nifty, others FX, etc.
Some people use still jBullet, other native bullet, other Minie.
Some people use externals libs that might be broken with future JME releases.
Some people use gltf exporter, but there are still people using ogre and etc.
… etc
this elastic system is power of opensource engine, not disadvantage.
But lets see we dont have 30 or more paid developers to fix all issues or add new that need to be added for each importer for example.
so we should think about dropping some of this parts to make maintenance lower. so single people can manage this. But only if there will be no protests.
because i think everyone know “more code = more complexity = more work areas = work time logarythmic increase”
Simple example would be “add X to importers” and now we have “99” importers to make this change and would need to be different for each importer
so i would like just suggest creating other topic type each month, like for WIP, just for discuss about some JME parts / future / suggestions to help with experience that everybody can share with something. This could also help people like @jayfella to find idea how to help next.
Based on what i said here, i would also add then:
- more engine future plans discussions for each area
2 Likes
Some good ideas accumulating here now. I guess my own tentative side project to-do list looks something like this, depending on interest (mine/others) and other factors:
- Contribute additional physics (or other) tests
- Learn more about the various physics lib dependencies, build nuances, bugs…
- Look for a way to improve JavaFX/JME interaction and event handling, if possible
- Maybe a JavaFX project starter/generator like LibGDX has (IIRC Nehon worked on something like this but not sure of final state?)
- Out of curiosity, experiment with comparing performance differences between JBullet and native Bullet/Minie (assuming I don’t find that someone has already done this?)
- Bugfixes or janitor monkey (code cleanup) stuff, general help where needed
Hmm, a “what’s on your todo list” could be its own thread huh… 
2 Likes
1 Like
Since I use Zay-ES, lemur, dyn4j, feather, libgdx-ai I don’t need a lot of boilerplates any more. I also us the SDK a lot and still like it.
It’s java and even when u use spring boot or similar you also have to collect ur libs and stuff.
My wish list would be
- better support for assets in SDK with gradle (I have to workaround that with a basic game to import blender stuff, which btw works just great for me)
- better/easier shader support like shadows for multiple lights, but here I guess even in unity you might have to write your own shaders when it comes to polishing
- more small examples for Zay-ES stuff (I think I will just add/document more „patterns“ to my blog and contribute that way)
- I would love to see support for nintendo switch, x-box, playstation, …
- EDIT: and of course steam support, actually I may provide samples for this, but I did only scratch the surface of it.
But I’m actually pretty fine what is there and as I said it is the way of java to have a lot of libs and gradle does a really good job on that
2 Likes
The bitmapfont don’t have any issue (well… almost none). It’s up to your 2D team to provide cool looking font assets (this apply to any engine).
Instead I want a 2d fx editor (particles, animation etc) that is:
- integrates with the engine
- professional and for professional use
With Jme, I currently have to pink one of the two. With other engines, I can have both.
JavaFX is cool but I don’t think it fits.
If the blurriness is due to issue 358 then it should be easy to work around.
Note: there is a section for stuff like this in the Zay-ES wiki if you ever feel up to contributing there.
1 Like
I started to do this back in January. Here’s how it went: Physics-library performance comparison
2 Likes
Missed that, thanks! Very interesting, bookmarked for later reading. 
1 Like