Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  20 FPS only to draw 600 textured quad???  (Read 5039 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Posted 2007-08-29 02:44:18 »

Hi!

In my game, when I draw nothing, I get between 200 and 500 FPS. When I draw only a part of the walls, 550 textured quads, I get only 22 FPS. I don't understand what's wrong. I bind the textures only when necessary, I use some static VBO when available. If I put all the coordinates into one single VBO or if I separate it in several VBO, the result is the same. The textures are composed of 1024*1024 pixels. I only use a part of these to draw a part of wall, some example I use a 256*256 square from the main wall texture to draw an "impacted" wall. I use only PNG image files. Can you give me a solution to improve my performance please?

My game (the installation is a bit long, it can take 10 minutes) :
http://membres.lycos.fr/javalution/tuer.php

Offline gouessej
« Reply #1 - Posted 2007-08-29 03:35:01 »

Even when I use smaller textures, whatever I do, when I send 557000 coordinates, I get the same results : between 17 and 21 FPS. I'm very disappointed, I don't know how to solve this problem.

Offline gouessej
« Reply #2 - Posted 2007-08-29 03:43:01 »

My message appears when I launch the game :
libGL warning: 3D driver claims to not support visual 0x4b

I use the extension Composite on my 3D card ATI radeon 9250 Pro. I tried other image file formats for the texture, it doesn't change the performance.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #3 - Posted 2007-08-29 03:48:34 »

Now I force the use of call lists instead of static VBO and I get 27 FPS instead of 20 FPS. But I don't know why it is so slow only to draw 600 textured quads.

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #4 - Posted 2007-08-29 05:09:26 »

How many textures are you using? A single 1024x1024 RGBA texture takes 4mb vram.

弾幕 ☆ @mahonnaiseblog
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2007-08-29 08:34:13 »

600 quads seems like a bit much considering your game. Are you sure culling is working? Did you consider using a library which does culling for you (Xith3D, jME, Java3D)?

What are your system specs? On my (not so new) machine, I easily get 60fps with your game.

Did you check if fill-rate is your problem? (If so, you could try to render front-to-back).

Did you profile your code?

Offline gouessej
« Reply #6 - Posted 2007-08-29 11:13:44 »

600 quads seems like a bit much considering your game. Are you sure culling is working? Did you consider using a library which does culling for you (Xith3D, jME, Java3D)?

What are your system specs? On my (not so new) machine, I easily get 60fps with your game.

Did you check if fill-rate is your problem? (If so, you could try to render front-to-back).

Did you profile your code?
I think that I don't need an other library, JOGL does the last part of the culling and my algorithm gives it less data to allow the GPU to do something else.

Mandriva Linux 2007, AMD Sempron 2300+, 2 GB DDRAM 400 Mhz, ATI Radeon 9250 Pro with a very bad Xorg open source driver (my former girkfriend has better performance with a SIS 661 FX chipset under Windows XP with a proprietary driver Sad ).

I use backface culling through JOGL.

Profile? A liitle bit and I think I have found the main problem. Display lists are quicker than static VBO only if you handle very small pieces of data.

I'm stupid, I have split all the walls into very small pieces to implement a temporary voxel-based visibility culling and my culling compensates my stupidity of splitting all. My culling is excellent but my structures are not correctly designed, I will correct it. I use 4 textures. I think that I will regroup all the walls of a same "cell" in a SINGLE vertex set (a vertex set might use VBO if available).

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2007-08-29 12:34:39 »

a very bad Xorg open source driver
Ick, I bet that's your problem. Most open source 3d drivers tend to do almost all of the work in software and only bung the final result to the graphics card for actual display. If thats the case it won't matter what you do with VBOs or display lists 'cos it'll be dog slow anyway.

Open source gfx drivers? Just say no. Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #8 - Posted 2007-08-29 14:12:12 »

isn't there a proprietary driver available for Linux for that gfx card?

Offline gouessej
« Reply #9 - Posted 2007-08-29 14:36:59 »

isn't there a proprietary driver available for Linux for that gfx card?

Yes but I need libexpat.so.0 and ln -s doesn't solve the problem. I'm waiting for the answer of an expert of Mandrivasoft.

Ick, I bet that's your problem. Most open source 3d drivers tend to do almost all of the work in software and only bung the final result to the graphics card for actual display. If thats the case it won't matter what you do with VBOs or display lists 'cos it'll be dog slow anyway.

Open source gfx drivers? Just say no. Grin
No, there is a noticeable difference of performance between open source and proprietary drivers but it is not as big as you assume. Open source drivers for the NVIDIA cards are quite good but open source drivers for the ATI cards are less performant. I'm responsible for the slowdown, I really think that is mainly my fault and I will solve the problem as quick as I can.

However, the alpha blending is extremely buggy with the open source driver I use.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #10 - Posted 2007-08-29 16:54:26 »

What happens to the frame rate if you choose a lower display resolution?
If it goes up drastically then fill-rate is the problem, in which case drawing front-to-back might help.

That said, I think my system's specs are lower than yours and I easily get 60fps. So I wouldn't completely dismiss your video drivers as the source of your problems just yet.

Offline gouessej
« Reply #11 - Posted 2007-08-29 18:40:22 »

What happens to the frame rate if you choose a lower display resolution?
If it goes up drastically then fill-rate is the problem, in which case drawing front-to-back might help.

That said, I think my system's specs are lower than yours and I easily get 60fps. So I wouldn't completely dismiss your video drivers as the source of your problems just yet.
No your system's specs is higher than mine! TUER mainly uses the GPU, not so much RAM. Your 3D card is better than mine.

I already draw front-to-back.

Offline gouessej
« Reply #12 - Posted 2007-08-29 21:27:04 »

When I reduce the size of data but still by putting all in a single VBO, the FPS increases  Grin. I will improve it and I might have better performance in a few weeks.

Offline gouessej
« Reply #13 - Posted 2007-08-30 11:59:25 »

I had forgotten to check the maximum number of primitves that can be treated when you call glDrawArrays. Then, that's why it worked so slow.

Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #14 - Posted 2007-09-01 18:31:43 »

Quote
No, there is a noticeable difference of performance between open source and proprietary drivers but it is not as big as you assume. Open source drivers for the NVIDIA cards are quite good but open source drivers for the ATI cards are less performant.
OpenSource driveres for NVidia are only 2D, a partly function 3D driver is in defelopment but far from beeing functional or good performing. The 3D NVIdia driver (proprietary, closed source) is probably the best 3D driver/opengl-implementation available for Linux these days (when talking about consumer hardware).
I have terrible experience with the opensource 3d drivers, I've a intel GMA950 which is called "one of the best supported chipsets by opensource 3D drivers" and its slow as hell. I can see people playing quite good games on the same hardware on Windows-XP whereas I have to reduce resolution and details to play Tuxracer or Quake3 fluently. Really disappointing.

There is a closed-source driver for your 9250, however only old versions of the proprietary ATI driver will work fine (and maybe will cause problems with your new Xorg/kernel based distribution). Newer drivers have only broken support, latest have completly removed 92xx support (R200 as far as I remember).
However it should perform _far_ better under any circumstances than the free part,

Good luck, lg Clemens
Offline gouessej
« Reply #15 - Posted 2007-09-02 09:18:42 »

I hope you're right. It means that I can expect a good increase of performance with a proprietary driver. But I'm sure something is wrong in my code. I play with Open Arena, Alien Arena 2006, Cube and Nexuiz fluently on my computer.

Offline phu004

JGO Coder


Medals: 4
Projects: 9
Exp: 10 years


NoSuchPersonException


« Reply #16 - Posted 2007-09-29 10:00:06 »

How far away are the quads from the camera?  I had similar experience with Opengl before.
What I did was drawing 100 idential texture mapped polygons at the exact same position which was very close to the camera.
(each poylgon occupied 3/4 of the screen area), the frame rate was horrible. 

I guess the graphic card is more sensitive to the number of pixels being processed rather than the number of polys that being processed.
Offline gouessej
« Reply #17 - Posted 2007-11-09 12:09:56 »

How far away are the quads from the camera?  I had similar experience with Opengl before.
What I did was drawing 100 idential texture mapped polygons at the exact same position which was very close to the camera.
(each poylgon occupied 3/4 of the screen area), the frame rate was horrible. 

I guess the graphic card is more sensitive to the number of pixels being processed rather than the number of polys that being processed.
Some of the quads are very close and some others are very very far. Which solution did you find?

Offline phu004

JGO Coder


Medals: 4
Projects: 9
Exp: 10 years


NoSuchPersonException


« Reply #18 - Posted 2007-11-10 03:12:42 »

My solution is always avoid drawing many big overlaping polygon,
and use smarter hidden surface removal algorithm.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (20 views)
2014-09-24 16:12:06

Grunnt (46 views)
2014-09-23 14:38:19

radar3301 (28 views)
2014-09-21 23:33:17

BurntPizza (64 views)
2014-09-21 02:42:18

BurntPizza (36 views)
2014-09-21 01:30:30

moogie (42 views)
2014-09-21 00:26:15

UprightPath (52 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!