Actually, I’m disappointed, something is missing in these fixes, it won’t solve the problem. There is not yet any support of applets using JNLP with OpenJDK (plain applets still work), another contributor of JogAmp has been trying to fix that.
I have just updated the source code. The enemies can suffer a bit before dying, several frame sets are used. I will add some sound samples for their pain and I will update the demo of the pre-beta version tomorrow.
I would like to remove the limitation mentioned by EgonOlsen, I don’t know what I broke when porting the code to Ardor3D.
Hi
I’ve just updated the demo. Now, you can hear the soldier increasingly suffering after several shots.
Hi
Icedtea 1.2.4 fixes matheus23’s problem, I have upgraded to Mageia Linux 2 in order to use it. However, Chrome wrongly respects the setting “Always enable”.
Cyanprime, I’m lazy, I will use JDIC to create such native installers… they will use Java Web Start under the hood.
Hi
RedLine RPM (Java RPM library) will be used next month to make an RPM for my game.
I’ve just updated the source code. Now the soldier has got a shotgun but still no artificial intelligence. The roadmap will be updated soon too.
Does he just hold it for no reason or does he fire it randomly in all directions? I hope for the second.
Currently, he holds it for no reason and I will fire in any person in his sight in a few days.
Hi
I’m currently working on the (minimal) artificial intelligence and I plan to update the road map very soon
I need your help to measure the frame rate of my game on different computers. I will resume my work on my biggest optimizations and I would like to know the actual performance of several versions of my game before modifying the spatial subdivisions. Please run the alpha version and the prebeta version, tell me the frame rate you get (it is displayed in the game, please don’t use Fraps), give me some information about your hardware (operating system, CPU frequency, number of cores, graphics card, driver version especially if you’re under GNU Linux, etc). I will make some tries to evaluate the impact of my improvements before fully implementing them by manually modifying the map.
You can try the alpha version here: http://tuer.sourceforge.net/alpha/tuer.jnlp
You can try the pre-beta version here: http://tuer.sourceforge.net/very_experimental/tuer.jnlp
N.B: As the bug with several screens has not been fixed, please perform these tests with a single one. Thank you.
Edit.: I have forgotten to disable the vertical synchronization in the pre-beta version.
Hi
The road map has been updated:
Please let me know any spelling mistake or wrong use of English words. Best regards.
The alpha fluctuates between 500 and 1000 fps…either 500 or 1000, nothing in between. Looks like as if the fps counter is flawed in that one. The newer version runs @ around 120fps.
System: Core i7 2600K @ 4Ghz, Windows 7 64bit, 16GB, Java 7.something, GeForce GTX 680, resolution 1920*1200
Hi
Maybe it is a bit flawed because I don’t use the common hack to force the use of the high precision timer under Windows. However, I get about 1700 frames per second with some high end graphics cards under GNU Linux and the alpha version sends only a very few data to the graphics card, the result is not surprising.
It’s not that bad but still not fast enough for a very simple level.
Thank you very much for testing, really. I get similar results with Dell Precision latest laptops, the frame rate is 3 times higher with the newer version but as it is a bit flawed…
I’ve just updated the demo. The vertical synchronization is off by default. It is now possible to switch from full screen mode to windowed mode and vice versa by pressing F11 (I will add a menu to do the same thing later). Pressing carriage return was necessary to go from the initialization state to the introduction state, I fixed that bug. Best regards.
Someone has just tested the both versions of my game with an ATI Radeon X600:
- alpha version: 55 FPS
- pre-beta version: 8 FPS
I will update the demo tomorrow, I now detect Microsoft’s software emulation drivers and I display a warning message instead of crashing. I still work on the artificial intelligence and the WaveFront OBJ exporter for Ardor3D.
I have driven the loading of JFPSM project files more robust but the most important piece of news is the huge performance improvement. Please find below the statistics obtained during the test with a graphical card Nvidia Quadro 2000:
alpha version: 1000 FPS
pre-beta version: 77 FPS
pre-beta + portal culling: [100 , 181] ~ 140 FPS
pre-beta + portal culling + hack: 2427 FPS
I just used a small piece of level to simulate the result of the portal culling. The hack consists in removing all context manipulations (makeCurrent() and release()) and using a queue. I still have to simulate the result of my mesh optimizer (which merges coplanar adjacent right triangles whose all 2D texture coordinates are canonical). Of course, the hack has no noticeable effect if the vertical synchronization is enabled or if the frame rate is so low that makeCurrent() has a negligible impact.
These results are quite promising and motivating even though they have to be interpreted with care because I have almost no idea of the CPU time necessary to perform the real time portal culling (my previous implementation was very rudimentary).
coplanar? How often is that going to happen? I can imagine it’s only really usable for walls, floors and ceilings, but the triangle count there is (supposed to be) so low that performance will not be drastically affected by merging triangles.
Hi
Actually, it is almost useless for outdoor environments whereas it is quite useful for indoor ones. As most environments of my game are indoor, it is quite logical to optimize this case. Reducing the triangle count has a bigger effect on old hardware. If I use both portal culling and my mesh optimizer, the latter won’t drastically improve the performance as most of the job will be done by the former because the remaining surfaces whose vertices are in the VBOs will be so small that the performance increase (compared to passing the triangles with no merge) will be very small too. However, my game will have a lower memory footprint and JFPSM will have lower memory requirement to compute cells and portals with this optimization. I already wrote that the first level of TUER is composed of 255 484 triangles, my mesh optimizer merges the 384 triangles of the first room into 14, how could this feature be useless?
I implemented a minimal artificial intelligence during SIGGRAPH 2012, the source code is on Sven’s laptop, I will commit it as soon as possible. The fifth step of the mesh optimizer will be ready in one or two weeks.
Looking at your specific scene, I can imagine that you could simply use 1 quad for the floor of the entire level. As everything is indoor, nobody will see that the ‘world-size quad’ continues behind the walls.
Yes, your suggestion would be nice only for a quick test on this specific level.
I have to say, Julien, much as people make fun of you over TUER (me included), kudos for sticking with it. I think having the drive to actually finish a game is really the most important attribute for a game dev to have. Well, behind a working brain, of course, but you seem to have one of those.
Hi
People have laughed about me since 1986? 1987? Nobody will stop me.
Thanks. TUER is living the most important acceleration of its development since 2006. Step by step, as time goes by, the pre-beta version is becoming a “game”, the soldier is now able to notice that your gun points to his direction. The memory footprint of JFPSM has been divided by more than 10 since 2010.
I have almost finished the implementation of the fifth step, the test of my algorithm will probably start in a few days.
My computer is broken once more, it doesn’t accept DVI output anymore. I have to use my very old ATI Radeon 9250 Pro. I think that I will keep my current computer only for testing and buy a better one soon.