@gouessej said:
Abstracting windowing stuffs is easy if and only if you don't allow the end users to modify the resolution, if you allow only the use of the default virtual monitor. @Momoko_Fan seems to talk above several renderers for the desktop whereas you talk about a single renderer :s I understand that you want the jME users to be "clients" of the jME API by wrapping NEWT or anything else.
Momoko is talking about different platforms renderers, i.e. desktop, iOS, Android, PS3 etc. Imo something like NEWT is backwards for us because the window frame is in almost all cases handled by the OS in the end and the programming environment already allows managing it. On desktop systems its convenient theres NEWT but for Android and iOS its kind of annoying to have an opaque library handle the native windows. On iOS for example the user can place and use the window any way he likes using XCode, on Android he can do that in the Android code of the application using the Android API.
Iāll have to switch to JOGL 2.2.4 soon, it contains numerous fixes including some impacting lots of Intel chips under Windows in offscreen rendering.
The next version of JOGL (probably 2.3) will fix once for all a very annoying problem under OS X by moving the classes from javax.media.* to some other packages: https://jogamp.org/bugzilla/show_bug.cgi?id=682
Apple goes on shipping a very old version of Java 3D even with OS X 10.10, this obsolete version comes with JOGL 1. As these libraries are installed as extensions, they are loaded in priority and they cause conflicts with other versions. It impacts those who still use Apple Java (which is deprecated since OS X 10.6), Iām not sure it impacts those who use OpenJDK or Oracle Java.
As we donāt want to make the same mistakes again, please avoid copying the JARs of third party libraries into the JVM (especially jre/lib/ext), into any directory mentioned in the CLASSPATH variable environment (use -cp or -classpath instead) and into any directory used by the extension mechanism. This advice applies to other operating systems too.
I will probably have to disable HiDpi on Retina displays by default. When itās on, pixel units and window units are different, this information is available in JOGL but itās tricky to take it into account in an engine. I have found no way of using only pixel units everywhere and using window units with a non unit surface scale would drive the mouse management inaccurate. The coordinates of the mouse events are in pixel units whereas the screen dimension(s) and the windows are in window units.
Sorry for the delay. Iāve just updated the JogAmp backend, it now uses JOGL 2.3.1. I have to check whether some fixes havenāt been ported to this backend, I have to implement the support of HiDpi and to follow the unified rendering architecture if it is possible.
In the future, Iād like to put this backend into our Maven development repository and maybe on Maven Central.
By the way, Gradle works very well in Eclipse, itās a pleasure to use it
I havenāt worked on the unified renderer yet and I have to use JOGL 2.3.2. Iāll try to find some time to update the JOGL backend at the beginning of September.
Please contact me on our official IRC channel, our official forum or by email if you need some help. Iām rarely on this forum and when some JOGL users make spelling mistakes when writing my pseudonym, I receive no alert. My little presence on this forum doesnāt mean that I have no time for the maintenance and the development of this backend. It just means that I have almost no time to spend on all forums of the web, rather come to us.
Moreover, my password became suddenly invalid and I had to reset it. Itās safer not to contact me on this forum.
Hi. Iāve just fixed the regression caused by a change on the gamma correction and Iāve added the support of DebugGL for OpenGL ES 3. Enjoy JoglNewtDisplay and JoglDisplay are working anew but there is still something wrong with JoglNewtCanvas and JoglCanvas (just a NullPointerException). The old-style JOGL renderer doesnāt work with TestInstanceNode because of a bound VBO in a location in which it should be unbound, Iāll fix it by implementing the unified renderer, maybe Iāll have a few questions to ask to some core developers about it.
By the way, I thank a lot @Mr_Marbles for his precious help.
Thanks @gouessej
Implementing the unified renderer is very important, as its already supported by all platforms (LWJGL, iOS, Android) except for JOGL. Some features that are added to the engine might only be supported by the unified renderer.
@Momoko_Fan As the old-style renderer has been removed from the other backends, the fixes are only in those unified renderers, I understand that itās the same for the new features. I assume that itās similar to what has been done in LibGDX for several years, it should work.
Iād like to rename the sub-project, ājme3-jogampā would be a better name as it uses both JOGL and JOAL (maybe JOCL one day?), it would be more consistent with LibGDX.
I see that there are more and more developers interested in non gaming applications with multiple windows. Should I plan to port the recent changes I did in LibGDX and what I did for a long time in JogAmpās Ardor3D Continuation? It would improve the interoperability with SWT, AWT, Swing and OpenJFX (JavaFX). GLJFXPanel will probably be implemented before the first stable release of Java 1.9, I have to keep it in mind too. Actually, instead of providing only one AWT canvas, one AWT display, one AWT-free canvas and one AWT-free display (which was the case in Ardor3D 0.9), I provide all available canvas and I separate them into several sub-projects so that it remains modular and it helps those who use the compact profiles and the work of the small VM JEP. It will be relevant if and only if JMonkeyEngine doesnāt stay focused on games.
Last but not least, splitting the JogAmp backend to isolate the AWT-free part would help to use it in environments not supporting AWT, for example Android Then, the JMonkeyEngine context for Android would require a few changes to be able to use JOGL optionally instead of AndroidGL. Actually, this is what I mean by āunified rendererā, a single renderer for both desktop and mobile environments.
Hardware skinning is currently broken with the JOGL renderer. The meshes look distorted. A workaround is to disable hardware skinning on the skeleton control.
I have temporarily re-enabled the legacy renderer as there is something wrong in the unified renderer. I hope to find a fix this week.
Edit.: The maintainer of JainJa got in touch with the JogAmp community recently, he succeeded in running Java and OpenGL ES 1 on a Nintendo Wii. His ātranspilerā has some hard constraints (Java <= 1.4) but maybe it will be worth a try.
I have to remove a useless empty character added when handling the attributes and the uniforms. I hope that it will fix the new unified renderer. Best regards.
Iāve just removed the old renderer as the new unified renderer works correctly now. Iāve just tested it with TestOgreAnim in debug mode to be sure that the unified renderer is used. I get a NullPointerException when exiting the demo but it works.
You can easily try the JOGL backend by settings the default renderer to JOGL and the default audio renderer to JOAL in the class āAppSettingsā. Enjoy
Edit.: Iāve just fixed the NullPointerException. Good night.
By the way, I tested it just now and I noticed that when I close the app by clicking the X button, it continues to run - it doesnāt seem the window close event has been caught by any of the backend code.
I am using Ubuntu 14.04 x64 with Intel HD Graphics.
Then, the JMonkeyEngine context for Android would require a few changes to be able to use JOGL optionally instead of AndroidGL. Actually, this is what I mean by āunified rendererā, a single renderer for both desktop and mobile environments.