Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Some newbies questions about JME...  (Read 21512 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Posted 2008-11-12 23:58:41 »

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

Offline gouessej
« Reply #1 - Posted 2008-11-13 06:52:11 »

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?

Offline kevglass

JGO Kernel


Medals: 186
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2008-11-13 08:45:24 »

From my recent foray into JME..

Quote
- Is it still maintained?

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.

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #3 - Posted 2008-11-13 11:53:17 »

Yes, the majority of the original authors have moved on but new maintainers have stepped up.
It doesn't reassure me  Sad

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.

Offline gouessej
« Reply #4 - Posted 2008-11-13 22:40:34 »

 Angry 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  Sad

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2008-11-14 10:40:28 »

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.

Offline kevglass

JGO Kernel


Medals: 186
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2008-11-14 11:10:41 »

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

Kev

Offline gouessej
« Reply #7 - Posted 2008-11-14 12:06:51 »

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.

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2008-11-14 12:16:51 »

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 Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #9 - Posted 2008-11-14 13:28:09 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #10 - Posted 2008-11-14 15:38:18 »

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?

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #11 - Posted 2008-11-14 17:04:30 »

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.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #12 - Posted 2008-11-14 20:02:12 »

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.

Offline gouessej
« Reply #13 - Posted 2008-11-14 21:42:22 »

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

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #14 - Posted 2008-11-15 00:25:47 »

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

Offline gouessej
« Reply #15 - Posted 2008-11-15 09:24:00 »

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 ( Huh 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)
http://lwjgl.org/forum/topics/on-missing-glut-functions/2483/view.html
Quote
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).

Offline sunsett

Senior Duke




ribbit!


« Reply #16 - Posted 2008-11-15 21:32:37 »

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.
Offline gouessej
« Reply #17 - Posted 2008-11-16 21:37:53 »

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  Angry

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #18 - Posted 2008-11-16 21:57:39 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #19 - Posted 2008-11-17 09:22:21 »

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.

Offline sunsett

Senior Duke




ribbit!


« Reply #20 - Posted 2008-11-17 19:05:21 »

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  Angry

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).
Offline gouessej
« Reply #21 - Posted 2008-11-18 12:19:13 »

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

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

Offline gouessej
« Reply #22 - Posted 2008-11-28 12:30:55 »

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.

Offline sunsett

Senior Duke




ribbit!


« Reply #23 - Posted 2008-11-30 13:45:02 »

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. Wink
Offline gouessej
« Reply #24 - Posted 2008-12-01 06:40:07 »

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. Wink
I tried to use the KeyBindingManager and the GameControlsManager with StandardGame, none of them worked.  Sad I have written a tiny class to "replace" StandardGame until this bug is fixed.

Offline sunsett

Senior Duke




ribbit!


« Reply #25 - Posted 2008-12-01 13:35:13 »

Take a look at the wiki...they work fine and lots of people use it in their games with StandardGame...including me.  Tongue
Offline gouessej
« Reply #26 - Posted 2008-12-02 06:37:43 »

Take a look at the wiki...they work fine and lots of people use it in their games with StandardGame...including me.  Tongue
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.

Offline sunsett

Senior Duke




ribbit!


« Reply #27 - Posted 2008-12-02 13:23:05 »

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.
Offline gouessej
« Reply #28 - Posted 2008-12-02 14:48:23 »

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  Grin It is a good temporary solution.

Offline sunsett

Senior Duke




ribbit!


« Reply #29 - Posted 2008-12-02 19:11:35 »

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.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (43 views)
2014-10-17 03:59:02

Norakomi (33 views)
2014-10-16 15:22:06

Norakomi (26 views)
2014-10-16 15:20:20

lcass (30 views)
2014-10-15 16:18:58

TehJavaDev (60 views)
2014-10-14 00:39:48

TehJavaDev (60 views)
2014-10-14 00:35:47

TehJavaDev (50 views)
2014-10-14 00:32:37

BurntPizza (66 views)
2014-10-11 23:24:42

BurntPizza (38 views)
2014-10-11 23:10:45

BurntPizza (80 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!