TUER: Truly Unusual Experience of Revolution, FPS using JOGL

WIP games, tools & toy projects
#281

The game is going to be updated tomorrow as I’m tired. The bug fix is very dirty, I will try to find a better solution.

#282

The update is going to be done this evening with the first “reliable” fix. I will find a better fix later.

#283

The game has been updated, the source code too. Now, I need to finish the implementation of the explosions.

#284

I’m going to finish the implementation of the “view” part of the explosions. I’m sorry for the long silence, I’m very tired, I have been a little bit ill. I plan to put at least a screenshot in some days.

#285

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

The rockets work better. I spent some time in trying to compile JIGAXtended unsuccessfully under Linux… :frowning:

I don’t know when the explosions are finished.

#286

Explosions are almost ready!!!

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

I’m off work exceptionally today to do that and I succeeded! ;D I’m going to update the game before the end of the evening.

#287

The game has been updated. I have some problems with the alpha channel of the textures used for the explosions, therefore they are not really impressive.

#288

Please could someone test the game with a “fast” machine? Some users complain that the robots kill themselves when shooting and that it is impossible to shoot as the rockets explode immediately. I don’t reproduce this bug on my machine as I get only 17 FPS. Could someone test on a machine that may get more than 30 FPS please?

#289

On my Intel Core 2 Quad Q6600 and Nvidia 8800 GTS system I observe the following:

  1. If I start a new game and do nothing but click my mouse 5 times - I die. I do not see any rockets (I hear them) and I’m pretty sure I am shooting myself, hence why I die.
    Also, yes, the robots do the same, they shoot themselves and die.
    If I walk backwards (and there is space behind me) and shoot then the rocket does appear and works as it should.

So it looks like some kind of hit-box problem.

  1. Turning is much quicker when not moving. IE the mouse rotates the player much slower if the A,W,S,D keys are being pressed.
#290

Thank you very much. I have the same problem when I reduce the resolution. Something is wrong in the time-based animation system, it is used when you move the mouse, not when you use the keys. I hope I will succeed in fixing this bug.

#291

You were right. The rocket started inside the box. It wasn’t a problem in the frame-based animation system as the step of movement between frames was big enough to put the rocket out of the box but it is no more the case in the time-based animation system, when this step becomes tiny when the frame rate is greater than 25 FPS. I hope I will solve this before tomorrow. Thank you for your help.

#292

Update of the Java archive

Some bugs have been fixed. Please could someone test on a fast machine again? The only remaining problem now comes from the first position of the rocket when the player shoots, I’m correcting it right now. I will have to improve the explosions too.

#293

Seems to work on an Intel Q6600 (which is fast…)

any change you’ll add support for multi-thread rendering? :stuck_out_tongue:

#294

Ok if there is nothing wrong when you shoot or when a bot shoots, that’s ok. I know multi-thread, I know rendering but I don’t know multi-thread rendering. Can you explain to me what you mean? I already said that the scenegraph is not ready but it will hugely improve the performance when I fix the 2 last bugs >:( even without multi-thread.

#295

Update of the source code and the Java archive:

  • improved explosions (I’ve solved the problem by using an alpha threshold through “The Gimp”)
  • some major bug fixes (the bots don’t suicide anymore)

If the problems with the rockets subsist, please let me know.

Now, I will add some funny things before working hard on the scenegraph (except if you find some bugs). If I succeed in harmonizing the collision handling system, I may add some weapons and some items. The easier thing that I think I will add is the bloody screen when dying.

#296

Easiest would be to render 2+ triangles at the same time, that you know are not overlapping (no depthbuffer synching required), At the other extreme end, you can split your viewport and let both threads render one part.

But it’s kinda hard to analyze/optimize that all on a single-core CPU.

#297

I think that it is an interesting optimization but finishing the scenegraph first would improve the performance more than this and I have already begun to write it. I will add your suggestion in the list of change request, it seems simple but it will require a way of checking that each thread has finished its job after each frame, by using join(), won’t it?

Do you really think that multi-thread rendering might improve the performance significantly whereas I use hardware acceleration through OpenGL (JOGL)?

#298

Only accelerates softwarerendering.

#299

Therefore, my game is not concerned. It is so slow that you believed that it uses software rendering :frowning:

#300

Update of the Java archive:

  • the player is falling on the floor when dying

The problem is that it doesn’t respect the law of the free fall that I studied in physics, then it is not realistic enough. The acceleration should be constant when falling, not the speed.

Now, I’m going to fix the problem of the progress bar that has become jumpy and I’m going to improve the death of the player.