Hello
I spent many months waiting for fixes in Maven several years ago. As far as I remember, maven-javadoc-plugin had been broken twice, I remained unable to generate the Java API documentation for a lot of time. Maven is a great tool but it’s the right tool only when you can strictly follow its conventions and it’s convenient as long as you don’t want to use libraries not coming from Maven repositories. I had to use dirtily patched (yes I edited the bytecode) versions of JOGL several times in TUER but I was forced to stick to versions of JOGL already available in Maven Central in JogAmp’s Ardor3D Continuation which means that developers using the JARs from Maven Central didn’t benefit of my fixes. To be honest, some problems could have been mitigated by publishing snapshots of JOGL into the Maven JogAmp development repository more often but unfixed bugs in Maven itself wouldn’t have magically disappeared. By the way, I consider that I have some experience with Maven, I still use it in JogAmp’s Ardor3D Continuation… for now. Actually, dropping Apache Ant completely isn’t quickly doable as JNDT is written with Ant and heavily relies on Ant Contrib, there is no equivalent of JNDT in Maven, the closest solutions based on Maven are totally unable to build native Windows installers under GNU Linux for example. You can call Maven from Ant (which is what Apache Ant does when you use fetch.xml to install optional dependencies) and you can call Ant from Maven but Gradle seems to be a better tool to play with Ant. Moreover, Ant Contrib hasn’t been updated for almost about a decade, Ant wasn’t designed to write loops, JNDT relies on an unmaintained unofficial extension of Ant which might become broken soon with changes in Java whereas the core of Gradle is designed from the very beginning to do the kind of things I do in JNDT. Using Gradle seems to be a wise choice on the long term, it supports both Ivy and Maven repositories which is a good piece of news as I’ll go on retrieving some dependencies from Maven Central. I just hope that I won’t run into too many problems as I rely more and more on “preview” or incubated APIs. There are so many things I would like to achieve but not enough time to try:
- build an alternative to Java Chromium Embedded Framework based on Mozilla Firefox in order to embed Firefox in Java to render web UIs in JOGL (and avoid using anything coming from Google, which is what I already do by using Mobian Linux on my smartphone
)
- replace GlueGen by Panama JExtract + Foreign-Memory Access API + Foreign Linker API (Martin Pernollet has already tried, promising job)
- improve NEWT mouse management
- support Wayland in JOGL
- use WebGPU instead of OpenGL
- give another chance to TUER in a web browser by automatically translating Java into Javascript and WebAssembly
TUER has used JOGL NEWT for many years, it doesn’t require AWT and Swing. I intentionally stopped using any JOGL canvas relying on AWT and Swing in JOGL but they still exist, GLCanvas and GLJPanel work. The game itself doesn’t require AWT and Swing but the editor, JFPSM, still does 
(Unchanged) Paul Lamb’s Sound System uses javax.sound for its build-in MIDI support in the class named MidiChannel, I had to remove it. It uses javax.sound.sampled.AudioFormat in some of its core classes. You can’t use it as is without Java Sound even when you don’t use its plugin for Java Sound which is my case as I use its plugin for JOAL. However, I modified my own source code a few hours ago so that it’s still possible to use a codec not based on Java Sound to reintroduce MIDI support without Java Sound. I’m not sure that I can totally remove any reference to AudioFormat without breaking completely my modified stuff. To be honest, the deprecated code was easy to edit, it took me only about ten minutes, it involved the constructors of the Integer class used in Info.java and I had to call getDeclaredConstructor().newInstance() somewhere, not that hard I’ll have to look at the source code more carefully, maybe a few deprecated calls are still there. For now, it can be compiled with Java 17 and probably Java 19 too.
Touchscreen support is implemented in JOGL itself. As far as I remember, Sven took care of Android and another contributor added GNU Linux support later. However, I have done nothing particular in TUER to handle touchscreen controls, NEWT is able to tell me that a pointer event doesn’t come from a mouse but I don’t do anything special in this case. TUER isn’t designed to be pleasant to play with such controls, it would be cumbersome to play with it on a tablet, you would need a virtual keyboard to walk.
Yes the mouse issues are annoying. I know which native APIs to call but I’ll need to modify the Java and C source code of NEWT to do that. It would be easier if I could stick to my guns by using Java only. JNI isn’t famous for being pleasant to use. I’ll probably have to look at Renanse’s source code to modify the way I handle relative mouse movements in JogAmp’s Ardor3D Continuation, keeping the mouse pointer in the center of the screen because of the lack of relative mouse movement support in NEWT will no longer be necessary. I just hope that my problem really comes from that, debugging while moving the mouse to reproduce the bug is very tricky. Investing a lot of time in such big changes without being confident about the root cause(s) doesn’t reassure me.
It allows to merge adjacent right-angled triangles using canonical texture coordinates ([0, 0], [0, 1], [1, 0] and [1, 1]) in the same planes, it uses coordinates greater than 1 to tell OpenGL to repeat the texture. I tested it on the very first level on the mesh containing the walls (not on the floor), I looked at the result by pressing the key “T” to toggle the wireframe mode, the frame rate is a bit better but it isn’t impressive yet because most triangles are on the floor and in the ceiling. I used a lot the Java streams when rewriting this mesh optimizer, I find the final result a lot more readable and the source code is almost twice smaller than my first attempt: