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.

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

Quote

- 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.

Quote

- 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.

Quote

- 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.

Quote

- 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.

Quote

- 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.

Quote

- 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.

Quote

- 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?

Quote

- 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.

Quote

- 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.

Quote

- 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.

Quote

- 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.

Quote

- Does gimbal lock occur with JME?

Don't think so, Quats all the way.

Quote

- 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.

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.

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.

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.

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.

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

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:

Quote

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

Quote

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

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.

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

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.

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

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.

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/

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org