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

Nifty Default Controls Example (1.3.1)

Nifty Standard Examples (1.3.1)

Have fun,
void

There are now two main development branches available:

1.3
The branch formerly known as 1.3.1. This branch will be the base for an eventual 1.3.2 release. Mostly bugfixes should go in there but maybe some improvements will find their way into this as well.

master
The main branch and the base for any 1.4 development. This will be an unstable version (1.4.0-SNAPSHOT) for a while but all the new nifty things will be in there.

While speaking of 1.4 there is not yet a final plan for it. We’ll need to sort out all of the bug and feature requests first. Please feel free to suggest other things you’d like to see in the comments or on the forum.

Both branches are available at sf.net and at github. Synchronizing both repos is a manual process at the moment but works pretty good thanks to git!

Ah and one final word about the git repository at sf.net: Unfortunately the sf.net “code / git” menu lists the wrong repository. I’ve talked to their tech support on IRC and this can’t be changed at the moment :/

The “develop” menu has the correct URL which is:

git clone git://nifty-gui.git.sourceforge.net/gitroot/nifty-gui/nifty

So the correct URL ends with “nifty” and not with “nifty-gui”! Sorry about this =)

void

• Nifty 1.3.1 Download Folder at sf.net
• Nifty 1.3.1 Maven Projects Page (You can browse the JavaDoc online here)

When you’re using Maven, you can 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 then you can add this dependency:

    
      lessvoid
      nifty
      1.3.1
    

You can find the nifty-1.3.1-changelog.txt at sf.net.

Here are some informations about Nifty 1.3.1.

GC and other speed improvements as well as Bugfixes

Nifty 1.3.1 should be compatible with 1.3. Its main purpose is improved performance. Nifty has been optimized for better GC performance as well as render performance. You should see more FPS with this version!

Additional standard controls

Thanks to contributions of Nifty user ractoc you can now find a TabsControl, a TreeBoxControl, a ChatControl and a MessageBox in the nifty-default-controls project!

Improved Slick2D Renderer

Thanks to Nifty user mkaring the Slick2D renderer has been greatly updated and improved. So Nifty should work a lot better with Slick2D again.

LWJGL 2.8.2

And last but not least Nifty has been updated to the latest stable LWJGL version 2.8.2. Which was easy since thanks to gemserk LWJGL is in the central maven repository!

Nifty 1.3.1 is not yet in the central. There are still a couple of jars in the Nifty universe that are not available in the central but we’re working on it!

void

You can find some pieces in the Nifty wiki, on the blog that you’re reading right now, in forums like the Nifty Forum at sf.net or the jMonkeyEngine GUI Forum. Basically you have some bits of knowledge here and others somewhere else.

Therefore something we’d really like to do was to consolidate all of Niftys documentation into one single information hub. And so we did … and we’re now proud to present to you:

Nifty GUI 1.3.1 – The Missing Manual

Nifty GUI 1.3.1 - The Missing Manual

The PDF is an epic 110 pages book hosted at sf.net that explains (almost) everything that you ever wanted to know about Nifty! The book will act as both a tutorial/introduction to Nifty as well as an in depth reference of the more complicated matters. The PDF contains lots of code examples, screenshots and illustrations.

I hope you had a great christmas 2011 and that you’ll enjoy reading the manual!

void

PS: In other news Nifty 1.3.1 has been released! Get it at sf.net while it’s hot! I’ll write a proper blog post about 1.3.1 as soon as I’ve got the complete changelog together

So, switching to a new LWJGL version was actually very easy. I’ve just changed the existing dependencies in the pom.xml for the nifty-lwjgl-renderer project to:

  org.lwjgl.lwjgl
  lwjgl
  2.8.1


  org.lwjgl.lwjgl
  lwjgl_util
  2.8.1

and that’s all!

As an additional benefit they created a natives plugin that will unpack all of the LWJGL natives in the target/natives directory. When combined with an eclipse plugin this will even add the natives to the native library location inside of Eclipse and … that’s all!

I’ve added it to the nifty-examples pom.xml and now you don’t need to manually specify the “-Djava.library.path= ” setting when you run any of the examples anymore! Works pretty well!

Great work Gemserk!
void

As it turned out these posts were related to each other and were both coming from the same gaming company Tygron Serious Gaming located in The Hague, The Netherlands. A couple of emails later we’ve identified some things that they’d like to be improved as well as other things to be added to Nifty. Since some of their existing game assets relied on the direct display of HTML data – which Nifty did not supported – they were especially interested in adding basic HTML support to Nifty.

Everything was very friendly and they especially made it clear from the very beginning that they had no interest in messing with Niftys “openness” in any way. That means that everything we’d change or add to Nifty will still be available for free without any added restrictions. I think this is not something that you can take for granted when dealing with a corporation. So in general that is a very nice attitude! Kudos for them for this!

To discuss all of this in more detail they’ve invited me to The Hague and suddenly I was sitting in a train to the Netherlands to meet everyone involved in the project. Travelling to discuss Nifty related things in a meeting! Amazing!

As expected everybody was nice and friendly. Marieke – their Office Manager – did an excellent job in organizing my travel and Raymond made sure that I’ve ended up at the right place.

Here is a little group photo they did. Look for me in a dark gray shirt in the middle of the picture.

Tygron Nifty GUI Meeting

It was really amazing to see Nifty being used in commercial software running on their big screen in the conference room! And seeing the Java Swing to Nifty GUI converter in action was quite amazing as well!

So what do you, as a Nifty User, get out of this collaboration? Basically two things:

- Niftys memory overhead has been greatly reduced. Nifty is now a lot more GC friendly (improved FPS too)
- The HTML Module is now available and will be a part of Nifty 1.3.1. This adds basic HTML support to Nifty which allows you to generate Nifty elements from basic (!) HTML data.

Well, exciting times for Nifty GUI!

So, I’d like to take this opportunity to (again) thank Maxim, Jeroen and especially Raymond and William for the invitation and of course Marieke for the whole organisation!

Thank you Tygron!
void

About Tygron Serious Gaming

Tygron Serious Gaming is a serious game developer located in The Hague, The Netherlands. It specializes in bringing real-life complex management challenges that have multiple actors with unique tasks and different interests into a ‘multiplayer serious game’, making use of modern game technology.

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.

void

Consequently the Nifty projects available in the git repo at sf.net have been updated to 1.4-SNAPSHOT. 1.4 will be build with Jenkins so that you can find nightly builds of 1.4-SNAPSHOT Nifty projects in the Maven Repo for Nifty as well.

If you had svn write access to the Nifty projects before you will be able to push to git now too.

There is one exception tho: The main development for Nifty happens on the “develop” Branch of the individual projects. Consequently the “develop” branch will be automatically build and deployed by Jenkins (1.4-SNAPSHOT). Pushing to “master” is restricted and is reserved for release candidates. This should allow the development to continue freely on the “develop” branch (or on any other branches as well!).

On another note 1.4 is not scheduled yet in any way and should be considered experimental – at least for the time being. So make sure you wear a safety helmet in case it explodes and stuff

void

If you had svn write access you should be able to push to the remote git repository.

We’ll keep the SVN repos for bugfixes and an eventually 1.3.x release. Everything else will happen in git

void