TUER: Truly Unusual Experience of Revolution, FPS using JOGL

I’ve noticed something very strange. When I use a texture twice during a single call of the method called “display” in a GLEventListener, the game is twice quicker. Nevertheless, all the textures are resident according to glAreTexturesResident and I have already increased the priority of the texture that I have used for this test. I think that there is something wrong with my driver. I think that resident textures are supported on my graphics card (ATI Radeon 9250 Pro) but I assume glAreResidentTextures returns always true even though a texture isn’t resident. Then, my graphics card puts the texture I use into the VRAM only when I use it several times between two swaps of buffer even though I use glPrioritize and even though it would be faster to put it into the VRAM at the first time this texture is bound. I get 19 FPS with a screen resolution of 1280*1024 instead of 8 FPS usually. Does anyone know a workaround to force the graphics card to put my textures into the VRAM? Now I realize that people using reliable drivers might have far better performance than me even with the same graphics card. It means that TUER is fast enough and “fluid” enough to work on PCs with any graphics cards of ATI and NVIDIA created from 2000 with a really reliable driver.

The game turns at 32 FPS with the graphics card NVIDIA Geforce FX 5200 under Microsoft Windows XP whereas this card has been famous to be a bit slow. I don’t understand why the download was so slow when I did the test. The game turns at 96 FPS with the graphics card NVIDIA Geforce 6600 even with an old microprocessor (Celeron 500 Mhz).

On the other hand, I still work on some optimization to increase the performance before adding complex models into the levels.

Finally, the impacts will be visible in the game maybe tonight. The accuracy of the computation has been hugely increased but it will be better when the cell-and-portal algorithm will be ready.

The impacts work quite fine :

http://tuer.tuxfamily.org/screenshots/screenshot_impact.png

My graphics card is stupid! Now it works faster whereas I draw more things ???
The game has been updated :

  • instead of freezing the screen, if your hardware isn’t supported, the game goes back to the menu and displays an error message
  • the impacts work (but the computations aren’t accurate enough for faster and smaller projectiles like bullets and laser)

Sorry if it still looks like a tech demo. I am going to modify the menu shown when you click on “about” because it doesn’t appear correctly under Microsoft Windows Vista and Microsoft Windows XP. Before doing this, I need to have a rest.

I would like to improve the rendering of impacts. I want to use blending. I planned to use it as below:

public final void init(GLAutoDrawable drawable){

gl.glBlendFunc(GL.GL_ONE,GL.GL_ZERO);
}

public final void display(GLAutoDrawable drawable){

//bind the texture of the walls
//draw the walls
gl.glEnable(GL.GL_BLEND);
//bind the texture of the impacts
//draw the impacts
gl.glDisable(GL.GL_BLEND);
}

It doesn’t work very good. Sometimes, the effect is fine and often the impact is flickering. Does someone have an idea? ???

flickering usually come from the fact you only draw one buffer with something and forgot to write other buffer in double buffering.

It would be good to have more code as this snipet of code doen’t help a lot as opengl is a state engine and maybe you call opengl function somewhere else that cause this issue. this snippet look good, maybe blend selection function “gl.glBlendFunc(GL.GL_ONE,GL.GL_ZERO);” can be moved near “gl.glEnable(GL.GL_BLEND);” , this will make code a little cleaner and will improve readabily/understand of your code.

You’re right but it happened when I used a PopupMenu displayed on a GLCanvas only under Microsoft Windows.

My project is open source, the whole source code is available and the lines I gave in this snippet are commented in the source code, in the file “/main/GameGLEventConstroller.java”. Maybe the problem comes from the alpha blending, I already use it.

It looks you’re drawing the impact close to (or right on top of) the wall, and that the flickering comes from the z-buffer that gets less precise for farther away objects causing ‘Z-fighting’.
Maybe a better solution would be to use multitexturing or to use the polygon offset feature (http://www.opengl.org/resources/faq/technical/polygonoffset.htm)

Yes you’re right. I draw the impacts a little bit in front of the walls because I didn’t succeed to use blending and I think I will keep this behavior in the future for people using graphics cards where blending isn’t enabled.

Yes! Nice idea. I tried to perform multipass rendering. Thank you for the link.

I’m still trying to improve the impacts. After that, I think I will try to display the rockets at least.

Now the problems with the impacts are solved. I will try to improve the shape of the objects and to display the rockets.

NEW UPDATE:

  • some bug fixes (impacts didn’t disappear when you lose…)
  • the tables aren’t flat anymore

When the engine doesn’t use Vincent Stahl’s color codes anymore, I will be able to write a map editor, something simple to draw maps with orthogonal walls very quickly, allowing to add some objects, enemies and power ups. Then, simplified maps will be used for the voxel-based collision system and complicated maps drawn with Blender for example will be used to be rendered in the game.

Currently, I need to improve the objects and display the rockets.

I corrected the bug in the “about” menu yesterday. I’m going to update the game tonight. I go on working on some improvements of the graphics.

NEW UPDATE:

  • minor bug fixes
  • the “about” menu works properly under Windows and doesn’t use Swing anymore

WARNING! MY WEBSITE IS TEMPORARILY UNAVAILABLE!

MY WEBSITE WORKS ANEW!!! ;D

NEW UPDATE:

  • the kind of huge “pot” with some grass is now in full 3D

Some bad news, 2 bugs:

  • it is often impossible to save a screenshot when using Firefox and Iceweasel under Linux
  • even though it is worthless to try to do it, the program tries to save the file in a directory that has not been created in this case

I suggest to use the property “user.home” hoping that I have the right to write inside it to prevent Java from using a directory that is owned by root under Linux.

If someone has some minutes to help me, I would like to check if my game works fine with these chipset: ATI Xpress 1100 and ATI Xpress 1000.

Finally, as at least one student might help me in some weeks, I will clarify the composition of the change requests by giving more details on the way of designing them.

One of the bug has been fixed, I’m going to update all tomorrow. I’ve updated the list of the change requests to allow people to participate to the project and to have a better visibility on the future of the game. It would be fine to put a screenshot to show you some improvements.

I’ve been trying to reuse the source code of the GLU in order to compute the coordinates of the new 3D objects and to save them in several files. Now, I’m going to test the method that computes the coordinates of a cylinder that is inspired by gluCylinder. I’m going to update the game tonight.

The source code has been updated, it contains only a bug fix and a new class called tools.ExtendedGLU. This class has not been fully tested. I’m going to update the whole game in several days.

Does someone know where I can find a simple OBJ loader? It doesn’t seem to be complicate to write it but I would like to avoid rewriting something that already exists.

The game has been updated! There is only a minor modification. As some players complain about the excessive speed of the game on recent machines, I decided to compute the speed of the player by taking into account the frame rate. Could someone test if it is more “playable” especially on a fast machine?