Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Aug 26, 2014
  1. @3xp0n3nt

    Rename jogl2 to jogl.

    3xp0n3nt authored
    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.
Commits on Jul 6, 2014
  1. [maven-release-plugin] prepare for next development iteration

    Illarion Jenkins - CI authored
  2. [maven-release-plugin] prepare release nifty-main-1.4.0

    Illarion Jenkins - CI authored
  3. jogamp.version: 2.1.5-01

    void authored
Commits on Jun 25, 2014
Commits on Jun 24, 2014
Commits on May 12, 2014
  1. #227 make jogl dependencies 'provided' instead of 'compile'

    void authored
    Please note that this means that you now have to provide the jogl
    libraries on your own when you depend on nifty-renderer-jogl2. They will
    not be included automatically anymore.
Commits on Mar 5, 2014
  1. Update jogamp to version 2.1.4

    void authored
Commits on Jan 25, 2014
  1. @3xp0n3nt

    Simplify rendering backends.

    3xp0n3nt authored
    nifty-core:
    
    - Delete BatchFactory & CoreBatchFactory, and just instaniate a
      BatchInternal & CoreBatchInternal directly, respectively, in
      BatchRenderBackendInternal & BatchRenderBackendCoreProfileInternal,
      respectively.
    
    - Remove the BatchFactory & CoreBatchFactory parameter from
      BatchRenderBackendInternal & BatchRenderBackendCoreProfileInternal
      constructors, respectively.
    
    Lwjgl / Jogl / LibGDX:
    
    - Delete JoglBatchRenderBackend & LwjglBatchRenderBackend, since they
      just delegate everything to BatchRenderBackendInternal anyway. Don't
      delete GdxBatchRenderBackend because it specializes a couple of methods
      rather than delegating.
    
    - Delete JoglBatchRenderBackendCoreProfile &
      LwjglBatchRenderBackendCoreProfile, since they just delegate
      everything to BatchRenderBackendCoreProfileInternal anyway (there is
      no GdxBatchRenderBackendCoreProfile).
    
    - Delete JoglBatch, LwjglBatch, GdxBatch, since they just delegate
      everything to BatchInternal anyway.
    
    - Delete JoglBatchFactory, LwjglBatchFactory, GdxBatchFactory.
    
    - Delete JoglCoreBatch, LwjglCoreBatch (there is no GdxCoreBatch).
    
    - Delete JoglCoreBatchFactory, LwjglCoreBatchFactory (there is no
      GdxCoreBatchFactory)
    
    - Move remaining classes in render/batch and render/batch/core packages
      into render/ package.
    
    - Delete batch & batch/core packages.
    
    - Modify JoglBatchRenderBackendFactory & LwjglBatchRenderBackendFactory
      to instantiate a BatchRenderBackendInternal directly, instead of
      instantiating a JoglBatchRenderBackend or LwjglBatchRenderBackend,
      respectively.
    
    - Modify JoglBatchRenderBackendCoreProfileFactory &
      LwjglBatchRenderBackendCoreProfileFactory to instantiate a
      BatchRenderBackendCoreProfileInternal directly, instead of instantiating
      a JoglBatchRenderBackendCoreProfile or
      LwjglBatchRenderBackendCoreProfile, respectively.
    
    - Remove instantiation of JoglBatch, LwjglBatch, GdxBatch from
      JoglBatchRenderBackendFactory, LwjglBatchRenderBackendFactory, &
      GdxBatchRenderBackendFactory, respectively.
    
    - Remove instantiation of JoglBatchCoreProfile & LwjglBatchCoreProfile
      from JoglBatchRenderBackendCoreProfileFactory &
      LwjglBatchRenderBackendCoreProfileFactory, respectively (there is no
      GdxBatchCoreProfile or GdxBatchRenderBackendCoreProfileFactory).
    
    - Mark JoglRenderDevice & LwjglRenderDevice as deprecated, including
      javadoc explaining what to use instead (there is no GdxRenderDevice).
  2. @3xp0n3nt
Commits on Jan 24, 2014
  1. fix missing gl31 local variable

    void authored
  2. @gouessej

    Update JoglCoreGL.java

    gouessej authored
    Same mistake than in JoglGL...
  3. @gouessej

    Update Tools.java

    gouessej authored
    Uses GLU.createGLU(GL).
  4. @gouessej

    Update JoglRenderImage.java

    gouessej authored
    Uses GLUgl2 instead of GLU to benefit of a full implementation
  5. @gouessej

    Update JoglGL.java

    gouessej authored
    Partial fix of the issue 205:
    #205
Commits on Jan 22, 2014
  1. @3xp0n3nt

    Major batch rendering system overhaul, 3rd draft.

    3xp0n3nt authored
    Core profile batch rendering system:
    
    - Refactor the entire core profile batch rendering system to match the
      new non-core profile batch rendering system setup / refactoring.
    
    - Core profile now has multiple atlas & non-atlas texture support.
    
    - Move all Core* classes into nifty-core.
    
    - Remove Core* duplication between nifty-renderer-lwjgl &
      nifty-renderer-jogl.
    
    - Abstract core profile OpenGL calls into CoreGL interface, which
      extends GL interface.
    
    - Remove obsolete compatibility code / checking in Core* classes, and
      require OpenGL 3.2 or higher in order to use the Core Profile
      rendering system at all. Since we requiring OpenGL 3.2 or higher, we
      don't need to pollute the system with all kinds of non-core profile
      compatibility junk.
    
    - Remove rare uses of OpenGL extensions that are preventing the
      abstraction of CoreGL, since not all implementations can be forced to
      deal with extension-specific OpenGL stuff. It's not needed anyway.
      There are only several places where extensions are used, and they aren't
      anything critical. It limited the functionality slightly, but it
      shouldn't be missed. The badly-needed refactoring of the core profile
      system is so much more important anyway.
    
    - Give *BatchRenderBackendCoreProfile classes package-private
      constructors to force users to rely on
      *BatchRenderBackendCoreProfileFactory.create() to instantiate. The
      reason being that the *BatchRenderBackendCoreProfile constructors are
      too complex and are managed automatically by their respective
      factories.
    
    - Refactor any examples that are using a *BatchRenderBackendCoreProfile
      to use the factory method instead.
    
    - Create JOGL & LWJGL implementations of CoreGL interface.
    
    - Rename CoreCheckGL & CoreGLException to CheckGL & GLException,
      respectively, because there is nothing "core profile" about them, and
      the non-core profile system could easily use them if needed.
      LwjglInitHelper class in nifty-examples currently uses these in non-core
      profile code already. Move CHeckGL & GLException out of the core
      package and into the parent package, "batch", since they are not
      core-profile specific.
    
    - Create CoreMatrix4f, CoreVector4f, & CoreMatrixFactory, based on Mat4,
      Vec4, & CoreMatrixFactory from nifty-renderer-jogl, for use in
      BatchRenderBackendCoreProfileInternal in nifty-core.
    
    - Non-core batch rendering system:
    
    - Rename OpenGLBatchRenderBackend to BatchRenderBackendInternal because
      that is a more accurate name.
    
    - Rename OpenGLBatch to BatchInternal because that is a more accurate
      name.
    
    - Rename OpenGLBatchFactory to BatchFactory, in line with the last two
      mentioned changes.
    
    - Add many non-core profile OpenGL methods that are only currently being
      used by the core profile system to the GL interface, rather than
      adding them to the
    
    - General code cleanup.
    
    - Miscellaneous:
    
    - Improve spelling, grammar, readability, formatting, & punctuation of
      existing javadoc and comments.
    - Add missing final keyword to method parameters.
    - Add missing JSR annotations.
    - Fix incorrect JSR annotations.
    - Add some asserts to deal with unsolvable JSR annotation warnings.
    - General code cleanup
    
    Caveats:
    
    - nifty-renderer-libgdx does not yet have a core profile rendering
      system, which means mobile devices / OpenGL ES2 is not officially
      supported yet.
    
    - I cannot integration-test the core profile rendering system because my
      computer is too old to support OpenGL 3.2, so I don't know if
      everything actually works. There may be (read: are probably) some bugs
      ;).
    
    - There is still a lot of duplicated code between
      BatchRenderBackendInternal & BatchRenderBackendCoreProfileInternal.
    
    - There are a few non-core profile OpenGL methods in the CoreGL
      interface because libGDX only supports them as part of the core
      profile (OpenGL ES 2 and up), so the nifty-renderer-libgdx non-core
      profile rendering system wouldn't have been able to implement them as
      part of the GL interface.
    
    - There are major API changes.
    
    - The Core* classes look like every line changed because they of being
      moved to a different module within the project.
Commits on Jan 19, 2014
  1. @3xp0n3nt

    Refactor image loading system.

    3xp0n3nt authored
    Note: All modules compile, all tests are passing, and all modules'
    examples (LWJGL, JOGL, LibGDX) render correctly on my machine.
    
    ImageLoader interface:
    
    - Remove unused load methods.
    
    - Refactor remaining load methods so that they make sense:
      - loadAsByteBufferRGBA & loadAsByteBufferARGB are the only needed options
      - loadAsByteBufferARGB has an option to flip the image vertically
      - get rid of "mouseCursor" in the interface names - image loading
        shouldn't need to know about mouse cursors (Single Responsibility
        Principle)
      - loadByteBufferARGB is used to load mouse cursors, setting
        shouldFlipVertically parameter to true
    
    - Clean up code formatting, add missing final keywords to parameters,
      update JSR annotations.
    
    - Rename image info get* methods to increase clarity.
    
    - In general, minimize the interface to provide only the functionality
      needed by the library to avoid bugs and confusion.
    
    ImageIOImageLoader:
    
    - loadAsByteBufferRGBA method adds alpha to all images instead of
      requiring the caller to try and decipher a long list of load methods
      that may or may not add alpha to the image. So all images will be loaded
      as RGBA.
    
    - Rename to DefaultImageLoader, since it's used as the default image
      loader, and it doesn't need to expose implementation details in the
      name, which in a way violates encapsulation.
    - Refactor the private methods, some of which were very long and
      complicated, splitting them up into small methods.
    
    - Remove features completely unused (and unlikely to ever be used) by
      Nifty Gui such as passing around a transparency integer array
      (although there are others as well).
    
    - Get rid of worthless comments and broken javadoc.
    
    - Create an ImageProperties nested class to keep track of a loaded
      image's properties, which helped clean up the class tremendously and
      removes potential for hidden bugs - for example, if one of the image
      info get* interface methods is called (such as getImageWidth), and is
      not set, it will now throw an exception instead of failing silently.
    
    - Clean up code formatting, add missing final keywords to parameters,
      add missing JSR annotations. Adding final to some parameters revealed
      some areas where the parameter values were being modified.
    
    - Update class to conform to new ImageLoader interface.
    
    TGAImageLoader:
    
    - This class has methods badly in need of refactoring, that have not yet
      been refactored. Add TODO comments where refactoring is needed.
    
    - Get rid of worthless comments and broken javadoc.
    
    - Clean up code formatting, add missing final keywords to parameters,
      add missing JSR annotations. Adding final to some parameters revealed
      some areas where the parameter values were being modified.
    
    - Update class to conform to new ImageLoader interface.
    
    Other Changes:
    
    - Update all client classes to use the correct form of the new
      ImageLoader interface methods.
Commits on Jan 18, 2014
  1. @3xp0n3nt

    Major batch rendering system overhaul, 2nd draft.

    3xp0n3nt authored
    - Switched everything from inheritance to composition & delegation.
    - CoreProfile rendering system still not updated yet.
    - LWJGL, JOGL, & LibGDX batch rendering systems are functioning correctly.
Commits on Jan 14, 2014
  1. Merge pull request #197 from 3xp0n3nt/batch-render-dev

    authored
    Major batch rendering system overhaul.
  2. @3xp0n3nt

    Major batch rendering system overhaul.

    3xp0n3nt authored
    Non-atlas textures:
    
    - A non-atlas texture is a texture that is not within atlas tolerance,
    meaning that it takes up too much a percentage of space in the atlas (or
    it's width or height or both won't physically fit in the atlas), and
    since all atlases and currently the same size, if it is not within atlas
    tolerance, it won't fit in any atlas, no matter how empty or full it
    might be. The atlas tolerance is separate from the fullness or emptiness
    of an atlas.
    
    - Sometimes we need to be able to create large background images that we
    don't want consuming an entire atlas, or even high-res images that won't
    even "physically" fit in an atlas even if we wanted them to. For these,
    it is convenient to render them as a separate, individual, non-atlas
    texture in order to allow the use of such large images.
    
    - The performance penalty for having several of these non-atlas textures
    is actually very minor. They are simply assigned to their own batch,
    since each batch can only have one texture id. You can see it as a
    performance benefit actually because you free up so much space in your
    atlas.
    
    - Non-atlas textures are managed completely automatically based on the
    atlas tolerance.
    
    Multiple texture atlases:
    
    - When an atlas gets too full, we don't want to render every texture
    individually. The GPU is actually very good at handling multiple texture
    atlases for us with very little performance penalty most of the time.
    
    - The beautiful part is when an atlas gets too full, the next atlas will
    be attempted to add the image to, and so on, until, if there are no more
    created atlases, a new atlas will be created. And because the image is
    within atlas tolerance, it is guaranteed to fit in a newly created,
    empty atlas in a worst case scenario =).
    
    - The other beautiful part is that for every image we go back to the
      first atlas to attempt upload even if the last image didn't fit
    because images are different sizes and there is always more room
    available, especially for very small images. This way the atlas space is
    not wasted because we don't start every time on the "latest" atlas, we
    always rewind back to the beginning. This only happens relatively rarely
    during image upload, so the performance penalty is once again moot, and
    we gain a lot of performance by utilizing multiple atlases rather than
    having the overflow images all be rendered in separate textures.
    
    OpenGL Non-Core-Profile Batch Rendering Changes:
    
    - Create Batch interface, whose begin() method takes not only a
      BlendMode parameter as usual, but also a texture id, since each batch
      is now going to potentially (not necessarily) be a different texture.
    
    - Create OpenGlBatch, an abstract Batch implementation to provide
      default behavior for OpenGL-based Batch implementations, to avoid code
      duplication.
    
    - Create LwjglBatch, JoglBatch, & GdxBatch concrete Batch
      implementations that extend OpenGlBatch. This gets rid of the static
      inner Batch classes that were nasty and had a ton of code duplication.
    
    - Create OpenGlBatchRenderBackend, an abstract BatchRenderBackend
      implementation to provide a ton of default behavior for OpenGL-based
      Batch implementations, to avoid code duplication. In fact, the
      BatchRenderBackend implementations are so similar that most of the real
      code is in here.
    
    - Make OpenGlBatchRenderBackend use abstract OpenGL calls, since the
      only real difference between the BatchRenderBackend implementations is
      the way in which OpenGL calls are invoked.
    
    - Make LwjglBatchRenderBackend, JoglBatchRenderBackend, &
      GdxBatchRenderBackend extend OpenGlBatchRenderBackend, and implement
      the abstract OpenGL methods from openGlBatchRenderBackend by simply
      forwarding the actual OpenGL calls from either LWGJL, JOGL, or LibGDX
      libraries. Only the OpenGL constants and methods that are actually used
      are implemented, not the entire collection, although that will become
      useful in the future for Nifty to have it's own complete OpenGL
      abstraction (can't do everything in one commit ;).
    
    - Make OpenGlBatchRenderBackend fully OpenGL ES compatible. It only uses
      calls that are available in OpenGL ES, which also works fine with
      regular "desktop" OpenGL. OpenGlBatchRenderBackend is a compatibility
      class; it seeks to provide the broadest application for classes which
      extend it. It does not use any core-profile functionality - that is a
      separate project.
    
    - Refactor duplicated fillRemovedTexture system property into
      BatchRenderConfiguration, and rename it fillRemovedImagesInAtlas
      because that is way clearer. Create fillRemovedImagesInAtlas method in
      BatchRenderBackend interface, so that BatchRenderDevice can inject the
      BatchRenderConfiguration value into the BatchRenderBackend
      implementation.
    
    OpenGL Core Profile Batch Rendering Changes:
    
    - Core Profile BatchRenderBackend's do not yet support multiple texture
      atlases or non-atlas textures in this commit, although that will be
      following shortly. The methods and framework are present, just not
      implemented yet. This won't cause any problems as long as all your stuff
      fits in one atlas. If it's a problem, you can temporarily use the
      parallel non-core profile BatchRenderBackend.
    
    - Core Profile classes are as lightly refactored as possible while still
      adapting to the new framework. This is a work in progress, so there is
      still a lot of code duplication here, and a lot of potential for future
      refactoring.
    
    - Create LwjglBatchCoreProfile, JoglBatchCoreProfile, &
      GdxBatchCoreProfile, which implement the Batch interface. These
      classes are simply extracted almost exactly from their original
      BatchRenderBackendCoreProfile counterpart.
    
    BatchRenderConfiguration:
    
    - Simple class that uses "LibGDX-style" preferences to cleanly pass
      user-options to BatchRenderDevice without the need for a million
      telescoping constructors or complex Builder patterns.
    
    - Allow easy configuration of old & new parameters: atlas size, atlas
      padding, atlas tolerance, initial number of atlases, whether to
      unload / dispose images between screens (requiring reupload) or not,
      whether to use high quality texture filtering, and whether to fill in
      removed image gaps in the atlas or not.
    
    - These configurations are all very well documents and have nice, sane,
      tested defaults so that you don't even have to configure any of these
      options unless you really want to.
    
    BatchRenderDevice:
     - Create additional constructor to receive a BatchRenderConfiguration
       instance
     - Make original constructor use BatchRenderConfiguration defaults
     - Refactor clipping code into inner Clipping class - increases clarity
       and prepares it for moving into its own class eventually
     - Overall refactoring and cleanup
     - Add textureId parameter to a lot of methods, such as addQuad, since
       we can't assume quads are part of a specific texture anymore.
       Everything is refactored to remove the assumption about everything being
       rendered to the same texture. Everything in this class passes around a
       texture id as necessary.
     - Add a ton of documentation to the top of the class explaining everything.
     - Implement image caching for when the BatchRenderConfiguration option
       is set for not disposing of images between screens. When this option is
       set to false (don't dispose / unload between screens), screen
       re-transitions are lightning fast and buttery smooth because after
       visiting a screen once, the images are permanently uploaded, and you
       can't run out of atlas space ;).
     - Add even more debugging log messages.
     - Each atlas has an accompanying TextureAtlasGenerator.
     - Much of the changes in this class are changing methods that used to
       assume acting on a single atlas to work with multiple atlases
       instead, including passing around a texture id.
    
    BatchRenderImage:
    
     - This class was badly in need of an overhaul, and it sure got one -
       almost a complete rewrite. Because the upload() method is internal to
       the BatchRenderImage itself, much of the multiple texture atlas logic
       and non-atlas texture logic is in this class.
     - Add a reupload method that takes a texture id and
       TextureAtlasGenerator. It is necessary for when the image fails to
       upload to the original atlas, then it must be able to reupload to a
       different atlas with it's accompanying TextureAtlasGenerator.
     - Add a lot of commentary to this class.
     - Add a lot of very useful debugging log messages so you can see what's
       happening with multiple texture atlases and non-atlas textures
       easily.
    
    TextureAtlasGenerator:
    
    - Add 28 tests for TextureAtlasGenerator
    - Create new method shouldAddImage that checks whether an image is
      within atlas tolerance
    - Delete unused TextureAtlasGeneratorException class
    - Result is now "Nullable", meaning that you can get a null Result
      returned when attempting to add an image to an atlas. That just means
      that the iamge was not within atlas tolerance. Anyway, the null Result's
      are handled perfectly by BatchRenderImage, and by the
      TextureAtlasGenerator tests.
    - Add a ton of documentation to this class.
    
    BatchRenderBackend:
    
    - Add a ton of documentation
    - Add some new methods for managing non-atlas textures
    - Modify atlas methods to take a texture id
    - Add a couple new methods for configuring settings from
      BatchRenderConfiguration
    - Add a createBatch factory method to return the specific concrete Batch
      implementation for use with OpenGlBatchRenderBackend - polymorphic
      Batch's
    - Add a generic type specifier to the class to specify the type of
      concrete Batch implementation, mainly for use with the createBatch
      method.
    
    Image IO:
    
    - Delete nasty duplicate ImageData interfaces in nifty-renderer-lwjl &
      nifty-renderer-jogl2
    
    - Delete nasty duplicate ImageData implementations, TGAImageData &
      ImageIOImageData in nifty-renderer-lwjl & nifty-renderer-jogl2
    
    - Rename ImageData interface to ImageLoader, since that's what it is.
    
    - Rename ImageIOImageData & TGAImageData to ImageIOImageLoader &
      TGAImageLoader, respectively.
    
    - Create ImageLoaderFactory for creating concrete ImageLoader instances
      based on the image filename extension. This code was duplicated all
      over the place.
    
    - Move ImageLoader interface, ImageLoaderFactory, TGAImageLoader, &
      ImageIOImageLoader to nifty-core/render/io where it belongs
    
    Mouse cursors:
    
    - Add enable() & disable() methods to MouseCursor interface for polymorphic mouse
    cursor handling (no more casting or instanceof checks, yay!)
    - MouseCursor implementations now take a filename & NiftyResourceLoader in
    their constructors to keep messy image loading code internal
    
    Faux changes:
    
    There are some files that appear to have every line changed but that is
    not the case at all; it is just git stripping out the evil CRLF
    characters.
  3. @3xp0n3nt

    Refactor examples.

    3xp0n3nt authored
    Jogl:
    
    - Fix JOGL mousewheel that didn't work
    
    - Refactor JOGL example loading to provide a clean, consistent way to
      run the examples
    
    - Organize JOGL examples into subpackages with a naming convention that
      makes sense and is consistent with nifty-examples
    
    - Add more JOGL examples, more could be added easily now due to the easy
      way they can be loaded
    
    - Add JOGL sound since there currently isn't any - use
      PaulsSoundsystemSoundDevice with JavaSound (only real option)
    
    - Change JOGL example rendering from old to batch mode - old mode
      crashes and is, well, old :P
    
    Other:
    
    - Create missing TutorialDemoMain NiftyExample implementation in
      nifty-examples
    
    - Delete obsolete, commented out tutorial examples for java2d, jme, etc.
    
    - Change initial atlas size for Android examples in
      nifty-examples-libgdx from 2048 to 1024
    
    - Set useCoreProfile to false in
      nifty-examples/default-controls/ControlsDemo for testing
      non-core-profile batch rendering
    
    - Fix code formatting throughout the examples files affected by these
      changes
    
    - Faux changes due to stripping out of nasty platform-dependent CRLF
      characters (newline normalization)
Commits on Jan 12, 2014
  1. @bgroenks96

    Implemented setMousePointer in JoglInputSystem

    bgroenks96 authored
    -setMousePointer via NEWT Window method 'warpPointer'
    -fixed incorrect auto-import from last commit
  2. @bgroenks96

    Implemented setMousePointer in JoglInputSystem

    bgroenks96 authored
    -setMousePointer via NEWT Window method 'warpPointer'
Commits on Dec 31, 2013
  1. Bugfix batched renderer (changes to texture atlas need bind() call!)

    void authored
    Usually when Nifty renders using the batched renderer the texture atlas
    is the only texture bound to GL_TEXTURE_2D for the whole time.
    
    However since we allow dynamically creating, modifying the texture atlas
    it is possible that calls to: clearAtlasTexture(), addImageToTexture()
    and  removeFromTexture() are executed while the texture atlas texture is
    not currently bound.
    
    This patch fixes this. Please note that we call bind() directly in the
    method and therefore potentially too often. This is not a problem for
    clearAtlasTexture() and removeFromTexture() because they will be called
    just a few times (or only once for clearAtlasTexture()). For
    addImageToTexture() we bind the texture atlas for each call of that
    method with is not optimal but shouldn't matter too much (mot verified
    in detail tho).
    
    Kudos to Andreas Drewke for figuring this one out!
Commits on Dec 29, 2013
  1. @iamtakingiteasy
Commits on Dec 28, 2013
  1. @mkaring

    Added some missing annotations

    mkaring authored
Commits on Dec 25, 2013
  1. @mkaring
  2. @mkaring

    Full refactoring of Nifty

    mkaring authored
     - Applied JSR-305 annotations
     - Fixed potential null problems
     - Got rid of most Null-Objects
     - Implemented enum related storage system
       -> Mainly used for EffectEventId related storages
     - Got rid of Hashtables
     - Added early checks for problems
     - Added a lot of additional log warnings
     - Formatted code to meet Nifty specifications
     - Implemented proper use of XmlPullParserFactory
     - Fixed ID bug
Commits on Dec 14, 2013
  1. @mkaring

    Refactored ObjectPool

    mkaring authored
     - Added JSR-305 annotations
     - Removed pooling of small objects
     - Changed pool to soft reference pool
Commits on Dec 12, 2013
  1. Batch Renderer (LWJGL/JOGL): Fix potential crash render empty batches

    void authored
    This was first discovered and fixed by 3xp0n3nt for the
    LwjglBatchRenderBackend but the same issue exists for the CoreProfile
    renderers as well as the Jogl Batch-Implementations. This commit fixes
    these potential problems as well.
Commits on Nov 20, 2013
  1. #167 Fix BatchRenderBackendCoreProfile (JOGL/LWJGL): enable GL_BLEND

    void authored
    Blending should be enabled for Nifty to render correctly. Usually the
    RenderDevice-Implementations do that in their render() method. The new
    batched render backends for core profile did not do that yet. This
    commit should fix that.
Commits on Sep 26, 2013
  1. @3xp0n3nt

    Various minor fixes.

    3xp0n3nt authored
    Details:
    
    - Add compile scope to xpp3 dependency in core pom. The scope was
    missing, and the default is 'compile', anyway. It's best not to rely
    on the defaults.
    
    - Fix spelling errors in NiftyInputConsumer and ControlsDemo.
    
    - Remove javadoc for nonexistent parameter in BatchRenderBackend.
    
    - Add @Override to toString method in ResolutionControlJOGL.
    
    - Fix getScreen method in ControlsDemo.  The getScreen method returns
    "demo" when it should return "start". The "demo" screen is the second
    screen in the ControlsDemo example. If someone were to use this method,
    they would miss the intro on the "start" screen.  Plus, all the
    getScreen method in every other NiftyExample implementation return
    "start".
    
    - Move comment to the correct location. Move the "internal
    implementations" divider comment above the first private method in
    LwjglBatchRenderBackend, where it should be. There is one private method
    that is above the comment.
    
    - Fix parsing of the "fillRemovedTexture" property. In the LWJGL and JOGL
    batch render backends (both core and non-core), fix the parsing of the
    boolean system property called "fillRemovedTexture". The current
    implementation doesn't respect the default setting; it will always be
    false, even if the default setting is set to true. The problem is that
    it should use the parseBoolean method instead of the getBoolean method
    because getBoolean tries to call System.getProperty, when
    System.getProperty is already being called, so it would result in a
    redundant call to System.getProperty, whereas the parseBoolean method
    just simply converts the result of System.getProperty from a String to a
    Boolean, if the value is "true" or "false", which is exactly what we
    want.
    
    - Fix crashing bug in LwjglBatchRenderBackend. Don't attempt to render an
    empty batch, i.e., if its vertex buffer is empty, because the render
    method will attempt to access non-accessible elements, throwing some
    nasty exception and crashing the program. This happens when the batch
    pool reaches maximum capacity, causing it to double in size, i.e., from
    2 to 4, and the problem is that in some cases it will only have enough
    data for the 3rd batch, and the 4th batch will be completely empty.
    
    - Fix example with dynamic drop down list. The problem is that there is
    not enough room for the dynamic drop down list to be inserted above the
    static drop down list in the drop down example, so increase the size of
    the spacer panel between them from 8px to 70px to make room. Otherwise
    they overlap, which looks bad. This may be a bug in Nifty, as it seems
    like it should make space on the fly instead of having to manually do
    it.
Commits on Aug 20, 2013
  1. JOGL: access to unprocessed events added and fixed char conversion newt

    authored void committed
    Conflicts:
    	nifty-renderer-jogl2/src/main/java/de/lessvoid/nifty/renderer/jogl/input/JoglInputSystem.java
Something went wrong with that request. Please try again.