TUER: Truly Unusual Experience of Revolution, FPS using JOGL

WIP games, tools & toy projects
#181

ATI radeon xpress 200 doesn’t work fine with TUER, I already said it. The ATI Radeon Xpress 200 has some problems in memory allocation, it is not a secret. Yesterday, my collegue and me had had the same problem than you. Nevertheless, when I use TUER with smaller VBO, I get 62 FPS with this ATI chipset. That’s what happened at the beginning of september when I tested the first implementation of the handling of impacts on the walls for the experimental mode. If you are assuming that I’m wrong, I can add a key in the game to allow you to get back to the previous behaviour. The progress bar doesn’t finish because of the free hosting system which is really slow.

Sorry but I can only know which operating system is running the JVM but not exactly which graphics card. TUER checks already if a card supports VBO, vertex arrays and display lists. ATI radeon xpress announces to support the VBO. If you had read some of the previous post, you would know that the slow mode (which uses the software rendering) is activated only if you push F3. The default mode is the experimental mode which uses JOGL. My own graphics card “should” have worse performance than yours and I get 17 FPS.

Sorry again but I don’t appreciate your humour. I worked about 1000 hours on this game, I still have a lot of work to do on it obviously. TUER works between 8 and 225 FPS on the graphics cards supporting at least OpenGL 1.3 and with no problem of memory allocation. I won’t try to make an applet, I won’t use a lower resolution. I will simply do what I planned, I will finish to implement the cells-and-portals algorithm, I will then use smaller VBOs as the level will be split into about 150 cells. Then, instead of having only 1 FPS, you will have at least 62 FPS, idem est the same performance you would have had with the previous software clipping algorithm used at the beginning of september. The bug on the memory allocation on the ATI xpress 200 won’t cause the game to be slow as the VBOs won’t be too big for its. I have a way to check how much vertices I can draw with a call of glDrawArrays BUT I have no way to know the maximum size of a full VBO which can be sent to a graphics card, do you see what I mean?

#182

I never reproduced this bug with the menu. If you gave me some precisions about your config, I should know where it comes from. If you didn’t update the game correctly or if the server had a problem, the file containing the text displayed when you click on “about” might be missing and then it would cause your problem. I’m really sorry, I don’t ask you to lie, but without any indication I can’t fix a bug.

#183

just tried the software mode… impressive 0.3 fps.
and tried the oudated jPCT walkthrough demo… 30-60 fps.

I don’t understand why you keep telling about your superior fast engine as long as there are so many problems with it.
Now please don’t answer “if you read my source code” / “if you read my 100 TUER posts”, I don’t know why your software mode is so slow, I just wanted to test it.
The advice with the applet in 320x240 was not meant as a joke.
[warning: joke]: Maybe an applet in 32x24 would give me 60 fps with your engine.
And even if I could run your game in 60 fps fullscreen, I would prefer to run it at 58 fps AND with billboards facing towards the player. I think your game should be a GAME and not a tech demo to demonstrate you can get 5% more fps [in special cases] than other, existing, working engines.

#184

Thanks for the compliment. It means that there is a small difference between the software and the hardware accelerated mode :wink:

Ok but I don’t see what you mean exactly. The unique level of TUER is boring, ugly (yes I admit it) but very very big. If you asked jPCT to draw the unique level of TUER in accelerated mode, it might be quicker than my current implementation but I’m not absolutely sure of it.

My engine is highly experimental, it is only an alpha version, what did you expect? I don’t say it is superior. I said that in a few special cases, in a near future, it might be a very little bit quicker than some engines. There is not so many problems. At first, the slowness of java webstart comes from the slowness of the free hosting solution (a lot of restriction on the traffic), not from the game itself. The flickering appears only in the menu, not inside the game and only on some graphics cards. Finally, the health indicator and the others indicator disappear only on some graphics cards. If my engine was so superior, I wouldn’t have to work on it every day.

Yes there are a lot of posts, it would be better if I avoided answering “if you read my 100 TUER posts”.

Ok but now that you know using an applet is not necessary to improve the performance, I don’t see the interest of doing it, it would be a regression on my view. Don’t forget that I’m using JOGL and there are still some bugs in JOGLAppletLauncher. I tried to use it at the beginning of the project. I quickly gave it up, there were too many limitations, no embedded screenshots, no RMI…

Yes yes yes I agree with you. I want to put a billboard too, some indicators and it is not a contradiction with the fullscreen mode. There are already some indicators (only a few) but maybe they don’t appear on your machine. One indicator alerts you when you enter a new zone. It is not enough. The user is lost. It would be better if people could see the ammunitions too, a small map and maybe other interesting data.

I understand your position. You expected to play with a game and you “played” with something that works a little bit but which is not user-friendly and too slow.

Nevertheless, don’t forget that there are many people here who show a sort of “prototype”, an unfinished game, or something which will become a game but which is not a game currently. We have a place here, there are many developers, not only some people who want to test some games. This website is not only a showcase to allow the developers to meet the players. It is a place for developers to share their knowledge too.

Finally, if you want to do a fair comparison between my so limited engine and jPCT, don’t take a demo that can’t work with my engine, take an example of something that can work on the both engines and then compare. As my engine is more limited than jPCT, I don’t see the interest of comparing it with mine. My engine is not a general-purpose engine.

As I said, it is a website for developers too. If you aren’t interested in reading my code, I can understand it but don’t be sure of what you’re saying when it is better to check in the code. Sometimes, I admit it would be better to show the small piece of code that I’m dealing with. Some people here looked into my source code and it is the aim of an open source project. It is still under GPL.

#185

GeForce 6800 GT, XP SP2, Athlon 2600 or something, latest video drivers available. I think the flickering is probably caused by a pesky interaction with AWT. I keep telling people to avoid AWT for games but no-one listens :stuck_out_tongue:

Cas :slight_smile:

#186

Tested again, no flickering here.

As an aside. I think if you’d just divide your mouse delta’s by 32 or something, the controls would already feel much better. It’s still impossible to control here with these ultra sensitive mouse controls.

I kind of agree with Hansdampf that a lower resolution for the software mode would be a big improvement. In software it just runs too slow with these kinds of resolutions and I don’t think any optimizing can solve that (except for turning it into an OGL game of course :))

#187

What do you suggest? I use AWT PopupMenu and Swing JOptionPane. I don’t understand, I don’t have this problem with a 6600 and you have this flickering with a 6800 GT.

You rassure me a little bit. ;D

It depends on the machine. On slower machines, people ask me to do the opposite. When the global speed of the engine is stable after the current optimization, I will reduce the delta by 32 if it is fair.

Yes you’re right, it would be an improvement but only for the slow mode which uses only software rendering. It uses raycasting and a decrease of the resolution would hugely improve the performance as the cost of raycasting mainly depends on it. Of course you see what I mean. I’m impatient to remove the slow mode when it becomes totally useless. That is why I won’t decrease the resolution. As the slow mode will disappear, reducing the resolution is useless as any development on it. You know I’m impatient to remove all the old slow things coming from the raycasting system of Art Attack… I want my engine to use only OpenGL. If I have enough time Saturday and Sunday, I will add a first “outline” of rocket launcher. The game will be a very little bit more playable when you see the weapon that you’re using. If I have only one hour to do it, maybe the first rocket launcher will look ugly but it will be temporary, ok?

#188

[quote]It depends on the machine. On slower machines, people ask me to do the opposite. When the global speed of the engine is stable after the current optimization, I will reduce the delta by 32 if it is fair.
[/quote]
Just make it configurable then to keep everybody happy :slight_smile:
Even just a little config file would do while in alpha. Right now it’s too unplayable to be even called alpha (it’s almost impossible to hit anything when I can’t even get an enemy in my crosshairs), and fixing the controls will be a big step in the right direction.

#189

I can’t see how it could possibly be that hard to get this right first time though…?

Anyway… I’d suggest maybe using GL to draw your menus and such and avoid the dependency on AWT altogether.

Cas :slight_smile:

#190

Ok I wanted to do this at the beginning but using AWT requires less work. As there is some flickering, I will look for a solution with nor AWT neither SWING.

This might be a temporary solution. However, on my view, an alpha version is for testers only, I consider that my game is really in an alpha version. As a first step, I’m going to reduce the delta by 8. If the development of the current optimization takes too much time, then I will add a config file with at least a property to configure the sensibility of the mouse.

Thank you very much for your suggestions.

#191

I tested Hexxagon (LWJGL Applet) under Debian Linux Etch with an ATI Radeon Xpress 200 and I got 27 FPS.
I tested Hexxagon (LWJGL Applet) under Mandriva Linux 2007 with an ATI Radeon 9250 Pro and I got 449 FPS.
Then, there are some games which don’t work fine with this chipset. Under Linux, it is mainly a problem of the driver. Under Microsoft Windows XP, this huge slowness appears only in a rare case : when you use huge VBOs. It is not surprising that some games (not only mine) work bad with this chipset and you seem not to believe me. Now, I have an evidence. Hexxagon is really more stable than TUER and however, it works slowly with this chipset. I think you have no problems with other games only because they use smaller VBOs, that’s all.

#192

I think your VBO size is limited by what’s set in the BIOS. (AGP aperture isn’t it?) Is there no way to query the driver for the maximum size? (I am a VBO n00b, never needed them)

Cas :slight_smile:

#193

The AGP aperture size is the size of the cache on the central memory. There is a way to query the driver at most how many vertices can be drawn in one call of glDrawArrays but I don’t know any method to get the maximum size of a VBO. Currently, using VBO might be quicker than using display lists (it depends on how you use it and it is true only if you put more than 10 vertices in your VBO) and is as quick as using vertex arrays but it will be different in OpenGL 3.0.

#194

glDrawRangeElements is probably the best and easiest way to do it so that it’s generally fast and reliable. VBOs for some reason never seemed to quite get it right.

Cas :slight_smile:

#195

It is time to show you the first results of my implementation of the cells-and-portals algorithm.
The schema below shows some steps of the algorithm. The first map shows the world map before applying the algorithm, the second map shows the map of cells obtained by applying the first unoptimized part of the algorithm and the last schema shows the map of cells obtained by applying the part which optimizes the result :

Link removed

Notice that the part which optimizes the map of cells reduces the count of cell and the average size of the portals. I need to perform some unitary tests before using these cells to display the whole game. I need to check if some walls of these cells overlap. Portals overlap is not worrying as it is the “normal” behavior of a portal shared by two cells.

On the other hand, I’m going to reduce the “delta” as erikd said. I will add the rocket launcher during this week too. Finally, what about adding a map in a corner of the screen?

#196

After some investigations, I decided to consider that the following chipsets will be considered as unsupported by TUER :

I still hesitate in changing the sensibility. The cells-and-portals algorithm works almost fine. 6 of the 179 cells produced by the optimization part are malformed. I have forgotten to treat a particular case when merging the cells.

#197

They are truly risible chipsets with utterly mediocre drivers. You get what you pay for!

Cas :slight_smile:

#198

I didn’t pay for it. These chipsets are on all our computers at work. Thank you for admitting that this chipset has a mediocre driver. Hansdampf said that this chipset works fine with all the games he played with (even though I get 8 times more FPS than him with an older graphics card with the game “Hexxagon”) and Orangy Tang said that it is not a driver problem.

#199

Don’t go putting words into my mouth. I was talking about an entirely unrelated problem on an entirely unrelated graphics card.

#200

The problem of slowness with Java Web Start comes from my free hosting solution, the provider adds about 5 MB of advertising while downloading. It happens when you click onto any link in my website. The advertisements on the right side are added by the provider. When you click onto my link, you don’t see these ads but they are transmitted. To solve this problem, I will try to find some free space somewhere else to host at least the link and the script to launch the game.