Archive for design

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.

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.

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) {"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:


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) {"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


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:


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 ;-)



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”

now git replaces svn completely and Nifty 1.3.1 is scheduled

// September 15th, 2011 // 5 Comments » // design

The idea to keep svn around for a bugfix release 1.3.1 while keeping the main development for Nifty 1.4 in git sounded reasonable at first. But since we’ve got so quickly used to git going back to svn each time really felt odd :) And although its possible to use git and svn together it kinda made no sense to keep svn around at all. So now everything is git which makes things more clear. Good bye svn!

So there is now a 1.3.1 branch in git. But wait! Doesn’t Nifty consist of lots of individual jars (nifty, controls, style, renderers, sound-system implementations and so on)? So we need a branch for each individual jar, don’t we?

Yes, but fortunately we can combine all of the individual maven projects into a multi-module maven project. This way we can now build the nifty-core project together with all of the dependent jars. This gives us the additional benefit to use the parent pom to define versions for plugins we use as well as common dependencies in one place instead of all the individual poms.

To combine the different repositories into one we’ve used yet another feature of git. It’s possible to treat another git repository as a remote repo when both exist on the same filesystem. And this his how it works:

git remote add <name-we-want-to-give-this> /path/to/other/repo/.git
git fetch <name-we-want-to-give-this>

And that’s all! We can now merge with this remote one exactly the same as with any regular branch! :)

So with all of the projects merged into one repository and with all of the maven multi-module setup in place everything looks pretty again. Instead of the individual projects/repos we only need to branch a single git repository/maven project. Here is the Nifty 1.3.1 Branch in the Git Repository.

The current development is concentrating on Nifty 1.3.1. This version will contain bugfixes and improvements based on the Nifty 1.3 release. 1.3.1 will be compatible with 1.3 and will especially improve Niftys performance. For instance with some of the latest commits Nifty will now generate much less new objects each frame which will reduces the amout of GC runs necessary by quite a bit already :)

There are some other performance improvements scheduled as well especially to improve the rendering speed of text elements.


ListBox Overhaul, new and improved API available and some more

// December 13th, 2010 // 4 Comments » // demo, design, docs

The ListBox has been greatly improved and got itself a new Nifty Java API. You can find an example right here (click the image for a webstart demo) or keep reading for all the details below.


You can check the first example of the new ListBox online with the following Webstart URL:

The source code of this project is available online. You can check out the source directly from SVN using or you can browse it online here:

And if that is not enough … we’ve done the same new API treatment to the CheckBox and we plan to do the same to the remaining Nifty Standard Controls!

Reference in the Wiki

You can find a complete reference about the new standard controls in Nifty 1.3 already on the Wiki (for the ListBox and the CheckBox):

And you can keep reading about all the little Nifty details we’ve changed and improved and especially why.


Tired of Nifty XML? Try the new Nifty Builder Java classes! :D

// September 4th, 2010 // 11 Comments » // design, docs

In order to improve the usability of Nifty, Nifty user arielsan of gemserk has started creating a “Builder Pattern” based way to create Nifty GUIs. These classes can be used from within java to create a Nifty GUI without the need for an external xml file.

We have improved the solution together and there is a Nifty ScreenBuilder class available as your starting point. Here is a quick example what you can do with it:

Screen mainScreen = new ScreenBuilder("main") {{
  controller(new ScreenControllerExample());

  layer(new LayerBuilder("layer") {{

    panel(new PanelBuilder() {{

This should really read very well. We create a new Nifty Screen, add a ScreenController, a single Layer with a backgroundColor and a panel which is centered in the middle of the layer.

Please Note the double “{” and “}” characters. We’re creating anonymous inner classes with an initialize block to have a nice and readable form.
You can use the Nifty Builder to create your GUI completly in Java and without the need for a Nifty XML file now. Another use would be to do rapid prototyping of your GUI directly within Java. And you even have support from your IDE like autocompletion and javadoc too.

Please Note:

As we’re creating annonymous inner classes each time we add a new xxxBuilder() {{ }} method and we’re nesting them it’s possible to access methods from the previous annonymous class and that could be confusing because we could misconfigure the parent element. So it’s probably best to only use methods from the current Builder class.

Ariel also wrote an example GUI using the Builder mechanism which is part of the Java2d Renderer tests but can be used with other renderer systems too of course. You can find it in svn or use this direkt link to the file:

Have fun,
void in cooperation with arielsan =)

Nifty User zozo64 creates Basis Drag and Drop Demo!

// June 28th, 2010 // 1 Comment » // bubble, demo, design

See! This is what I’ve meant! :)

Nifty gives you an easy to use framework that you can extend with your own ideas. Just like Nifty user zozo64 did. Nifty is missing drag and drop support? No problem! He created his own! :D

To be honest, he found some bugs too :) but all of that improved Niftys core systems. So that’s a good thing. We’ll probably bring his work as a standard drag and drop control into the standard controls project soon.

For the moment you can take a look at the code. It’s part of the nifty examples project:

And here is a first preview of zozo64 work:

Nifty Basic Drag and Drop from void on Vimeo.

Dynamically Changing Button Text/Width and the Centerlayout

// February 21st, 2010 // 1 Comment » // bubble, design

Jattra tries to dynamically change button text from within Java and he needs a Button that automatically resizes according to the width of the changed text.

You can follow both threads at the Nifty Help Forum at

Read the complete blog post for details.

New Feature – Keyframes for Nifty Effects

// October 27th, 2009 // No Comments » // bubble, design

Well, I’m currently rewriting the old Nifty Introduction Demonstration that somehow didn’t survive my last blog server switch :( It was posted right here but the jnlp disappear. The demo explained some basic concepts of Nifty and it was written in Nifty :) I’m rewritting it now to update it to the current Nifty Standards.

In the process I just want a moving Nifty GUI Logo like this one

So the logo should resize while fading in and keep on resizing while fading out.


Nifty plays well with others and of course with slick2d too

// September 13th, 2009 // 5 Comments » // design, docs

Nifty can be used as a standalone GUI. So when your game enters its menu or option screens Nifty is all there is on the screen and all user input is handled by Nifty.

When using Nifty together with Slick2d this is represented by the NiftyGameState class. Using this class your Slick2d StateBasedGame can easliy switch from your in game state to the NiftyGameState and display the GUI.

But this is not the only way Nifty can be used. You can easily use Nifty to render your in-game GUI too! Nifty plays well with others (as long as they use OpenGL/lwjgl for rendering that is).

It’s not complicated at all and I wanted to write example code that demonstrates how easy it is for a long time. Motivated by a question at the Nifty Forum at I did now :)

What’s demonstrated in the new slick example is, how you can use Nifty to render a GUI on top of a normal slick GameState.

Here is a screenshot of the example which renderes Text from within Slick that changes color when you press the keys 1-3. On top of this it renders a Nifty GUI that responds to mouse events. Additionally if you press 1-3 the colored Nifty boxes start to shake :D

Slick Overlay with Nifty GUI

Slick Overlay with Nifty GUI

You can try it out with the Webstart:

and you can find the example in svn or you can browse it online here: (Java classes) (Nifty XML for the Screen – overlay.xml)

Keep reading the full Article to see the details on how we get this to work and what you need to consider.