The explosion animation is a great addition, but I think it could be improved:
Nice to see your game progressing.
Ok, I will increase framesPerSecond in the instance of the class AnimationInfo used for an explosion view. The varying opacity often doesnât work. The previous version of the game used this and many people saw only the first texture of an explosion and nothing else. I use glAlphaFunc. Do you have any suggestion to handle varying opacity efficiently even without shaders?
I will modify the impacts when the scenegraph is ended as it requires to know quickly which walls are linked.
I tried to run it on a Core2Duo @2.4Ghz/ATI X1900XT/2GB/Win XP/Java6 machine. I had two problems: On some passages, there were white polygons like in this picture: http://www.jpct.net/pics/tuer.JPG. The second problem was, that, after i spotted the first enemy (right behind that white âwallâ), the keyboard controls stopped working. The mouse was still working as expected and the game ran at 62fps, but every time i pressed a key (forward, backwardâŚ), it stopped responding for about 2-4 seconds.
Thank you for this test. The problem of âwhite wallâ happened with another graphics card:
http://tuer.tuxfamily.org/screenshots/screenshot_nvidia8800gtx.jpg
Some graphics cards have strange behavior when using TUER because it uses a very very deep Z-buffer and a huge VBO for the level. I had the same problem with an ATI X1950 Pro 512 MB whereas the ATI X1950 Pro 256 MB worked fine. I plan to solve this by using a less deep Z-buffer, it requires to change some things in the program that generates all the coordinates. It is not enough to fix it, I must reduce the size of the VBOs. Then, I need to finish the scenegraph to split the level geometry into smaller VBOs. After that, the game might work better anew even on small âoldâ onboard graphics. Notice that on your screenshot, the frame rate is not displayed, it means that there is a serious problem with the JOGL TextRenderer. It happens when no more VBO can be created. 62 FPS is very low for this generation of graphics card, it should be twice better.
Update of the Java archive:
Update of the Java archive:
Please donât use âIntel Corporation Mobile 915GM/GMS/910GML Express Graphics Controllerâ with my game or you will get this:
[java] javax.media.opengl.GLException:
javax.media.opengl.GLException: array vertex_buffer_object must be
disabled to call this method
[java] at
javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
[java] at
javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
[java] at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
[java] at
main.GameGLEventController.display(GameGLEventController.java:334)
[java] at main.GameView.display(GameView.java:104)
[java] at main.GameModel.runEngine(GameModel.java:1104)
[java] at main.GameView.(GameView.java:81)
[java] at
connection.GameServiceProvider.main(GameServiceProvider.java:81)
[java] Caused by: javax.media.opengl.GLException: array
vertex_buffer_object must be disabled to call this method
[java] at
com.sun.opengl.impl.GLImpl.checkBufferObject(GLImpl.java:30668)
[java] at
com.sun.opengl.impl.GLImpl.checkArrayVBODisabled(GLImpl.java:30716)
[java] at com.sun.opengl.impl.GLImpl.glVertexPointer(GLImpl.java:27937)
[java] at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.drawVertexArrays(TextRenderer.java:1771)
[java] at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.draw(TextRenderer.java:1745)
[java] at
com.sun.opengl.util.j2d.TextRenderer$Pipelined_QuadRenderer.access$000(TextRenderer.java:1687)
[java] at
com.sun.opengl.util.j2d.TextRenderer.flushGlyphPipeline(TextRenderer.java:809)
[java] at
com.sun.opengl.util.j2d.TextRenderer.endRendering(TextRenderer.java:705)
[java] at
com.sun.opengl.util.j2d.TextRenderer.endRendering(TextRenderer.java:541)
[java] at main.GLProgressBar.display(GLProgressBar.java:223)
[java] at
main.GameGLEventController.display(GameGLEventController.java:615)
[java] at
com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
[java] at
javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
[java] at
com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
[java] at
javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
[java] at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
[java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
[java] at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
[java] at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
[java] at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
[java] at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
[java] at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
[java] at
java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
These are the different features Iâm working on :
Hi!
Finally, as many people here and on happypenguin.org have complained about the mouse control, Iâm modifying it. It requires much time than I thought as I must modify the auto-centering system too. Can someone give me an example of what you expect for the mouse handling? Currently, in the next version, I plan to use the shift between the old position and the new position (MouseEvent.getX()) to compute the direction but my auto-centering system generates sometimes strange values :-\
Yeah! The mouse look has been improved thanks to Riven! I hope erikd will appreciate this aspect (the sensibility will have to be more easily modifiable). Together we are stronger! I will update the whole game tomorrow after some cleaning. Yeah break some robots! I hope that the next weapon will help you to destroy them by shooting through the walls! ;D ;D ;D
Update of the source code and the Java archive:
Have fun! ;D
Mouse movement is much better (much smoother) now, but was a little too slow on my PC (easy to fix (if its based on time))
There is one more thing I think you should do to give the game the justice it deserves in terms of looking fast:
Make moving around smoother: When I move, the game is very jerky.
What I am saying is that now if I just use the mouse to look around it looks like 60fps (Looks fantastic), but as soon as I press a key it looks like 10fps (Bad).
Perhaps in your code you have something like when W is pressed add 10 to X position, well it shouldnât, it should somehow incrementally add to X over time so that it doesnât suddenly go from X=42 to X=52.
I think the game will benefit greatly from this change as it will appear that the performance has increased alot.
The mouse is no more based on time (it gave something strange when I mixed the new algorithm with a time-based approach). I will allow the user to configure the sensitivity. Youâre right, Iâm going to improve the movement by using the keys. Thank you very much for your advice. ;D
Iâm going to update the Java archive and the source tomorrow. I failed in using JOGL 1.1.1 RC8, I got a ClassCastException for an unknown reason. Now, I use the immediate mode only sometimes in the menus and in the game only when the graphics card canât create any display list, vertex array and any VBO. It is interesting to notice that the performance decreases significantly when I mix the immediate mode with some VBO.
Yes, the mouse look and bullets are a huge improvement and the game is actually starting to become playable. Well done!
What I did notice in this release that when I move I hear some rattling, as if a sound effect is started every frame when you move. This also seems to affect the smoothness of the framerate somewhat.
I also agree that the mouse look could be a bit more sensitive.
Youâre right. I think it comes from the âcarpetâ sound, I will try to solve this problem.
The development of the game has been temporarily paused. I will try to finish to implement some power ups when I am less tired.
The development of TUER resumes today, sorry for the delay. The model factory and the view factory are ready, Iâm going to update the source code tonight. I will implement a way of positioning health power up on the map, the collection mechanism has not yet been tested. From now, as Iâm very tired and as it sometimes becomes hard to find spare time to program, I will subdivide all tasks in smaller tasks that I can complete in some hours and I might display a planning on my website to help people to see the guidelines of the project.
I have decided not to use RMI directly for the online mode as the latency should be a big obstacle. I donât know where to start but I will probably use Project Darkstar if it fits into my project and if it is easier than only modifying my software architecture to use only TCP sockets.
I will provide low quality textures for old graphics cards. Does someone know if on-board graphics produced in 2000 generally support 128*128 texture size? If you use old VIA chips, it works better under Linux, I didnât expect that ;D.
I think you can also safely use 256x256 textures. Even the first voodoo cards from before 2000 (which were the first mass market, popular 3D cards) supported up to 256x256 textures.
If you really want to support hw that old, also make sure you donât use any OpenGL calls beyond 1.1 (and 3dfx âMiniGLâ drivers even supported just a subset of OpenGL 1.1, just enough to run Quake2)
I donât understand. I donât find the reason why some old VIA chips produced between 2000 and 2003 donât support TUER, I donât find the reason, I thought it was because of the texture size. I will have to investigate again. I only want to support major graphics cards produced from 2000 to now if possible and onboard graphics from 2003.
