Menu
▾
▴
gl4java-development — development for GL4Java
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(12) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
(9) |
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sahuc D. <Sa...@th...> - 2002-04-04 13:03:38
|
Oops, it seems it's already done ... I'll try it :-) Sorry. David. > -----Original Message----- > From: Sahuc David [mailto:Sa...@th...] > Sent: jeudi 4 avril 2002 14:17 > To: 'gl4...@li...' > Subject: [Gl4java-development] JDK1.4 & ByteBuffer > > > It's me again, > > Do you plan to use ByteBuffer class (for ex. adding new methods with > ByteBuffer instead of byte[]) for JNI 1.4 version of GL4Java ? > It could be great (easy to modify & access data) and not so hard to > implement. > > See you. > > David. > > _______________________________________________ > Gl4java-development mailing list > Gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-development > |
|
From: Sahuc D. <Sa...@th...> - 2002-04-04 12:17:55
|
It's me again, Do you plan to use ByteBuffer class (for ex. adding new methods with ByteBuffer instead of byte[]) for JNI 1.4 version of GL4Java ? It could be great (easy to modify & access data) and not so hard to implement. See you. David. |
|
From: Sahuc D. <Sa...@th...> - 2002-04-04 12:09:27
|
Hi folks ! I don't know if it's a bug of mine, but I doubt considering the following: I've an application with texturing of objects. while exiting, I wish to free texture resources by using glGenTextures method. Under NT4, there is no problem but under Win2000 this makes the Java application crashing in the native gl4java method (That's what Hotspot is telling me). I'm using JDK1.3.1_02 and GL4Java 2.8.2.0 on both configuration and using a Nvidia Quadro2 Pro card (28.32 drivers) Has any1 already got the same problem or should I change my config ? ;-) Thanks. David. |
|
From: <av...@sy...> - 2002-03-27 17:40:07
|
Hi, I was wondering if there were plans to add GLOffScreenDrawable to the Mac OSX port of GL4Java? Thanks a lot... Andrew Vardy av...@sc... |
|
From: <wj...@Th...> - 2001-10-04 13:29:43
|
I've got the GLJPanel samples working on 98, NT, and 2000 (all laptops with
varying quality video cards). I had to pull down the number of colors on
the display down to 256 colors on some of them (not sure how strong the
video cards are). I assume this is the issue? Anyway, when the numColors is
too high, the error is very cryptic. Line 234(?) fails with the "setpixel
failed" message. A better message would be in order, I suppose. I'm kind of
new at this, I don't see why this order of calls should EVER fail (these
are in SetDCPixelFormat):
ChoosePixelFormat
SetPixelFormat
but it does!
So if you get the "setpixel failed" message, try reducing the number of
colors and the samples will work.
Bill K
"Kenneth B. Russell"
<kbr...@al...> To: wj...@th...
Sent by: cc: gl4...@li...,
gl4...@li...urc gl4...@li...
eforge.net Subject: Re: [gl4java-usergroup] GLJPanel Under Windows 2000
10/04/2001 08:20 AM
Please respond to kbrussel
> I am trying to get the GLJPanel working on Windows...
Thanks for the clear bug report. This patch should fix the
problem. Will be checked in to the cvs tree shortly.
>cvs diff -c OpenGL_Win32_jawt.c
Index: OpenGL_Win32_jawt.c
===================================================================
RCS file:
/cvsroot/gl4java/GL4Java/GL4Java/CNativeCode/OpenGL_Win32_jawt.c,v
retrieving revision 1.5
diff -c -r1.5 OpenGL_Win32_jawt.c
*** OpenGL_Win32_jawt.c 2001/07/24 12:07:18 1.5
--- OpenGL_Win32_jawt.c 2001/10/04 06:19:09
***************
*** 426,431 ****
--- 426,435 ----
return JNI_FALSE;
}
+ if (joffScreenRenderer) {
+ pData->dsi_win = theWindow;
+ }
+
/* fetch the states of doubleBuffer and stereo */
(void) PixelFormatDescriptorFromDc( theWindow, &pfd);
_______________________________________________
gl4java-usergroup mailing list
gl4...@li...
https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
|
|
From: Kenneth B. R. <kbr...@al...> - 2001-10-04 06:20:22
|
> I am trying to get the GLJPanel working on Windows...
Thanks for the clear bug report. This patch should fix the
problem. Will be checked in to the cvs tree shortly.
>cvs diff -c OpenGL_Win32_jawt.c
Index: OpenGL_Win32_jawt.c
===================================================================
RCS file:
/cvsroot/gl4java/GL4Java/GL4Java/CNativeCode/OpenGL_Win32_jawt.c,v
retrieving revision 1.5
diff -c -r1.5 OpenGL_Win32_jawt.c
*** OpenGL_Win32_jawt.c 2001/07/24 12:07:18 1.5
--- OpenGL_Win32_jawt.c 2001/10/04 06:19:09
***************
*** 426,431 ****
--- 426,435 ----
return JNI_FALSE;
}
+ if (joffScreenRenderer) {
+ pData->dsi_win = theWindow;
+ }
+
/* fetch the states of doubleBuffer and stereo */
(void) PixelFormatDescriptorFromDc( theWindow, &pfd);
|
|
From: <wj...@Th...> - 2001-10-03 15:23:19
|
I'm a novice to GL4Java (pretty new to GL in for that matter). I tried to
run some of the GLJPanel samples, and I can't get any of them to run
successfully. I am successfully using GLCanvas.
I am trying to get the GLJPanel working on Windows. I'm using Windows 2000.
I can get create a GLContext successfully, but the native call to
gljMakeCurrent fails. I compiled all the native code and poked around in a
bit, and it seems to me that something is missing in the Windows version of
Java_gl4java_GLContext_gljMakeCurrentNative.
The line it dies on is:
if ( ret==JNI_TRUE && !disp__wglMakeCurrent(GET_USED_WINDOW(thisWin),
(HGLRC)((PointerHolder)glContext)) )
The first parameter is 0. It appears to be that dsi_win is initialized to
NULL in the jawt_create_offscreen call, and it is never set to anything
else. The only chance it would get to be changed is in jawt_lock, but since
dsi_win_created is never updated anywhere, it's initial value of 1 remains
unchanged, and dsi_win is never set. It is actually set in
gljDestroyNative, but I don't think that helps here...
This is a bit different from the X11 code though. It has this code:
if(ownwind || joffScreenRenderer==JNI_TRUE)
{
pData->dsi_win=(void *)(PointerHolder)theWindow;
pData->dsi_win_created=1;
}
So, here are some questions:
1 - Has anyone run the GLJPanel samples under Windows?
2 - How does dsi_win get updated if dsi_win_created is never changed?
Thanks in advance!
Bill K
|
|
From: markhacker <mar...@ho...> - 2001-05-31 18:14:40
|
I am intrested in demo jave4gl under solaris, and I noted that you = talked about solaris binary on the web site, but I can't find them. = Does some body have them ? Many Thanks |
|
From: Jiba <a1...@So...> - 2001-04-23 09:27:35
|
Sven Goethel wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 20 April 2001 16:33, Jiba wrote: > > Hi Sven, > > > > I've done a Java Web Start file for GL4Java ! > > (Java Web Start is a new way to lauch Java apps or applet from a browser > > - http://java.sun.com/products/javawebstart/ ) > > > > ;-) > > great effort > > well, i have checked this tool by myself, > but i think it is too complicated .. > > since gl4java 2.7.1, if gl4java is installed, no more need for > special privileges (java.policy editing) is needed anymore to run applet's, > since gl4java uses the java2's "AccessController.doPrivileged" block ! > (work's if installed within jre/lib/ext only, of course) > > > This will allow automatic installation of GL4Java for Java Web Start > > apps ! > > > > too sun TM'ed ;-), Here, you are true. > too many user interaction, e.g. you have to install > java web start, then do some options, the download gl4java, then ... I really think installation can be easier: install java web start, and then just click to download and launch any application. Lots of people have problems to install my game (Arkanae) so i am trying this... > also, the jar's have to be signed .. > > i do not like this product very much .. > > anyway, this is just my personal opinion. > > cheers, sven > > - -- > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE64R0tHdOA30NoFAARAjHlAJ4uH6QfS61OUEH0eaiT97HyWEwlEgCgs/b3 > DNx7xwOUfqw2yXtxwWS6lfs= > =gWV5 > -----END PGP SIGNATURE----- > > _______________________________________________ > Gl4java-development mailing list > Gl4...@li... > http://lists.sourceforge.net/lists/listinfo/gl4java-development |
|
From: Sven G. <sgo...@ja...> - 2001-04-21 05:41:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 April 2001 16:33, Jiba wrote: > Hi Sven, > > I've done a Java Web Start file for GL4Java ! > (Java Web Start is a new way to lauch Java apps or applet from a browser > - http://java.sun.com/products/javawebstart/ ) > ;-) great effort well, i have checked this tool by myself, but i think it is too complicated .. since gl4java 2.7.1, if gl4java is installed, no more need for special privileges (java.policy editing) is needed anymore to run applet's, since gl4java uses the java2's "AccessController.doPrivileged" block ! (work's if installed within jre/lib/ext only, of course) > This will allow automatic installation of GL4Java for Java Web Start > apps ! > too sun TM'ed ;-), too many user interaction, e.g. you have to install java web start, then do some options, the download gl4java, then ... also, the jar's have to be signed .. i do not like this product very much .. anyway, this is just my personal opinion. cheers, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE64R0tHdOA30NoFAARAjHlAJ4uH6QfS61OUEH0eaiT97HyWEwlEgCgs/b3 DNx7xwOUfqw2yXtxwWS6lfs= =gWV5 -----END PGP SIGNATURE----- |
|
From: Jiba <a1...@So...> - 2001-04-20 14:40:51
|
Hi Sven, I've done a Java Web Start file for GL4Java ! (Java Web Start is a new way to lauch Java apps or applet from a browser - http://java.sun.com/products/javawebstart/ ) This will allow automatic installation of GL4Java for Java Web Start apps ! With Java Web Start, all the file (including classes, datas and native libs) must be placed into .jar files. I've worked with : gl4java.jar gl4java-glutfonts.jar libGL4Java-Linux.jar png.jar (The libGL4Java-Linux.jar file contains all the 3 native libs for Linux.) I've done 2 different extension, one for the PNG jar and one for GL4Java itself; to each extension corresponds a .jnlp file (those files have a XML syntax). The GL4Java extension is cut in two piece, called "GL4Java" and "GL4Java-GlutFonts", so if we doen't need the glut-fonts, they won't be downloaded. The GL4Java extension is run with all security permission (in order to access to native lib); but THIS REQUIRE TO SIGN sign ALL THE JAR. Java Web Start just require to add a mime type in the server for JNLP file, like (for Apache) : application/x-java-jnlp-file JNLP The jnlp files assume that all the file (the jar, gl4java.jnlp, png.jnlp) are in the same directory. This directory must be written in the file, in the "codebase" attrib of the <jnlp> element (replace my value, "http://localhost/~aonw/javaws", with your one). The index.html, test.jnlp and test.jar are just a very little demo, that lauch the GL4Java console (GLContext -info). Those 3 files sould be placed in the same directory than the other. To run the demo you also need to install Java Web Start client (cf URL before). The GL4Java extension can be declared in any .jnlp file, inside the <resources> element as following : <extension name = "GL4Java" href = "[GL4Java URL]/gl4java.jnlp"> <ext-download ext-part = "GL4Java"/> <ext-download ext-part = "GL4Java-GlutFonts"/> </extension> Feel free to modify information stuff or anything. Thanks for reading so far ! Jiba |
|
From: Max G. <gi...@li...> - 2001-04-14 13:46:43
|
Hi! Why glEdgeFlagPointer(...) has so many versions since it should only support boolean arrays? Similarly for all other gl*Pointer methods - none of them support all types of arguments. Eg. calling gl.VertexPointer(int, long[]) should not be allowed. IMHOP they should be removed from GLFunc. Max -- ----------------------------------------------------------- -- Max Gilead --- gi...@li... -- -- XMage library --- http://xmage.sourceforge.net -- ----------------------------------------------------------- -- Any system that depends on reliability is unreliable. -- -- --- Nogg's postulate -- |
|
From: Jiba <a1...@So...> - 2001-04-05 08:20:46
|
Hi,
I'm trying to use the GL4Java Installer for the new version of Arkanae.
I think that a "ldconfig" may be needed after Linux installation !
Something like :
protected void ldconfig() {
if("Linux".equals(System.getProperty("os.name"))) {
System.out.println("Linux system - good ! - Running ldconfig...");
try {
Process p = Runtime.getRuntime().exec("ldconfig");
int r = p.waitFor();
if(r != 0) throw new Exception("ldconfig failed ! You should do
it manually...");
}
catch(Exception x) {
x.printStackTrace();
}
}
}
I'm right ???
Thanks !
A11W
|
|
From: Sven G. <sgo...@ja...> - 2001-03-28 06:44:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 26 March 2001 10:46, Artiste on the Web wrote: > Hi, > > I experiment problem with GL4Java 2.6, too... under winME but Linux > also. > > I wonder in witch order do you load the native libraries ? > this is the order, as can seen in GLContext.java:678 gljLibName, glLibName, gluLibName, defGljMSWinLib java gl4java.GLContext -info <snip> GLContext.loadNativeLibraries will do it ! jvm vendor: Sun Microsystems Inc. jvm version: 1.3.0_02 jvm version (parsed): major: 1, minor: 3 loaded native library: GL4JavaJauGljJNI13 loaded native library: GL4JavaJauGLJNI12 loaded native library: GL4JavaJauGLUJNI12 native Libraries loaded succesfull <snip> <snip> > > So i think the problem is the order... > In GLContext.loadNativeLibraries(), you need to load > libGL4JavaJauGLjJNI.so before libGL4JavaJauGLJNI.so. > Under Linux, just loading libGL4JavaJauGLjJNI.so before i call > GLContext.loadNativeLibraries() is OK. > as you can see above, gl4java loads the libs as default in the correct order ! > A11W > cheers, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6wYgQHdOA30NoFAARAncfAKC6pSNjEwyuVIa6Rb1adwBynE3jpwCgoDh4 hAoaDQFwWU77fBQbNbJBpJA= =FL2L -----END PGP SIGNATURE----- |
|
From: Artiste on t. W. <a1...@So...> - 2001-03-26 09:57:01
|
Hi,
I experiment problem with GL4Java 2.6, too... under winME but Linux
also.
I wonder in witch order do you load the native libraries ?
If we have 2 lib, lib1 and lib2, and if lib1 depend on lib2, if we call
(in java) :
System.loadLibrary("lib1");
I think Java will search lib1 in the java.library.path, but who will
search lib2, required by lib1 ? Java or the OS ???
Probably the OS... and the OS will not search in the java.library.path.
I've tried this : I take libGL4JavaJauGLJNI.so as lib1 and
libGL4JavaJauGLjJNI.so as lib2 (according to "objdump -p",
libGL4JavaJauGLJNI.so needs libGL4JavaJauGLjJNI.so). Both libraries are
in the java.library.path, but NOT in the OS library path (/usr/lib,
/usr/local/lib, ...).
If i do :
System.loadLibrary("libGL4JavaJauGLJNI.so"); // =lib1
It crashes and says libGL4JavaJauGLjJNI.so (=lib2) cannot be found.
But i load lib2 first :
System.loadLibrary("libGL4JavaJauGLjJNI.so"); // =lib2
System.loadLibrary("libGL4JavaJauGLJNI.so"); // =lib1
it's OK.
So i think the problem is the order...
In GLContext.loadNativeLibraries(), you need to load
libGL4JavaJauGLjJNI.so before libGL4JavaJauGLJNI.so.
Under Linux, just loading libGL4JavaJauGLjJNI.so before i call
GLContext.loadNativeLibraries() is OK.
A11W
|
|
From: Sven G. <sgo...@ja...> - 2001-02-24 03:59:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear gl4javas, the new version 2.6.0.0 is released yesterday. I have attached the CHANGES.txt for this version, and the README-Version-2-5-2.txt which describes all new features and difficulties. comments are wellcome byebye, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6lzG/HdOA30NoFAARAhjzAJ9zfEiMXTuU9pvjZ3rryBzBlqgFdgCfULng uA2o7JMl4Co1RUUbbSWwNLA= =jd4b -----END PGP SIGNATURE----- |
|
From: Artiste on t. W. <a1...@So...> - 2001-02-18 14:55:06
|
Sven Goethel wrote: > On Friday 16 February 2001 18:31, Artiste on the Web wrote: > > Sven Goethel wrote: > > > On Tuesday 19 December 2000 15:38, Artiste on the Web wrote: > > > > Arkanae is a 3D game, developped with Java and GL4Java. > > > > The 0.2.1 version of Arkanae is available here : > > > > http://perso.club-internet.fr/b_lamy > > > > > > > > This new version includes bugfixes, graphic settings, german > > > > translation, and spellcasting with incredible 3D particle system > > > > effects > > > > > > > > :-) > > > > > > > > PS to Sven : In the game, I use by default a the yield() method to > > > > suspend the rendering thread; an option allows to use a sleep(1). > > > > > > > > A11W > > > > > > Dear A11W ;-), > > > > > > i checked out arkanae - it is getting greater and greater, > > > with gl4java 2-5-2-0-test2 prerelease ! > > > > > > well, the rendering acts cool (with a sleep or not), > > > but i got not keyboard action :-( > > > > Yes, i have had the same problem but now it's OK ! > > > > I have forgotten a "gljFree()" after the code that dump the OpenGL > > version/vendor/... (that call "gljMakeCurrent()" before dumping). > > hu .. thanxs, I got into coold sweating .. > > > > i would love to see you testing the new gl4java, > > > to make it more stable .. > > > > Now 2.5.2.0 runs very well. > > But i still get this printed on the console : > > > > GLContext.loadNativeLibraries ... > > GLContext.loadNativeLibraries will do it ! > > > > ??? > > ;-) it is a test release ;-) > i missed this .. I delete it now, thanxs ! > > > > well, i guess the usage of no-repaint with usesleep > > > should be the default for now, it is quiet stable and thread safe. > > > > But what about speed ??? Yield is quickier than sleep, no ? > > > see below .. the quickness of yield is, that YOU USE the > cpu at max .. see below. > > > > the use sleep fps with about 25fps may be importent, > > > if you do not want to give all the cpu power to the renderer ... > > > > Hey !? That's what i want : to give the maximum of the cpu time to the > > 3D ! And only as few as possible for handling events,... > > oh sorry, your eyes are better than mine - or guess what ;-)) ? > > fps - addicted ? > > well, you can not see the difference of a fps 30 - infinitve .., I guess so, > may be it will start just at about 40 fps .. > But why spend all the power of the cpu, just to achieve 100 fps (thats what I got ...). > Just to have a new heating system :-) or spending energy ? > > Well, in the future, you may add some intelligence AI to the enemies, > so theire AI needs cpu either (may be much more than the dumb rendering ..). > > So .. setting a convinent maximum grants you power for other tasks. > Also .. the player may own just one linux-box, > and wants to play the game but wants to compile other things also .. > > So why stealing the cpu power if unneccessary from the global ressources ? > > .. well just my 5 cents :-) > > > Do you kwow about this class : java.lang.ThreadLocal ? > > I've just discovered it today, it is used to create thread-local > > property (=with a different value for each thread). What about making > > the current GL context of a thread a thread-local property ? > > Just an idea... > > because you may want to share the context between NATIVE THREADS ! > > it is about, that the ctx can be used for one native thread at a time ! > > of yourse, you are able to lock the ctx to one thread, > you can do this today, just do not call gljFree() :-), > than nobody else will get this ctx while trying it with MakeCurrent !! > > you allready know these .. (the keyboard - AWT lock, the AWT thread was > set on the waiting state, while requesting the locked - never be freed ctx) ! > > > And maybe a suggestion : don't free the context at the end of display() > > (= after we have done with it) but before another thread use it. So if > > only one thread use the context, it is never freed => speed boost. > > see above: you do not have to call gljFree() ;-), > then nobody will get the ctx ;-) > may be it is about the easy design ... > > the OpenGL definition says, that the implementation of: > glXMakeCurrent(display, drawable, ctx) // our native part of gljMakeCurrent > and > glXMakeCurrent(display, None, NULL) // our native part of gljFree > should not use much ressources (-> cpu) ! > So it must be safe to use it for thread safety ! > > Well, for Win32 and others this MUST be the same ! > > So my Idea: Only call gljFree, if you really want to use OpenGL in one > special thread ! Then just call gljFree() only if this thread is it's creator thread. > The creator thread is the thread who calls init(), usually the AWT thread ! > > The other problem: > One thread can not unlock the ressources (monitor) of another thread > in java, and native (e.g. OpenGL's threads restrictions) ! > > So: How it is is the way it goes .. > > - -- > mailto:sgo...@ja... > > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > > voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE6jyHzHdOA30NoFAARAr/sAJ0YxuEdOccAev0Fk0P8oIbMvtw2PgCfQ2yv > dIwg77qoKN4tCU8FgsYrSIs= > =F0Ej > -----END PGP SIGNATURE----- |
|
From: Artiste on t. W. <a1...@So...> - 2001-02-18 14:55:02
|
Sven Goethel wrote: > On Friday 16 February 2001 18:31, Artiste on the Web wrote: > > > > What about (OpenGL[tm] for Java[tm])[tm] ? > > One [tm] for OpenGL, one for Java and one for you :-))) > > 1st of all: thanxs for the TM joke .. > :-) > > I guess everybody will still use gl4java, > but I showed those lawyers, that i tried my best :-)) > > kind regards, sven > > - -- > mailto:sgo...@ja... > > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > > voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE6jyHzHdOA30NoFAARAr/sAJ0YxuEdOccAev0Fk0P8oIbMvtw2PgCfQ2yv > dIwg77qoKN4tCU8FgsYrSIs= > =F0Ej > -----END PGP SIGNATURE----- |
|
From: Artiste on t. W. <a1...@So...> - 2001-02-18 14:54:59
|
> > And a question : why GLContext.getClassVersion() and getNativeVersion() > > always return 2.4.1.0 and not 2.5.* ? > > ;-) > > And this is the trueth for GLFunc and GLUFunc, > because I did not modified the version .. > I must change it for GLUFunc, because I changed the gluNew* l-values to long-type ! > > But GLContext has no function called getNativeVersion ;-), > use gljGetNativeLibVersion() and gljGetNativeLibVendor() instead, > they do return 2.5.* ! > > I guess the later are better .. > > > > yours, sven > > > > > > > A11W > > kind regards, sven > > - -- > mailto:sgo...@ja... > > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > > voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE6jyHzHdOA30NoFAARAr/sAJ0YxuEdOccAev0Fk0P8oIbMvtw2PgCfQ2yv > dIwg77qoKN4tCU8FgsYrSIs= > =F0Ej > -----END PGP SIGNATURE----- |
|
From: Artiste on t. W. <a1...@So...> - 2001-02-16 13:16:13
|
Sven Goethel wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A test release is done ! Hi, I've tried this release with my game Arkanae. The 3D works well and quick, but there is a problem with events : i no longer receive keyboard event (though it works well with GL4Java 2.5), and my Swing interface is no longer refreshed... ??? It also prints this in the console : GLContext.loadNativeLibraries ... GLContext.loadNativeLibraries will do it ! ??? > Yours, sven > - -- > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE6iM90HdOA30NoFAARApPWAKCuZlUklyFlxY4DJzO8wtpiiqj4hgCgizvV > hq8htuSHTGJHFYfk4rQ4awE= > =+QDi > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------ > Name: CHANGES.txt > CHANGES.txt Type: Plain Text (text/plain) > Encoding: base64 A11W |
|
From: Sven G. <sgo...@ja...> - 2001-02-14 08:35:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A new bugfixed test release is done ! This one is well testable ! Please do so, to make it more stable ! you can get it from: binary-packages: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/binpkg sources, doc's, demo's: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/archive The CVS repository is commited and tagged: rev-2-5-2-0-test2 Experience: ========== Linux 2.4.1, XFree86 4.0.2, kde 2.1 beta2: Command-Line JDK (1.1-1.3, sun, blackdown, ibm(no jawt)): OK ! Indirect DRI (Mesa-Soft 3.3): OK NVidia 0.96: OK See NVidia notes below ! Netscape + Netscape JVM: ERROR ! does not work, because Netscape's JVM implementation on linux looks like not to handle long-types within the JNI API .. ?! Netscape + j2re-1_3_0_01: OK ! Indirect DRI (Mesa-Soft 3.3): OK NVidia 0.96: OK See NVidia notes below ! Konqueror (2.1 beta2): jdk 1.3-sun: ERROR Applet runs, but nothing is visible ! jdk 1.3-ibm (no jawt): OK ! jdk 1.3-blackdown: OK ! Indirect DRI (Mesa-Soft 3.3): OK NVidia 0.96: OK See NVidia notes below ! Win98/WinNT4.0(*): Command-Line JDK (1.1-1.3, sun): OK ! Well, you have to start the java.exe from the <jdk-path>/jre/bin/java.exe Otherwise, the jawt.dll is not found !! BUG in JDK !! IExplorer + MS-JVM buil 3802: OK ! JDirect usage .. JRE 1.3* Plugin + ( IExplorer | Netscape ) OK ! Netscape + Netscape JVM OK ! (*) WinNT 4.0: On my system (servicepack6, nvidia detonator3), i cannot restart the applet ! An read access to adress 0x000000 occures right from NVidia's OGL implementation !! Looks like another bug within NVidia ? See NVidia notes below ! Well, Win98 runs fine NVidia Driver Note's: ================ The Linux 0.96 driver, and may be the winnt4.0 drivers, looks like not being able to handle THREAD's very well ! Example: JVM Process 1: JVM Process 1 - Thread 1: >MakeCurrent() >Free() This Produces many .X.err logs regarding to new created drawables for same thread !(?) If you use the same JVM process, and you start many applets -> native threads, the GL context managment looks like very confused. On Linux the GL rendering went slower and slower ! But a restarted JVM is fast as its first time ! Yes - GL4Java does destroy the glcontext and finalizes well ! comments, ideas are very wellcome ! kind regards, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6ikNcHdOA30NoFAARAhoZAKCEkjmEb8oYuVsMMRXezBOhU/vP9gCgh+Lx JkwKrgR7WwChh8BrulCwANA= =B3cQ -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-13 06:09:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A test release is done ! The new revision may be incompatible with the previous, because: - The GLUFunc.gluNew* etc. methods uses the long type for the reference holder for quadric, tesselation, .. (old: int type) ! This is, because this new revision is completly 64bit clean ! All native reference holders are long ! - You do not encapsulate your OpenGL calls within GLContext.gljMakeCurrent <your render code> GLContext.gljFree e.g. within the GLCanvas.display method: glj.gljMakeCurrent(); // lock GL Context gl.glBegin(); gl.glEnd(); glj.gljSwap(); glj.gljFree(); // release GL Context All the demo's have been updated in the new test release, to work with 2.5.2.0 ! This new Version try's to use JDK >=1.3's JAWT API to handle with the native window ! The new library, which uses this is called "GL4JavaJauGljJNI13" ! I do have problems with IBM's JDK 1.3: No library "jawt" (linux: libjawt.so, win32: jawt.dll) exists at all ! I do have problems with Sun's JDK 1.3 for Windows: No library "jawt" (linux: libjawt.so, win32: jawt.dll) is NOT found ! They do exist in jre/bin. Workaround: Add <java-home-dir>/jre/bin to your PATH environment variable ! Well, this version improves the multithreading behavior a lot. I have attached the last CHANGES.txt changes ;-) here ! Thoughts & Ideas are wellcome ! Last but not least: You can get the test release here: binary-packages: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/binpkg sources, doc's, demo's: http://www.jausoft.com/Files/Java/1.1.X/GL4Java/archive The CVS repository is commited and tagged: rev-2-5-2-0-test1 Yours, sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6iM90HdOA30NoFAARApPWAKCuZlUklyFlxY4DJzO8wtpiiqj4hgCgizvV hq8htuSHTGJHFYfk4rQ4awE= =+QDi -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-09 03:22:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have checked the old performance log files (avaiable on the web site -> documentation), and what i have seen is, that the older NVidia GLX implementation had no speed loss _with_ the call of gljFree (releasing the glx-context) !!! So it must be about the new implementation !? sven - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g2JiHdOA30NoFAARAroIAKCOkzMRl54oxC0jZZGm+KmHtfoNJACeKxjM 9BLy2D2uY9oliHoMqA8kqCk= =11nW -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-02-09 03:07:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, well I have: linux-2.4.1 + i686, XFree86 4.0.2 + GeForce256 +nvidia 0.96-nda-binary-driver (at 32bpp) .X.err: ===== (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients ... (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7758 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 7757 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients ... ! no exception ! The problem - you are right - is the call of the gljFree() method, which calls glXMakeCurrent( (Display *)disp, None, NULL ) to free the GLXContext ! The NVidia driver makes a stderr printout of the context numbers .. The reason is, that if you have bound one GLXContext to one thread, and another thread wants to use it, it will fail. There can be only one current GLX context per thread. The reason in the demo's and for the advice to encapsulate your frame renderings within gljMakeCurrent/gljFree is to make the GLX context avaiable for possible other threads. This is more safe. Well, I do not know why the NVidia driver is that verbose :-). The OpenGL manual says, that a call of MakeCurrent should not be very time consuming ! The implementation of gljMakeCurrent only changes the GLXContext, if the current GLXContext is not the one we want to make current ! I have just testet with gears.java (>java gears -perftest): With gljFree() call in end of display method: loading libs(gl, glu): null, null: true useFpsSleep: false useRepaint: false GL VERSION : 1.2.1 GL RENDERER: GeForce 256/AGP/SSE GL VENDOR : NVIDIA Corporation 280 frames in 5.005 seconds = 55.94405594405595 FPS 670 frames in 5.001 seconds = 133.9732053589282 FPS 656 frames in 5.006 seconds = 131.0427487015581 FPS 607 frames in 5.005 seconds = 121.27872127872128 FPS 587 frames in 5.008 seconds = 117.21246006389777 FPS Without gljFree() call in end of display method: loading libs(gl, glu): null, null: true useFpsSleep: false useRepaint: false GL VERSION : 1.2.1 GL RENDERER: GeForce 256/AGP/SSE GL VENDOR : NVIDIA Corporation 3491 frames in 5.0 seconds = 698.2 FPS 4945 frames in 5.0 seconds = 989.0 FPS 4973 frames in 5.0 seconds = 994.6 FPS 4940 frames in 5.0 seconds = 988.0 FPS 4919 frames in 5.001 seconds = 983.6032793441311 FPS 4903 frames in 5.0 seconds = 980.6 FPS 4944 frames in 5.0 seconds = 988.8 FPS Well, this looks like a need to think things over ! This is a performance task and a call for thinking the thread-safe mechanism over ! Ideas ? sven On Friday 09 February 2001 01:35, you wrote: > Hi *, > > here comes rather a feedback than a question... Have fun with my bad > english... 8-) > (I hope it's not off-topic) >(II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 4 clients (II) [GLX]: Updating NV driver (scrn 0) with 5 contexts, 0 drawables, 5 clients > I wonder if somebody else has the same problems: > > I've wrote a tiny test-application, doing nothing but "swapping" front and > back buffer. > (ok, copying back to front buffer via "gljSwap()" - have a look at the > attachment) > > I've got the following log: > > === schnipp === > > [...<java emptyLoop_GLCanvas>...] > > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 0 > clients > (II) NVIDIA(0): purgeCache: Free=0x198f000 Total=0x1fd0000 > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 1 drawables, 1 > clients > emptyLoop_canvas.init > emptyLoop_canvas.reshape > ..(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 2 drawables, 1 > clients > .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3 drawables, 1 > clients > .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 4 drawables, 1 > clients > > [...<counting "drawables" 5-3888> ...] > > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3889 drawables, 1 > clients > # # An unexpected exception has been detected in native code outside the > VM.# Program counter=0x48c3cf8c > # > # Problematic Thread: prio=5 tid=0x81f1498 nid=0x581 runnable > # > Aborted > [thr@elite thr]$ (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, > 3888 drawables, 1 clients > (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 > clients > > [...<last line repeats ~20 times> ...] > [...<auto re-init of X/nvidia-driver> ...] > > === schnipp === > > Configuration: > > PC > - AMD Athlon 600MHz > - Asus K7M Mainboard > - 256MB Ram > - Asus GeForce2 32MB V7700 > - SBLive Player 1024 > > Linux Red Hat 7.0 > - XFree 4.01 > - Gnome (default version on redhat 7.0) > - KDE (default version on redhat 7.0) > > OpenGL > - gl4java 2.5.0.0 > - nVidia Drivers 0.94 - 0.96 > > also tried > - Kernel 2.2.18 > - kde 2.01 > - no window manager at all > > So I wrote a tiny "GLAnimCanvas" class for my own. As a result there is no > need to call "gljMakeCurrent()" and "gljFree()" in the display() method > anymore (both are called only once at initialization time). Via a > SwingUtilities like method "invokeLater" and "invokeAndWait" other Threads > are able to use OpenGL commands getting executed in the main Render-Thread. > Now no more crashes after two days of running tests. Then I studied the > differences between the class implementations. > > My thesis: It look's like something (i.e. the nvidia driver, X, or > whatever) doesn't "like" the gljMakeCurrent()/gljFree() combination called > to often. What is the reason having to call both methods in > GLAnimCanvas.display() every frame? > > Any comments ? > [ ] what a hero! ;-) > [ ] nice to know > [ ] what a pain to read > [ ] text to long > [ ] never send attachments > [ ] just get away > > ciao, Thorsten - ---------------------------------------- Content-Type: application/octet-stream; charset="iso-8859-1"; name="emptyLoop_GLCanvas.java" Content-Transfer-Encoding: quoted-printable Content-Description: - ---------------------------------------- - -- mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6g17rHdOA30NoFAARAnG2AKCykVtWJdRe+wwuYlG8cuBnlpgx1wCgiPNZ 2apDQPgaBYGFrRB+Cs6wlxA= =mQed -----END PGP SIGNATURE----- |
|
From: Thorsten R. <ni...@gm...> - 2001-02-09 00:35:27
|
Hi *, here comes rather a feedback than a question... Have fun with my bad english... 8-) (I hope it's not off-topic) I wonder if somebody else has the same problems: I've wrote a tiny test-application, doing nothing but "swapping" front and back buffer. (ok, copying back to front buffer via "gljSwap()" - have a look at the attachment) I've got the following log: === schnipp === [...<java emptyLoop_GLCanvas>...] (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 0 clients (II) NVIDIA(0): purgeCache: Free=0x198f000 Total=0x1fd0000 (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 clients (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 clients (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 clients (II) [GLX]: Updating NV driver (scrn 0) with 0 contexts, 0 drawables, 1 clients (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 clients (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 1 drawables, 1 clients emptyLoop_canvas.init emptyLoop_canvas.reshape ..(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 2 drawables, 1 clients .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3 drawables, 1 clients .(II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 4 drawables, 1 clients [...<counting "drawables" 5-3888> ...] (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3889 drawables, 1 clients # # An unexpected exception has been detected in native code outside the VM.# Program counter=0x48c3cf8c # # Problematic Thread: prio=5 tid=0x81f1498 nid=0x581 runnable # Aborted [thr@elite thr]$ (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 3888 drawables, 1 clients (II) [GLX]: Updating NV driver (scrn 0) with 1 contexts, 0 drawables, 1 clients [...<last line repeats ~20 times> ...] [...<auto re-init of X/nvidia-driver> ...] === schnipp === Configuration: PC - AMD Athlon 600MHz - Asus K7M Mainboard - 256MB Ram - Asus GeForce2 32MB V7700 - SBLive Player 1024 Linux Red Hat 7.0 - XFree 4.01 - Gnome (default version on redhat 7.0) - KDE (default version on redhat 7.0) OpenGL - gl4java 2.5.0.0 - nVidia Drivers 0.94 - 0.96 also tried - Kernel 2.2.18 - kde 2.01 - no window manager at all So I wrote a tiny "GLAnimCanvas" class for my own. As a result there is no need to call "gljMakeCurrent()" and "gljFree()" in the display() method anymore (both are called only once at initialization time). Via a SwingUtilities like method "invokeLater" and "invokeAndWait" other Threads are able to use OpenGL commands getting executed in the main Render-Thread. Now no more crashes after two days of running tests. Then I studied the differences between the class implementations. My thesis: It look's like something (i.e. the nvidia driver, X, or whatever) doesn't "like" the gljMakeCurrent()/gljFree() combination called to often. What is the reason having to call both methods in GLAnimCanvas.display() every frame? Any comments ? [ ] what a hero! ;-) [ ] nice to know [ ] what a pain to read [ ] text to long [ ] never send attachments [ ] just get away ciao, Thorsten |
