Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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  
  a non-debug precompiled version [withdrawn]  (Read 2133 times)
0 Members and 1 Guest are viewing this topic.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 842
Projects: 4
Exp: 16 years


Hand over your head.


« Posted 2005-12-25 15:47:08 »

In my game-engine, I have lots of nature: bushes, trees, grass, etc. All these are items which get rendered by a couple of VBO calls. The 'problem' is that the amount of checks for the VBO-calls is huge, there are even stacks and switch-statements inthere. When rendering thousands of items per frame, this overhead begins to count. My solution is to group geometry of multiple-items into 1. This works, but makes the engine much more complex, because of all the managing.

I heard matzon say in another thread that LWJGL was precompiled by default in debug-mode. I have to admit that I don't know C/C++, nor do I know how to compile dynamic-libraries, so that pretty much leaves me asking somebody for a favor. It would be nice to have non-debug precompiled libraries on the official LWJGL site, or made available by anybody who would like to share their non-debug version of LWJGL with this community.

Thanks in advance!

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2005-12-25 20:20:20 »

this could probably be automated in the build script - I'll talk to elias about this and see if we can work something out

Offline Spasi
« Reply #2 - Posted 2005-12-27 17:19:04 »

Hi Riven,

I've found that OpenGL pseudo-instancing helps a lot when you're CPU bound (if you can afford to use vertex shaders). I've seen up to 50% speed-ups when rendering thousands of low-poly objects in Marathon. Removing VBO checks from LWJGL might improve things a bit, but I wouldn't expect anything dramatic.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 842
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2005-12-28 09:18:09 »

I know, a few percent speedup would be nice.

Further, my engine has never been CPU-bound Wink

I'll investigate "psuedo instancing", I never heard of it.

I also found that reducing the polycount of a VBO below a certain value (under 75 on my card), won't increase performance anymore. So in the end I might have to do geom-grouping anyway, whatever overhead LWJGL has. Or do that "pseudo-instancing" or yours, whatever it may be Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2005-12-28 09:20:53 »

I talked to elias about this:
http://echelog.matzon.dk/logs/browse/lwjgl/1135675132
at around 13:00

Would it be possible for you to get some numbers so that we bay actually evaluate the feasability of doing 2 builds

Offline Spasi
« Reply #5 - Posted 2005-12-28 15:52:42 »

Further, my engine has never been CPU-bound Wink

I also found that reducing the polycount of a VBO below a certain value (under 75 on my card), won't increase performance anymore. So in the end I might have to do geom-grouping anyway, whatever overhead LWJGL has. Or do that "pseudo-instancing" or yours, whatever it may be Smiley

Under 75 polygons, you *are* CPU bound. Also, no matter the scene you're rendering, the CPU always affects the frame rate to a certain degree.

Pseudo-instancing is very simple actually. Instead of changing the modelview matrix for every object in the scene, you only load the view matrix at the beginning of the frame and then pass the model matrix individually for every object. The trick is to pass the model matrix as a bunch of "persistent" vertex attributes. Because the modelview matrix is not changing, the driver doesn't have to "touch" the shader code for every object and that's where the speed-up comes from.

Go here for details and sample code (search => pseudo).

I've also found that this can be applied to other uniform values too. So, for example, instead of defining a model-space light position as a uniform, it's faster to pass it as a vertex attribute. Btw, because of the above model matrix trick, you end up with a vertex position in *world-space* inside the shader. This is actually very convenient and saves some instructions when you've got to do shadow mapping or calculate an eye vector (for specular, parallax, etc).
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 842
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #6 - Posted 2005-12-29 15:50:23 »

Thanks for the above. Let's get back on topic:

The LWJGL overhead is only noticable when rendering a lot of tiny items. Ofcourse reducing the overhead will increase performance by a few percent, but I think the true optimisations will have such a dramatic increase in performance that it might not be worth it to work on the tiny overhead.

Besides that, there will be a massive increase of posts on this forum, about native crashes, when newbies deploy the 'release-version' without thinking of the side-effects.

Considering all that, I withdraw the request.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
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.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (30 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (98 views)
2014-12-08 04:46:31

JscottyBieshaar (59 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!