Some newbies questions about JME...

Engines, Libraries and Tools jMonkeyEngine
#16

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

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]

[quote]org.lwjgl.LWJGLException: Could not switch mode.
at org.lwjgl.opengl.LinuxDisplay.nSwitchDisplayMode(Native Method)
[/quote]
http://lwjgl.org/forum/index.php/topic,2483.0.html

[quote]Caused by: org.lwjgl.LWJGLException: No modes available
at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:560)
at org.lwjgl.opengl.Display.(Display.java:111)
… 2 more
[/quote]
Sorry, I prefer JOGL (and avoid using the exclusive full screen mode).

#17

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.

#18

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 >:(

#19

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.

#20

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.

#21

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

#22

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

#23

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:

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


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

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

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.

#24

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:

#25

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

#26

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

#27

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.

#28

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.

#29

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

#30

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.

#31

As I was unable to rewrite StandardGame, I wrote a very simple class that builds a window, create a canvas, put this canvas into the window and use an extended implementation of SimpleCanvasImpl in order to take into account the state machine. Of course, I would have preferred to fix the bug in StandardGame. I submitted a bug with a small test case on Google Code. If you have some time, can you give a look at it? I’m a beginner in JME, maybe I forgot an obvious thing but I spent days, I posted my source code, nobody told me I was doing something wrong.

It is time to make this come true; without StandardGame, it is quite more complicated.

#32

The problem is nobody has been willing to take the reigns of the JOGL support and keep it updated and fix bugs. Since it’s obviously something you’re interested in and something you have experience in you should lobby on the jME forum to become a contributor so you can commit your own changes (after posting the changes for approval on the forum).

I’ll try to have a look at the bug, but unfortunately my time is not my own right now and I have very little time for anything game development related.

#33

I am already a contributor but the password on Google Code doesn’t work :frowning:

Ok, I understand your position, do what you can.

#34

What do you mean when you say the google-code pwd does not work?

1. Can you log into google?

1.1 No. Troubleshoot the problem using this google help page.

1.2 Yes. Log in and go to page http://code.google.com/hosting/settings. The ‘googlecode.com password’ which is listed on this page - is this the pwd that you have been using? Try regenerating this password if it does not work. Also when logging in through SVN, please note that the username is not the full e-mail address if you are using a gmail account, but just the first part of it - in case of ‘myname@gmail.com’ - just ‘myname’

#35

Thank you for your help. I was using the wrong password. :smiley: I will submit my fixes later, I need to sleep and it would be better to clean my source code once again.