jogl vs. lwjgl speed test

OpenGL Development JOGL Development
#41

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 :slight_smile:

#42

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 .
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]

#43

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:

#44

/me gets it now.

#45

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.

#46

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.

#47

[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.
[/quote]
Good point.
Can’t wait for your tutorial on texturing. :slight_smile: The last one has been great.

Thanks to all being involved in Jogl. It’s a pleasure to use. :slight_smile:

#48

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.

#49

[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.
[/quote]
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.

#50

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.

#51

[quote]Buffer behavior and multithreading are completely different issues.
[/quote]
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.

#52

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.

#53

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.

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 :slight_smile: 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.

#54

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

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 :slight_smile:

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 ;D

Trying not to be a zealot here :slight_smile:

#55

Who’s harassing the lwjgl developers?

#56

Obviously a bad word (not native speaker). Hope I didn’t hurt your feelings too much :slight_smile:

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 ::slight_smile:

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:

#57

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.

#58

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 :slight_smile:

#59

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.

#60

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 :slight_smile: