TUER: Truly Unusual Experience of Revolution, FPS using JOGL

[Eli Delventhal]

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? :-P

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:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15

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!

Looks good, no problems with Mac OS X Snow Leopard.

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.

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? :-P

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

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.

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 :

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.

[Eli Delventhal]

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.

Games published by our own members! Go get 'em!

[gouessej]

Hi!

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 

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]

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]

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.

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.

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 

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

[Markus_Persson]

Could you post a recent screenshot? =)

[gouessej]

Could you post a recent screenshot? =)

I'm going to do it tonight.

Games published by our own members! Go get 'em!

[gouessej]

I will post a snapshot later because there are almost nothing new. I wanted to modify some enemies with the software "MakeHuman" but my Linux is too old to support it

[gouessej]

Could you post a recent screenshot? =)

Done.

[h3ckboy]

nothing there.... it has the little file does not exist thing.

[gouessej]

nothing there.... it has the little file does not exist thing.

I have just finished to update all files including the latest version of TUER and JFPSM (there are only pretty minor changes). Now it should work. I don't understand what you mean, "it has the little file does not exist thing"  Let me know if there is something wrong. I'm going to have a rest some days, I might be tempted to work on some algorithms as usual... 

[h3ckboy]

sry my bad, I dont know why it didnt appear, it is there now.

[gouessej]

sry my bad, I dont know why it didnt appear, it is there now.

Ok it is solved

The creature has no texture yet because I have a lot of problem with Blender, I had to use the original model that was delivered with some blood marks and a useless outdoor, I put it into 3DVIA converter, I manually modified the DAE file and I converted it into Ardor3D binary format.

[gouessej]

Hi!

The project TUER will be paused until April as I have to develop another game on Freebox (ADSL box).

However, someone tried to launch the alpha version of TUER and said that it stayed frozen in full-screen mode, the game did not respond. He has a graphics card Nvidia 8600 GT, he is under Windows XP. Can someone with a similar configuration give it another try please? This is here:
http://tuer.sourceforge.net/tuer.jnlp

[gouessej]

Hi!

I'm adding the possibility of taking the weapons:

[gouessej]

Hi!

I have just updated the very experimental version relying on Ardor3D here:
http://tuer.sourceforge.net/very_experimental/tuer.jnlp

New features:
- pick up 6 weapons (pistol 9mm, pistol 10mm, mag 60, uzi, smach (submachine gun), laser)
- change weapons (mouse wheel, P & M)

It is not yet possible to shoot but I will implement this feature as soon as possible 

[h3ckboy]

sounds great, you rmaking good progress

[gouessej]

sounds great, you rmaking good progress

Thanks. Someone said it does not work on Windows 7, I hope there is nothing wrong.

[Hansdampf]

Works on win7.
The menu buttons resized to width*8 after returning from a sub menu but the responsive area was still width.

sounds great, you rmaking good progress

Nice words but frankly I can't see a progress - I was flying around (through walls and the ceiling) with 20fps, saw no weapons, no moving entities, not able to fire.
ok, maybe it does work with win7 but not as expected. Some years ago it worked a lot better for me.

edit: to be fair, I wanted to try the not experimental version, but it did not load. Loading forever.

[h3ckboy]

Works on win7.
The menu buttons resized to width*8 after returning from a sub menu but the responsive area was still width.Nice words but frankly I can't see a progress - I was flying around (through walls and the ceiling) with 20fps, saw no weapons, no moving entities, not able to fire.
ok, maybe it does work with win7 but not as expected. Some years ago it worked a lot better for me.

edit: to be fair, I wanted to try the not experimental version, but it did not load. Loading forever.

well, he added gun picking up, which isnt that easy, and if he is gunna soon have collision, that is a huge step. BTW, a kind word usually helps someone achieve more than obvious negativity

[Hansdampf]

BTW, a kind word usually helps someone achieve more than obvious negativity

And honest words help even more - better than positive critics just for the sake of it. I'm pretty sure you did not try the new version before posting.

[gouessej]

Works on win7.
The menu buttons resized to width*8 after returning from a sub menu but the responsive area was still width.

Thank you for testing. Do you speak about the menu buttons of the game? I don't understand what you mean.

Nice words but frankly I can't see a progress - I was flying around (through walls and the ceiling) with 20fps, saw no weapons, no moving entities, not able to fire.

When you start, 6 weapons are visible, they are in the first room. I wrote yesterday "It is not yet possible to shoot" therefore you should not be surprised not to be able to fire. I already wrote in the past that the collision system was not yet ready.

ok, maybe it does work with win7 but not as expected. Some years ago it worked a lot better for me.

edit: to be fair, I wanted to try the not experimental version, but it did not load. Loading forever.

I began implementing this very experimental version in September 2009, I had to slow down the development of TUER because of another project, I had a lot of problems with my computer for several weeks, I do my best with the little spare time I have. I have never said that this version was complete, it requires a lot more work.

[h3ckboy]

And honest words help even more - better than positive critics just for the sake of it. I'm pretty sure you did not try the new version before posting.

I didnt need to. and btw, u posted things like goussej said, that he already knew. I never said that criticism is bad, I said that pointless obvious criticism is, if he already knows it isnt complete, and says stuff doenst work, then you sound like an idiot if you just repeat back what he already knows (no, I am not calling u an idiot, just explaining what I said).

u get what I mean?

[gouessej]

I didnt need to. and btw, u posted things like goussej said, that he already knew. I never said that criticism is bad, I said that pointless obvious criticism is, if he already knows it isnt complete, and says stuff doenst work, then you sound like an idiot if you just repeat back what he already knows (no, I am not calling u an idiot, just explaining what I said).

u get what I mean?

He posted some things that we already knew as you can see below:

I have to implement the collision system

It is not yet possible to shoot

In order to prevent Hansdampf from going completely through all walls, I have implemented a dirty thing to prevent temporarily any change of ordinate. It should be a bit better now.

Edit.: ok if the lack of collisions is so problematic, I will try to implement a fast dirty thing until I have much time to implement a cleaner approach.

[Hansdampf]

Thank you for testing. Do you speak about the menu buttons of the game? I don't understand what you mean.

yes, the menu buttons. They (except the start button) were stretched, but not responsive in the (over)stretched area.
I just tried again - I didnt see the weapons as weapons because they were pink and without textures.
Sorry, I had a bad day - then I wasted again time with this game because I thought hmm must be a good progress because this blog was bumped again.

[gouessej]

yes, the menu buttons. They (except the start button) were stretched, but not responsive in the (over)stretched area.
I just tried again - I didnt see the weapons as weapons because they were pink and without textures.
Sorry, I had a bad day - then I wasted again time with this game because I thought hmm must be a good progress because this blog was bumped again.

bobjob showed me the bug, he reproduced it and it is fixed now (the JPEG files were not in the JAR). I have added a basic collision system, it is a very bit inaccurate but better than nothing. I really do my best. Is it any better now? Empty your Java Web Start cache if you don't see any difference. Please can you give me a screen capture of the menu?

I thank bobjob a lot for his help. Thank you everyone for testing.

[h3ckboy]

I tried the newest version, and I only had an FPS ~7, and it was pretty jumpy.

but aside from that the collision seemed to work(well, sometimes it glitched, but that is probably cause of low fps).

although I wouldnt worry bout fps too much, cause this computer sux, it only has 1.33 GHz dual core....