Looks more like pre alpha to me, im sorry but its not playable on my pc.100fps, but the player is stuttering to move forward.Also the mouse is not visible or working.i can walk trough the glitched guy, the wall stops me correctly i think.I cant use or see any weapons.

I already explained in this thread that it is called "pre-beta" but it is not yet in a correct state, it is very incomplete, it doesn't deserve to be shown as a pre-beta. That's why the main link still points to the other alpha. I don't reproduce this "stuttering", the mouse is working but there is no crosshair yet, the collisions are not fully working except partially for walls. You can use the weapons, you have to pick them up, then pick up some ammo (the green box), reload them (by pressing R) before shooting (left mouse button).

Haha oke, sorry 37 pages is a bit much to read.With mouse not working, i ment i can seem to shoot, but i see i need to do some more actions to make it work.Maybe its nice if there was an icon of the current weapon showing + ammo / loaded ammo.Stuttering happens when the player is moving, so it could be delta rounded to much (with my 100 fps)?

Haha oke, sorry 37 pages is a bit much to read.With mouse not working, i ment i can seem to shoot, but i see i need to do some more actions to make it work.Maybe its nice if there was an icon of the current weapon showing + ammo / loaded ammo.

I see what you mean but there is a menu showing all controls. Usually people don't read the instructions, it's not my fault. The ammo and the loaded ammo are shown in the bottom left corner, in white but the icons are missing.

Could you please re-calculate the projection matrix, when the user resizes the window? That would be pretty helpful... I think you also need to re-set the viewport, since I have a problem playing this on one monitor windowed... Because the point where I look at is right at the right mid of the window.

Could you please re-calculate the projection matrix, when the user resizes the window? That would be pretty helpful... I think you also need to re-set the viewport, since I have a problem playing this on one monitor windowed... Because the point where I look at is right at the right mid of the window.

Could you please re-calculate the projection matrix, when the user resizes the window? That would be pretty helpful... I think you also need to re-set the viewport, since I have a problem playing this on one monitor windowed... Because the point where I look at is right at the right mid of the window.

Could you please re-calculate the projection matrix, when the user resizes the window? That would be pretty helpful... I think you also need to re-set the viewport, since I have a problem playing this on one monitor windowed... Because the point where I look at is right at the right mid of the window.

Actually, I didn't want to allow the user to resize the window...

I would really like to have this feature.

Historically, canvases in Ardor3D were not designed to be resized... which is a bit silly. I will ask Renanse if he would like me to remove this limitation. If he agrees with me, I will implement it directly in Ardor3D, otherwise I will do it only in TUER.

matheus23, when do you want to resize the window? The cursor is hidden when you're playing, it would be better to be allowed to switch to windowed mode earlier in the main menu.

I would like to be able to resize, just when the app starts...And I think for that you need to enable the app to be switchable to windowed mode with F11 even when not in-game.I think F11 failed in the menu.

EDIT: Yes, you're right btw, I was only able to resize the window at one single specific mouse pixel position on the edge of the window... or at the top two edges

I will probably be forced to allow to choose a size only in a specific menu before entering the game because if I use a PBuffer or a FBO for post effects, I will have to resize it too if the user is allowed to resize the window whenever he wants.

(currently at a monologue of 7 posts). Better to batch up your updates and only post when you have something substantial to show case.

I just hope that this minor problem is not an occasion to laugh about my project. My "monologue" has been read by some people, I haven't forced them to do so. The notion of substantiality sometimes depends on subjective criteria. The graphics of my game are absolutely ugly, I'm not a computer artist, I don't have tons of pretty things to show. If only this kind of things is considered substantial even in the WIP section, then I have almost nothing to show about my game. I'm on a forum for Java game programmers, I assume I can talk about other aspects, not only the graphics. You could have simply sent me a private message instead of loudly complaining about that here. Why is there nobody to remove completely off topic posts like this one?

Why is there nobody to remove completely off topic posts like this one?

Nobody complained, and I try to keep moderation to a minimum. It's very easy to create an atmosphere were people start to think twice about posting. I like to keep JGO as 'light' as possible in that regard. Everybody should feel free to post anything, until I receive a complaint, or I think something is offensive.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I realize that my previous schemas were not very easy to understand. All adjacent right triangles located in the same plane are stored by pairs, there is a pair per cell. I store these pairs in a 2D array. This array is often obviously not full. I have to reduce the count of full arrays in order to reduce the complexity of the mesh sent to the graphics card. The fewer rectangles I get, the fewer quads will be necessary to represent the whole mesh. That's exactly what I have succeeded to do as you can see below:[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][X][ ][ ][ ][ ][ ][X][X][X][X][X][X][X][ ][ ][X][X][X][X][ ][ ][ ][X][X][X][X][ ][ ][ ][ ][X][X][X][X][ ][ ][ ][ ][ ][X][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]

Instead of having 21 quads, I only use 7 quads, each one is represented with a different color. Best regards.

I have respect for your capability to handle code with so many indentation levels. (up to 20!)

When this class becomes too fat, I will have to split them into smaller ones and it will be fine to avoid using static methods. Eclipse already puts tabs even though I modify its settings, it drives the source code harder to read outside of this IDE.

Sorry. I try to comment this class as much as possible and I really need such names. If I call this variable 0cscvo2ososl, I will have to remember its real meaning while reading the source code whereas this very long name already tells me exactly in which case I am.

Edit.: My website was unavailable for several hours because of a problem on Sourceforge.net. It should work fine anew now.

Some combinations of java-vm-args and <property> elements in a jnlp file may cause some properties to be set incorrectly when Java Web Start is forced to relaunch. The problem is applicable to Solaris and Linux platforms.

In some cases, adding dummy property elements to the jnlp file may help prevent the problem.

I have updated my game, it should work correctly. I don't really understand how the maximum direct memory size is set by default, especially in Java 1.7. If it is set to the maximum heap size, I won't have to use -XX:MaxDirectMemorySize any more.@Riven, do you know how it works? Is there a difference between Java 1.6 and Java 1.7 for the handling of this VM option? Maybe I should dig a bit in the source code. I use sun.nio.MaxDirectMemorySize too.

I've almost ended up implementing the sixth step of my optimization. I will try to implement the 7th and the 8th steps before the end of December.

Why clear the zbuffer? Just change the range on the depth buffer when rendering the weapon.

It's a possible solution too. Why would it be better than clearing the z-buffer?

I have just ended up with implementing the 8th step of the optimizer but I need to test it (a lot) as only a part of the 5th step is covered by a unit test. I remind that this optimizer is based on a suggestion of a French computer artist in March 30th, 2010, it has required lots of work, I really expect an important increase of the frame rate from it.

I have just started to test the whole optimizer:- first step: OK- second step: OK- third step: OK- fourth step: NOK (the test about vertex order seems to be wrong)- fifth step: partially OK (the first algorithm loops forever, the second one works in its separate unit test)- sixth step: untested- seventh step: untested- eighth step: untested

I don't think that I will have enough time to fix it this week but I still hope to make it work before 2013.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org