- Move all LWJGL content in nifty-examples module to it's own new module, nifty-examples-lwjgl. LWJGL isn't special - it can have its own examples module just like everyone else. - Remove nifty-renderer-lwjgl dependency from nifty-examples. - Refactor LWJGL initialization code in nifty-examples-lwjgl to make it stupid-easy to load & run any NiftyExample in one line of code (hint: it's easier than Slick2D, and that's difficult to beat) - nifty-examples-lwjgl now implements every single example found in nifty-examples - Cleanup & refactor the code in many of the examples in nifty-examples. TODO: Many more examples still need a ton of cleanup though! - Delete the "issues" package & classes out of nifty-examples: This has got to be the most horrible idea I've seen in Nifty in a long time. It reeks of laziness. First of all, there's the problem of unsustainability. What's going to happen as the number of these issues keeps growing? At some point it's going to get nasty. It increases the size of the Nifty Gui library as well. Secondly, all those issues have been resolved! Who wants to see a bunch of code demonstrating non-existent problems? Probably no one. Who's going to want to maintain & update code for non-existent issues in the future when the examples or other code needs refactoring? *Cricket, cricket* That's what I thought. I've refactored the Nifty examples, and in the process, I've broken these stupid issues classes. Guess how much motivation I have to fix them? If you want to create demonstrations of bugs, please maintain your own repository for such things. In fact, why not have a public nifty-issues repository for this? There, problem solved. - Delete the top-secret, uber-special "meins" file. It's from 2008, and it looks like @void256's personal notes or something? Doesn't belong in Nifty Gui. - Add some missing examples to nifty-examples-slick2d (tutorial, multiclick, healthimage), since it's insanely easy to add new examples (thanks to @mkaring). - Unrelated: Fix Slick2D naming inconsistencies. Some modules / packages / comments / etc use the word "slick", some use the word "slick2d", and still others use the word "slick2D". Rename comments & text mentions Slick2D, for package names & module names that require lowercase, use slick2d everywhere. - Note: Slick2D still has some pre-existing unresolved issues, such as certain examples crashing due to "java.lang.NoClassDefFoundError: com/jcraft/jorbis/Info" (music issue?). - Unit tests & integration tests are successful (excluding all the pre-existing examples issues - what I mean is that the changes did not introduce any bugs / regressions as far as could be tested).
Rename nifty-renderer-jogl2 to nifty-renderer-jogl. Rename the actual module directory and its reference in the main parent pom. Why have version numbers in the module name? It makes no sense. Not only would it be tedious to maintain as the version changed, but it's inconsistent with all the other rendering modules. The whole point of each module having it's own pom file is to specify the current version in there.
some test made problems because it was using classes from the easymock classextension jar and the regular easymock jar. however classextension has been deprecated some time ago and was therefore removed. tests have been modified accordingly.
Upgrade EasyMock dependency in main pom.xml to version 3.1. Change EasyMock imports from package org.easymock.classextension.* to org.easymock.*, since the classextension package is deprecated; i.e., the functionality has been merged into standard EasyMock in version 3.1. When stubReturn-ing the getMsTime() method on the TimeProvider mock, specify the return value as 0L to satisfy the compiler, since it needs to return a long, rather than casting the 0 to a long, since it's more elegant.
The main changes are the addition of two new Maven modules to Nifty: nifty-renderer-libgdx and nifty-examples-libgdx. Changes to existing modules are listed at the very bottom. All Nifty tests are passing, and the two new modules are working perfectly after extensive integration testing. Important Note: Android / Nifty integration is a work in progress. The LibGDX renderer seems to work on Android, but it has not been extensively tested, especially because of the fact that the size of the resources used in the Nifty Examples module are designed for desktops, not mobile devices. The Android submodule of the nifty-examples-libgdx module is broken at this time. Important Note: iOS is completely unsupported at this time. Detailed changes: New Module 1: nifty-renderer-libgdx: The new Nifty LibGDX renderer handles mouse & keyboard input, sound, music, custom mouse cursors, graphics, pretty much anything Nifty can throw at it ;-). It runs the main Nifty demo, the default controls demo, and the Nifty 1.2 tutorial demo. It uses the new BatchRenderBackend interface for rendering, but not yet core profile. The renderer only uses OpenGL 1.0 functionality for maximum compatibility. I have a very old computer, so even if I write a core profile renderer, I would not be able to test it or run it :'(. The LwjglBatchRenderBackend served as a reference; in fact, the renderer doesn't really make use of any high-level features of LibGDX; the original RenderDevice implementation of the LibGDX renderer written by Martin Karing <firstname.lastname@example.org> tried to take that route, but there were too many issues, and I eventually removed it completely and focused on porting the LwjglBatchRenderBackend instead. LibGDX does use LWJGL for it's desktop implementation after all. The real "magic" that was required to port LwjglBatchRenderBackend to LibGDX involved using GL_TRIANGLES in the call to glDrawArrays. The reason for this is that LibGDX only provides OpenGL ES functionality, since it must work on Android and iOS, and GL_QUADS is not available in OpenGL ES. Using GL_TRIANGLES (triangle list) requires the duplication of two vertices per quad, since two joined triangles must be formed to create a quad, and they share two vertices. This results in a total of 6 vertices per quad, but the performance should be made up for by the fact that OpenGL LOVES triangles, and gobbles them up at a faster rate than large, unwieldy quads, which it has to chew into triangles eventually anyway, lol. New Module 2: nifty-examples-libgdx: This is a complete LibGDX project, set up Maven-style. It has a parent module with pom packaging, and three sub-modules, core, desktop, and android. The core submodule contains a LibGDX example application. The desktop and android submodules merely instantiate a NiftyExample and pass it to the LibGDX example application in the core submodule. Three main NiftyExample demos are provided, and work just fine: Nifty Main Examples Demo Nifty Default Controls Demo Nifty 1.2 Tutorial Demo The example application was set up in IntelliJ with Maven using the LibGDX Maven archetype project, located at: https://github.com/libgdx/libgdx-maven-archetype Changes to existing modules / files in Nifty: pom.xml: Add nifty-renderer-libgdx and nifty-examples-libgdx as modules. nifty-examples/src/main/java/de/lessvoid/nifty/examples/controls/ControlsDemoStartScreen.java: Add "LibGDX" as a dropdown choice in the controls demo. nifty-examples/src/main/resources/all/intro.xml: nifty-examples/src/main/resources/all/libgdx.png: Add LibGDX mention & logo in main example credits. nifty-core/src/main/java/de/lessvoid/nifty/input/keyboard/KeyboardInputEvent.java: Create an empty default constructor because GdxKeyboardInputEvent, which subclasses KeyboardInputEvent, makes use of a default constructor, and needs to call super(). Also add a public setData method, to initialize the data for the object, so it doesn't have to be done in the constructor. This is necessary because GdxKeyboardInputEvent relies on a pool to obtain new instances, and the data required by Nifty to initialize the KeyboardInputEvent with the parameterized constructor is not yet available. These changes are made by Martin Karing <email@example.com>, who wrote most of the original input system for the LibGDX renderer.
This makes it somewhat easier to override the Java version from child POMs. Also, it does not nail down the maven-compiler-plugin version anymore. Sure enough, this bumped the version from 2.3.1 to 2.3.2 (2.3.2 fixes http://jira.codehaus.org/browse/MCOMPILER-109).
Umlauts etc. should now properly work even when compiling on Windows.