[quote=“gouessej,post:740,topic:29428”]
What’s your plan for getting there?
A while back in this thread, you said something about people judging the game from and outdated version of the game, and I asked you to post a recent screenshot. You posted this:
Gouessej, have you ever considered abandoning TUER and starting completely afresh with a reasonable plan and an objective? As in “as good as Doom” or even “as good as Wolfenstein”? And then working from first principles one step at a time until your game really is as good as those games at each step of the way. Starting with game init, through the title screen menu, through to the game itself, etc.
It’s funny watching gouessej running around chasing his tail over obscure compatibility/launching issues when the actual gameplay is so horribly broken. I seem to remember playing Tuer originally and at least being able to move around, shoot enemies, have them shoot back and complete a level. Yet now the movement is glitchy, collision detection is broken, weapons don’t work and there’s no enemies in sight, and that’s not to mention the strange work-in-progress artifacts lying around everywhere (like the untextured models).
Cas’ suggestion of starting from scratch is probably the most practical and productive, because it looks like Tuer is just going backwards.
I got same issue then Hansdampf & Markus_Persson on Vista (wrong texture), I suppose that you have a problem in your opengl states, that’s will explain why some texture does not appear and or wrong textures are sometime applied to models.
The roof and ceiling height can he changed in JFPSM, the camera doesn’t clip through the ceiling anymore, this is not my importer (it comes from Ardor3D), I’m not an artist so I prefer using existing models for the moment, I still use Vincent’s textures and I get a low frame rate because I have still a very slow machine with a big screen.
I will never consider abandoning this project and obviously it is not a commercial project, I think I disagree with you about what is reasonable and what is not.
[quote=“princec,post:742,topic:29428”]
This looks like a little bit my plan. If you look at the very experimental version, you notice that I began with improving the introduction scene, etc… In my humble opinion, it is reasonable but I don’t deny I made some wrong decisions especially concerning the use of JMonkeyEngine. It is an excellent engine but I should have used it with LWJGL (but the bug of the straight lines has been fixed only very recently) or I should have chosen a better engine that relies on JOGL instead of wasting my time in fixing some bugs in JME 2.0 whereas these fixes have become useless (people who want to use JOGL with JME use JME 3).
I won’t start another project from scratch. I want to go on developing TUER. Thank you for your suggestion.
Do you remember why the default version that gets launched on my website is the alpha version of TUER (the version you’re talking about with working enemies, etc…)? The alpha version is still online because this is my choice, a logical choice. While the very experimental version is not at least as good as the alpha version, it won’t replace it. TUER is not going backward, a playable version is still available, the very experimental version is just not ready to be considered as a working game. Therefore, you don’t teach me anything.
However, I have to remind you some things concerning my small progresses, TUER is just going forward in the following aspects:
it is now possible to look up and down
the introduction scene is really better
the ability of picking up objects in the alpha version was buggy whereas it works fine in the very experimental version
there was only one weapon in the alpha version whereas there are 6 weapons in the very experimental version
the robots were flat (2D) in the alpha version whereas all enemies are in 3D in the very experimental version
it is now possible to take one weapon per hand
unlike what you said, the collision system (that has been implemented in only a few hours) works quite fine but it is still incomplete
I admit that there is no artificial intelligence and the weapons are not yet working. I need more time.
[quote=“Markus_Persson,post:737,topic:29428”]
For example, the bug of the menu came from RowLayout, a class of Ardor3D and it has been fixed. Therefore, I was right, I wasn’t blaming bugs on external factors. While I don’t change anything in my source code and I get a regression, I find it logical to assume that the problem might come from external tools.
One model is white because it has no texture but the bug Hansdampf noticed has been fixed, some JPG images were missing in the main JAR, it was my fault. If some weapons still have no texture, empty your cache and reinstall the game. Did you test it with Windows 7 too? Thank you very much for testing it
[quote=“gouessej,post:732,topic:29428”]
I quote myself. I’m implementing this thing. It is a bit difficult but very promising ;D
If someone really wants to help me, please give it a try under Windows 7 and tell me which version of Java you use.
Thank you for this information. Only bobjob succeeded in launching and using successfully TUER with Windows 7 once. I have modified the depth bits (OpenGL see GLCapabilities) and I’m trying to remove some parts of the code that might force the OpenGL context to become current when it shouldn’t. I will try to submit a fix and update the JARs before midnight (French time). I don’t even understand why I don’t reproduce this bug.
[quote=“gouessej,post:732,topic:29428”]
Time has come to explain what I meant more precisely. The image below shows the first level of TUER in Blender:
Actually, each square composing the floor, the ceiling and the walls is explicitly computed. I mean that one quad is used for each square even though they are adjacent and identical.
A French artist accustomed to use modelers showed me this:
He explained to me that he used only a very few quads to do this. Unlike me, he used only one quad for several adjacent squares using the same textures.
Currently the first room is composed of 80 squares on the floor, 80 squares on the ceiling and 32 squares on the walls (= 192 squares). Therefore, 384 triangles are used. By using his suggestion, only 14 triangles will be necessary to draw the same things, I will only have to use texture coordinates greater than 1 with GL_REPEAT. Now I assume you understand why I’m impatient to make it work. Of course, another optimization will be implemented for more complex rooms.
What do you mean exactly? The very experimental version sends the whole level to the graphics card without using any spatial subdivision (I don’t have enough time to port all my source code from JME 2 to Ardor3D). It means that hundreds of thousands triangles are currently sent to the graphics card whereas the optimization that he suggested will allow me to send only about 10 000 triangles to the graphics card. Obviously this optimization is efficient mostly on very orthogonal levels. Are you still skeptical?
Actually, I will try to do the both but I won’t limit the geometry to potentially visible set first because I think maybe a part of the algorithm used to build big squares could be used later and modified to compute cells. Why do you think the gains of merging is very minor? Sending 500 000 triangles to the graphics card is obviously slower than sending only 10 000 triangles, isn’t it?
I understand it is confusing as the alpha version and the version relying on JME do not render the whole level.
When I used a reasonable PVS, it was between 2 and 4 times faster. After some more calculations, I think that only 4000 triangles will be necessary after the merging, it is about 100 times less. I don’t think it will reduce the rendering cost by a factor of 100 but, as the VBO will be 100 times smaller (maybe less because I use indices), it will be noticeably faster with my graphics card above all because its implementation of VBO consists in using vertex arrays, it means the data are sent for each frame.
With resonable culling you could add many more rooms to your level with zero performance hit
With your merging algorithm, if you add more rooms, you get a non zero performance hit!
To be honest I don’t think you should stick with levels made out of primitive quads anyway.
Yes but if I add no room, my merging algorithm will improve the performances in comparison with what is done currently.
Yes, you’re right. See this as a step. It is easier to implement frustum culling and cells-and-portals algorithm on primitive quads than on complicated levels. At first, I have to handle “simple” levels efficiently and then I can plan to support more complicated structures. Proceeding like this is easier than trying directly to support complicated levels.
I plan to put this into TUER in a far future:
It is better than the current level, isn’t it?
Edit.: bobjob and someone else confirmed that TUER works reliably with Windows 7. I remind you that the frame rate is capped as I use the vertical synchronization in order to remove the screen tearing as cylab advised me some months ago.
While implementing the merge of adjacent and identical faces, I realized that I need to be able to use one texture per face. I succeeded in making a first partial implementation of this merge but now I have to implement a mechanism to create a separate node (of a scene graph) per kind of face, it is not very complicated, it will require a few hours. I will let you know when the performances are better
The code used by JFPSM to generate the levels is very memory-hungry, I will have to do something to reduce the minimal memory requirements because at least one student failed to use it on a laptop with only 1 GB of RAM. Using only indirect NIO buffers when direct buffers are not required might help a bit.
[quote=“gouessej,post:759,topic:29428”]
Direct buffers don’t need to consume more memory than heap buffers.
If you allocate lots of tiny direct buffers the overhead is massive (4K per allocated buffer) but if you allocate one large direct buffer, and slice() it, the overhead becomes negligible.
