TUER: Truly Unusual Experience of Revolution, FPS using JOGL

[gouessej]

@EgonOlsen

Works fine here under Vista 32Bit/Ati Radeon 4870/Java6.

Thank you, you reassure me, it means that the bug mentioned by Riven is not reproducible on all machines under Vista. Do you see the FPS counter at the bottom left corner?

[Riven]

@gouessej

Thank you, you reassure me, it means that the bug mentioned by Riven is not reproducible on all machines under Vista. Do you see the FPS counter at the bottom left corner?

Vista 64bit, GeForce 8600GT

[EgonOlsen]

@gouessej

Do you see the FPS counter at the bottom left corner?

Yes, i do.

[bobjob]

hey gouessej.

I had a try on Windows XP. Really liked the Cop Model.

I noticed a few things though.

• After I quit the game javaw.exe was still running in my task manager.
• If you hold forward and turn the mouse left and right you will go forward faster.

[h3ckboy]

I had the same issue as riven, Windows XP :persecutioncomplex:

[gouessej]

Hi!

@h3ckboy

I had the same issue as riven, Windows XP :persecutioncomplex:

Ok I will speak about it to the developers of Ardor3D.

@bobjob

• After I quit the game javaw.exe was still running in my task manager.

It is the same bug than Riven and H3ckboy reported.

@bobjob

• If you hold forward and turn the mouse left and right you will go forward faster.

It is a known bug of Ardor3D, in the mouse manager, it appeared when Renanse tried to fix the bug in the mouse grabbing, it will be fixed in the version 0.7.

Thank you for testing.

[gouessej]

Hi!

I will add a try catch finally clause in the main class but it would be fine the guys who have problems on leaving the “game” could have a look at their logs, I think an exception is thrown.

[h3ckboy]

@gouessej

Hi!

I will add a try catch finally clause in the main class but it would be fine the guys who have problems on leaving the “game” could have a look at their logs, I think an exception is thrown.

byt that you mean, console? or is there an actual log somewhere?

[gouessej]

@h3ckboy

byt that you mean, console? or is there an actual log somewhere?

At first, if possible, look at the console. I think that if I add a try catch finally clause, the game will quit normally but it won’t solve the real problem, something is wrong during the cleanup.

[h3ckboy]

hmm closed fine in windows 7

[Demonpants]

Looks good, no problems with Mac OS X Snow Leopard. I agree with Riven - you are rendering so much that you probably don’t need to render. But obviously you know that already, so why am I telling you?

Instead of spending a lot of time on portal culling, you could get away with a simplified sort of raycasting - given that your level is grid-based (or at least appears to be), just do a simple algorithm that does like 16 casts around a circle. Kinda like this:

ArrayList drawableTiles = new ArrayList();
drawableTiles.add( (int)(playerPos.x / gridSize), (int) (playerPos.y / gridSize) );

for (float angle = 0; angle < 2*Math.PI; angle += Math.PI / 8.0f)
{
    float checkX = playerPos.x;
    float checkY = playerPos.y;

    while (positionIsNotWall(checkX, checkY))
    {
            checkX += Math.cos(angle) * gridSize;
            checkY += Math.sin(angle) * gridSize;
            drawableTiles.add( (int)(checkX / gridSize), (int)(checkY / gridSize) );
    }
}

Just pretend the drawableTiles automatically doesn’t add duplicates. Also, the reason you add a check position even if it might be a wall is because you also want to draw the wall. Obviously you’d need to do some more work than this, like probably increasing the number of angles you’re checking from dependent upon the size of the room, etc. but the implementation is obviously very quick and easy. Definitely doesn’t take months.

You could also do another simple algorithm where you add all tiles to the north, south, east, and west of the player’s position (until you encounter a wall in that direction). Then you continue to add any unadded tiles that have at least two adjacent neighbors that have already been added. This works great for a grid environment, although doesn’t look totally perfect when you’re near corners.

[gouessej]

Hi!

[quote=“Demonpants,post:691,topic:29428”]
Thanks for testing. I’m happy to know that it still works fine under Mac OS X, there are more people under Mac than under Linux, I cannot settle for the support of Linux.

@Demonpants

much that you probably don’t need to render. But obviously you know that already, so why am I telling you?

Lol I already know it, the frame rate is lower in this version.

@Demonpants

Actually, JFPSM tries to use regular and irregular grids when it is possible. However, some potential users already ask me a support of ordinary levels mixing complicated structures, indoor and outdoor environments. Moreover, Orangy Tang wrote that concerning some FPS that I quoted :

[quote]Pretty much all of the games on that list are ones that dodge the content issue somehow - either they take a simplified approach (like flat, doom-style 2d maps rather than proper 3d ones, or sprites for enemies rather than models) or they base themselves on an existing game to take advantage of existing content.

JPCT already supports the portal culling with jKılavuz (closed source, not free of charge for unlimited use). I have to go past the limitations that Orangy Tang noticed and the portal culling is an important feature that should already be implemented in all decent 3D engines written in Java. Your suggestion is excellent but if I use it, I will reach one of my aim later. I want to implement portal culling to support any kind of levels, not only flat levels, not only doom-style or wolfenstein-style 2D maps even though JFPSM begins with supporting such maps at first.
I will at least implement the creation of cells and portals, then I will probably use your suggestion temporarily (it is better to use your algorithm on bigger cells than on voxels) until the portal culling is ready except if implementing the portal culling will seem noticeably easier to implement than now. Thank you.

[Demonpants]

Well that’s a very good point. If you did my implementation you would indeed be limiting yourself to a grid-based system. If you manage to get portal culling and open environments in play, that will look very cool.

[gouessej]

Hi!

@Demonpants

Well that’s a very good point. If you did my implementation you would indeed be limiting yourself to a grid-based system. If you manage to get portal culling and open environments in play, that will look very cool.

You’re right, it will be very cool ;D

TUER now uses directly a level generated by JFPSM, the merge option works fine. I’m very happy because in spite of the complexity of the algorithm, my implementation (about 500 lines of code) has worked immediately, I did not need to fix any bug. I’m very tired (I celebrated my birthday yesterday). I will update TUER and JFPSM when I feel better.

I’m going to work both on the space partitioning and the collisions.

[h3ckboy]

congratz on getting it first try, Il be sure to try it out.

happy birthday

[gouessej]

Hi!

The computations of the bounding boxes used to handle the collisions will need some convex sets in input. The difficult part of the algorithm consists in computing these convex sets for any soup of triangles. I hope I won’t spend too much time on it.

[Riven]

@gouessej

Hi!

The computations of the bounding boxes used to handle the collisions will need some convex sets in input. The difficult part of the algorithm consists in computing these convex sets for any soup of triangles. I hope I won’t spend too much time on it.

Say what? Just make it work, with a simple implementation, using either bounding boxes and bounding spheres (or a combination). Nobody cares about extremely efficient code if there is no gameplay. Do it quick-and-dirty, and keep it that way, until you find a need to replace it with something better. Over-engineering is what is killing TUER (no pun intended), seriously, and I’m not trying to be offending, just hoping you will realize and ditch a heck of a lot code and implement a simple frustrum culler, like a quadtree, not even an octtree. I’m sure it will be an order of magnitude faster than what you have now.

[gouessej]

@Riven

Say what? Just make it work, with a simple implementation, using either bounding boxes and bounding spheres (or a combination). Nobody cares about extremely efficient code if there is no gameplay. Do it quick-and-dirty, and keep it that way, until you find a need to replace it with something better.

I have found a solution that is clean but close to what you’re saying. For the moment, I’m going to implement the computation of bounding boxes only for tiles that use cuboids (which is easier than handling all cases), the other kinds of shape will have to override one method to do it properly and I will do this later in order to improve the gameplay now. I don’t need to support the other kinds of shape in the short-term perspective.

[quote=“Riven,post:697,topic:29428”]
What was killing TUER some months ago was rather the buggy JOGL renderer of JME 2.0 despite our efforts (cylab made a great job). I try to do something clean because it is easier to maintain (Vincent Stahl’s source code was becoming really difficult to maintain with my own features) and because TUER is used in several university lessons (in Portugal as far as I know). I don’t want to do something dirty because I already know the consequences. I have worked on TUER for several years; when the source code becomes unreadable, it is just discouraging. I don’t understand why you talk about over-engineering. I admit that a tree would be enough for static levels but I have already partially (in some restricted cases) implemented the space subdivision into cells and portals in other engine, I feel more comfortable with it. I think that no player cares about extremely efficient code if there is no gameplay but now I have a bigger screen, the frame rate has fallen at 5 FPS without space partitioning, there will be no testable gameplay on my machine without space partitioning. On the other hand, there is no competition, TUER won’t participate to any contest, there are far better FPS written in Java, Tesseract has a better gameplay, Resistance Force is more beautiful, Night Squad 2 is better even though it is less cross-platform. I’m not in a hurry. I can work on such a project during years if and only if the source code is beautiful lol ;D

Edit.: if there was no “playable” version of TUER, I would completely agree with Riven.

[Markus_Persson]

Could you post a recent screenshot? =)

[gouessej]

@Markus_Persson

Could you post a recent screenshot? =)

I’m going to do it tonight.