Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  jogl vs. lwjgl speed test  (Read 13006 times)
0 Members and 1 Guest are viewing this topic.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #30 - Posted 2003-07-18 08:04:55 »

The only legal place to perform OpenGL calls is within the methods of your GLEventListener.

To state again: I'd suggest doing the heavyweight work in a worker thread and informing your rendering thread of its progress. Your application will be more cleanly separable this way. A similar approach is used in updating Swing progress bars.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #31 - Posted 2003-07-18 14:12:00 »

Err, but you just implied that the rendering thread (the thread that goes into GLContext and calls all GLEventListener) is the only thread that CAN perform those calls.

Defining lists for complex meshes, rendering to textures and even defining the textures cannot be done outside that thread.


I really don't understand why you can't just, say, add a swapBuffers() method, even if you only allow it to be called from within an GLEventListener call.

Play Minecraft!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #32 - Posted 2003-07-18 15:06:38 »

The worker thread does the heavy lifting of bringing in the data from disk and the rendering thread only does the glTexture2D call, which is relatively lightweight.

We'll think about exposing swapBuffers(); please feel free to file an RFE on the JOGL Issues page. Please keep the following in mind, though: if the loading isn't separated into worker and rendering threads, you're going to get e.g. one redraw every second or so while the textures are being loaded. While this is happening, if your application window is obscured and revealed again, you're going to see damaged regions for a long period of time.

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

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #33 - Posted 2003-07-18 15:53:58 »

That's usually not an issue in fullscreen games.

I really don't want to make a singlethreaded game multithreaded just to work around an artificial restriction.
I'll file the RFE now.

Play Minecraft!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #34 - Posted 2003-07-18 16:59:37 »

Resource loading is usually best done in another thread anyway.  Your main game loop can remain single threaded.

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #35 - Posted 2003-07-18 17:25:58 »

The point is that the decision to make it multithreaded should be mine to make. There's no point at all in Jogl not exposing the swapBuffers() call.

It's really weird as it is now, as the opengl api forces you to only have one thread doing opengl commands at a time (makes sense, since opengl isn't thread safe), but forces you to use several threads if you want to have progress information.

Play Minecraft!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #36 - Posted 2003-07-18 19:18:35 »

Can you do something like this in your rendering function?

1  
2  
3  
4  
5  
6  
7  
if( resource < numResources)
{
   loadResource( resource++ );
   // *** GL calls to advance the progressbar ***
}

// JOGL will swap buffers here

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #37 - Posted 2003-07-18 20:35:44 »

Not exactly like that, since I'm both loading normal textures, defining dynamic textures, building lists, and (when jogl supports it) building and filling vertex buffer objects.

I was considering adding an elaborate scheme of a list of Runnables, but then realized how much of an overkill that was for a very simple task with a very simple solution. Wink

/me puts on zealot suit

Play Minecraft!
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #38 - Posted 2003-07-18 20:36:14 »

Hey, cool, this is the first BBS I've ever seen that supports CTCP ACTION. =D

Play Minecraft!
Offline AndersDahlberg

Junior Member





« Reply #39 - Posted 2003-07-18 20:56:36 »

/me is happy now when the "old" forums are back!

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

JGO Coder




Where's the Kaboom?


« Reply #40 - Posted 2003-07-18 22:23:07 »

What is "CTCP ACTION" and how do I do it ?

Yeah - I was oversimplifying the resource loading. although there is probably an easy Oo way to do something similar to SwingUtilities invokeLater or invokeAndWait.. I guess that is what you were getting at with the Runnables.  I don't think it has to be messy though. If you have objects that manage differnt aspect of the resource creation - dump them all in a list/array whatever and process that list where GL calls are allowed.

I don't mean to be arguing the point though, cause it seem that the swapBuffers call would be simple enough to add, and relatively harmless..  I'm not an OpenGL program yet so I shouldn't even be talking Smiley

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #41 - Posted 2003-07-18 22:31:41 »

Long version:

CTCP ACTION is a "hack" in the irc protocol to allow for emotes.

Normally, CTCP (client-to-client-protocol) commands are sent as privmsgs to clients, and usually require a notice back, like CTCP TIME and CTCP PING <number>.
CTCP ACTION is a special CTCP command that's usually sent to channels instead of other clients, and doesn't require a return value.
The clients then display that as an emote. a CTCP ACTION "freaks out" from MonkeyBoy would usually be displayed as "** MonkeyBoy freaks out"

To send a CTCP ACTION (or emote) in most irc clients, you just enter "/ me jumps around" (without the space between / and me) in the desired room, but entering "/ctcp #room ACTION jumps around" usually works as well.


Short version:

Type "/ me freaks out", without the space between the "/" and the "me".  Wink


[edit: "client-to-client-commands"? heh]

Play Minecraft!
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #42 - Posted 2003-07-18 22:35:39 »

Oh, and a CTCP is just a privmsg (if it's a request) or a notice (if it's a reply) surrounded by (char)1.. So you could even go "/privmsg #room ^AACTION jumps around^A" if you wanted to. Wink

Play Minecraft!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #43 - Posted 2003-07-19 02:09:27 »

/me gets it now.

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #44 - Posted 2003-07-19 14:55:06 »

Well I haven't yet seen the restriction of not having swapBuffers(). The newbie tutorial on texturing (not that you're a newbie) is finally ready. Once I push that out I will see how I would solve your specific problem.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #45 - Posted 2003-07-19 15:09:55 »

Isn't the argument that all other opengl implementations have a manual swapbuffers good enough?

Even jogl has it, but for some reason, it's not available.
Exposing it would solve a very simple problem with a very simple solution instead of forcing the developers to build an overly complicated framework just for doing a very simple procedural load and repaint method.


I KNOW it's possible to work around it, but I'm saying I shouldn't have to.

Play Minecraft!
Archimedes
Guest
« Reply #46 - Posted 2003-07-19 15:54:43 »

Quote
Well I haven't yet seen the restriction of not having swapBuffers(). The newbie tutorial on texturing (not that you're a newbie) is finally ready. Once I push that out I will see how I would solve your specific problem.

Good point.
Can't wait for your tutorial on texturing. :-) The last one has been great.

Thanks to all being involved in Jogl. It's a pleasure to use. :-)
Offline josgood

Senior Newbie




Nudge reality.


« Reply #47 - Posted 2003-07-20 17:49:53 »

Quote

We'll think about exposing swapBuffers(); please feel free to file an RFE on the JOGL Issues page.



I can't think of any reason whatsoever to expose the buffer handling behavior.  My biggest complaint of Magician's API was that it had too many sharp edges.  From various postings, I gather the same was true of GL4Java.

I removed the GLContext class in my rewrite of Magician.  Further, all of the WGL, GLX, etc, calls are completely hidden.  I figure the rare person who needs that stuff can subclass GLComponent.

Offline josgood

Senior Newbie




Nudge reality.


« Reply #48 - Posted 2003-07-20 17:55:48 »

Quote
The point is that the decision to make it multithreaded should be mine to make. There's no point at all in Jogl not exposing the swapBuffers() call.


Buffer behavior and multithreading are completely different issues.  

The JOGL (nee Jungle) API gives you control over multithreading via the Animator class.  

Hiding the swapBuffer behavior is A Good Thing, ensuring that either swapbuffer or a simple glFlush is correctly called at the end of the 'display' event.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #49 - Posted 2003-07-20 18:05:35 »

Sorry, but hiding the swapBuffer behavior is definitly A Bad Thing.
If people don't want to use it, fine, but _I_ want to use it.

There's nothing magical about it being an opengl buffer swap.. It's just there to put what I just drew onto the screen.
If the java2d buffer swapping was as deeply hidden away in a similar design as the jogl one, I'd complain just as loudly about that.

Play Minecraft!
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #50 - Posted 2003-07-20 18:07:32 »

Quote
Buffer behavior and multithreading are completely different issues.


Feel free to look around these boards after places where people have suggested that I use several threads (ie make my game multithreaded) to get around this problem. You'll find a few.


Play Minecraft!
Offline josgood

Senior Newbie




Nudge reality.


« Reply #51 - Posted 2003-07-20 18:08:04 »

Quote

With the actual bindings both using native byte buffers to pass large byte arrays to the actual opengl calls, the biggest bottleneck in an OpenGL binding is already out of the way.


I'm sorry for being thick on this issue.  But I'm still not grokking the advantage of using direct buffers.  I must be missing something.

I was asked to add support for direct buffers to Magician.  The goal was to avoid the penalty of the copying data arrays across the Java/JNI boundary.  So I did some benchmarking and could not measure a difference between normal Java arrays and using a ByteBuffer.

It turns out that Sun's 1.4.x JVM doesn't copy the array at all.  Further, from what I gathered on BugParade and some newsgroups, using ByteBuffers (in 1.4.x) wasn't efficient for many small blocks.  So I backed out my ByteBuffer experiments.

The only advantage I can think of is allocating memory natively (e.g. textures in VRAM).  I peeked at LWJGL earlier this year and I think that's what's happening for everything.

That approach puts a lot of responsibility on the programmer vs within the library/API.  Ugh.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #52 - Posted 2003-07-20 20:20:58 »

The advantage is the ability to create native memory for storage of vertices and the ability to move that ByteBuffer onto the hardware accelerator itself.

Quote

The only advantage I can think of is allocating memory natively (e.g. textures in VRAM).  I peeked at LWJGL earlier this year and I think that's what's happening for everything.
 
That approach puts a lot of responsibility on the programmer vs within the library/API.  Ugh.
 


LWJGLs implementation is a little different that that used in JOGL - it does require you to keep track of memory addresses wheras JOGL is pretty good about hiding that. However, that doesn't mean that allocating native memory is a bad thing, quite clearly I've seen incredibly marked speed increases in the methods that take arrays and the methods that take direct ByteBuffers in JOGL - it was a clear night and day thing to me. I'm not familiar with your situation or environment, but for me after dealing with native buffers I wouldn't use any JNI binding that didn't use them. The memory utilization and performance impact for me were huge.

You may want to see if there is a difference in JOGL. LWJGL requires that you only use ByteBuffers for all of your constructs since they are looking for speed and not taking the time to do anything that doesn't give speed - in essence only giving you the route that would yield maximum performance. Nothing particularly wrong with that in a gaming API Smiley Since JOGL gives you both methods, why don't you write an application that does the same workload both ways. I'm sure you'll see a difference.

If you don't it would be interesting to see what version of Java you're running and on what OS, because on Windows and OSX there was a clear win.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline AndersDahlberg

Junior Member





« Reply #53 - Posted 2003-07-20 20:39:43 »

Hmm, not that I really care that much, but seeing stuff like this seems a bit unfair to me:
Quote

LWJGLs implementation is a little different that that used in JOGL - it does require you to keep track of memory addresses wheras JOGL ---


Maybe you could argue that when there was only the 0.6 release available and the change to use buffers instead of pointers where only in cvs. But now when there is a new 0.7 release which, just like jogl, uses buffers instead of native pointers I feel we all should stop harassing the lwjgl developers and start using constructive critique on the actual implementations and not old, removed, design misstakes! (otherwise we could just go to the comp.lang.java.advocasy group and give 'em some extra trolling - I'm sure they would appreciate it Smiley

Release notes for 0.7:
http://www.puppygames.net/forums/viewtopic.php?t=151
" Ported OpenGL to Buffers "

See the same thread for a discussion on which methods/code should go/change for good example of such critique Grin

Trying not to be a zealot here Smiley
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #54 - Posted 2003-07-20 22:20:22 »

Quote

But now when there is a new 0.7 release which, just like jogl, uses buffers instead of native pointers I feel we all should stop harassing the lwjgl developers and start using constructive critique on the actual implementations and not old, removed, design misstakes!


Who's harassing the lwjgl developers?

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline AndersDahlberg

Junior Member





« Reply #55 - Posted 2003-07-20 22:51:06 »

Obviously a bad word (not native speaker). Hope I didn't hurt your feelings too much Smiley

But since there is a new lwjgl version out, which doesn't use native pointers I just wanted to point that out (as it's been a lot of talk about just that issue).

I would rather have a more friendly discussion on how to evolve java gaming api's. This IMHO doesn't include trying to scare people away from any of them (e.g. by talking about stuff like "lwjgl uses native pointers", "jogl is sooo much slower than lwjgl" or "jogl/lwjgl sucks because of #" - do you see my point?)

instead of saying:
"JoGL got a requirement of using awt - thus you can't compile it to native form using JET"
one can say:
"JoGL is today also a lot integrated with awt - thus you can use it with awt/swing code" (<== not implying that this will always be the case, or that this should stop anyone from using jogl!)

I.e. it's just a matter of style Roll Eyes

Btw, now I feel like that person from the other thread who said "he was just arguing for the arguments sake" (hmm, not sure if that makes any sense, spelling, grammar etc Wink
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #56 - Posted 2003-07-21 03:40:06 »

Pointing out limitations of a design should not be taken only as criticism either though.  There ARE trade-offs made in every project and it is just as important to be aware of how they limit you as well as how they liberate you.  I don't think anything negative was meant toward the LWJGL project itself.  No one is bashing anything here.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2003-07-21 12:14:39 »

I'd just like to point out that Jet is perfectly capable of compiling Swing and AWT (and SWT) based applications, it's just that you need to deploy 5 megs of crap along with your compiled exe which sort of defeats the point (from an internet deployment point of view).

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #58 - Posted 2003-07-21 15:33:15 »

That's good to know. I actually hadn't really looked at the possibility of using Jet to compile a complete application. Its interesting that the Jet runtime libs are that large now that the JRE has gotten smaller.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #59 - Posted 2003-07-21 22:29:14 »

It's all to do with inlining. I turn it down low for AF because it bloats the exe by several megs without adding any significant performance boost.
(Actually the 5megs thing was a guess but it is pretty big - too big for me to consider shipping)

Cas Smiley

Pages: 1 [2]
  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.

xsi3rr4x (28 views)
2014-04-15 18:08:23

BurntPizza (25 views)
2014-04-15 03:46:01

UprightPath (40 views)
2014-04-14 17:39:50

UprightPath (22 views)
2014-04-14 17:35:47

Porlus (38 views)
2014-04-14 15:48:38

tom_mai78101 (62 views)
2014-04-10 04:04:31

BurntPizza (121 views)
2014-04-08 23:06:04

tom_mai78101 (221 views)
2014-04-05 13:34:39

trollwarrior1 (188 views)
2014-04-04 12:06:45

CJLetsGame (195 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!