I think I forgot to include the OpenAL native libs for linux in an old version, I’m guessing that was what the problem is. Since I don’t have a linux (or mac) machine to test on I pretty much just have to upload it and hope like hell.
Hi!
Before porting the game to JME, I will deliver a last version with some bug fixes:
- TUER is still incompatible with the OpenJDK 1.6 because of a NetX bug
http://sourceforge.net/tracker/index.php?func=detail&aid=2340161&group_id=72541&atid=534854 - on some machines, after some minutes, the game becomes unplayable, the screen gets frozen when you press the keyboard
If you want me to fix some other bugs that prevent you from playing pleasantly, let me know but I won’t do any major modification in this version.
Hi!
I update the source code daily. Now, you need JME to compile the source code if you take the latest build on the SVN repository. Please wait for some days because I have to submit several fixes for JOGL, they are on my machine but I have some problems with Subclipse, I’m going to use KDESVN instead.
Hi!
My problems with Google Code have been solved, I will submit my fixes for the JOGL renderer of JME in some days.
As lots of people said that the graphical user interface of TUER is really ugly, I have been spending a lot of time in rewriting the main menu and the pause menu. I’m going to post a screenshot.
Currently, the main menu is composed of menu items rendered as 3D boxes that rotate on themselves when selected/unselected and I will add the animated logo of the game above it.
The pause menu will look like a watch like in Goldeneye 007 on Nintendo 64 but I would like to use ellipsoid shapes rotating around an axis when selected/unselected. When closing it, the menu items will go to the top left corner of the window, moving like air bubbles, becoming bigger and finally exploding.
The intro will show a map of the world becoming progressively red. At the end, the logo will appear.
This is the main menu (it is not finished, it is only a blue print):
http://tuer.tuxfamily.org/screenshots/jmeMainMenu.png
The gray circle comes from the software Ksnapsnot :s
I will update this screenshot as often as possible.
The conversion from the format of the game to the format WaveFront OBJ is working, I only have to improve the way of eliminating duplicate vertices and duplicate texture coordinates :
Just create some class that holds V,T,C,N. Then implement hashCode() and equals() and use a HashMap<VertexData, Integer>.
Do a map.get(VertexData) and see whether you have an index (Integer).
If not, map.put(vdata, currentIndex++).
It’s very scalable, due to the characteristics of the HashMap.
Then simply use indexed geometry in OpenGL.
I already implemented something that looks like this and it requires several hours to remove all redundant vertices because I didn’t implement hashCode. I assume that your solution is nice in the general case, thanks. I found another one that relies on the fact I already have a forest of graphs with cells and portals, it consists in comparing all walls of each cell first and then comparing all walls that are linked to at least a portal, if one of the cells linked to a portal has been already marked (visited), then some vertices are already known, otherwise they might be unknown. I have to compute the indices correctly in order to use them to write the face primitives : f x y z. I hope that this time it will require less that a night to succeed. Thank you for your help.
You can index your models at load time with this technique.
It runs in a split second even for models that have 10k tris.
The problem is that my map is composed of about 1 000 000 quads. Ok I’m going to give it a try. Thanks.
The thing is, that access to HashMaps is log(N), so if 10k is done in a split second, 1000k might take a few seconds.
Can I use a LinkedHashMap?
Ofcourse, it would just be very slow.
It is almost half past 3 in France, my neighbor listen to music and I cannot fall asleep, therefore I do some algorithmic. I have just found a way of using both my first idea and Riven’s suggestion. Each cell contains one LinkedHashMap to associate duplicate indices to unique indices and one HashMap to associate VertexData to unique indices (as Riven suggested) and duplicate indices. I use another HashMap to associate cells to these Map instances.
When I visit a cell, if a vertex is in a wall but not in a portal, I apply Riven’s algorithm to fill the second table, otherwise I get the unique index from the neighbor cell that matches with this portal by using the last table and the second table.
Then, in the both cases, I fill the first table.
After that, when I finish visiting a cell, I fill the last table.
Finally, I use the last table and the second table to write the vertex primitives (v x y z) and I use the last table and the first table to write the face primitives (f v1 v2 v3 v4). It is simple ;D
Sorry for the off-topic, but I needed to correct this:
???
accessing hashmap is O(1), not O(log(N))!
where does they come from?
It is not off-topic, don’t worry. This is an open source project. I appreciate the help of everybody. At least 4 people (Riven, Bienator, erikd, EgonOlsen …) gave me excellent and precise advices that are directly visible in the source code 
Everybody can participate and the result of the collective efforts is available for everybody under GPL licence in return, I find it fair.
[quote=“luckyvae,post:415,topic:29428”]
Thank you very much, you had the good reflex.
[quote=“luckyvae,post:415,topic:29428”]
I generate a forest of graphs containing some cells and some portals. Each cell is composed of several walls. Two cells can be linked together with a portal. For example, if a room is linked to another room, the portal contains the vertices that are common to the both cells. You can have the same vertex several times in a single cell in a corner.
I have already implemented a part of what I spoke. As I make some tables per cell and I fully benefit of the spatial coherence, I think it is faster than using huge tables that concern all vertices. Nevertheless, I have to apply Riven’s suggestion and nothing else for the texture coordinates as I cannot benefit of spatial coherence in this case. I will submit my modification on my SVN repository tomorrow.
[quote=""]
And in this case, you will have in your program multiple reference to the same object or multiple objects representing the same vertex?
I have multiple objects representing the same vertex.
[quote=""]
:o
that (and other) could explain that we need more or less 90Mb of memory which is quite a lot for your game…
I think you should change that, it may take more memory than needed. Less memory mean less time to switch between the memory -> more speed…
Actually, when the scenegraph is activated, only 27 MB are used and without it, only 11 MB are used. The JVM starts with 96 MB because of a parameter in the JNLP file (I can modify it easily). Therefore, I won’t change this aspect, I will go on using multiple objects for the same vertex because changing it would cause other problems in the system that will compute geographical modifications, the walls have to be independent to allow their coordinates to be modified independently even though at a certain instant, some vertices can have exactly the same value. I consider that 27 MB of memory use is acceptable and not performance critical for a map composed of 1 000 000 vertices (with texture coordinates). Each vertex is composed of 5 coordinates (including texture coordinates: u v x y z) and each coordinate is stored as a float, then all vertices occupy 1 000 000 * 5 * 4 Bytes = 20 MB, this is not surprising, there is no memory leak.
To conclude, less than 30 MB for such a map with 1 000 000 vertices is acceptable, isn’t it? For the moment, I prepare the next version that will use JMonkeyEngine. If I want to keep a good frame rate even on low end machines, I will have to ensure that I perform the same optimizations in this version than in the current version and after that, it would be fine to use the view frustum culling of JME to optimize the way of distinguishing which cells are visible from the player’s viewpoint and this might have a significant impact on low end machines if it allows to avoid drawing cells containing a lot of enemies and objects.