Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
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  
  JoGL > LWJGL?  (Read 3178 times)
0 Members and 1 Guest are viewing this topic.
Offline Java Cool Dude

Senior Member




Java forever


« Posted 2004-03-07 08:31:25 »

JoGL
VS
LWJGL

Too damn tired to throw any comments right now.
/me is off to bed
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2004-03-07 08:58:13 »

missing DisplayOptions class in jogl, but as you said - you were tired Wink

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #2 - Posted 2004-03-07 09:12:28 »

k, so I can't get jogl going, but I did notice that in lwjgl mode, you also render a cursor which (on my system) costs aroung 10% fps

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

JGO Coder


Medals: 1


pixels! :x


« Reply #3 - Posted 2004-03-07 09:12:40 »

J:489674
L:481593 -> 7zip -> 444580

Tongue Grin

弾幕 ☆ @mahonnaiseblog
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2004-03-07 09:16:19 »

actually, JCD - when you awake, I would be very interrested in your comments about working with the jogl/lwjgl api...

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2004-03-07 11:05:01 »

Got 228fps for both of them. LWJGL one starts up a lot faster.

Specs:
Radeon 8500 / Dual 1GHz P3 / JRE1.5beta / Server VM / 640x480x32xwindowed / WinXP
(I turned off the Cursor in the LWJGL one, and it didn't make even a single fps difference)

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2004-03-07 11:25:31 »

What? Not even an executable jar? Embarrassed

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #7 - Posted 2004-03-07 12:09:18 »

well, some more tests show that the cursor does not make any big impact - might just have been a fluke...
tried running both in fullscreen getting 620ish in jogl and 630ish in lwjgl...

Offline Java Cool Dude

Senior Member




Java forever


« Reply #8 - Posted 2004-03-07 15:10:10 »

Well sorry for not giving any more details, thing is, I was litteraly dead tired from staying up coding all night :sad panda:.

Here's the displayOptions for anyone who cares; it's a simple GUI for choosing screen mode.

Now here's my $.02 on the whole situation;
JoGL does indeed run faster than LWJGL, in the range of ~10% though which is not that bad considering all the benefits that comes with switching to the latter.

I have few concerns however; The Display class is a bit bogus since it reports the existence of refresh rates that are ways higher than what my monitor supports.
In the TextureCubeMapL, where L stands for LWJGL, try scrapping line 215 where it says    
1  
2  
 if(rate > 85) //TEMPORARY FIX
       continue;

and then try to go into fullscreen 32 bit, that's right the jvm crashes...
A simple printout of the parameters array reveals refresh rates of order 120-100 which are definitely not supported @ 1024*768, 800*600 and 1240*1024.

Other things that I spent some decent time attempting to accomplish is cutting all ties with AWT/SWING; that means that I can't use features such as BufferedImages and ImageIO, guess until some kind soul out there points me to some open source PNG/JPG loader, it's pure TGA and BMP for me :sad panda:

Also it frustrates me how making a texture involves creating a Direct ByteBuffer; someone has no clue on how much time I wasted trying to get my TextureLoader to work with wrapped ByteBuffers...
But eventually I figured out and now everything runs fine.


/me goes to breakfast
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #9 - Posted 2004-03-07 15:35:32 »

Quote
JoGL does indeed run faster than LWJGL, in the range of ~10%


me = surpised  Huh

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #10 - Posted 2004-03-07 15:59:49 »

Quote
I have few concerns however; The Display class is a bit bogus since it reports the existence of refresh rates that are ways higher than what my monitor supports.

We just report what your display driver and monitor is telling us...

Quote
and then try to go into fullscreen 32 bit, that's right the jvm crashes...
A simple printout of the parameters array reveals refresh rates of order 120-100 which are definitely not supported @ 1024*768, 800*600 and 1240*1024.

again, fullscreen works fine here (my monitor is fine at those values) - problem is that your drivers (in cooperation with your monitor) is claiming higher abilities than is possible.
We can't magically remove modes, since we  have no way of determening whether they're valid or not. To make it even more fun, Linux typically returns 0 as refresh rate!

I am a bit puzzled by the JVM crash though?

Quote
JoGL does indeed run faster than LWJGL, in the range of ~10% though which is not that bad considering all the benefits that comes with switching to the latter.

I don't get this statement...
you say that jogl is 10% faster? but you then say that, that is ok, since lwjgl brings other benefits to the table?
fwiw, I am almost not seeing any speed difference - in fact lwjgl is a bit quicker than jogl (negligible difference).

Quote
Other things that I spent some decent time attempting to accomplish is cutting all ties with AWT/SWING; that means that I can't use features such as BufferedImages and ImageIO, guess until some kind soul out there points me to some open source PNG/JPG loader, it's pure TGA and BMP for me :sad panda:

You don't *have* to avoid ImageIO! - only if you want to natively compile.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #11 - Posted 2004-03-07 16:05:16 »

Quote
Now here's my $.02 on the whole situation;
JoGL does indeed run faster than LWJGL, in the range of ~10% though which is not that bad considering all the benefits that comes with switching to the latter.

I would love to see you summarize the benefits that you realized by using LWJGL.   A table of pros and cons from someone who has actually used both to do the same thing would be great.

Offline Java Cool Dude

Senior Member




Java forever


« Reply #12 - Posted 2004-03-07 16:11:11 »

That's bizarre, I know the same code executes to perfection when using  
1  
2  
    DisplayMode[] displayModes = GraphicsEnvironment.getLocalGraphicsEnvironment().
                                 getDefaultScreenDevice().getDisplayModes();


provided with the AWT package, as in returning no more than 85Hz at 1024*768, and 60Hz for 1280*1024.
I provided a case sample with the LWJGL version of texture cube mapping, can you please check it out?
I'm positive the JVM is crashing due to unsuppored resfresh rates fed to the monitor (120hz at 1024*768) though.

Back to benchmarking, it's not a question about whetheir you think LWJGL runs faster than JoGL or not, as matter of fact the FPS numbers produced on my machine are definitely on JoGL's side.
However you never know, it's not like everyone out there has got the same machine.
But like I said I'd code using LWJGL anytime over JoGL for the simplicity and the non-AWT/SWING dependency.

Finally when I made the move towards LWJGL, I made this commitment of not using any AWT/SWING component, and  I'm doing ok so far.
So any PNG loader out there by any chance?
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2004-03-07 16:18:30 »

Quote
You don't *have* to avoid ImageIO! - only if you want to natively compile.

Or run on Mac Smiley

Hoping that one is fixed soon.  I've noticed activity in CVS... maybe we finally have a Mac fix for AWT compatibility?

Offline Java Cool Dude

Senior Member




Java forever


« Reply #14 - Posted 2004-03-07 16:22:21 »

At this point I can't draw a final conclusion on which one is better; JoGL or LWJGL.
But here's few comments;

What I like about LWJGL is the fact that I can use a native compiler like JET and have Java-phobe run my demos without all the usual b*tching that comes with telling them to download a runtime.
It also loads a bit faster than JoGL and kicks almost immidiately at full speed rendering.
Another plus is, once GL is initialized after creating a window, you can call openGL functions pretty much everywhere without passing a valid GL instance to every single rendering function out there, and that alone is worth switching to LWJGL IMHO.
Now what bothers me about LWJGL is how they've created different instances of OpenGL matching the versions that were put up to the public.
It's quite a hassle to look up GL15, 14,13,12,11 docs to figure what extension goes where, but I look at it as a history challenge (Never knew that CUBE_MAP was introduced as late as OpenGL 1.3)
Cutting the AWT/SWING ties however is a bit troublesome since you gotta look for a decent open source PNG/JPG loader on your own to still keep the comiling to native option, which is again why I'm using LWJGL...
Will think about more things later
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #15 - Posted 2004-03-07 17:22:35 »

IMHO Jogl is still way too unstable and buggy to be considered as a serious alternative. I'd estimate that about 50% of machines I've tried on that have a non-nVidia or non-ATi card fail to create a display surface. LWJGL display mode selection may be more lengthy code, but its a lot more robust (and actually fails gracefully too).

Syntax, speed, etc. differences are all moot if you can't create a display surface in the first place.

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

Senior Member




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


« Reply #16 - Posted 2004-03-07 18:02:03 »

Quote

Or run on Mac Smiley

Hoping that one is fixed soon.  I've noticed activity in CVS... maybe we finally have a Mac fix for AWT compatibility?


ImageIO runs just fine on the Mac.

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 elias

Senior Member





« Reply #17 - Posted 2004-03-07 18:37:24 »

I think swpalmer means the LWJGL on mac problems of not being able to work with AWT without either locking up or getting no input.

- elias

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #18 - Posted 2004-03-07 20:51:09 »

Yes that's exactly what I meant.

Offline karatemarkel

Junior Member





« Reply #19 - Posted 2004-03-08 12:18:16 »

I'm having no luck with LWJGL at the moment, both demos compiled and ran on my computer and both gave a reading of 76fps which I assume is syncing to my refresh rate. However, when I ran the LWJGL version the culling (at least I think its that) seems to be messed up as you can see all surfaces of the Buda all the time, also (and I know this isn't directly related to LWJGL) the display mode dialog if a bit iffy, if the mouse pointer leaves the window it disappears and I have to restart the app, and the movement speed of the mouse at the display options stage of the app is very slow.

Both these problems are none existent in the JOGL version, and obviously, the messed up display of the LWJGL is the main issue.

I think I probably need a better vid card  Grin

Compiled with jogl 1.0beta, and lwjgl_unofficial_0_89 and j2sdk1.4.2_01 on winXPpro sp1, Geforce4Ti 4400 with Version 6.14.10.5303 drivers.
Offline Java Cool Dude

Senior Member




Java forever


« Reply #20 - Posted 2004-03-08 12:25:34 »

I noticed the culling bug on Geforce cards ALONE, ATi on the other hand was performing and acting like a true champ.
ATi 1, Nvidia 0 Grin

Now back to the mouse problem, I fixed it in my own LWJGL binaries; as a matter of fact, the bug is showing because mouse was clipped to the width and width instead of width and height.
I have no clue why it's running slow on your computer though, so far I tested it on a Geforce FX 5900, 5800, a Radeon 9600/9700 both pro and stuff was working good, except the artifact on Nvidia's cards...
Offline karatemarkel

Junior Member





« Reply #21 - Posted 2004-03-08 12:42:42 »

Oh good, so the culling problem is a driver issue then Roll Eyes, or something Smiley

Edited to say:

My poor little brain can't handle this, if the culling bug is related to the vid card how come the jogl version isn't effected by it?

/*head explodes  Grin



Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #22 - Posted 2004-03-11 13:49:23 »

Quote

Now back to the mouse problem, I fixed it in my own LWJGL binaries; as a matter of fact, the bug is showing because mouse was clipped to the width and width instead of width and height.


In your thread: The JWS thread *LWJGL demos only*, the jws file still has this bug for me (and I've only just tried it for the 1st time, so it's not that I have an old version Smiley).

Is this because you haven't updated that demo, or is it that the bug is still there?

(geforce 2, linux)

malloc will be first against the wall when the revolution comes...
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.

Riven (4 views)
2014-07-29 12:53:52

Dwinin (7 views)
2014-07-29 10:59:34

E.R. Fleming (20 views)
2014-07-29 03:07:13

E.R. Fleming (8 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (51 views)
2014-07-17 23:47:54
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!