So let’s start … + if anything is unclear to you then just ask again …
You have two transparent objects which are very close to each other. You did not say which kind of camera you use (ortho or perspective) but I assume it’s a perspective camera.
Now you have a problem: the Z value of both objects (in camera space) is very near. Both the computation of the Z value and the Z buffer resolution are limited in their precision. For the Z buffer on today’s graphics cards it’s 32 bits (or 4 billion possible Z value ranges) which the computer can distinguish. These 4 billion Z ranges are distributed from the camera’s near plane to the camera’s far plane. They are not distributed linearly: Typically the closer you are to the near plane, the finer the resolution of the Z buffer.
Now you have two objects and they start what it’s called a “Z fight” - like you said, the rendering system seems unsure which sprite is in front of which - a flickering is the result.
4 different solutions (the order is not related to which is the “best” solution):
1st idea: use “alpha discard threshold”:
This will only render texels of a texture with an alpha values > threshold. What you want in your case is that only texels with alpha == 1.0 will be rendered. For this you can use the following:
The value 0.9961f is just a guess - make it smaller or bigger to achieve the right look. Problem with this idea is, that you will lose all half-tranparent pixels (which may look bad).
2nd idea: use an “orthographic (parallel) camera”:
There are two types of camera: orthographic and perspective. The perspective camera renders distant objects smaller than nearby objects. The perspective camera is used to render photorealistic scenes (which have a “3D perspective” in them). The orthographic (or “parallel”) camera renders all objects in the same size (no matter how far) and layers them by Z value. It’s used for UI, blueprints, top-down-view-games, 2D sidescrolling games, etc. and can be used for 2D games in general. To activate the ortho (parallel) camera:
Note: Will need some playing with the frustum dimensions and view direction until it works as expected.
3rd idea: implement a custom render queue bucket and Z sorting
You could tell the computer exactly which object is closer and command the order in which the objects are being rendered (from most distant object to least distant object). You know, in 2D games we most certainly know which is the most distant object.
Alternatively you could implement a custom comparison. Here is a link to that topic: http://javadoc.jmonkeyengine.org/com/jme3/renderer/queue/RenderQueue.html#setGeometryComparator(com.jme3.renderer.queue.RenderQueue.Bucket,%20com.jme3.renderer.queue.GeometryComparator)
(the GuiComparator is what you need)
Or just make a second guiNode (behind the real guiNode) and just use that.
Also includes 2nd idea (parallel camera).
4th idea “don’t let two objects come too close”:
You could manage the distance between the objects and make sure that they don’t come to close to each other. This is most certainly the worst solution.
5th idea “???”
I had another one when I was outside for a couple of minutes, but I forgot that one. Sorry.
Now, that's it. Hope you can find the right solution from this.