My Writings. My Thoughts.

JogAmp BOF Siggraph 2013

// August 1st, 2013 // 1 Comment » // Uncategorized

The JogAmp project had a BOF session at this years Siggraph convention. They presented a lot of amazing projects that use JogAmp. You can find the original session video at youtube.

As a part of their presentation they showcased Nifty (look for it at 0:20:54 but make sure you watch the whole video too!) with some slides, a demo and a showcase video that we’ve prepared for them. The original video was cut a bit because of the time limitations of their presentation.

However the original full-length video is far too awesome so we’d like to show it to you right here :)

Featuring (in the order of appearance):

Thanks for providing footage and/or demo versions people! :)

JogAmp BOF Siggraph 2013 – Full Nifty GUI games showcase from void on Vimeo.

Have fun,
void

Nifty 1.3.3 has been released

// June 22nd, 2013 // 2 Comments » // Uncategorized

Nifty 1.3.3 is mainly a bugfix release and is compatible with older Nifty 1.3.x versions.

The main new feature is the batched renderer for improved rendering speed of more complex GUIs (with many elements) and OpenGL Core Profile support (in native LWJGL/JOGL renderer).

Usage of the batched renderer is easy. Instead of your regular RenderDevice implementation you use the new BatchRenderDevice that Nifty already provides together with the BatchRendererBackend implementation and the size of the texture atlas. The following examples all use a texture atlas of 2048×2048 pixels which worked very well for all Nifty standard examples.

Examples:
Continue Reading

Inside Niftys RenderDevice and how to speed it up (Part 2/2)

// April 1st, 2013 // 4 Comments » // design

Welcome back to the second part of this two part mini series. Today we’ll speed up the Nifty rendering process. So fasten your seat belts – it will be a long and rough ride! :)

In the first part we’ve identified several problems that we’d like to fix today:

  • primitive/polygon submission is not optimal and requires way too many GL calls
  • we switch GL state very often, especially enabling/disabling texturing while rendering and switching the current texture costs performance
  • we enable/disable and change the clipping rectangle very often (eventually)
  • we change other states like the blend mode. Not a lot but it is still happening if you ask for it within your screen (f.i. using some effect)

So let’s tackle these issues one at a time.
Continue Reading

Correctly configure jdk14-logging (guest blog post by Ben)

// March 16th, 2013 // 3 Comments » // Uncategorized

After being puzzled for a while why he wasn’t able to configure logging in jME-Nifty properly Ben (“ben dot foxmoore at gmail dot com”) set aside some time to figure it out. He was kind enough to share his findings with us in this guest blog post :)

So here is Ben explaining a proper way to configure Nifty logging:

It seems that most people who have issues with Nifty’s logs want to cut down on the number shown, but I, on the other hand, wanted to see more. Unfortunately, setting the global logging level to Info caused JME3 to also log lots of information that wasn’t relevant to the problem at hand. I attempted a quick fix using the following code:

public static void main(String[] args) {
        Logger.getLogger("").setLevel(Level.WARNING);
        Logger.getLogger("de.lessvoid.nifty").setLevel(Level.INFO);
        SimpleApplication app = new SimpleApplication() {
            public void simpleInitApp() {
                NiftyJmeDisplay niftyDisplay = new NiftyJmeDisplay(
                     assetManager, inputManager, audioRenderer, guiViewPort);
                Nifty nifty = niftyDisplay.getNifty();
                nifty.loadStyleFile("nifty-default-styles.xml");
                nifty.loadControlFile("nifty-default-controls.xml");
                guiViewPort.addProcessor(niftyDisplay);
            }
        };
        app.start();
    }

However, you’ll quickly realise that this doesn’t actually cause Nifty to display any extra logs. After many hours trying to work out why, I discovered that it’s all down to an intricacy in the way LogManager keeps track of the Loggers in your program. LogManager only keeps a weakReference to each Logger, allowing any that are no longer being used to be garbage collected. Because of this, in the time between line 3 and line 6, the JRE garbage collects the original “de.lessvoid.nifty” Logger created at line 3. When the “de.lessvoid.nifty.Nifty” Logger is retrieved in the Nifty constructor (called by the NiftyJmeDisplay constructor at line 6), a new one is created and it inherits its Level from the rootLogger, which is set to Warning at line 2. (The LogManager keeps a strong reference to the rootLogger so it is never garbage collected.)

A quick (but not very nifty) solution to this problem is to just keep a static (strong) reference to the “de.lessvoid.nifty” Logger in your class, as such:

    private static Logger logger;

    public static void main(String[] args) {
        Logger.getLogger("").setLevel(Level.WARNING);
        logger = Logger.getLogger("de.lessvoid.nifty");
        logger.setLevel(Level.INFO);
        SimpleApplication app = new SimpleApplication() {
            public void simpleInitApp() {
                ...
            }
        };
        app.start();
    }

Ultimately though, the niftiest solution to this problem is to use a custom properties file which specifies to the LogManager how to initialize all of the Loggers. The following “logging.properties” file will initialize the Logging system in the same way as the code above:

handlers=java.util.logging.ConsoleHandler
.level=WARNING
de.lessvoid.nifty.level=INFO

There are two ways to tell the LogManager to use this file. Either use the

"-Djava.util.logging.config.file=pathToLogging.properties"

flag when running your program, or, alternatively, use the following code:

    public static void main(String[] args) throws Exception {
        InputStream inputStream =
             ClassLoader.getSystemResourceAsStream("logging.properties");
        LogManager.getLogManager().readConfiguration(inputStream);
        SimpleApplication app = new SimpleApplication() {
            public void simpleInitApp() {
                ...
            }
        };
        app.start();
    }

Hopefully this should help anyone who comes across the same issue that I did!

(As a small side note, there is one final alternative: LogManager can also use the “java.util.logging.config.class” property. If present, the given class will be loaded, an object will be instantiated, and that object’s constructor is responsible for providing the initial configuration as an InputStream, just as above.)

So that’s it! Finally you can configure logging correctly! THANKS A LOT BEN! :D

void

PS: Nifty 1.3.3 and Nifty 1.4 have already been configured to log less by default. So most people should now be more happy with the new defaults. But if you really need the logging to debug an issue you now can do it properly – thanks to Ben :)

Inside Niftys RenderDevice and how to speed it up (Part 1/2)

// March 10th, 2013 // 6 Comments » // design

When I started Nifty my mindset was like, “well, games can render millions of polys each frame so throwing a couple of hundred textured polys at the GPU shouldn’t hurt performance that much”.

Well, I was wrong.

To achieve a somewhat high performance you still have to play by the GPU rules. Simply throwing polys at the GPU and expect the best rendering performance doesn’t really work. In this two part series of blog posts I’ll try to explain what basically sucks in the current way we render things and what we’ve done in the last couple of months to achieve better rendering performance.

There is of course always room for more improvement. One thing I’d like to tackle in the future and especially in Nifty 2.0 would be to render only the parts of a scene that have changed. Since the best performance you can ever get is not to render :) But since this is a bit more involved for now we’re stuck with the “render the whole GUI each frame” approach of current generation Nifty. BUT at least we can make Nifty render fast. Very fast.
Continue Reading

Updated Manual for Nifty GUI 1.3.2 available

// November 12th, 2012 // 2 Comments » // docs

The updated Manual for Nifty GUI 1.3.2 is now available as a sf.net file download: nifty-gui-the-manual-1.3.2.pdf

Nifty GUI Manual 1.3.2

The changes are marked in the document but here is a summary of everthing that has been added:

  • Grammar and spelling corrections thanks to wezrule
  • Get Nifty Version String Feature Description
  • (Short) description of imageMode=”subImageDirect:x,y,w,h” Feature
  • Padding feature description including lots of examples with screenshots
  • Margin feature description
  • Renderorder feature description
  • Nifty event consuming and disable flags description
  • Description of general mouse event processing changes in Nifty 1.3.2
  • Dynamically changing effect parameters example

:)
void

Nifty GUI Editor Project

// November 8th, 2012 // 1 Comment » // sightings

There is a Nifty editor project started by Cristiano Aguzzi which looks very promising. It allows you to create Nifty GUI XML by simply adding Nifty Elements and Controls with drag’n'drop!

http://niftyguieditor.altervista.org/

It’s a Java Swing application that uses the Nifty Java2D renderer for preview. This means you can change Element properties and see the changes in realtime! Pretty, erm, Nifty! :D

Nifty 1.3.2 contributors kudos

// October 10th, 2012 // 2 Comments » // Uncategorized

Well, this was really planned to be a part of yesterdays release announcement but somehow I missed to include it :/

There are a lot of people worth mentioning here that have helped in Niftys development in one way or another, be it forum posts, comments, bug reports or emails. Actually there are countless people and I’d not be able to list them all! But all of that feedback – may it positive or negative – is greatly appreciated! Keep it coming and thanks A LOT for it!

This time I’d really like to mention a couple of special people that have provided direct patches and pull requests for Nifty 1.3.2. First of all there is:

Martin Karing (nitram) of http://illarion.org/

who provided countless suggestions and patches. He rewrote the Slick2D renderer and pretty much rewrote the Tabs control to make it actually usable. So extra special kudos go out to Martin! :D

Other Nifty 1.3.2 contributors I’d like to thank for improving Nifty are – in alpabetical order:

Jeremy Woertink / jwoertink
Joachim Durchholz / toolforger
Jonathan Fischer Friberg / odyssomay
Mark / ractoc
Tony Ivanov / telamohn

Thank you all. You rock! And see you all in Nifty 2.0! =D

void

Nifty 1.3.2 finally arrived

// October 8th, 2012 // 11 Comments » // release

Nifty 1.3.2 is mainly a bugfix release and is compatible with Nifty 1.3.1. There are a couple of nifty new features available too :) We’ve counted 175 individual changes which is A LOT!

There will be an updated Nifty Manual available soon. Until it is available you can find out what’s new in the Nifty 1.3.2 change log (sf.net)

And here are the other Nifty links:

Nifty 1.3.2 Download Folder at sf.net
Nifty 1.3.2 Maven Projects Page (browse the JavaDoc online!)
Get a nightly jME3 build with Nifty 1.3.2 (jME3_2012-10-08.zip+)
Webstart – Nifty Default Controls Example (1.3.2)
Webstart – Nifty Standard Examples (1.3.2)

For Maven simply add our sf.net Nifty Maven Repo to your pom.xml:

  
    
      nifty-maven-repo.sourceforge.net
      http://nifty-gui.sourceforge.net/nifty-maven-repo
    
  

and upgrade your dependency to 1.3.2:

    
      lessvoid
      nifty
      1.3.2
    

Have a lot of fun with Nifty 1.3.2! The best Nifty since Nifty ;-)
void

java.util.logging (jdk14 logging) oddities explained (and fixed)

// April 1st, 2012 // 17 Comments » // bubble, design

Usually when you add logging to your application you create a java.util.logging.Logger that has the same name as the class you use the Logger in. Your code might look like this:

package some.test;

import java.util.logging.Logger;

public class Main {
  private static Logger log = Logger.getLogger(Main.class.getName());

  public static void main(final String[] args) {
    log.info("test");
  }
}

This works well and you get something like this as the log output:

01.04.2012 19:10:39 some.test.Main main
INFO: test

Now we can easily change the configuration of this logger and change the Loglevel. So for instance when we don’t like any logging we can disable logging for this class either using a configuration file or do it directly from code like so:

Logger.getLogger("some.test").setLevel(Level.OFF);

and the class will not log anymore.

Sometimes doing this in Nifty and using the name “de.lessvoid.nifty” for instance to shut off the logging refused to work. Some classes simply didn’t stop logging at all. What’s going on?

After a long headache we’ve finally found out!

Nifty used some special logger names for eventbus and inputevent logging. Both loggers used special names that did not relate to any class because there where several classes that would need to log those events. So a special name, like “NiftyEventBusLog” made sense for me.

In some places we had code like that:

package some.test;

import java.util.logging.Logger;

public class Main {
  private static Logger differentLog = Logger.getLogger("SpecialLog");

  public static void main(final String[] args) {
    differentLog.info("test");
  }
}

I somehow expected the loggername in the log to be “SpecialLog” since it’s the name of the logger. But in fact we get something else:

01.04.2012 19:24:41 some.test.Main main
INFO: test

O_o

The information still shows “some.test.Main” since this is the class that actually logged!

If you now try to disable logging for this class, like we’ve seen above:

Logger.getLogger("some.test").setLevel(Level.OFF);

YOU WOULD STILL SEE THE LINE IN THE LOG – even though you’ve disabled it (kinda) :-)

Of course to fix this you would need to disable the “SpecialLog” additionaly to “some.test.Main” but that’s pretty odd since you usually don’t know the exact names of all loggers beforehand.

So to make a long story short Nifty now (current git) removed all the special loggers and always only uses the logger with the name of the current class. When you now disable a logger you should be pretty sure that you really disable any output with that name ;-)

void

EDIT

I just realized that it would be very helpful to give you the actual logger names you need to disable when you still use Nifty 1.3.1:

  • “NiftyInputEventHandlingLog”
  • “NiftyEventBusLog”
  • “NiftyImageManager”