It crashes under Debian Etch with a chipset ATI Xpress 200 and a proprietary driver. Sometimes the screen keeps black. I will modify the jnlp config files to increase the size of the heap at the start, I think the problem is caused by a lack of memory. I'm sorry, I don't have internet anymore at home. Therefore it is becoming complicated to update the game.

It's not my fault, it is especially a bug of the driver for the chipset ATI Xpress 200 under Linux during the initialisation of the memory. I will test the same chipset under Windows. Sorry for the users of this chipset under Linux, I don't know how to find a workaround to prevent black screen.

Now, the game doesn't crash anymore because of a lack of memory. I will correct the component which handles the VBOs to decrease the slowdown. Sometimes the game doesn't respond immediatly when you move the mouse. It will be corrected too in a few days. It's becoming hard to go on developping the game as I have a full time work and no more access to internet at home to update the source code and the java archive.

I have now internet at home again! I'm currently updating the source code. I'm adding the cell-and-portal algorithm implementation in my simplified case. It's not finished. I hope to get better performance thanks to this system of spatial subdivision. I will add some figures to show you how it works. The tasks that my algorithm performs are these furthers : - merge all pieces of wall to build full walls (each wall may contain several parts, a part is a square with a texture)- associate walls oriented to the top with closest walls oriented to the bottom in order to build the first cells- complete the cells with walls oriented to the left and to the right and when possible, otherwise generate portals- resize and optimize the cells to reduce the width of the portals- add ceiling and floor to the cells- add the third component (until now, the walls were represented by a pair of point in 2D)- add the coordinates of texturesI think I will need several months to finish it but I will give you lots of details to allow you to reuse this kind of algorithm in your own game or maybe directly my software component.

The first part is the map as it is at the beginning of the process.The second part shows a part of the map at the bottom where 3 cells have been created. Notice that the portals are very wide.The third part shows the optimized cells, the portals are less wide, it gives better performance.I'm sorry, the schema is tiny.

I notice that you seem to be very focussed on performance and compatibility, while I think you should at this point focus more on playability. I mean, the game just doesn't *feel* right yet. The controls are too twitchy, I keep getting killed before I even notice the enemy, the artwork is not very inspiring, things like that...I don't mean to be harsh but I suggest to work on the game itself before worrying about framerates and optimizations and such. Old school FPS-es are cool and this game could become something, but just I want to blow shit up instead of just wandering around only to get killed instantly only because I went around a corner, you know what I mean?Maybe it's because the engine development interests you more than gameplay mechanics and artwork?

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!

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.

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.8. 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.

4. It looks like you're using key repeat events for rotation, resulting in really jerky movement and an annoying delay before rotating.

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.

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.

It is a good suggestion but it does not come from the clipping plane, it is something close... The clipping algorithm that I addedremoves 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?

7. Enemy bullets aren't visible, and theres no feedback to indicate when you've been hit, making death seemingly random and unexpected.

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.

8. Generally ugly. Some consistancy in style would go a long way to making it look better with minimal artistic effort.

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 , I get only 17 FPS here.

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 , 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.

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!

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.

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?

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 225 FPS with an ATI X1950! Can you make it with 557000 vertices?? My engine has still many drawbacks...

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?

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.

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).

3. Screen randomly flashes (particularly in the menus). Looks like it's occasionally drawing an entire frame black for some reason. Very annoying.

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 .

4. It looks like you're using key repeat events for rotation, resulting in really jerky movement and an annoying delay before rotating.

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.

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.

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.

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?

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? good luck with your engine.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org