TUER: Truly Unusual Experience of Revolution, FPS using JME 2.0 & JOGL

Hi!



The first blue print of the next version of TUER is ready, give it a try:

http://download.tuxfamily.org/tuer/tuer.jnlp



It is extremely experimental and very limited but it allows to show you the progress of my project. For the moment, I only display the cell that contains the player and some bugs are still in the JOGL renderer of JME 2.0:

  • the flickering in the middle of the screen
  • no mouse move when no mouse button pressed



    It still uses JOGL, it still works under Linux, Solaris, Mac OS X 10.5 and Windows and it still requires Java 1.6.



    For those who don’t know TUER, watch this (screenshots of the previous version without JME 2.0):























    The videos are here:

    http://tuer.tuxfamily.org/video.php



    You can test the previous version there:

    http://tuer.tuxfamily.org/tuer.jnlp



    TUER is a first person shooter that I have begun in October 2006. As I was beginning in reinventing the wheel, I decided to switch to JME 2.0 some months ago. Now you know that it is possible to do something with the JOGL renderer of JME 2.0  :smiley: Thanks for your attention.

Hi



The flickering in the middle of the screen might be the result of "screen tearing". Using V-sync might solve this problem. Can someone confirm that this symptom in my game is really some screen tearing (see wikipedia)?

Hmm, bummer it requires 1.6; 32bit Macs will not be able to run it (and that includes me :)).

the enemies look like sprites, are you gonna replace them with 3d models ?

Looks like a fun game! Enjoyed the videos.

With those kinds of graphics, it might even work on those 1985 unix machines! :smiley:

I tried running it on my WinXP machine and it did indeed run, but it seems like the keys randomly get sticky and send me spinning around in circles endlessly or shooting off into oblivion.



Also, if the maps are all the same height level, i'd suggest fixing the player height to be always the same.  Since you don't have any wall collision working, it's already hard enough to stay inside your cells.  Fixing the height to always be a certain value would help a little.



Interesting start. :slight_smile:

basixs said:

Hmm, bummer it requires 1.6; 32bit Macs will not be able to run it (and that includes me :)).

Sorry but the use of Java 1.6 instead of Java 1.5 improved the reliability of the game (reliability of NIO, some bugs in the sound). However, in the future, maybe I will modify the deployment to allow Mac with Java 1.5 only to use different JARs. What about Soylatte? OpenJDK 1.6?

Core-Dump said:

the enemies look like sprites, are you gonna replace them with 3d models ?

Yes of course I plan to do it as the current enemies are ugly.

nymon said:

Looks like a fun game! Enjoyed the videos.

Thanks.

Momoko_Fan said:

With those kinds of graphics, it might even work on those 1985 unix machines! :D

Lol. The previous version of TUER works quite fast (at least playable) even on computers bought in 2002.

renanse said:

I tried running it on my WinXP machine and it did indeed run, but it seems like the keys randomly get sticky and send me spinning around in circles endlessly or shooting off into oblivion.

It comes from bugs of JME 2.0  :'( this one is even not reproducible under Linux. I have decided to pay someone to help me to fix the main bugs in the JOGL side of JME because I don't want to waste months to fix them alone.

renanse said:

Also, if the maps are all the same height level, i'd suggest fixing the player height to be always the same.  Since you don't have any wall collision working, it's already hard enough to stay inside your cells.  Fixing the height to always be a certain value would help a little.

Interesting start. :)

I'm trying to finish to implement the last part of my algorithm of view frustum culling and then I will implement a collision system. I use JME in order to ease the development (not reinvent the wheel...) and I won't use only simple levels with orthogonal walls with the same height. Thank you for your feedback.

A new build is ready, give it a try:

http://download.tuxfamily.org/tuer/tuer.jnlp

Now, a dummy algorithm shows all visible cells, a better one will be implemented later.

Hm the Portal stuff is kinda intresting, so you can build impossible levels?  Like a room with a hole in the floor, and the ceiling. And when you fall through the floor you fall through the celing in the very same room? (sorry for that sentene, but I can’t really explain it better , but maybee someone reminds about

DM_Fractal from Unreal Tournament99


Hi!



I have an excellent piece of news: the frame rate of my blue print using JMonkeyEngine 2.0 is greater than the frame rate of my previous engine that does not use JMonkeyEngine 2.0  since I found how to reset the culled test!  :smiley: Now I get between 60 and 142 FPS instead of 16 FPS on my "old" computer (Mandriva Linux 2007, AMD Sempron 2600+, 2 GB DDRAM, ATI Radeon 9250 Pro).



I feel reassured and I'm glad to say that I will go on using your nice engine. It becomes really nicer with my portal culling  :smiley: even though it is not finished. A smaller boost in the performances is expected when the algorithm is completely implemented. I will update my blue print soon.

Good to hear.

Just out of intrest, what is TUER exactly?



I mean from what is written I can get it is a fps, (I even used the webstart and played it a little untill i descover the mentioned Key bug).



So the question most intresting for me is:



What exactly makes TUER special? I guess your intention never was to create something with best grafic ever ^^. Also from the few minutes I was able to play it, i assume that neither the Enemys nor the Weapons are special (I might be wrong here though).

Empire Phoenix said:

Just out of intrest, what is TUER exactly?

T.U.E.R ("tuer" means "kill", it is a French word and the abbreviation for "Truly Unusual Experiment of Revolution") is a modest first person shooter.

Empire Phoenix said:

I mean from what is written I can get it is a fps, (I even used the webstart and played it a little untill i descover the mentioned Key bug).

Which webstart? There are 2 JNLP file, one for the version that depends on JME 2.0 (no enemy, very empty) and one for the previous version that uses my own "engine" (a more complete game that should not have any key bug).

Empire Phoenix said:

So the question most intresting for me is:

What exactly makes TUER special? I guess your intention never was to create something with best grafic ever ^^. Also from the few minutes I was able to play it, i assume that neither the Enemys nor the Weapons are special (I might be wrong here though).

TUER has been mainly used as a field of algorithmic experimentation, not a AAA game as you noticed, the graphics are ugly and the gameplay is quite limited. The artistic aspect has never been a priority in this project. However, I decided to use JME 2.0 some months ago to avoid reinventing the wheel and then to have some reliable loaders already available and fully implemented in order to load more beautiful weapons and enemies. A 15-year-old guy drew a pretty rocket launcher to replace the current one, someone else has authorized me to use its MD2 human models and someone else has authorized me to use its sound samples of Techno music. Little by little I will add all these artworks into the blue print. JME 2.0 allows me to add de facto some features into my game as they are already working and asked by the players, for example the full mouse look.

As I'm already a politician and union activist, I might use the game in order to propagate political messages as I did during the Olympic games in 2008.

Finally, I said TUER has been mainly used as a field of algorithmic experimentation. I would like to implement a complete solution to use cells-and-portals subdivision and portal culling on any level. For the moment, I have almost succeeded in implementing it in a simplified case with one stair and orthogonal walls. The next step will be to support any kind of arena and to use at least anti-portals in outdoor environments (it is already possible in JPCT as far as I know).

Alric said:

Good to hear.

Thanks. :D

Way to work through some tough stuff gouessej :slight_smile:

basixs said:

Way to work through some tough stuff gouessej :)

Yes... years of work... especially for the portalizer.

I have forgotten to treat a case. When a portal is just between the near plane of the view frustum and the observer, I have to use the current frustum as the new sub-frustum. For the moment, I get a black screen :( I'm fixing it now. If I have enough time, I will deploy this build (with the fix of course).

By "portal", I mean this:

In computer-generated imagery and real-time 3D computer graphics, portal rendering is an algorithm for visibility determination. A game level might contain many graphical polygons; only a few of which may be visible on screen at a given time. Visibility determination allows the renderer to decide which of those fall into that category and thus reduce rendering time.

A portal system is based on using the partitioning of space to form generalizations about the visibility of objects within those spaces. Regions of map space are divided into polygonal, generally convex, areas called sectors. Adjacent sectors are linked to one another via shared dividing polygons termed portals. Approaches that precompute visibility for sectors are referred to as potentially visible set or PVS methods.

For example, in a computer game, the game area might be divided to several sectors. These sectors would be then connected to each other by small openings such as doors or windows. These openings are referred as portals. When the sector behind a portal needs to be drawn, the only parts that are visible are the parts that can be seen through the portal. Therefore, the sector can be clipped against the portal boundaries to remove overdraw.

The use of portals simplifies the game engine's task of determining visible areas and objects from any given point of view of the level, and simplifies rendering by allowing it to use each portal as a viewing frustum for the area it leads to. Ideally, portals are formed of confined areas (like doors or tunnels), connecting two complex areas of the level, where each of these areas would be enclosed in such a polygonal body.

Portals are best suitable for indoor scenes such as mazes. Outdoor scenes do not usually have door-like objects that would clearly separate one sector from another.

Ah, I see, so more like the BSP system from Quake3/Source Engine Games.

Empire Phoenix said:

Ah, I see, so more like the BSP system from Quake3/Source Engine Games.

Actually, I use cells and portals to work around the drawbacks of the BSP trees. It is possible to mix portals and trees but I don't do it.

pretty good, I would personally wish for more mouse sensitivity (is that in the options?)



A little error: when someone shoots at the edge of a wall the damage sprite goes past the edge of the wall and looks strange.



There is no HUD to know how damaged you are.



Other than that its good! it ran with no problems