TUER: Truly Unusual Experience of Revolution, FPS using JOGL

WIP games, tools & toy projects
#381

I have completely rewritten the algorithm that builds the indexation system between cells and portals and the result is fantastic!!!
3 good news:

  • the loading time has been significantly reduced
  • the target “run-tilesgenerator” used to produce the data files is 4 times faster
  • at home, I get between 19 and 47 FPS
    I’m a bit tired. I’m going to update the source code on the SVN repository. I will update the ZIP and the JAR tomorrow. I plan to try some few improvements in the temporary algorithm of frustum culling and once it is done, I will work on some improvements in the gameplay.
#382

Hi!

I have a small problem with the artificial intelligence, the enemies sometimes shoot themselves, they don’t try dodging (it was already the case before my modifications) and they don’t try following you if you were in sight and you’re leaving the room (it was already the case before my modifications). I will update the game in some days.

#383

I have another problem. Now, the game uses more memory and the garbage collector is really bothering me more often, watch this:
[GC 41182K->39072K(41960K), 0,0038450 secs]
[Full GC 39072K->29275K(41960K), 0,3174410 secs]
[GC 32393K->29315K(52504K), 0,0015180 secs]
[GC 32643K->29791K(52504K), 0,0030210 secs]
[GC 33119K->30303K(52504K), 0,0034050 secs]
[GC 33631K->30816K(52504K), 0,0030590 secs]
[GC 34144K->31330K(52504K), 0,0030970 secs]
[GC 34506K->31586K(52504K), 0,0024400 secs]
[GC 34914K->31843K(52504K), 0,0023820 secs]
[Full GC 33965K->26694K(52504K), 0,3485490 secs]
[Full GC 26696K->26694K(52504K), 0,2803580 secs]
[GC 30022K->26885K(52504K), 0,0043550 secs]
I’m going to use the low pause garbage collector to solve this problem. I don’t want my game to become unplayable because of too long garbage collections.

#384

I quote myself here…this problem still exists on one machine of mine. I’ve noticed that the cpu usage goes from 50% (i.e. one core) down to something like 4% during this pauses. On my home machine (Core2 Quad/Vista/Radeon HD4870/Java6u7), something similar happens. It doesn’t really pause like it does on this machine but it gets very very jerky, albeit the fps counter tells me that it has 1000fps. It is smooth for some time, then starts to jerk (feels like 10fps or something), then it’s smooth again and so on…

#385

I think that it comes from the sound. When I disable it, it works quite better and then I have less full garbage collection. I have no profiler to check it. Thank you very much for testing.

#386

The build in profiler in Netbeans is quite good IMHO.

#387

It is an excellent idea :smiley: Thank you. I use this for the garbage collection tuning:
-verbose:gc -server -XX:+UseConcMarkSweepGC -XX:-UseParNewGC -XX:MaxGCPauseMillis=10 -Xnoclassgc -XX:+DisableExplicitGC
Now I have almost no more full garbage collections except when I enable the sound.

#388

The problem doesn’t come from the garbage collector because most of the garbage collections are done during the loading, not when I play. There is at most 2 garbage collections per minute on my machine. I still suspect the sound. I have used the profiler of Netbeans 6.1 but I don’t know how to use it to find the root cause of my problem.

#389

Yesterday, 446 different people used TUER!!! An article about it has been recently published on Framasoft:

;D It is very motivating. I’m still rewriting the sound system, I hope I won’t spend too much time on it.

#390

Last night, I finally decided to prepare the switch to JME. I want to finish some implementations before working on the tools used for the upgrade. I’m going to finish the sound manager and then, I will convert the maps, the weapon and the objects into OBJ models, the robots into MD3 models. I fear that I will spend a lot of time in repairing the JOGL renderer of JME. I don’t give up. I think that now, if I went on working on my own engine, I would have to rewrite some features that are already implemented in JME and I don’t think it is interesting because I’m unable to improve them except the space subdivision system, the precomputation of interpolations for MD3 models and the anti-gimbal lock system. What do you think about my decision?

#391

Why would you need to? Just go with the LWJGL renderer.

Changing to a tested scenegraph might allow you to concentrate more on the gaming experience, so could be a good thing.

Good luck!

#392

Makes no sense to me. You already have an engine that works reasonable well for this kind of game. You should rather concentrate on the game itself instead of switching technologies after two years of development IMHO.

#393

Thank you for your encouragement. On my view, JOGL is a bit more reliable than LWJGL because it contains only an OpenGL binding (+ 150 lines of code fixing some bugs under Windows) and it contains a pure Java port of the GLU (avoiding the bugs in the GLU under Linux). Some games using LWJGL crash on my machine because of JOAL and/or JInput bugs, I don’t need them, I don’t want to undergo their bugs.

I agree with you about the gaming experience. If I don’t spend too much time in improving JME, I will have much time to improve the GUI, the sounds, the gameplay and the game design.

I understand your position. I admit I thought that my engine was reliable enough and complete enough but if I go on developing it (watch the list of the change requests), I will simply rewrite some parts of Java3D and JME without really improving it, it is a waste of time. What I have done during 2 years is not lost, JME doesn’t have nor cells-and-portals algorithm neither anti-gimbal lock system yet ;D You remind me that I’m aware it is a risky choice, maybe I will be disappointed.

#394

[quote]JOGL is a bit more reliable than LWJGL because it contains only an OpenGL binding
[/quote]
I’m not sure how this makes JOGL more reliable? Would you also argue that JOGL, JOAL and JINPUT combined are about as reliable as LWJGL because they then contain approx the same API’s (even when you only use OpenGL)?

[quote]and it contains a pure Java port of the GLU (avoiding the bugs in the GLU under Linux)
[/quote]
Unless something has changed, GLU support in LWJGL is pure java too. In fact I believe JOGL uses some LWJGL code for GLU.

#395

@gouessej - we’d be grateful if you could tell us about the bugs, or they won’t get fixed!

Cas :slight_smile:

#396

You’re right, JOGL+JOAL+JINPUT might be as reliable as LWJGL, but I don’t want to rely on too much natives, that’s is why I use nor JInput neither JOAL.

Can you prove it?

“Snowman Village” crashes at home under Linux complaining about the absence of OpenAL whereas I installed it for example.

#397

That’s not LWJGL’s problem, that’s Snowman Village and your installation’s problem. LWJGL even ships with OpenAL for linux so it’s pretty probably something strange and nonstandard on your oddly configured developer rig. What’s more you really don’t need to use OpenAL in LWJGL at all, it’s the same as JOAL - simply ignore it if you’re not going to use it. Likewise JInput, which is what LWJGL uses as its input for gamepads. At the end of the day LWJGL does only what you need it to, and it generally does this as reliably as it can. Snowman Village it has to be said is really a demo effort by OrangyTang, not a proper commercial release with weeks of testing behind it.

In the meantime though it might be nice to know why OpenAL couldn’t be initialised on your Linux rig (stacktrace), which might lead to a solution for it. It doesn’t even work on my Windows rig here, and he’s using my SPGL code as well!

Cas :slight_smile:

#398

I have the same kind of problem with “Arabian Nights” when I use JOAL for the sound. The build 498:499M of Snowman village fixes the bug, I tested it a few minutes ago.

#399

There you go then, nothing to do with LWJGL, see?

Cas :slight_smile:

#400

I don’t have enough time to test all games that use LWJGL now, you know that they are numerous.