@ItsMike54, did you have any specific 2D tutorial in mind?
@ndebruyn, along the lines of these: maybe how to properly position the camera so the 3D objects look two dimensional? Because iirc you can’t put everything in the guiNode. Also maybe how to use physics as well in a 2D environment?
1 Like
The guiNode has no perspective and scales z to 0 at rendering time. I cannot really be used for 3D objects.
…but placing a camera some distance away from 3D objects is pretty straight forward.
Thats what I said
Mmm… I misread “can’t” as “can”.
Easiest way to use physics in a 2D environment is to use a 2D physics engine like dyn4j.
Yeah, I’m wondering how one would do that, because I don’t think dyn4j is built to be used with jME like Minie is for example.
@ItsMike54, I am putting together a little tutorial of how one can make 2D games in jME3.
I might provide a light weight library on the Software store for anyone to use.
5 Likes
Awesome! I’d love to see it on asset store.
You can check out my game here: GitHub - assofohdz/Subspace-Infinity: A spiritual and technical successor the infamous 2d space mmo Subspace if you want to see dyn4j in “action”
3 Likes
Swing in JME3 Window 
Rendering Swing is done to a BufferedImage, which is copied to Jme3 texture.
Input is handled with jme input system and events are dispatched with Component.dispatchEvent function.
All rendering is done on Jme3 Thread.
20 Likes
@The_Leo Awesome.
1 Like
Swing gui 2.0, powered by jME, awesome 
1 Like
That is awesome.
Do combo boxes and context menus work?
Would you mind sharing the code?
EDIT: I wonder if this could solve the problem for the jme startup app settings breaking the render thread on linux?
2 Likes
My understanding: If you use Swing then there will be an AWT thread. If there is an AWT thread then GLFW will be unhappy.
…it matters not what you do with the image that Swing renders or when you render it. (In fact, rendering Swing components from a separate thread may have unpredictable results if any AWT events are ever let fly.)
2 Likes
Oh, this is a glfw not lwjgl issue?
Edit: Strange since glfw is simply a wrapper over native window systems and I think awt is too, of course with gui but still?
Yes, hmmm… Strange that two completely different windowing systems might not get along for some reason…
Yes, it’s a GLFW problem. I feel like this has been mentioned 50-60 times on discord but I don’t remember which channels. I tend to think all of lwjgl3’s jme-related issues are actually glfw.
2 Likes
I had never really thought about it, but I think you are right. 90% of the issues I have seen with lwjgl3 are glfw related. Not sure about where the key binding issues are from, they might also be glfw related, in that case it is actually closer to 99%.
Yeah, pretty sure the key events are glfw also.
ComboBoxes haven’t worked when I posted this, but now I just wrote a ComponentPeer that returns position on screen and ComboBox popup menu works correctly.
Hehe… Now ill just have to find where AWT Thread gets used and see if its easy to replace it…
Well I could let Swing use its AWT thread and synchronize input and copying the result, I wonder which approach is easier. For now it seems I got paiting & input on custom thread… Thou there might be some AWT thread lurking somewhere… maybe during popups? etc…
PS: Heavy-weight popups/Dialogs use separate Window, thus they get AWT thread, afaik. So either support lightweight popups or maybe using AWTThread + synchronize will be easier
