Some newbies questions about JME...

[gouessej]

Hi!

I seriously plan to use JME for my own FPS called TUER. As you may know, for the moment, I use my own engine. I consider that my scientific investigations and experimentations will end in some months and it will be the time to switch to a true engine. I have some questions for you all :
- Is it still maintained?
- Is it already possible to use it with JOGL rather than LWJGL? If yes, is it easily possible to modify the text rendering to use my own bug fixes for JOGL (in TextRenderer.java)?
- Is it possible to use JME without JOAL (for example, is it possible to use only JavaSound, JOGG and JORBIS for the sound support)?
- Is it possible to use JME on low end machines (for example under OpenGL 1.3 with an ATI Radeon 7500 or a Geforce 1)?
- Does it work fine under Solaris?
- Does it work fine with the OpenJDK? Kaffe? GNU Classpath?
- JME is a scenegraph too, does it use a cells-and-portals algorithm? If not, is it possible to modify it so that it uses an implementation of it?
- Does JME contain a system of computation of geographic modifications like the engine of Red Faction 2 (you can break almost all walls, etc...)?
- What kind of spatial subdivisions are available with it?
- Does JME provide graphical hardware accelerated components? If not, is it possible to use it with FengGUI or Slick?
- Does the JME team need a financial help?
- The geometry of my FPS is really extremely simple. If I switch to JME, do I have a chance to get a better frame rate if I use it correctly?
- Does JME include anything that helps to write online games? If not, has someone tried to use it with JGN or Project Darkstar?

I'm sorry, I ask you a lot of questions. I have looked for answers but some people told me some contradictory things, I don't know what to think For example, someone told me that it is possible to use JME with JOGL but it is written in the introduction : "Currently, LWJGL is supported with plans for JOGL support in the near future.". Thank you for reading.

[gouessej]

I have some other questions:
- Does gimbal lock occur with JME?
- Is it possible to use only Java for keyboard and mouse handling and not JInput?

[kevglass]

From my recent foray into JME..

- Is it still maintained?

Yes, the majority of the original authors have moved on but new maintainers have stepped up.

- Is it already possible to use it with JOGL rather than LWJGL? If yes, is it easily possible to modify the text rendering to use my own bug fixes for JOGL (in TextRenderer.java)?

Yes, in JME 2 there is a JOGL renderer. However, the text rendering in JME doesn't rely on JOGL's text renderer. JME's LWJGL is also more tried and tested than the JOGL one. Not sure how many people have tried to use the JOGL renderer in JME.

- Is it possible to use JME without JOAL (for example, is it possible to use only JavaSound, JOGG and JORBIS for the sound support)?

I believe so, but there's no plugin's for their sound system to use anything other than OpenAL via LWJGL last time I checked.

- Is it possible to use JME on low end machines (for example under OpenGL 1.3 with an ATI Radeon 7500 or a Geforce 1)?

Yes, as you can imagine rendering would be limited but the renderer in JME2 attempts to not use things that arn't supported  - for instance, shaders are ignored where shaders arn't supported.

- JME is a scenegraph too, does it use a cells-and-portals algorithm? If not, is it possible to modify it so that it uses an implementation of it?

It doesn't but you could.

- Does JME contain a system of computation of geographic modifications like the engine of Red Faction 2 (you can break almost all walls, etc...)?

No.

- What kind of spatial subdivisions are available with it?

Not quite sure what you're looking for here. The scene is culled using bounding shapes which are hieachial based on the scenegraph. The terrain renderer has some quad tree based stuff in it. I think the approach is general to add the subdivision based on the type of thing being renderer - but you'd need an original author to tell you that for sure.

- Does it work fine under Solaris?
- Does it work fine with the OpenJDK? Kaffe? GNU Classpath?

No idea. LWJGL works under SolarisX86 now I think. The other JDKs as long as they're compatible with core Java they should work right?

- Does JME provide graphical hardware accelerated components? If not, is it possible to use it with FengGUI or Slick?

It has a series of different GUIs implemented for it. I've used FengGUI, BUI, Slick and Thingle on top of JME in different projects, all of which have been fine to work with.

- Does the JME team need a financial help?

They're an open source collective so probably not. Everyone likes to have some cash to spend on things for the project though so I guess they'd like donations.

- The geometry of my FPS is really extremely simple. If I switch to JME, do I have a chance to get a better frame rate if I use it correctly?

Depends how efficient the original implementation was. A highly tuned custom system for a game nearly always out performs a more generic library approach. You sacrifice performance for ease of development. However, if the developers of the library no a bit more about rendering then they might just surprise the author.

- Does JME include anything that helps to write online games? If not, has someone tried to use it with JGN or Project Darkstar?

No, but JGN provides some great integration tools and has been used to write several multiplayer games with JME.

Project Darkstar doesn't provide anything directly related to JME but again has been used to produce several impressive demos with it.

- Does gimbal lock occur with JME?

Don't think so, Quats all the way.

- Is it possible to use only Java for keyboard and mouse handling and not JInput?

Not sure about this, I guess they depend on LWJGL's input routines.

You'd be better to post this at the JME forums though, very active place with lots of users ready to answer.

Kev

Games published by our own members! Check 'em out!

[gouessej]

Yes, the majority of the original authors have moved on but new maintainers have stepped up.

It doesn't reassure me 

Yes, in JME 2 there is a JOGL renderer. However, the text rendering in JME doesn't rely on JOGL's text renderer. JME's LWJGL is also more tried and tested than the JOGL one. Not sure how many people have tried to use the JOGL renderer in JME.

Some JME users told me that the JOGL renderer is no more really maintained, I will have to do something.

Yes, as you can imagine rendering would be limited but the renderer in JME2 attempts to not use things that arn't supported  - for instance, shaders are ignored where shaders arn't supported.

Are VBO ignored if not supported?

The other JDKs as long as they're compatible with core Java they should work right?

TUER crashes under OpenJDK, I don't know why, that's why I asked it.

Don't think so, Quats all the way.

It is not the title of the next James Bond but I often say THE QUATERNIONS ARE NOT ENOUGH!!!!!!!!!!. Quaternions must be used with non eulerian transforms to avoid gimbal lock.

You'd be better to post this at the JME forums though, very active place with lots of users ready to answer.

You're right. Thank you for your precise answers, you helped me a lot.

[gouessej]

  I spent some hours to repair the first test application for the JOGL canvas in JME. The JOGL renderer seems to be absolutely not maintained 

[erikd]

Why not use LWJGL then?
When you use a library like JME, the OpenGL binding is no big deal as you typically don't use it directly. Just use the one that works best.

[kevglass]

Are you sure you're using JME2 not JME1? The JOGL renderer in JME2 seemed to be functioning correct a few months ago.

Kev

[gouessej]

Are you sure you're using JME2 not JME1? The JOGL renderer in JME2 seemed to be functioning correct a few months ago.

Kev

Yes JME 2. It worked fine only if you have a recent graphics card. Lots of try/catch clauses were missing to handle the case your graphics card has no shader for example, I modified JOGLContextCapabilities.

Why not use LWJGL then?
When you use a library like JME, the OpenGL binding is no big deal as you typically don't use it directly. Just use the one that works best.

I just want to use the OpenGL binding that works the best on my view, that is the most reliable, JOGL, what else? JOGL must work reliably inside JME, a few people try to use it, it cannot stay no more maintained. A JOGL renderer that doesn't work is useless in JME.

Nevertheless, you're right about the fact it is not important because you rarely use it directly in JME except when you want to add new features in it, that is my case, I want to add some results of my experiments into JME. When I tested plenty of games for the first version of the Java game tome, I had more problems with games using LWJGL than games using JOGL even proportionally. I don't trust LWJGL, I would have never planned to use JME if there was no JOGL renderer. You know I have used JOGL for more than 2 years, I have no reason to use LWJGL now, I don't see any advantage to do it, I see some drawbacks as I'm not sure LWJGL works fine under Solaris 32 and 64 bits.

[princec]

I'd urge you to stick with LWJGL for JME... it's got a far, far longer track record of success, and nearly all commercially released Java games currently use LWJGL - for a good reason.

Cas

[erikd]

LWJGL games that don't work is by and large the developer's fault, not LWJGL's (relying too much on specific videocard features and screenmodes and such).
I think you won't have that problem with JME because (in my experience) they got LWJGL support right. Just try it.

Games published by our own members! Check 'em out!

[gouessej]

LWJGL games that don't work is by and large the developer's fault, not LWJGL's (relying too much on specific videocard features and screenmodes and such).

Right, same problem with JOGLContextCapabilities in JME.

I think you won't have that problem with JME because (in my experience) they got LWJGL support right. Just try it.

They didn't have JOGL support right whereas I plan to use it. Why would I use LWJGL instead of JOGL? If I repaired the JOGL renderer, why would I use LWJGL?

[erikd]

They didn't have JOGL support right whereas I plan to use it. Why would I use LWJGL instead of JOGL? If I repaired the JOGL renderer, why would I use LWJGL?

Depends on your goals I suppose. Do you want to create your game or work on the JOGL renderer?
If it's the latter, then you made the right choice.

[Matzon]

If you want to use JME then go for it. Choosing a renderer should be the least of your issues. Select the first one - if it works stay with it, if it doesn't choose another one. If none of them works, skip JME or fix something. Fixing a renderer when another one already works(?) is a noble idea, but not relevant if you want to *create* something in JME.

[gouessej]

Depends on your goals I suppose. Do you want to create your game or work on the JOGL renderer?
If it's the latter, then you made the right choice.

I want to use JME for TUER that historically has used JOGL, I want to allow my game to go on working reliably with JME where it was already the case before I decided to use it, I estimate that JOGL was a good choice and I want to go on using it inside JME. Then, I admit it is not simple (it might become even very hard), I have to do the both tasks, repairing the JOGL renderer and using the engine for TUER (contributing to JME too  ).

[Matzon]

I want to use JME for TUER that historically has used JOGL, I want to allow my game to go on working reliably with JME where it was already the case before I decided to use it

Since you're going from a raw binding to a scene graph, why do you care what renderer you're running under? - as long as it works?

Then, I admit it is not simple (it might become even very hard), I have to do the both tasks, repairing the JOGL renderer and using the engine for TUER (contributing to JME too  ).

No, you have the option of not fixing the renderer...

You seem to be fighting damn hard to avoid LWJGL and I fail to see why (if the objective is to get TUER running on JME)? Does it not work for you?

[gouessej]

Since you're going from a raw binding to a scene graph, why do you care what renderer you're running under? - as long as it works?
No, you have the option of not fixing the renderer...

TUER has contained a kind of scenegraph for some months. I think that the reliability depends on the renderer used in JME too.

You seem to be fighting damn hard to avoid LWJGL and I fail to see why (if the objective is to get TUER running on JME)? Does it not work for you?

Honestly, I have rarely had problems with games using JME under Linux except with the game "Stardust" (that uses the LWJGL renderer), do you succeed in launching it? Does your graphics card support FBO? I really fear that my game works on less machines than before because of the use of LWJGL. Lots of people who use TUER are under Linux, some under Mac, a few under Solaris, some under ... AmigaOS ( I don't know how they do), I don't want to "punish" people who don't own a recent graphics card and I don't want to take the risk of relying on another OpenGL binding whereas JOGL has proved to be very reliable. Therefore, I will fight damn hard to avoid changing the OpenGL binding used for TUER and to avoid using OpenAL.

Watch this:

Exception in thread "main" java.lang.NoSuchMethodError: Method org.lwjgl.openal.AL10.alEnable(I)V is not declared as native

org.lwjgl.LWJGLException: Could not switch mode.
        at org.lwjgl.opengl.LinuxDisplay.nSwitchDisplayMode(Native Method)

http://lwjgl.org/forum/topics/on-missing-glut-functions/2483/view.html

Caused by: org.lwjgl.LWJGLException: No modes available
        at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:560)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:111)
        ... 2 more

Sorry, I prefer JOGL (and avoid using the exclusive full screen mode).

[sunsett]

If you're willing to do the work to fix the JOGL renderer then more power to you....I think all the jME devs will support such an endeavor and the only reason that more work hasn't been done is because we all feel more confident in the abilities of LWJGL and really have no reason to really care about JOGL.

[gouessej]

If you're willing to do the work to fix the JOGL renderer then more power to you....I think all the jME devs will support such an endeavor and the only reason that more work hasn't been done is because we all feel more confident in the abilities of LWJGL and really have no reason to really care about JOGL.

I have lots of reason to really care about JOGL unlike you. For the moment, none of my fixes have been included, maybe the JME team has been sleeping for some days lol. I've found a bug in StandardGame!!! When you select JOGL in the settings, your renderer will be the JOGL renderer but the canvas constructor will be the canvas constructor of LWJGL 

[Riven]

The point is that if you wouldn't use JOGL as a renderer, you wouldn't run into all those JOGL bugs in JME.

But I guess that won't change your mind.

[gouessej]

The point is that if you wouldn't use JOGL as a renderer, you wouldn't run into all those JOGL bugs in JME.

But I guess that won't change your mind.

I mainly explore the part of the source code that deals with JOGL, then you might be right. Nevertheless, if the way of coding is the same in the LWJGL renderer (for example, not enough tests or inappropriate tests to avoid crashes on low end machines), I might find some similar bugs in the LWJGL side (but I won't check it, it is not up to me to drive the LWJGL renderer more reliable). I remind you that some programmers using LWJGL try to force a display mode that is unavailable on my machine and I find exactly the same mistake in the JOGL renderer.

Yes, that won't change my mind, I have found some bugs, it is annoying, I have fixed them rather than only complaining or switching to LWJGL. I don't give up, I'm very motivated, the switch to JME will require some months (maybe a full year) to implement all features of TUER with this engine.

[sunsett]

I have lots of reason to really care about JOGL unlike you. For the moment, none of my fixes have been included, maybe the JME team has been sleeping for some days lol. I've found a bug in StandardGame!!! When you select JOGL in the settings, your renderer will be the JOGL renderer but the canvas constructor will be the canvas constructor of LWJGL 

Nobody is sleeping...have you submitted a patch to the forum?  I haven't been developing much in jME lately, but typically stay up on the forums (darkfrog, btw).

[gouessej]

Nobody is sleeping...have you submitted a patch to the forum?  I haven't been developing much in jME lately, but typically stay up on the forums (darkfrog, btw).

I have submitted 3 patches until today on the proper forum. I'm going to submit a fourth patch in some hours to drive the JOGLDisplaySystem class extremely robust  I test if the exclusive fullscreen mode is really supported and if I use it, I test if the display mode change is supported. On some machines, display mode changes are not supported even in exclusive fullscreen mode. If I change the display mode, I restore the previous display mode when the window closes.

  I have forgotten to get out the fullscreen mode when exiting, it would be cleaner. I should sleep more and program a bit less.

[gouessej]

I don't succeed in using the InputHandler (my class that extends it is called  ExtendedMenuHandler). When I press ESC, it should exit but it does nothing. I do this in the handler:

1   2   3

KeyBindingManager keyBindingManager=KeyBindingManager.getKeyBindingManager(); keyBindingManager.set("exit",KeyInput.KEY_ESCAPE); addAction(new ExitAction(serviceProvider.getGame()),"exit",false);

1   2   3   4   5   6   7   8   9   10   11   12

private static final class ExitAction extends InputAction{                 private StandardGame game;                 private ExitAction(StandardGame game){             this.game=game;         }                 public final void performAction(InputActionEvent evt){             this.game.shutdown();         }     }

And in MenuState.java (that extends BasicGameState):

1   2   3   4   5

@Override     public final void update(final float tpf) {         super.update(tpf);         this.input.update(tpf);     }

1	this.input=new ExtendedMenuHandler(serviceProvider,this);

The first piece of code configures the action, the second one defines the action to perform when ESC is pressed, the third one updates the InputHandler each time the update method of the state if called and the last one builds the handler. I tried to debug, the update method is often called but the handler does nothing, pressing ESC doesn't allow to leave the game. I already ask for help on the jmonkeyengine forum but nobody has answered for the moment. Can someone help me? The whole source code is in the package "jme" in my source code on my SVN repository:
https://tuer.svn.sourceforge.net/svnroot/tuer/

I want to do something clean, an InputHandler instance per GameState.

[sunsett]

I would recommend against using the KeyBindingManager personally.  I always use the GameControlsManager as it is much more flexible...granted I'm biased because I wrote it, but still.

[gouessej]

I would recommend against using the KeyBindingManager personally.  I always use the GameControlsManager as it is much more flexible...granted I'm biased because I wrote it, but still.

I tried to use the KeyBindingManager and the GameControlsManager with StandardGame, none of them worked.  I have written a tiny class to "replace" StandardGame until this bug is fixed.

[sunsett]

Take a look at the wiki...they work fine and lots of people use it in their games with StandardGame...including me. 

[gouessej]

Take a look at the wiki...they work fine and lots of people use it in their games with StandardGame...including me. 

I already watched some source code using it, especially Stardust. When I do the same thing, it doesn't work, I created a bug report for it, I investigated for days, it is not a joke. It is an excellent class but it seems not to work with the JOGL renderer. When I call the method update() of the InputHandler in the method update() of a GameState, nothing happens, this is called but nothing happens. When I debug, I see that the keyboard press is not refreshed even though ImputSystem.update() is called in StandardGame.

[sunsett]

Have you made a post to the jME forum about this?  It's not very beneficial posting here as only a small fraction of the jME community ever visits this forum.

[gouessej]

Have you made a post to the jME forum about this?  It's not very beneficial posting here as only a small fraction of the jME community ever visits this forum.

Yes I did it. Only one person answered, he said that he has no time to investigate and that I should rather use LWJGL.

For the moment, the class I wrote to replace StandardGame works fine  It is a good temporary solution.

[sunsett]

What did you end up changing?  I'm the original author of StandardGame...if there's a problem with it I'll make sure it gets fixed if you have a patch to contribute.