Major bug in JME when using JOGL and AWT input system

General Discussions
#1

Hi!

Sorry to disturb you with this but it makes me waste a lot of time in developing the next version of TUER. When using the class StandardGame of JME with JOGL and AWT, it is impossible to listen to the keyboard. I looked for a solution but I failed. Please vote for my bug, it is very urgent, I need to show my game in a conference in February, I’m worried:
https://jme.dev.java.net/issues/show_bug.cgi?id=282

I asked for help and someone answered :

[quote]i’m afraid i have no time to look into it, just use lwjgl for now :slight_smile:
[/quote]
Another one answered :

[quote]While you’re entitled to choose JOGL and it’s IMO good to have people working on that side of things, please bear in mind that most other users are only familiar with LWJGL. I don’t think people have anything against JOGL - in fact when it was not supported there were a lot of people wanting it. But it’s not what most people are using, so the number of people who can help is considerably less.

Personally, I don’t use JOGL, or GameControls or even StandardGame so I really shouldn’t be on this thread at all
[/quote]
In other word, nobody seems to plan to help me. I’m a JME newbie, I can’t solve this problem alone.

#2

You could also follow the advise of just about everybody and use LWJGL instead of JOGL for JME.

But no, you won’t.

Further, just post it on the JME forums, don’t bother us with it.

#3

Thank you very much for your solidarity.

#4

Rivens answer is a bit harsh but has a point. If you insist on using JOGL with JME, fix the problems for youself, because you aren’t developing on your game, but on the JME JOGL binding.

If you have to finish porting your game 'til februrary, use LWJGL and fix the JOGL binding later (if you still want to).

You are just a bit bullheaded with your decisions. Take the easy way - just for once :wink:

#5

You are making life so incredibly hard for yourself.

If I had a deadline, I would never ever bet everything on unproven technology when there was a thoroughly tested alternative, enabled on the flip of a switch.

So… no solidarity from me, you’re just stubborn.

#6

[quote]I need to show my game in a conference in February, I’m worried
[/quote]
No need to worry, there’s always LWJGL to the rescue :wink:

Maybe you should separate your work on TUER from your work on JME and not let TUER depend on such blocking issues in the JOGL renderer from JME. Especially since your game seems to have a deadline.
In other words, develop your game using the LWJGL renderer and when you have more experience with JME and a working game, you can always switch to JOGL and use TUER as a test case for fixing the JOGL renderer in JME.
I bet that when you are at the point that you have a working game in JME/LWJGL, you will have a far easier time fixing the JOGL renderer.

#7

In the worst case, I prefer showing the “old” version of TUER without JME instead of using LWJGL. Using LWJGL would ruin my efforts to drive the JOGL renderer more reliable in JME.

You’re right, my game should not depend on blocking issues in the JOGL renderer. I’m currently implementing a workaround to avoid the use of the class StandardGame. The problem is that 2 days ago, someone submitted a fix that introduced a new regression in the JOGL renderer (I fixed it some hours ago). If this kind of things happens too often, I will have to separate my work from JME so that I can connect and disconnect TUER to JME when I want.

It is not so simple. JME has been designed with LWJGL as a perspective. It is sometimes really difficult to implement some features by using AWT/JOGL.

#8

What features of JOGL do you actually need in TUER? Seeing as it’s functionally identical to LWJGL…

Cas :slight_smile:

#9

You are really really doing this wrong, because you resist to accept advices. Go with JME and LWJGL or continue your game with the old JOGL only setup and leave JME alone alltogether. Avoiding StandardGame just because you don’t want to use LWJGL is just stupid. JME provides an abstraction to subsystems, so use this abstraction. Don’t dare to think abstracting the abstraction away. Fix the JOGL renderer later.

Actually eriks advice to use TUER as a test case is the best thing you can do to achieve both of your goals. Fix the game and fix the JOGL renderer.

#10

[quote=“George Bernard Shaw, Man and Superman (1903)
“Maxims for Revolutionists””]“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
[/quote]
That being said the topic’s name is just wrong, it’s not major and it’s certainly not a bug. It’s a feature request. Also it’s wrong to think anyone would do anything to further your own agenda or push your agenda onto anyone else by yelling murder. If you want something be prepared to put in the effort to get it done, if you get any help along the way consider it a bonus - certainly not a given.

Same with opensolaris mysql etc if you want to be certain that they work on your issues, put money on the table.

#11

[quote]In the worst case, I prefer showing the “old” version of TUER without JME instead of using LWJGL. Using LWJGL would ruin my efforts to drive the JOGL renderer more reliable in JME.
[/quote]
Maybe a silly question, but wouldn’t you think it would be MUCH easier to clearly identify your reliability problem with LWJGL?
If there’s a bug, I’m sure it can be fixed, which would 1) be helpful for everyone using LWJGL and 2) be a lot quicker and easier than the road you’re following now. As said before, you’re making things terribly difficult for yourself.

To be honest, I don’t see any functional benefit of fixing the JOGL renderer in JME at all when your problem is in LWJGL (if there actually is a problem in LWJGL, of which I’m not really convinced).
Actually I don’t even see any benefit of supporting 2 OpenGL renderers in JME in the first place.

#12

I think I should have spent some time to fill some bug reports because improving the reliability of any OpenGL binding for Java helps the whole community because games are then more robust and the users are happier.
I have written a temporary substitute to StandardGame, my class is obvious worse, there are less services but it works, it supports the state machine and the scenegraph of JME. You gave me an excellent idea. Rather than using TUER to find some bugs in the JOGL renderer, I should better use a “game” or a complete demo that already uses lots of classes in JME and switch to JOGL to see what happens as Core-Dump did with some programs. Then, I could detect lots of bugs, fill some bug reports, avoid lots of buggy classes, keep concentrate in developing TUER and fix those bugs later.

I often use crappy machines with bad graphics cards, I fear that using another binding ruins my efforts to maintain my game for low end machines.

The authors of Jake2 use both JOGL and LWJGL and they invoke excellent reasons:

[quote]You have the choice to start Jake2 with jogl OpenGL driver and joal OpenAL driver or to use lwjgl as OpenGL and audio library. The lwjgl version has the advantage of better fullscreen support especially on linux and it is slightly faster than jogl. But there are still some keyboard issues with the lwjgl version (deadkeys and repeats are not handled properly). So try out both versions and use the one you like better.
[/quote]
If I work hard, I might have something to show you at Christmas.

There are some rumors of using JME with JOGL for the project Wonderland (Sun labs so forget LWJGL) and SRA International invested some time into the JOGL renderer some time ago.

Using Stardust (a complete demo) rather than TUER could be more efficient for such tests, what do you think of it?

I watched http://www.lwjgl.org/javadoc/, I don’t see an equivalent of the class Screenshot, TextRenderer and TextureIO :(. Is the GLU written in pure Java?

#13

Those are all tiny utility classes, and (IMHO) don’t belong in an OpenGL library. If you want to use someone else’s utility code then Slick contains text and texture utils. I posted some screenshot code in Shared Code for LWJGL a while back too.

#14

When I download Slick, I see some DLLs :frowning: It seems interesting if I forget this point. I know some 2D games using this library. Does it work under Solaris/OpenSolaris and Mac? And under 64-bits architecture?

;D Impressive support of TrueType fonts.

#15

The GLU library is pure Java.

Cas :slight_smile:

#16

Wait, what am I saying. If you’re using JME you should be using their text/texture/screenshot code rather than LWJGL or Jogl specific code, otherwise the whole pluggable-renderer bussiness goes clean out the window. If that’s the approach you’re taking then it’s no wonder you’re having problems with JME. ::slight_smile:

#17

[quote]Using Stardust (a complete demo) rather than TUER could be more efficient for such tests, what do you think of it?
[/quote]
I guess you have 2 options:

  1. Identify your reliability issue with LWJGL and file a bug report (or even better, submit a fix).
  2. Fix the JOGL renderer in JME.

Seeing that you clearly have your mind set on getting JOGL to work with JME, you have a good point to use Stardust rather than TUER as a testcase.
However, I’d urge you to still seriously consider point 1). It might save you a lot of work, the broken JOGL renderer won’t stop you from developing TUER, and I think more people would benefit in the end.

I mean, the road you’re persueing now is fixing the JOGL renderer merely as a workaround for a LWJGL problem that you haven’t even clearly identified to begin with. I still think that the problems you’ve been seeing in LWJGL could well be bugs from developers using LWJGL, but even if there is a bug in LWJGL it’ll be worth it to fix. IMHO even more so than a fixed JOGL renderer in JME.

#18

On your view it is better to fix LWJGL bugs if any rather than fixing the JOGL renderer in JME. As there are already a lot of games using LWJGL, fixing bugs (if any) in this OpenGL binding would benefit to a lot of potential players but some people on other forums said that lots of programmer have been asking for the JOGL support in JME. If Sun labs really plan to use JME (and then JOGL obviously) for the project Wonderland, I would be happy to work with them as I have a huge respect and admiration for Kenneth Russell. I really appreciate the decision of Sun Microsystems consisting in open sourcing Java under GPL v2. I should ask him whether some engineers of Sun might help me.

#19

[quote=“gouessej,post:18,topic:32587”]
yeah, you should get a team of at least five specialists and two interns… :persecutioncomplex:

#20

That is not what I meant. If I could have even at least an occasional help of one person at Sun Microsystems, it would be better than nothing.