[quote]I had forgotten the bold part of the code in the method below:
…
[/quote]
Hehe, that’s such an easy to make mistake. 
Yes, it is so easy… I think that I will ask some people to read my code. The project is open source but only a few people download the source code.
N.B: I made an effort to compute a distinct color per cell. Nevertheless, sometimes, two cells are almost the same color, don’t hesitate to use an image editor to check it.
I’m going to submit an update after a good night, I need to sleep. The fix for the issue #356 doesn’t work after 99 seconds, then I come back to the older implementation of TextRenderer. The software view frustum culling is not fully ready. I wanted to use an existing source code found on a french tutorial but the author hasn’t realized that his algorithm works only with axis aligned boxes. The method that computes the frustum is very fast, it has no noticeable impact on the frame rate. I really think that OpenGL spends a long time to reject a huge part of the geometry. If I succeed in sending it less information, I expect a better frame rate.
I don’t want to use glSelectBuffer because it would force me to test all portals even though I quickly notice that one of them is outside the view frustum and sending the portals one by one to the graphics card would not be performant.
The source code has been updated a few minutes ago. I’m still writing the scenegraph. Tomorrow, I’m going to try to implement the following aspects:
- conversion of simple 2D cells into full 3D cells with all geometric data required to display them
- serialization/deserialization of a network of cells and portals
- use of the methods I wrote to locate the player in the network and to determine the visible cells in the view part of the application (MVC)
Then, in the next weeks, I will try to uniform the engine as most as possible, remove many useless things, use the network of cells and portals to optimize the view part by putting the enemies and the objects inside it. If I succeed, you can expect a noticeable improvement of the frame rate (at least twice better).
After that, I will use the network of cells and portals to optimize the model part of the application.
Finally, I might be able to introduce some important changes in the gameplay, for example the possibility to look up and down, more complex levels…
Sorry, I spent a lot of time in configuring the SVN repository:
https://tuer.svn.sourceforge.net/svnroot/tuer/
The first commit is extremely slow and I have forgotten to remove the .class files :-\
Look at this: http://forum.games-creators.org/showpost.php?p=59470&postcount=2
TUER works at 21 FPS with ATI Radeon XPress 200 with the latest driver under Windows. Therefore, Hansdampf has no more reason to laugh about my engine ;D. If you have some slowdowns with this chip under Windows, please update your driver before complaining or suggesting to lower the resolution.
I was not laughing about your engine.
I was laughing about your obvious lack of humor. That was the reason I wrote xpress200 rules under some posts.
Looking forward to your next [i agree…], […make it open source] posts and links to french sites.
Sorry, I don’t have a xpress200 anymore, cause it sucks. Congratulations on your engine.
Lol you admit XPress 200 sucks ;D Thank you for your compliment. 21 FPS is not enough, 60 FPS would be better. Here we go…
The first attempt of implementing a scene graph is almost finished, look at the SVN repository if you’re interested in it. I fixed some bugs in the breadth-first search. I have to test the serialization.
N.B: The last step of the algorithm that has to build the network by linking each cell to its neighbors is very slow, it can spend about 28 seconds. If you modify my source code to treat huge maps, you will have enough time to drink a coffee during the computations. I think there is some room for improvement.
The first test of the scene graph starts tomorrow morning, French time, I’m very worried. Good night. Stay tuned.
I’m going to commit the last stable modifications now on SVN. I have repaired the deserialization of the network, the file is quite big >:( 24 MB. The scene graph is not completely ready to be used. I have taken a day off to solve this problem immediately. My “game” is not only a piece of shit with GL underneath, I want to prove it, NOW!
The scene graph is not working fine. The view frustum is wrong, then too much cells are considered as visible, even the algorithm is too conservative, lots of walls don’t appear for another reason. The source code has been updated on SVN. In order to activate the experimental scene graph, comment the line n°375 and uncomment the line n°377 in the class main.GameGLView.
Only one positive aspect: when I tinker the algorithm to display only the true visible cells in some particular cases, when it works, the frame rate is far better than before (between 2 and 4 times better).
I’ve submitted the latest changes on the SVN repository. As the view frustum culling doesn’t work, I have temporarily used a kind of contribution culling that is less efficient. The improvement of performance is then hardly noticeable (24 FPS instead of 16 FPS on my machine). I have 2 problems to use in order to use the view frustum culling:
- repair the cells that are overlapping (I’ve discovered such 30 cells)
- fix the bug in the method that computes the view frustum
However, I will update both the ZIP archive and the Java archive tomorrow to allow everyone to benefit from the improvements.
I’ve improved the contribution culling and removed a useless call that consumed some CPU time uselessly. I get now 25 FPS instead of 16 FPS. I will update the ZIP and the JAR tomorrow morning (French time).
Now, TUER works even under Linux with an open source driver thanks to this:
IntBuffer buffer=BufferUtil.newIntBuffer(1);
this.gl.glGetIntegerv(GL.GL_MAX_ELEMENTS_VERTICES,buffer);
buffer.position(0);
int tmp=buffer.get();
//f**king driver for ATI Xpress 200 returns -1 under Linux
if(tmp>1)
GL_MAX_ELEMENTS_VERTICES=tmp;
Don’t expect an high frame rate, I get only 2 FPS.
Now, TUER doesn’t crash if ITunes already uses the line:
if(asdl[i].available()<=0)
return(false);
I’m going to update the JAR and the ZIP in some hours.
The fix for the sound doesn’t work 
sorry
The server is up anew, sorry for the disturbance. Tuxfamily had to perform some maintenance on its servers.
Now, the problem on the computer with no sound has been solved, it works here. I’m going to tune finely the contribution culling to get a better frame rate.
Good news!!! The cells are no more overlapping ;D I’m going to submit the code on SVN.
I have to solve the 2 following problems now:
- build some “connected” graphs instead of mixing a connected graph with isolated nodes
- repair the software view frustum culling
I’ve updated the source code on SVN. Now, the network set is handled correctly, it improves the speed a little bit but the simplified frustum culling is not accurate enough for the moment. I hope that the frame rate is now good even on computers with a very old graphics card. I get at least more than 15 FPS on NVIDIA Geforce 1.
There is a bug in the method getCommonPortalsList in the class tools.Full3DCell. A portal is composed of 4 consecutive arrays, each array contains the data concerning a single point (texture coordinates and vertex coordinates). My checks were not complex enough and then I added some points that were a part of a portal but even though I was looking for such point into a succession of 4 arrays that didn’t form a portal. I’m going to fix it in a few hours (I’m currently at work).