I downloaded GBUI a while ago … all test code in the project itself woks fine … I also have a small example running in a different project I built just to test out a few things and see if it was even worth while using.
So I started a new project set it up exactlyy like the others but now I keep getting the following error …
SEVERE: Exception in game loop
java.lang.NoSuchMethodError: com.jme.renderer.Renderer.checkAndAdd(Lcom/jme/scene/Spatial;)Z
at com.jmex.bui.BRootNode.onDraw(BRootNode.java:380)
at com.jme.scene.Node.draw(Unknown Source)
at com.jme.scene.Spatial.onDraw(Unknown Source)
at com.jme.renderer.lwjgl.LWJGLRenderer.draw(Unknown Source)
at com.jme.app.SimpleGame.render(Unknown Source)
at com.jme.app.BaseGame.start(Unknown Source)
at app.MainApp.main(MainApp.java:88)
Nov 8, 2009 12:14:50 PM com.jme.app.BaseSimpleGame cleanup
This is really driving me crazy because GBUI works fine everywhere else … anyone seen this error before?? I checked the com.jme.renderer class and the checkandAdd() method does actually exist … this reallt has me stmped. All worked fine when I was playing around but now that I want to get seriouse this happends … what a bummer.
btw. does anyone know of any other gui libraries besides GBUI and FengGUI these two libraries seem to be outdated and not compatible with jme 2.0 … although I did get it working with some 2.0 code . I really need a gui so any help would be appreciated … and I'd rather not use JMEDesktop.
If you post the related code, it may be possible to see an error (if there is one)
GBUI is fully compatible with JME 2.0 - the jars may be out of date, but SVN is most definitely up to date, I completed that a month or more ago. A lot has been going on or I'd publish newer 2.0 jars, but I won't be able to do anything until after my mother's funeral this week, so it'll probably be Tuesday before I post new jars.
It looks as though you may have two versions of JME in your classpath, one with the suggested method, one without…the one without is the one your classpath is telling the code that it should be.
Can you publish your classpath list here? Are you running in an IDE? or command line?
In the last week, I've worked to Maven-ize GBUI (done!) and run into a number of issues where changes in jME break compatibility with GBUI, but I think I've got them figured out. (Currently, jME itself is broken, so beware if you update to the HEAD.) If you want something before standtrooper can get to it, just give me a shout. I can either send you my notes on version compatibility, or I can just shoot you the compiled jars.
The latest of JME 2.0 has some changes to the Spatial as an abstract class. In earlier versions it expected you to implement hasCollisions and findCollisions, but they recently changed it to be final methods in Spatial, which causes GBui to not compile (and I would guess a many other projects out there in the world since they are changing the API).
Changes like this can be a little tough to work with, and it appears that we either need to branch the project to have a JME 2.0 supporting version and a JME 1.0 version or just push forward. I’ll check with Standtrooper on this as to what we can do, and try to provide a fix (currently with my project http://code.google.com/p/aether-rpg/, i’m just using the JME 2.0 that comes with GBui).
I think there should be one tag/version that is compatible to the corresponding jME-Version. (usually for main version there should be a branch but I think that this is not necessary. Bugfixing from down to up and merging the code can really be a mess)
e.g.
- tag the current state that is compatible to 2.0 with jME2.0 compatible (there is a 2.0 branch in jME-svn).
- tag the 2.0.1 fixed version 2.0.1 (as there is a 2.0.1 tag in jME-svn as well)
- the gbui-trunk should be compatible to the jME-trunk.
as soon as there will be a new jME-version gbui can also make a version…
Just one possibility how to handle it…but I think for most developers trunk-compatibilty is most important…