The temporary clipping algorithm gives strange results sometimes. No, I don’t think it comes from vsync. I don’t find why I get only 20 FPS to draw about 550 textured quads.
An other member told me that it might be because of the decompression of my class files. I have 128 class files inside my game. When you update the game, Java Web Start decompresses the new class files. Host limiting might be an other explanation.
I just meant that I think I would’ve got higher frame rates if it wasn’t vsync-ed.
I don’t think it can come from decompression of class files. JEmu2 has more than 800 class files and there’s no delay there.
If you want, I can do a test and put your game on my server to see if the delay is still there.
You would have higher frame rate if I were a better programmer, that’s my fault.
Yes ok it’s open source, you do what you want, you can put my game onto your server and it could help me to understand why there is a delay. Thanks a lot.
This just totally hangs on download. Could also do with getting the mime type right on the server.
Kev
I cannot directly access to it, it is a free hosting solution. I only precise the mime type in the php file which is used when you click onto the link. If you’re right, I will have to find an other solution for my game.
My bad, clicked on the JNLP expecting it to work - might be worth removing that link if it doesn’t work from there.
Kev
Forgot, game still just hangs while trying to load here. Never get a game window, though webstart progress reports it’s only going to take one more second. Never seen a webstart like it. 
Kev
I had two similar experiences…one on javagamesfactory, where webstart loaded everything twice and one when using a local proxy (Sambar proxy), where webstart was asking for new files multiple times with large wait times in between. It always took a few minutes before it accepted that there are new files to download. Maybe it’s something similar here, but given that it is a free hosting service, it will be difficult to check due to the lack of log access.
I let this link for people launching my game through command line, under Vista for example.
The game spends a huge time to load but it works! I asked people to try under Microsoft Windows and Mac OS X 10 and it worked.
I won’t have any internet connection from tomorrow until an undetermined date. I don’t give up. I will correct the “drawer” component to handle the limitation of the count of vertices which can be sent when you call glDrawArrays and I will finish the implementation of the cell-and-portal algorithm. I’m sure the FPS will hugely increase. When I play with Tremulous or Nexuiz with my PC, I get between 30 and 90 FPS. But when I play with TUER, I get only 20 FPS whereas the graphics are simpler than the graphics of these bith games. I will be able to read my emails il there is something wrong.
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 get a black screen under Debian Etch and it seems not to come from the driver. Can someone test under other operating systems please?
Now it works, I don’t know why, I only deleted the trace before launching again the game but I got only 2 FPS
62 FPS with the same machine but under microsoft windows! It was a problem of the driver!!!
I will update the game next week. There are only some minor fixes. The cell-and-portal algorithm requires a lot of effort and I have only a little free time. Be patient.
I have now internet at home again! ;D 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 :
The schema below shows 2 steps of creation of the cells :
Link removed
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.
[quote]I’m sorry, the schema is tiny.
[/quote]
Yes, it is… Very 
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?
Meant as positive feedback