TUER: Truly Unusual Experience of Revolution, FPS using JOGL

You’re right but it is easier than you think… I have forgotten to update the java archive, this problem of lack of “smoothness” has been solved when I began using the constant GL_MAX_ELEMENTS_VERTICES. In the past, I tried to draw too much vertices in a single pass. If you compile the code, you will notice a pleasant difference. Even when the framerate is low, the mouse responds quite good! ;D

Your approach is good and your remarks are fair. Nevertheless, did you look the code? I can’t add anything in the gameplay now, it is too dirty, not quick enough. If I modify anything, I have to be very careful. I do the opposite of your suggestion. I prefer building a good engine to allow me to add plenty of things easier. I tried to add explosions, weapons… but it is too early. I need to unify the way of handling all the 3D objects and the collisions. It requires a lot of work. When it is done, I will be very happy to put quickly some weapons and new effects.

Don’t forget that the implementation of the cells-and-portals algorithm is a massive optimization of my engine. If I succeed, I will be able to display MD3 models composed of thousands of vertices without hurting too much the performances. Of course, I know the robots are too fast but it is linked to the unification of the handling of 3D objects… If I solve it now, I will be harder to put cells and portals in my engine. For me, it is easier to do the things in this order (approximatively) :

  • use cells and portals ( + unify the way of reading all the maps)
  • unify the detection of collisions and the correction of collisions
  • unify the “view” part of the 3D models
  • unify the “model” part of the 3D models (physics, time-based animations : slower robots ;), explosions, impacts)
  • remove the slow mode
  • add some items
  • add some weapons, some vehicles
  • allow more complex movements (look up and down, jump, crouch, zoom)
  • add some levels and some ennemies
  • add a network mode thanks to RMI…
    Gameplay mechanics and artwork interest me too but I have only a very few time to work on the whole game. I would prefer to spend all my time in working on it. It is sometimes hard to find some motivation as the development of new optimizations requires tens of hours only to define the algorithmic approach. However, when the FPS gets higher, I see my work wasn’t useless. I have drawn on some sheets of paper a blueprint of about 10 maps, 30 ennemies and 100 weapons, it is an interesting aspect too. Thank you very much for your feedback. I think that many people agree with you. It allows me to explain to you why I have been working like that.

I might add a temporary fix to decrease the speed of the robots? Are you interested in this solution?

Gave this a quick try, some comments:

  1. The interface is horrible. It looks like you’re (ab)using a context menu as your main menu, and seems to vanish at random times.
  2. “About” menu option doesn’t show anything except open an extra window with the same “click for menu” text. (Edit: actually none of the menus except for “new game” appear to work)
  3. Screen randomly flashes (particularly in the menus). Looks like it’s occasionally drawing an entire frame black for some reason. Very annoying.
  4. It looks like you’re using key repeat events for rotation, resulting in really jerky movement and an annoying delay before rotating.
  5. Your far clipping plane is very near, resulting in lots of white void in the distance. I’d either increase the distance or cover it up with some fog.
  6. Bullets aren’t visible meaning it’s very hard to see where you’re shooting and if you’re hitting.
  7. Enemy bullets aren’t visible, and theres no feedback to indicate when you’ve been hit, making death seemingly random and unexpected.
  8. Is there a strafe key? I couldn’t find one, and without it theres no real way to dodge the enemy shots.
  9. Generally ugly. Some consistancy in style would go a long way to making it look better with minimal artistic effort.

The awkward controls and lack of feedback mean that it’s basically impossible to play. :frowning:

I don’t use key repeat. If you have looked at the source code, you would have noticed that it is deactivated (by the game itself) at the launch (under Linux). If you had read what I wrote above in the previous posts, you would have known that this problem has already been solved (the source code has been updated recently) but the java archive of the game has not yet been updated.

It is a good suggestion but it does not come from the clipping plane, it is something close… The clipping algorithm that I added
removes too much walls. The next optimisation using the cells-and-portals algorithm will allow me to deactivate this ugly clipping algorithm and then remove this white void in the distance by keeping good performance.
Look at main/GameGLEventListener.java :
/modify the projection matrix only when in 3D full mode/
gl.glFrustum(-50,50,-50,50,50,3000000);
Is it ok now?

Yes, you’re right. That’s why I didn’t remove the slow mode which is more complete. I said that I had less time to work on my game. Then I can’t do all what I would like to do.

Yes, you’re right. That’s why I didn’t remove the slow mode which is more complete. Nevertheless, when you get hit, your health decreases and it is displayed. You start with 100 points and it decreases when you get damages.

??? W,S,A,D on a QWERTY keyboard

Thanks. Vincent Stahl who is a german artist and who drew all the artworks would be happy to read these lines lol. It is hard to do even a minimal effort when you have a full time job.

OK. I’m going to update the game now. The handling of the impacts is temporarily deactivated. If you have a good openGL driver unlike me, you shouldn’t have any white void and you won’t have any jerky control now. You can display some traces showing an example of the temporary result of the cells-and-portals algorithm applied on the map (the cells are not yet optimized) by typing this : java tools.TilesGenerator pic256/worldmap.gif pic256/worldmap.data

The game has been updated. There are only minor improvements as I told in some other posts. In a few days, I will reduce the speed of the bots to allow you to have some time to shoot them. I’m rassured by the performance. If you don’t have enough time to shoot them, it means that you have an higher framerate than me ;D, I get only 17 FPS here.

The game will be updated tomorrow anew to add a first “fix” to decrease the speed of the bots to satisfy erikd and many other people.

What’s all this then?

Cas :slight_smile:

What do you mean? Your link goes to the ancester of TUER which is called “Art Attack”, using an engine called “d3caster”. The slow mode of TUER was mainly based on this game and the whole artworks of TUER come from this too. “Art Attack” uses only software rendering (ZBuffer + raycasting) whereas the experimental default mode of TUER uses hardware rendering (JOGL). Now, TUER uses only between 10 and 15 % of the code of d3caster, mainly for the slow mode which is still here until the experimental default mode will be more complete (rockets, explosions and impacts are still missing). The use of OpenGL has required to rewrite many parts of the engine as its structures of data were fitted mostly for raycasting. Many of the optimizations which have been designed require to rewrite around 5 and 10 % of the game model (MVC) and the slow mode will disappear in a few months to allow the game to start quickly. Are you satisfied by my answer? Do you still have any question?

If you compare the performance of “Art Attack” and TUER, to be fair, put the both into fullscreen. Even the slow mode of TUER which uses a little bit of hardware acceleration is quicker than “Art Attack” in FULLSCREEN MODE.

I precise that I suspect that the author of “Art Attack” modifies a very little bit its engine by looking at mine ;D , open source is done to allow this. Since october 2006, its engine has become a little bit longer to start but does less loading during the game itself and is now a little bit quicker.

Ok, fair enough.
I didn’t look at the code, and I’ve got too much work on my plate to do that now, so I suppose you’re right that the engine needs work before adding a real game.
The thing is, I suspect that it will be hard for you to keep interest as the game is currently close to unplayable and you’re posting so many updates that are not helping gameplay (well, they are on the long run but not directly) that people might give up before you’ve even started with gameplay.

As an aside, did you consider using an existing engine like Xith, JME or J3D?

or jPCT? :wink:

NEVER!
It works for your game, that’s fine, I’m happy for you but the engine of TUER has only one advantage on jPCT : HIGHER FRAMERATE ;D ;D ;D 225 FPS with an ATI X1950! Can you make it with 557000 vertices?? My engine has still many drawbacks… :’(

Yes, many people might give up, it is a risk but I don’t give up. Many linux users criticize my choice of using java, some others insult me, some french programmers say that my game is ridiculous. TUER has on year now, the slow mode is still playable even though it is slow. I won’t give up but it would be easier if some people helped me not only in testing but rather in programming the game itself. The experimental mode is close to unplayable BUT some of my updates help gameplay. I updated the game last night to solve the “smoothness” problem. I updated the game this morning to decrease the speed of the bots by introducing a small latency. However, I admit that many updates don’t improve the gameplay directly but will help to improve the gameplay on the long term.

Actually, Mr Russell advised me to use an existing engine just before TUER got an experimental mode. Java 3D is too heavy and to complicated to configure on my view, Xith is excellent and JME too but TUER is an experimental game too, it is a field of experimentation, I try lighter implementation of the cells-and-portals algorithm, the optimized version is OK since this morning. If I wanted to make a game without building my own engine, of course I should follow your advice and then use JME for example. I need to improve all this step by step. I think you have more experience than me, your remarks are very fair, you see clearly the difficulties I have known and these I will know. I go on working on the engine. Thanks for your feedback. It is motivating.

Well I’m not suggesting you to give up!
Regarding jPCT, I actually think that it would have been a good choice (you do know that jPCT supports hardware accellerated rendering too, right?). Maybe your own tailor-made engine could be somewhat faster and I see that you’re interested in creating your own engine, and that’s just fine.
Anyway, good luck.

I know you don’t suggest me to give up. jPCT supports hardware accelerated rendering through LWJGL and already supports a cells-and-portals algorithm but not as light as mine. My engine supports MD3 models, you saw Lara Croft dancing at the beginning of this thread, jPCT supports MD2 but not MD3. I know that jPCT has a lot of features.

The class which computes the cells and the portals contains a lot of comments because I want my engine to have a pedagogical interest and I know that other parts of the game are too poorly commented. My engine will have a vanishingly small chance to be quicker in a very dynamic context when using a computing system for geographic modifications (for example that’s the case of Red Faction 2). Thank you for your interest. I hope that someone will reuse my whole game when I give up as it happened for Art Attack. I will make efforts to improve the gameplay as soon as possible. Don’t forget that there are still people who have only 8 FPS when playing with my game, it is a shame.

The new update has got several problems because of a pipe broken at the socket during the transmission, the game is buggy. It might not work.

The health counter doesn’t appear anymore sometimes. This bug has been reproduced only on small chipsets under Windows. Nevertheless, the game works fine with a NVIDIA Geforce 6600 or an ATI 9250 Pro for example. The successfull tests have been done with a resolution of 1280*1024. If someone could test with an higher resolution and a “good” card, it would help me to know if it comes from my code or of a lack of memory when you use a chipset. Please help me. I thank people who spend some time to launch my game, really, thank you very very much for your patience.

The cells-and-portals sudivision system is not completely finished as the previous implementation causes a ConcurrentModificationException and the previous algorithm was iterative whereas I realized that the forgotten cases require to drive it recursive (or to complicate hugely the iterative implementation).

Wrong. The “quit” menu allows to quit. The “about” menu displays the text below :

TUER : Truly Ununsual Experience of Revolution
alpha version (extremely unstable)

Single player first player shooter
created by Julien Gouesse (alumni of the university of Paris 6)
largely inspired from “Art Attack” by Vincent Stahl (www.stahlforce.com)

project under GPL licence

requires OpenGL 1.1 and Java Runtime Environment 6

please report any bug : gouessej@yahoo.fr

   Special thanks to:

Vincent Stahl (author of “Art Attack”, TUER wouldn’t exist without him)
“Egon Olsen” from www.java-gaming.org (occasional tester under Microsoft Windows Vista)
Gurvan Jegou (main alpha tester under Ubuntu and Microsoft Windows XP)
Valerie B- (main alpha tester under Microsoft Windows XP for the chipset SiS 661 FX)
Elodie B- (alpha tester under Microsoft Windows XP)
Thomas Gouesse (alpha tester under Microsoft Windows XP for an old VIA chipset)

That appears only on some graphics card, mainly on graphics chipset (ATI Xpress 200 for example), it doesn’t come from my game itself but from the OpenGL driver. Please tell me which operating system you used when you “played” with my game and which graphics card. If possible, I will look for a workaround. When one of my collegue tested the game under windows yesterday, it was worse, the game took 660 MB of RAM and when the menu appears, the image was torn, there were all the colors of the rainbow, ugly :frowning: :o .

That’s no more a problem, there’s no more problem of smoothness BUT the game is temporarily unsupported under “small” chipsets and old graphics cards (cards appeared before ATI Radeon 7000 and Nvidia Geforce). People using these chipsets will have to wait for at least some weeks, maybe some months, the next major optimization will solve both the problem of smoothness definitively and the possibility of playing smoothly even with a “small” graphics card (except when there are too much things to display of course). I precise that even JME doesn’t support graphics cards appeared before 2000.

I wanted to increase the “zfar” in glFrustum but it had no effect on many graphics card because I used already a very big value. Nevertheless, it has an effect on some good graphics cards with good drivers.

Yes but there is a noise when you’re being hit by a rocket and where you’re shooting. If you don’t have any sound, it means that another application keeps a lock on it.

Yes but a small music sample is played especially when you died, the same than in “Art Attack”. The indicator of health might not appear on some chipsets for the same reason I discussed above.

I used some standard keys as some people here suggested, the same control than in CounterStrike if I remember : W, S,A ,D .

No, it means that many people test the game but don’t subscribe. TUER appears on many web sites. If you enter “java doomlike” under Google, you will see what I mean. TUER appears here :
http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/FPS/TUER-28895.shtml
http://www.happypenguin.org/show?TUER
http://www.games4linux.eu/fr/wiki/TUER
http://jeuxlibres.net/showgame/tuer.html
Next year, I think that I will write an article on wikipedia about my game when I am prouder of the result, I’m still unsatisfied.

Screen randomly flashes black here too. It’s not the driver btw. My games don’t randomly flash black, and nor do anyone else’s.

Cas :slight_smile:

I made some tests, I tried to see where it happens. I reproduced this flickering problem with ATI Xpress 200, an old VIA chipset and SiS 661 FX. With ATI Radeon 9250 and Nvidia Geforce 6600, there was no flickering.

Please can you at least tell me which graphics card you use and which operating system? It might help me to find the cause. Perhaps you know that ATI Xpress 200 is famous on laptops for problems when playing with video games and under Linux, the problem has been identified. On your view, where does this problem come from? Why does it work correctly on many “recent” graphics cards and not with the chipsets I quoted? Do you have an other explanation?

Unusual Experience:

The first time I started it webstart failed (the progressbar didn’t finish)
The second time it loaded ok but I had the java console open by default, the screen started flashing like hell, then there was a big, white void with a crosshair. My machine didn’t respond anymore and I had to reboot. Ok, the console’s fault I thought and I was right. The third time I could play it (at about 1 fps).
Maybe you should check the capabilities of graphic cards before launching the game in super-hires (in software rendering mode?) and start windowed instead.
I don’t know my driver’s version (I don’t care cause all other games run fine).
Your billboards are not facing to the player, so they appear flat. I would like to try it again as applet (in 320x240 ?).
Maybe you could save the time of another TUERupdatePost and implement a fallback to such a low resolution? :wink:
good luck with your engine.

radeon xpress 200, amd 3500+, winxp, 1 gig

Whatever. I’m telling you what I see happen on my machine. As described earlier I get nothing on the “about” menu, no health bar and random screen flickering. If you don’t want to believe me and pretend that everything works ok then thats fine by me.