Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (604)
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  
  Damn @$#^%%&^%  (Read 1615 times)
0 Members and 1 Guest are viewing this topic.
Offline Java Cool Dude

Senior Devvie




Java forever


« Posted 2003-09-30 06:14:25 »

Ok I've been introduced to JoGL by a fellow javagaming member not that long ago, and I was definitely charmed by the fact that I can go down to the byte level unlike other APIs such as Java3D.
Anyways I started making ports to compare performance between the demos once written in Java and the original C++ code.
To my surprise the JoGL ports were slightly faster than the original C++ demo.
That's before I ran into some demos such as CellShading and HeightMap rendering:
Basically the frame rate was cut in HALF and sometimes even lower.
So I started taking off bits of code here and there to finally narrow the circle of suspicions to the "for" loops.
Indeed looping takes huge chunks of time everytime it's called in Java, to the point of EMBARASSMENT Cry.
Check the code in the JoGL forum and you'll definitely notice the rather poor performance of the said ports due to Java slow loops...
Also that depressing observation can be noticed in every demo that requires a lot of polygon drawing such as Quake 3 Loader and Animators.
In case of the loader, we're dealing with still Models so we can call a display list to avoid continuous looping but unfortuantely it is near impossible to use such approach when it comes to animation.
/me off to cry a bit :-/ Cry
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-09-30 09:46:54 »

'sfunny, I've never had a problem with loops...

Cas Smiley

Offline Mojomonkey

Senior Devvie




ooh ooh eee eeee


« Reply #2 - Posted 2003-09-30 10:14:24 »

Do these for loops contain your code to render you object? And if so, are they calls to glVertex, glNormal, etc? If so, your penalty could be JNI overhead rather than the loops themselves. Because these demos are rendering a lot more vertices that overhead is becoming more apparent. If you are rendering in this way, i.e. glBegin/glEnd block, you should look into VBO or vertex arrays. This will require a few calls (1 for vertices, 1 for colors, 1 for texture, etc) each rendering cycle rather than thousands for each vertex.

Don't send a man to do a monkey's work.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #3 - Posted 2003-09-30 12:13:09 »

Yeah, you would have thought that any glaring performance problems with "for" loops would have been spotted by now...

Microbenchmark time, methinks!

Hellomynameis Charlie Dobbie.
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-09-30 14:38:29 »

Java Cool Dude, run with -Xprof and post it up here and we'll find out how to fix it.

Cas Smiley

Offline Java Cool Dude

Senior Devvie




Java forever


« Reply #5 - Posted 2003-09-30 15:35:59 »

One example
So yes, I'm thinking the native call to opengl functions is what slowing the ports to hell.
See the demos that ran better on Java than C++ only called glVertex3f, glNormal3f...very few times, enough to draw a cube or a simple 3D shape.
The example I posted up above draws huge maps by calling their vertices and textures coordinates. The level of complexity of the mentioned map as well as the delay in calling the native functions explains the huge slow downs that I'm pointing out.
Oh well I can still call vertexArrays and Display lists Roll Eyes
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #6 - Posted 2003-09-30 16:56:21 »

Yep, tunneling lots of calls through JNI to OpenGL will be a performance killer.  It's not even a good idea in C/C++ land, although the effect is a lot less.  Using glBegin/glEnd and lots of glColor/glVertex/glNormals etc is generally referred to as "immediate mode".

Make good use of the batching features of the API - use vertex arrays, display lists, VBOs etc.  With a bit of luck your bottleneck will move somewhere else! Grin

Hellomynameis Charlie Dobbie.
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2003-10-01 09:17:45 »

That code's a great way to show somebody how to draw terrain really slowly but it shows you the worst possible way to do it in OpenGL and Java.

Cas Smiley

Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #8 - Posted 2003-10-01 11:19:27 »

Actually, Wurm STILL uses very immediate mode rendering as well..

I was going to fix it a long time ago, but it turned out the biggest bottleneck was fillrate in forests. Drawing thousands of large billboards is an efficient way of stabbing performance in the face.

But Soon(tm) I will finally implement the occlusion test, and move everything into VBOs (or vertex arrays, if VBOs aren't availabe). Muoahaha. *rubs hands*

[edit:]
Oh, and the closest trees will be models instead of billboards. I need to cut down on fillrate, AND models look better.

Play Minecraft!
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.

Elsealabs (15 views)
2014-12-28 10:39:27

CopyableCougar4 (19 views)
2014-12-28 02:10:29

BurntPizza (24 views)
2014-12-27 22:38:51

Mr.CodeIt (14 views)
2014-12-27 04:03:04

TheDudeFromCI (19 views)
2014-12-27 02:14:49

Mr.CodeIt (26 views)
2014-12-23 03:34:11

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

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

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

BurntPizza (115 views)
2014-12-08 04:46:31
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

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