Nifty GUI Changelog

What's new in Nifty GUI 1.3.3

• JOGL: add NiftyTutorialJOGL and extract setup code to JOGLNiftyRunner
• Enabled Core-Profile/Batch-Rendering for TutorialMainNativeLWJGL
• BatchRenderDevice: fixed text encoded color support
• added NullSoundHandle to NullSoundDevice for improved stability
• fix resolution switching for batched renderer using lwjgl and jogl
• fix core profile GL extension check so that no silly GL error appears
• JOGL: add core profile batched renderer support
• 110: Updated Slick2d to Build "20121001-264 "and lwjgl-2.9.0
• JOGL: batch renderer support added
• JOGL: mouse move support added to JoglInputSystem
• JOGL: update jogl version
• JOGL examples project added
• fixes #109: Assigning an id from a custom attribute to a control
• resolveParameters() needs to happen before makeFlatControls() since makeFlatControls() resolves the ids and propagates the id to childelements. which is ok ... unless someone comes and changes the actual ids with some $parameter! In that case makeFlatControls() did nothing since there was no actual id available! This commit seems to fix that. I'm not sure if something else breaks now although all the standard demos/examples I've checked seem to work.
• LwjglBatchedRendererBackend: Handle missing images without NPE
• this fixes some missing vertex buffer bind() calls as well
• method markBatchRenderImageAsUnloaded() added to NiftyImage
• This method allows you to modify a backing texture externally and then notify Nifty that you've changed the texture. Nifty will then upload the image to the texture atlas the next time the image is accessed. Without this method Nifty would never know about the change of the texture and would never update the texture atlas with the updated texture. This method is specific to the new BatchRenderer.
• LwjglBatchRenderBackendCoreProfile: BatchRenderBackend for Core Profile
• console.fnt removed from examples since the font is in the style-black
• jglfont-core-1.2 added to enable embedded textcolor for batched rendere
• improve renderEngine.createImage() JavaDoc since it was changed in 1.3.3
• workaround for issue #73 added
• The KeyboardInputEvent constructor sets the character instance variable to 0 when the control-key is pressed. This prevents characters you can only reach with the help of control and alt, like AltGr+Q on Windows to insert a @ character for certain keyboard layouts. To prevent this issue I've now removed the "if (controlDown)" check in
• the constructor. This means any character code pressed while any of the special keys is down (alt, shift, control) will be processed as a regular key.
• However, the InputMapping implementation, f.i. TextfieldInputMapping will handle some control+key combinations like ctrl+A or ctrl+C and so correctly and will prevent any character input into the textfield in that case. Other, unhandled combinations will still find it's way to the textfield which is not quite right but shouldn't do any harm. For instance you can now press ctrl-P and a you would see "P" in the textfield.
• shut off spamming by changing logging from INFO to FINE, closes #65
• Extract NiftyImageManager differences between batched and non-batched
• additionally this fixed non batched rendering which the NiftyImageManager broke
• BatchRenderer Image Management corrected for newly loaded screens
• When a new XML file is loaded with nifty.fromXml() all existing screen based cache information in NiftyImageManager will now be removed. This fixes an issue that old images (referenced by old screens with the same id) are still uploaded to the texture atlas even though they are not needed in the newly version of the screen with the same id.
• The same fixes have been applied when screens are being removed dynamically with nifty.removeScreen(). So now everything that's being uploaded to the texture atlas is really only the images that are needed.
• It was possible that the onEndScreen() event could be triggered from a nifty.render() call which in turned would call the niftyImageManager to unload all the images. And then when the rendering continued the dynamic upload mechanism was activated that would upload the images again since they could still be references from other render calls. To prevent this issue the onEndScreen stuff is now being delayed as an EndOfFrameAction which prevents this issue.
• So finally with this commit the whole batched renderer and extended image manager business should be in place correctly.
• Automatically filter out newline when pasting from Clipboard. fixes #97
• Newlines (both regular and windows ones) are now automaticallyremoved when Clipboard content is being pasted into a Textfield. This should fix the issue.
• I agree that the other part of the issue (fixing the handling of multi-line selections) needs to be fixed as well. But this is more involved and should be worked on separately.
• we need to mark all images as unloaded in unloadScreenImages
• new examples and explanation added to logging.properties
• Huge BatchRenderDevice update with better texture atlas management
• Ok, this was more work than anticipated but it should handle the texture atlas a lot better now. Here is a short explanation - I really need to blog about all of that stuff soon in more detail tho ;)
• So basically there is a texture atlas of a certain size. The actual size can be adjusted by the user. At the moment all of the examples I've modified to use the batch renderer uses a 2048x2048 texture which seems to be more than enough for all of the standard examples I've tried.
• This texture atlas is now filled with images for the current active Nifty screen. So that all the images required by the current active will be part of the texture atlas. To do that Nifty keeps track of which image belongs to which Screen when it reads a XML file or when a Screen is created with a Builder. This tracking is done for all loaded screens and even for images that are dynamically created with Nifty.createImage(). These dynamic images will be added to the current active screen. If there is no current active Screen then the images will still be loaded and uploaded to the texture atlas at the first render access.
• But in general Nifty will upload all images that are required for the current screen into the texture atlas when a new Screen is started. Consequently when a screen ends the texture atlas is being reset to an empty one.
• Nifty already implemented a reference counting mechanism to keep track of already loaded image resources. This was used to prevent loading the same image multiple times and it is still being used for this purpose. However, the process of loading an image is now separated into two steps:
• 1. the actual image data is loaded into whatever image representation a BatchRenderBackend supports (the example implementation using native LWJGL will simply load an image file into a ByteBuffer) and
• 2. the loaded image data is put into the texture atlas at a position that Nifty decided when it's time for this image to be a part of the current screen.
• When an image is accessed dynamically while a screen is running it will be uploaded at the time of the first access. For best performance static images - or at least ones that Nifty knows about before the screen is started - should be preferred so that Nifty can upload them to the texture atlas at the time the screen starts and not while the screen is already running. Although I think you can get away easily with a couple of image uploads if you don't access multiple images in a single render frame.
• All of this is required to keep only the currently active images in the texture atlas if possible. This should work quite well for most use cases although it's still possible to use up all of the available space in the texture atlas. The batch renderer still should provide much better rendering performance and should work well when being carefully used.
• List of changes in this commit:
• lots of changes to the image managment in NiftyImageManager especially tracking of the screen an image is attached to renderEngine.createImage() now requires a Screen instance removeFromTexture() and clearAtlasTexture() methods added to BatchRenderBackend TextureAtlasGenerator now supports removal of images as well BatchRenderImage now supports upload() and unload() methods font resource loading now attached to upload() and unload() as well
• Attention:
• It is unlikely but still possible that some of these changes will break existing code especially when this code uses internal methods like renderEngine.createImage() instead of nifty.createImage(). These errors should show up as compile errors and should therefore be easily fixed though. I'm sure there are other more hidden issues but I've really tried to keep the changes at a minimum so in general it should be fine.
• Batch API JavaDoc cleanup
• finish BatchRenderDevice and LwjglBatchRenderBackend
• BatchRenderFont implements RenderFont added to fix compiler issues
• first version of BatchRenderDevice implementation
• Merge pull request #81 from floyd1982/1.3
• Take current threads contextClassLoader for resource loading, which is more flexible
• start the controls example at the "start" screen
• close issue #58 Can not load fonts in sub folders