I didn’t fix it, I’m under Linux and I don’t reproduce this bug on this operating system. However, cylab said that it is possible to fix it by doing like Jagatoo:
In Jagatoo, the input handling works reliably under Windows, Linux, Unix and Mac.
Some people here know that the performances are very important for me. Today is a great day ;D
Hi!
I forgot to treat a case, a portal can be located between the near plane of the view frustum and the observer. In this case, the sub-frustum is the current frustum. As a consequence, for the moment, everything becomes black sometimes when you are going from a cell to another one. The fix consists in moving back the view frustum using near (see glFrustum) to perform another culled test. When it is done, I will prepare another build of the blue print.
Edit.: I have updated the source code on the SVN repository. The solution above is not accurate enough, I will have to improve it by rather using a small bounding volume in front of the view frustum.
Hi!
Please Linux users, if you use the OpenJDK 1.6, try my game as I think I have fixed the bug in the JNLP file by removing the useless tag .
If you used my JNLP file as an example, fix it in yours too.
Hi!
The portal culling is not yet completely implemented, I don’t succeed in computing the sub-frusta correctly but I will add some 3D debug displays into my blue print to understand what is wrong. I know that some tools used to create mods of Fallout 3 show the projection of the portals, it would help me to see in real-time the result of my buggy implementation.
I’m going to deploy a version that uses cells-and-portals subdivisions with a simple view frustum culling until the portal culling is ready. For those who profiled the blue print, you may have noticed an important increase of memory allocation, I plan to reduce it by using a single instance of the class jme.com.renderer.AbstractCamera and putting only values of the parameters left, right, top and bottom into a list.
On the other hand, the chip NVIDIA 8400M works very slowly with TUER, this chip is very unreliable and is referenced as a very buggy graphics chip by Dell, don’t expect good frame rate with it. If your computer crashes, maybe you can benefit of the warranty to change your chip for free. However, many games will go on suffering of noticeable slowdowns especially under Vista.
Finally, I realize that the implementation of the portal culling requires much time than I thought. I will defer the improvement of cells-and-portals subdivisions to spend much time in adding weapons, enemies, power-ups, etc… into my game. I won’t plan the implementation of any other advanced feature for JMonkeyEngine as it would be too ambitious, I can’t try to port my game to JME and improve this engine at the same time. I admit I had underestimated the necessary time to implement such things when I began in October 2006.
Edit.: the blue print has been updated. Now you can notice the frame rate is higher 
Hi!
I am debugging the portal culling right now. As you can see on the screenshot below, the portals are computed correctly:
http://tuer.tuxfamily.org/screenshots/jme2portalsDebugging.png
I notice that the portal culling works bad only when the sub-frustum does not contain the center of the whole view frustum. It is strange, isn’t it?
Cool, these should make things more fun.
Also the end of your post just reminded me of this: http://sonicstrange.ytmnd.com/
Lol, the portals are displayed only for debugging purposes like in Fallout 3:
I don’t have this kind of references…
I got an idea on how to make the game more fun.
Make the rocket launcher into a Gatling gun. rapid fire is so much more fun.
Also is there strafing yet?
Wow that was a bit of a heated discussion .
this game is way out of my league, i wouldnt even know where to start making a game like this i think its brilliant compared to mine :persecutioncomplex:
if you want to settle disputes try my game thats what i made it for ;D windows users that dont use opera only and who have a fast connection only 
Hi!
Wouldn’t it be better to have a separate Gatling gun? For the moment, I’m trying to add the pistol and the AK 47.
The strafing is in the both versions (try using W, S, A and D) but you know the version using JME 2 works bad under Windows for the moment.
I was in the same situation in October 2006, that was why I tried to rewrite the engine of an existing game rather than starting from scratch. Thank you for the compliment.
Lol ok I give it a try before going to work
Woo! Keep up the good work ;D
You stop turning once the invisible mouse hits the border of the screen.
It certainly gives the game an edge.
Thank you very much. It will be useful to fix this bug. Maybe the cursor is centered too late and then the window does not receive the events during a short instant. I will have to look at the source code of JMonkeyEngine 2 to find how this aspect is handled.
Thanks. It is important for me to make something less ugly.
Well, I finally booted into PC mode and downloaded Java 6, just so I could try TUER.
It’s not bad, it’s not good. There is a lot of merit here for something that was created from scratch but it also is lacking a tremendous number of features that fans of FPS will no doubt expect. Like not being able to aim up/down was weird, and the combat felt pretty much like dumb luck (in terms of getting hit). First and foremost, the game is ugly, as you’ve admitted to already.
But as a technical showpiece, you’ve definitely done a pretty good job, so be proud of that. Just find somebody to draw you a few things, and the apparent quality of this will improve. From what I can tell, it looks like you’re most useful in a purely technical role, which is fine as long as you work on a team where other people can do the rest, like gameplay / design / art / sound.
Hi!
Thank your for trying my game 
The problem is that I have tried to improve the artificial intelligence and now there are some regressions. When it worked, the robots were intelligent enough to follow you if they failed to shoot you. I remind you that this version of the game has been explicitly frozen, there are no new features on it.
Thank you. I admit that I’m really happy to get a nice frame rate. The latest build of TUER that uses JMonkeyEngine 2 (not the one you tested) is 64 times faster than the very first version of TUER written in October 2006.
I agree with you. That is why I’m not the author of the pistol, I’m not the author of the zombies that are going to be included. I’m useful mostly for programming and a bit for the artistic inspirations (I have drawn lots of maps that cannot yet be supported by my cells-and-portals implementation of JMonkeyEngine 2). I assume it is not clear for some people:
The version that does not use JMonkeyEngine 2 and that is more complete is frozen and the development effort has been done on the version that relies on both my algorithms and JMonkeyEngine 2 for some months now.
TUER is not dead (French people may laugh about it). I will never give up.
Well, all those things considered when you’ve got a new build with enough noticeable differences to it, let me know and I’ll give it a go.
Personally, I see this as a WIP.
I consider that the version of TUER that does not rely on JMonkeyEngine 2 as a quite complete casual game (one weapon, one level, some medikits, one kind of enemy, a minimal GUI, some sound effects, some animations, …) whereas the latest version that relies on JMonkeyEngine 2 is quite experimental. I don’t want to make 2 separate threads to speak about these versions. That’s why I don’t want to put my game into the WIP section.
However, if I only had the latest experimental version that is quite empty, buggy and boring, I would have to put it into the WIP section.
Thank you. I let you know when it is ready. As far as I know, you’re under Mac, it will be interesting to have someone to test my game with this operating system :).
how many polies are in the pistol? or is it a sprite?
looks impressive.
