Menu
▾
▴
gl4java-usergroup
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(39) |
Feb
(22) |
Mar
(41) |
Apr
(44) |
May
(47) |
Jun
(25) |
Jul
(28) |
Aug
(39) |
Sep
(35) |
Oct
(31) |
Nov
(31) |
Dec
(3) |
| 2001 |
Jan
(18) |
Feb
(43) |
Mar
(47) |
Apr
(38) |
May
(9) |
Jun
(20) |
Jul
(8) |
Aug
(11) |
Sep
(15) |
Oct
(43) |
Nov
(27) |
Dec
(73) |
| 2002 |
Jan
(42) |
Feb
(47) |
Mar
(49) |
Apr
(58) |
May
(12) |
Jun
(68) |
Jul
(42) |
Aug
(9) |
Sep
(19) |
Oct
(36) |
Nov
(28) |
Dec
(12) |
| 2003 |
Jan
(13) |
Feb
(24) |
Mar
(40) |
Apr
(52) |
May
(39) |
Jun
(46) |
Jul
(17) |
Aug
(5) |
Sep
(4) |
Oct
(9) |
Nov
(13) |
Dec
(12) |
| 2004 |
Jan
(1) |
Feb
(17) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(6) |
Nov
(6) |
Dec
(3) |
| 2005 |
Jan
|
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
(3) |
Dec
(1) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
(5) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(5) |
| 2007 |
Jan
(3) |
Feb
(11) |
Mar
(5) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(5) |
| 2008 |
Jan
(7) |
Feb
(8) |
Mar
(30) |
Apr
(17) |
May
(20) |
Jun
(8) |
Jul
(19) |
Aug
(10) |
Sep
(7) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(13) |
Feb
(7) |
Mar
(13) |
Apr
(27) |
May
(95) |
Jun
(77) |
Jul
(43) |
Aug
(25) |
Sep
(24) |
Oct
(32) |
Nov
(6) |
Dec
(6) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(30) |
Apr
(58) |
May
(60) |
Jun
(72) |
Jul
(32) |
Aug
(45) |
Sep
(19) |
Oct
(4) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-29 05:46:31
|
> I am new to GL4Java, so I have a simple question. Many methods and demo > programs in GL4Java include the string "cvs" in the name. What does this mean? > Is it an abbreviation for "canvas"? Yes, that's what it means in this context. |
|
From: Antony R. <ri...@to...> - 2002-01-29 00:12:58
|
"CVS" is an acronym for the "Concurrent Versions System". CVS is a "Source Control" or "Revision Control" tool designed to keep track of source changes made by groups of developers working on the same files, allowing them to stay in sync with each other as each individual chooses. hth ribot. ----- Original Message ----- From: "Mark Montana" <pat...@lm...> To: <gl4...@li...> Sent: Monday, January 28, 2002 9:22 PM Subject: [gl4java-usergroup] cvs > I am new to GL4Java, so I have a simple question. Many methods and demo > programs in GL4Java include the string "cvs" in the name. What does this mean? > Is it an abbreviation for "canvas"? > > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup |
|
From: Mark M. <pat...@lm...> - 2002-01-28 21:25:07
|
I am new to GL4Java, so I have a simple question. Many methods and demo programs in GL4Java include the string "cvs" in the name. What does this mean? Is it an abbreviation for "canvas"? |
|
From: nader <nz...@st...> - 2002-01-27 00:09:45
|
Hello,
Let me first say thanks (again) for enabling the option to disable all
debugging output. I am also thankful that you have implemented a more
straightforward offscreen rendering class.
There is however one problem with it (or what looks like a problem). The
setSize(Dimension size) method located at line 236 in file
GLOffScreenDrawable.java is implemented to set the internal size
(offScrnSize) to the passed in size by reference, not by copying the
actuall values (width and height). This poses a problem as a user might
use the same passed in reference (size), but that has been changed, again
in a call to setSize, and due to the implementation of setSize
(following), a size change is not recognized:
if((size!=null && size.equals(offScrnSize)==false) ||
size!=offScrnSize
)
{
offScrnSizeChanged=true;
offScrnSize=size;
initDrawable();
}
It seems it would be better if the components of the reference (size.width
and size.height) are copied to offScrnSize, than by saving the reference
itself.
To all relevant folks, thanks again for the newer version of GL4Java ... a
lot of these features are/were needed.
nader
|
|
From: Sven G. <sgo...@ja...> - 2002-01-22 21:41:21
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 22 January 2002 11:28, pet...@ba... wrote: > Hi all, > > I'm currently trying to clamp down on my security permissions using a > policy file. The problem I've come across is that Gl4Java defaults back > to using a DummyGLDrawableFactory unless the following permissions > appear in the policy file: > > > permission java.lang.RuntimePermission > "accessClassInPackage.sun.awt"; > permission java.lang.RuntimePermission "accessDeclaredMembers"; > permission java.lang.reflect.ReflectPermission > "suppressAccessChecks"; > > > Don't get me wrong: I don't have any major qualms about having to add > these things to my policy file, I just thought I'd contribute the above > lines in case they were of use to someone else... Perhaps Sven would > like to add an entry in the FAQ for this one? > well, gl4java asks if it can use a privilegedAction, loading a special implementation (class). if gl4java is installed in the regular location, the jre/lib/ext (see the FAQ for details), the default policy file gives us all needed rights: - loading a native library - loading a java class looks like, you are using it on a different location ? therefore, of course, you need to grant proviliges by hand. > Hope someone finds it useful anyway... > ok, can be FAQ entry, thanxs > Cheers, > > Pete > cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TdlfHdOA30NoFAARAuFTAKDAKyCCLdtFFqBR1WlCi7kYBkt6JACfXC17 XJgcKDqgdaH2wt1vsb+oeuU= =EMLu -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2002-01-22 21:41:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 21 January 2002 22:07, Andy wrote: > http://www.andyq.pwp.blueyonder.co.uk cool, it runs out of the box thanxs a lot cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TdxQHdOA30NoFAARAuP3AKCYEn33W4bPViBzJTFFpydtbjn2ywCfaYnq yudzY/7EdClPmqMPDuO1QfY= =yuZj -----END PGP SIGNATURE----- |
|
From: <pet...@ba...> - 2002-01-22 10:39:38
|
Hi all, I'm currently trying to clamp down on my security permissions using a policy file. The problem I've come across is that Gl4Java defaults back to using a DummyGLDrawableFactory unless the following permissions appear in the policy file: permission java.lang.RuntimePermission "accessClassInPackage.sun.awt"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; Don't get me wrong: I don't have any major qualms about having to add these things to my policy file, I just thought I'd contribute the above lines in case they were of use to someone else... Perhaps Sven would like to add an entry in the FAQ for this one? Hope someone finds it useful anyway... Cheers, Pete ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** |
|
From: Andy <and...@bi...> - 2002-01-21 21:07:11
|
Hi there, Just thought I'd mention that v1.4 of GLDominos has been released. New changes : Added flyby view - create your own spectacular flybys - easily and visually. Also some bug fixes and other mnor enhancements. Goto http://www.andyq.pwp.blueyonder.co.uk. Goto the Java section and select Projects. Source code is available also. Cheers Andy |
|
From: Andy <and...@bi...> - 2002-01-13 18:17:53
|
Hi there, Just thought I'd post a quick message to say that I've just released version 1.2 of GLDomino. What is GLDomino? Well remember when you had a set of dominos what was the only thing you ever did with them? Yup, thats right, stand then up in a row and then knock them down. Well, thats what GLDomino does. It allows you to design your own layouts (with special types of dominos such as Burst and Elevator & Ropes), and then switch to a 3D window and knock them down. Best of all, you can watch them fall over and over (if that takes your fancy) and you don't ever have the fustration of getting them almost set up and then clumsily setting them off too soon :). Anyway, take a look and let me know any comments (bugs, etc). The address is http://www.andyq.pwp.blueyonder.co.uk and then go to the Java section. Cheers Andy |
|
From: gerard z. <gzi...@ma...> - 2002-01-12 22:25:31
|
hi Joe, I'll update it to 2.7.2 (tomorrow?). In the meantime I'd appreciate it if you emailed me an example that shows the bug. cheers On Saturday, January 12, 2002, at 12:03 PM, gl4java-usergroup- re...@li... wrote: > Message: 1 > Date: Fri, 11 Jan 2002 16:57:59 -0600 > From: Joe <jo...@mo...> > To: gl4...@li... > Subject: [gl4java-usergroup] Mac OS X GL4Java -- latest version? > > Hey all, > > I'm having some problems with the latest version of the Mac OS > X GL4Java > build (on Gerard Ziemski's site) which is version 2.7.2.0. > Swing-related > functions (GLJPanel, specifically) do not work, but everything > else seems > to be fine. I'm running Mac OS 10.1. I was under the impression > that Swing > should work OK on 2.7.2, but maybe it's a Mac OS 10.1 problem? > > Is Gerard Ziemski on this list? I'd like to rebuild GL4Java for > Mac OS X > to the latest version, but I might need a little bit of assistance. |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-12 19:09:36
|
Please send all questions to the usergroup list. > Do you use an IDE for Java, and if so which one? Historically > I've used emaces and the command line, but since I've used > Visual Studio from microsoft for the last couple of years I've > grown quite fond if the integrated debugger and class browser > and such. I've tried most of the free java IDE's that run on > linux but none of them feel very good. I personally currently use emacs and javac. Based on personal experience and others' recommendations I'd recommend first JBuilder and CodeGuide. I've also used Forte for Java and Visual Cafe in the past; VC had a fast Java compiler (written in C rather than Java, unfortunately) and a fairly good debugger. Forte for Java was not bad, but I had trouble figuring out how to run under the debugger in the early version I used. This has probably improved in recent versions. |
|
From: Joe <jo...@mo...> - 2002-01-11 22:58:08
|
Hey all, I'm having some problems with the latest version of the Mac OS X GL4Java build (on Gerard Ziemski's site) which is version 2.7.2.0. Swing-related functions (GLJPanel, specifically) do not work, but everything else seems to be fine. I'm running Mac OS 10.1. I was under the impression that Swing should work OK on 2.7.2, but maybe it's a Mac OS 10.1 problem? Is Gerard Ziemski on this list? I'd like to rebuild GL4Java for Mac OS X to the latest version, but I might need a little bit of assistance. |
|
From: Kenneth B. R. <kbr...@al...> - 2002-01-11 03:07:42
|
Quick point: it is illegal to return from a native method when you have called Get*Critical but without calling the succeeding Release*Critical. > From: Pepijn Van Eeckhoudt <pep...@lu...> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 > X-Accept-Language: en-us > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > X-Loop-Detect: 1 > Sender: gl4...@li... > Errors-To: gl4...@li... > X-BeenThere: gl4...@li... > X-Mailman-Version: 2.0.5 > Precedence: bulk > List-Help: <mailto:gl4...@li...?subject=help> > List-Post: <mailto:gl4...@li...> > List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup>, > <mailto:gl4...@li...?subject=subscribe> > List-Id: <gl4java-usergroup.lists.sourceforge.net> > List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup>, > <mailto:gl4...@li...?subject=unsubscribe> > List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=gl4java-usergroup> > X-Original-Date: Thu, 10 Jan 2002 11:19:25 +0100 > Date: Thu, 10 Jan 2002 11:19:25 +0100 > > That's exactly what i had in mind for the non buffer stuff. > > Pepijn Van Eeckhoudt > > Sven Goethel wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wednesday 09 January 2002 11:43, Pepijn Van Eeckhoudt wrote: > > > >>Sorry 'bout the reply to the repy to the digest ;) > >> > >>I agree that NIO buffers are the way to go, but in the case of my > >>application pre jdk 1.4 compatibility is required, so this should work > >>correctly as well. > >> > >> > > > > ok, so for the pre 1.3 aera, > > we may use the older non CriticalArray function or/and > > do not release the GC lock within the native function stub .. > > > > later, the kinda END function can then relase the lock .. > > > > ok ? > > > > cheers, sven > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.6 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE8PCqIHdOA30NoFAARAquxAJ47ez1soIMt9lv/HoZdmGIKEEn/OwCfXmv8 > > 0U9WG7fJucQ0NAWP2LQmU0E= > > =VSxh > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > gl4java-usergroup mailing list > > gl4...@li... > > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > > > > > > > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup |
|
From: Sven G. <sgo...@ja...> - 2002-01-10 21:48:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 10 January 2002 18:07, Andy wrote: > Just a quick question - is it OK to include the GL4Java jar files and > DLL files in a zip file? > > If it is, I'm assuming that the readme files and license files should > also be included. > of course, regarding the LGPL, it _is_ ! mention the usage of GL4Java (e.g. including a readme, license, etc.) is nice - thx. but be sure, that offering a kinda changes _within_ gl4java, needs to offer such changes as source code also, regarding the LGPL ! > Andy > cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PgwpHdOA30NoFAARAjIBAKCZxdB3hIkmrllCIX1ZtS0KqO4MzACeL64Y nEM2fM+L7WIOSzJsPDAFtic= =T23e -----END PGP SIGNATURE----- |
|
From: Marcel R. <mr...@em...> - 2002-01-10 19:47:02
|
Hi Sven, Found it... I should have read the FAQ closer :-( With "GLAnimCanvas" and "GLCanvas" it runs "GeForce2 GTS/AGP/3DNOW!" from "NVIDIA Corporation". With "GLAnimJPanel" and "GLJPanel" it runs "GDI Generic" from "Microsoft Corporation". The swing implementation has to work "behind the screen" and cannot use hardware acceleration. This is covered in item "GLAnimCanvas vs GLJPanel, which should I choose ?" in the FAQ, which I, like I said, should have read closer... Marcel Romijn ----- Original Message ----- From: "Sven Goethel" <sgo...@ja...> To: "Marcel Romijn" <mr...@em...>; "gl4java-usergroup" <gl4...@li...> Sent: Thursday, January 10, 2002 8:04 AM Subject: Re: [gl4java-usergroup] Re: Software rendering, no hardware acceleration? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 09 January 2002 23:37, Marcel Romijn wrote: > > Hello Sven, > > > > This really is an interesting problem.... :-) > > > > I have one "opengl32.dll" on my system (which is Windows XP Professional) > > and it is located in "C:\WINNT\system32\opengl32.dll". > > I have an ASUS 7700 card and I'm using the NVidia Detonator drivers. > > > > Running my port of NeHe lesson 8, with a strategic println(), the > > "GL_VENDOR" is "Microsoft" and the "GL_RENDERER" is "GDI Generic". > > However, running from the same location, with the same JVM, the "java > > gl4java.GLContext -info", I get: > > > > <snip> > > Java Virtual Machine: Version 1.3.1_01 (1.3), Vendor: Sun Microsystems Inc. > > > > OpenGL - Versions > > ----------------------------------------------- > > GL VENDOR: NVIDIA Corporation > > GL RENDERER: GeForce2 GTS/AGP/3DNOW! > > GL VERSION: 1.3.0 > > <snip> > > > > Surprise, surprise... "NVIDIA" :-) > > > > In situations like this, I'd like to get to the bottom of it. > > > > very funny .. > > as you might know, i do not know win xp ;-) > > > So I'll dive into this in the (very) near future. > > I will keep you (and the maillinglist) posted. > > > > cool, thx. > > > Oh, BTW. I see that with the NeHe lessons, that Darren Hodges has a number > > of Java ports on his site. Is it safe to assume that lesson 13 to 15, > > lesson 17 and all lessons above 20 have not been ported to Java? > > > > well look at the nehe ports within the gl4java demo's and on hodge's site > > then you know what's missing .. > > right ! > > > Marcel Romijn. > > > > cheers, sven > - -- > health & wealth > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440 ; fax : +49-521-2399442 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8PT0OHdOA30NoFAARAiopAKCKbLQdXaQwV5HsIVNF8hUVAWq+MACgqVP7 > SGII0MmY5jVyieMD4YRmjG0= > =rRmU > -----END PGP SIGNATURE----- |
|
From: Andy <and...@bi...> - 2002-01-10 17:23:53
|
Just a quick question - is it OK to include the GL4Java jar files and DLL files in a zip file? If it is, I'm assuming that the readme files and license files should also be included. Andy |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-10 10:19:39
|
That's exactly what i had in mind for the non buffer stuff. Pepijn Van Eeckhoudt Sven Goethel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 09 January 2002 11:43, Pepijn Van Eeckhoudt wrote: > >>Sorry 'bout the reply to the repy to the digest ;) >> >>I agree that NIO buffers are the way to go, but in the case of my >>application pre jdk 1.4 compatibility is required, so this should work >>correctly as well. >> >> > > ok, so for the pre 1.3 aera, > we may use the older non CriticalArray function or/and > do not release the GC lock within the native function stub .. > > later, the kinda END function can then relase the lock .. > > ok ? > > cheers, sven > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8PCqIHdOA30NoFAARAquxAJ47ez1soIMt9lv/HoZdmGIKEEn/OwCfXmv8 > 0U9WG7fJucQ0NAWP2LQmU0E= > =VSxh > -----END PGP SIGNATURE----- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-10 10:18:36
|
I noticed that only one set of callback functions can currently be defined per context. I have made a simple fix for this. (Only tested with the tesselators, not yet with quadrics and nurbs but should work as well). I've changed the following: 1. Added a void pointer curCbObj to GLCallbackHelperJNI.c 2. FindCallBackNode now also checks if cbn->this->cb_obj!=curCbObj 3. Every glu tesselation function sets the curCbObj to the value that it receives as a parameter. Does this sound like a good fix? Pepijn Van Eeckhoudt |
|
From: Sven G. <sgo...@ja...> - 2002-01-10 07:04:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 January 2002 23:37, Marcel Romijn wrote: > Hello Sven, > > This really is an interesting problem.... :-) > > I have one "opengl32.dll" on my system (which is Windows XP Professional) > and it is located in "C:\WINNT\system32\opengl32.dll". > I have an ASUS 7700 card and I'm using the NVidia Detonator drivers. > > Running my port of NeHe lesson 8, with a strategic println(), the > "GL_VENDOR" is "Microsoft" and the "GL_RENDERER" is "GDI Generic". > However, running from the same location, with the same JVM, the "java > gl4java.GLContext -info", I get: > > <snip> > Java Virtual Machine: Version 1.3.1_01 (1.3), Vendor: Sun Microsystems Inc. > > OpenGL - Versions > ----------------------------------------------- > GL VENDOR: NVIDIA Corporation > GL RENDERER: GeForce2 GTS/AGP/3DNOW! > GL VERSION: 1.3.0 <snip> > > Surprise, surprise... "NVIDIA" :-) > > In situations like this, I'd like to get to the bottom of it. > very funny .. as you might know, i do not know win xp ;-) > So I'll dive into this in the (very) near future. > I will keep you (and the maillinglist) posted. > cool, thx. > Oh, BTW. I see that with the NeHe lessons, that Darren Hodges has a number > of Java ports on his site. Is it safe to assume that lesson 13 to 15, > lesson 17 and all lessons above 20 have not been ported to Java? > well look at the nehe ports within the gl4java demo's and on hodge's site then you know what's missing .. right ! > Marcel Romijn. > cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PT0OHdOA30NoFAARAiopAKCKbLQdXaQwV5HsIVNF8hUVAWq+MACgqVP7 SGII0MmY5jVyieMD4YRmjG0= =rRmU -----END PGP SIGNATURE----- |
|
From: Marcel R. <mr...@em...> - 2002-01-09 23:38:44
|
Hello Sven, This really is an interesting problem.... :-) I have one "opengl32.dll" on my system (which is Windows XP Professional) and it is located in "C:\WINNT\system32\opengl32.dll". I have an ASUS 7700 card and I'm using the NVidia Detonator drivers. Running my port of NeHe lesson 8, with a strategic println(), the "GL_VENDOR" is "Microsoft" and the "GL_RENDERER" is "GDI Generic". However, running from the same location, with the same JVM, the "java gl4java.GLContext -info", I get: <snip> Java Virtual Machine: Version 1.3.1_01 (1.3), Vendor: Sun Microsystems Inc. OpenGL - Versions ----------------------------------------------- GL VENDOR: NVIDIA Corporation GL RENDERER: GeForce2 GTS/AGP/3DNOW! GL VERSION: 1.3.0 GL EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_S3_s3tc GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_cube_map GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_vertex_weighting GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_evaluators GL_NV_fence GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_packed_depth_stencil GL_NV_register_combiners GL_NV_texgen_emboss GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_lod GL_WIN_swap_hint WGL_EXT_swap_control GLU VERSION: 1.2.2.0 Microsoft Corporation GLU EXTENSIONS: GL_EXT_bgra </snip> Surprise, surprise... "NVIDIA" :-) In situations like this, I'd like to get to the bottom of it. So I'll dive into this in the (very) near future. I will keep you (and the maillinglist) posted. Oh, BTW. I see that with the NeHe lessons, that Darren Hodges has a number of Java ports on his site. Is it safe to assume that lesson 13 to 15, lesson 17 and all lessons above 20 have not been ported to Java? Marcel Romijn. ----- Original Message ----- From: "Sven Goethel" <sgo...@ja...> To: "Marcel Romijn" <mr...@em...>; "gl4java-usergroup" <gl4...@li...> Sent: Wednesday, January 09, 2002 6:10 AM Subject: Re: Software rendering, no hardware acceleration? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 31 December 2001 12:00, Marcel Romijn wrote: > > Hello, > > > > I've been looking at the GL4Java implementation to use OpenGL in Java. > > > > To learn it, I've ported the NeHe lesson 1 through 8 in Java. > > did you port other lessons than allready ported ? > if so, please mail the sources (zip, bzip2) - thx > > > This all > > works nice, but I noticed that drawing gets slower as my window size > > increases. So I printed out 'gl.glGetString( gl.GL_RENDERER )' and > > 'gl.glGetString( gl.GL_VENDOR )'. They return "GDI Generic" and "Microsoft > > Corporation" respectively. This means that the software rendering of > > Windows is used. > > do a "java gl4java.GLContext -info" > > RTFM -> read the FAQ ;-) > > > > > When I run the NeHe lessons, compiled in C++, they all run very fast, > > independent of the window size (when running windowed and not full-screen). > > So no problem with the hardware acceleration. > > > > Is there a reason why GL4Java end up with the software rendering? > > i do not know .. > > GL4Java does load the opengl32.dll (i guess thats the name ;-), > within the default location. > > so, if you do have installed an opengl ICD, e.g. nvidia's detonator etc., > it is hw accelerated automatically, and you should see the vendors id .. > > but - if you have linked an alternated GL dll to your c++ nehe lessons, > you need to tell GL4Java which one you need .. > > have a look at CHANGES.txt: > > <snip> > 5th April 2001 (Version 2.7.0 - Release 0 ) > <snip> > o It is now possible to specify/switch the gl/glu lib's at runtime !! > > E.g. the classes > "gl4java.GLContext", > "gl4java.utils.Test" > (you better use the one within the demos/MiscDemos > directory just called Test) > now takes the arguments: > "-GLLib <name>" and > "-GLULib <name>" > to specify the OpenGL and GLU library which should be used !! > > You can also switch to another GL/GLU set of libraries, > while just calling gl4java.GLContext.gljFetchGLFunctions(...), > with force:=true ! > But be shure that no GLContext is alive ;-) > > Last but not least, you can use gltool's feature of > specifying the GL/GLU library names by the systems > environment variables: > GLTOOL_USE_GLLIB - OpenGL library name > GLTOOL_USE_GLULIB - GLU library name > these environment variables does _always_ overrides > any given ones from the java side ! > <snip> > > just give the later solution a try, if you do not use an ICD .., > or install your non-ICD opengl dll (with the name opengl32.dll) > to your: > - current directory, or > - to the default system[32] directory .. > but be sure, the opengl32.dll you want to use should/must contain > at least the std. opengl 1.1 function set, otherwise it is very useless. > > remind: all opengl function (-pointers) are fetched automagically > from the opengl dll. > > if any function is not implemented within the dll, > the application will _not_ crash, just nothing happens then ! > > > > > Thanks in advance, > > Marcel Romijn > > I hope this helps, because this is for general purpose, > I fwd'ed this Q to the mailinglist - later we will add it to the FAQ !! > > please use the mailinglist for further questions ! > > cheers, sven > - -- > health & wealth > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440 ; fax : +49-521-2399442 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8O9DDHdOA30NoFAARAuGKAKC/N1YcsJwojh14NADOm36Ic9VJFACfTjQ3 > uD3VtvEZ/kerYLpbY8UzU7I= > =6049 > -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 11:33:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 January 2002 11:43, Pepijn Van Eeckhoudt wrote: > Sorry 'bout the reply to the repy to the digest ;) > > I agree that NIO buffers are the way to go, but in the case of my > application pre jdk 1.4 compatibility is required, so this should work > correctly as well. > ok, so for the pre 1.3 aera, we may use the older non CriticalArray function or/and do not release the GC lock within the native function stub .. later, the kinda END function can then relase the lock .. ok ? cheers, sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PCqIHdOA30NoFAARAquxAJ47ez1soIMt9lv/HoZdmGIKEEn/OwCfXmv8 0U9WG7fJucQ0NAWP2LQmU0E= =VSxh -----END PGP SIGNATURE----- |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-09 10:55:54
|
Sorry if i wasn't clear. In the makefile in the C2J directory there are rules like: ../CNativeCode/OpenGLU_JauJNI_funcs.c: C2J.class \ warning.skel \ ../CNativeCode/OpenGLU_funcs.c.skel \ manual/glu-manualCodedImplJNI.c \ glu-proto-auto.c cat warning.skel \ ../CNativeCode/OpenGLU_funcs.c.skel \ manual/glu-manualCodedImplJNI.c \ glu-proto-auto.c \ > ../CNativeCode/OpenGLU_JauJNI_funcs.c Which cats the C2J generated file (glu-proto-auto.c) and the manual file (glu-manualCodedImplJNI.c) together. The auto generated file however already contains an implementation for a lot of glu functions (for instance "JNIEXPORT void JNICALL Java_gl4java_GLUFuncJauJNI_gluTessVertex__J_3D_3B"). If I put a manually coded implementation for this function in glu-manualCodedImplJNI.c, then the cat'ed file has two implementations of the function in it. Is there a way to do this correctly or do am I mistaken somewhere? Pepijn Van Eeckhoudt Sven Goethel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 09 January 2002 10:42, Pepijn Van Eeckhoudt wrote: > >>If I wanted to change the native code for a standard opengl function >>(for instance the glu tesselator stuff), is it enough to add my own >>implementations to the files in C2J\manual. >> > > YES > > please read my latest explanation I send to the mailinglist, see below .. > > >>From the makefile it seems >>like the auto generated stuff is put together with the manual file using >>cat, so I assume you would have a duplicate function declaration then. >> > > where is the duplicate ? > > nono, it just depends on your point of view. > > for me, the generated sources (C2J'ed and cat'ed) > placed to gl4java/ and CNativeCode/ are not kinda temporaery files .. > > the true sources within C2J/manual, e.g. for gl4java/GLUFunc14JauJNI.java, > are the origin ones ! > > or may be i misunderstood you, so please gimme more details ! > > >>Or did I miss something? If I'm correct, then how sould I add a manual >>implementation for a gl function? >> > > like i mentions before (see below) .. > > >>Pepijn Van Eeckhoudt >> >>Sven Goethel wrote: >> > > <snip> > >>>you can find such manual codes within the GL4Java/C2J/manual directory ! >>> >>>then we need some new functions within the: >>> gl4java/GLUFunc14.java (interface) >>> C2J/manual/glu-manualCodedVirt-14.java (manual part) >>> >>> gl4java/GLUFunc14JauJNI.java (implementation - JNI declarations and >>>stubs ..) C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) >>> >>> CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) >>> C2J/manual/glu-manualCodedImplJNI14.c (manual part) >>> >>>just have a look - and understand, how it is done within the >>>manual GLFunc14* counterpart of the NV extension ..: >>> >>>GL4Java/C2J/manual: >>> gl-manualCodedImplJNI1-14.java gl-manualCodedImplJNI14.c >>>gl-manualCodedVirt1-14.java >>> >>>we might want to make the memory managment functions more general >>>purpose, so we can use them for e.g. (as you suggested) >>> - glTessVertex >>> - we should create a native NIO buffer which will be used .., >>> straight outta the java application, >>> or by a new general purpose GL4Java utility function .. >>> >>> - all passed NIO buffers might be freed by the glTessEndPolygon >>>function or by another one .. if allocated by a GL4Java utility function >>> >>> - glTessEndPolygon >>> - might free all passed NIO buffers, if allocated by a GL4Java utility >>>function >>> >>>so this little concept - please review and make it more clean RFC .., >>>might be introduced to all OpenGL functions which handles a big amount of >>>data, e.g. textures etc., where the JVM's GC might moves or cleans the >>>memory .. >>> >>>cheers, sven >>> > > - -- > health & wealth > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440 ; fax : +49-521-2399442 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8PBoRHdOA30NoFAARAmZZAJwMEFkRHaVBqEmK3AA2MaTOtVT9KgCgkVO+ > 84T+4Y0FCr02cRS8HIjAAWQ= > =dMkU > -----END PGP SIGNATURE----- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-09 10:43:45
|
Sorry 'bout the reply to the repy to the digest ;) I agree that NIO buffers are the way to go, but in the case of my application pre jdk 1.4 compatibility is required, so this should work correctly as well. Pepijn Van Eeckhoudt Sven Goethel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1st of all, PLEASE REPLY TO THE POSTINGS ITSELF, > not the digest - so it is more easy to find such archived emails ;-) > > QUESTION: how can we setup the mailinglist, so the REPLY-TO field is set .. ? > > On Wednesday 09 January 2002 10:39, Pepijn Van Eeckhoudt wrote: > > >>1. It depends on where you keep the pointer, in java or in c. If you >>keep a pointer in java it won't make any difference. I'm working on >>keeping a pointer in the c code. (or at least trying ;)) >> > <snip> > >>What is necessary to fix this is to keep a >>native copy of the data and use a pointer to this native copy instead of >> a pointer to the java object. This raises the problem of finding the >>right time to free the native copy. >> >>2. This would work (I think) , but creating a display list for code that >>runs only once seems like unnecessary overhead. Also this is just a >>workaround. What I'm looking for is a way to fix the problem, so you >>don't need workarounds. The opengl code by itslef is correct so (imho) >>it should work with gl4java without workarounds. >> > > well, but we should use the new NIO buffers, > which solves all such issues for Java 1.4 !! > > so please mention and anticipate my latest suggestions > and help developing it straight forward to offer a quiet nice > solution .. > > i guess this is better than an ugly kinda workaround or manual > extra array-copy .. > > cheers, sven > - -- > health & wealth > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440 ; fax : +49-521-2399442 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8PBvFHdOA30NoFAARAh0MAKCDrY7mb1TYlD9dX+y8pnTrkVZDaACeLfqm > cpteDQX4JbbWbqzqe53NBzQ= > =pl7y > -----END PGP SIGNATURE----- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 10:30:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1st of all, PLEASE REPLY TO THE POSTINGS ITSELF, not the digest - so it is more easy to find such archived emails ;-) QUESTION: how can we setup the mailinglist, so the REPLY-TO field is set .. ? On Wednesday 09 January 2002 10:39, Pepijn Van Eeckhoudt wrote: > 1. It depends on where you keep the pointer, in java or in c. If you > keep a pointer in java it won't make any difference. I'm working on > keeping a pointer in the c code. (or at least trying ;)) <snip> > What is necessary to fix this is to keep a > native copy of the data and use a pointer to this native copy instead of > a pointer to the java object. This raises the problem of finding the > right time to free the native copy. > > 2. This would work (I think) , but creating a display list for code that > runs only once seems like unnecessary overhead. Also this is just a > workaround. What I'm looking for is a way to fix the problem, so you > don't need workarounds. The opengl code by itslef is correct so (imho) > it should work with gl4java without workarounds. well, but we should use the new NIO buffers, which solves all such issues for Java 1.4 !! so please mention and anticipate my latest suggestions and help developing it straight forward to offer a quiet nice solution .. i guess this is better than an ugly kinda workaround or manual extra array-copy .. cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PBvFHdOA30NoFAARAh0MAKCDrY7mb1TYlD9dX+y8pnTrkVZDaACeLfqm cpteDQX4JbbWbqzqe53NBzQ= =pl7y -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2002-01-09 10:23:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 January 2002 10:42, Pepijn Van Eeckhoudt wrote: > If I wanted to change the native code for a standard opengl function > (for instance the glu tesselator stuff), is it enough to add my own > implementations to the files in C2J\manual. YES please read my latest explanation I send to the mailinglist, see below .. > From the makefile it seems > like the auto generated stuff is put together with the manual file using > cat, so I assume you would have a duplicate function declaration then. where is the duplicate ? nono, it just depends on your point of view. for me, the generated sources (C2J'ed and cat'ed) placed to gl4java/ and CNativeCode/ are not kinda temporaery files .. the true sources within C2J/manual, e.g. for gl4java/GLUFunc14JauJNI.java, are the origin ones ! or may be i misunderstood you, so please gimme more details ! > Or did I miss something? If I'm correct, then how sould I add a manual > implementation for a gl function? like i mentions before (see below) .. > > Pepijn Van Eeckhoudt > > Sven Goethel wrote: <snip> > > you can find such manual codes within the GL4Java/C2J/manual directory ! > > > > then we need some new functions within the: > > gl4java/GLUFunc14.java (interface) > > C2J/manual/glu-manualCodedVirt-14.java (manual part) > > > > gl4java/GLUFunc14JauJNI.java (implementation - JNI declarations and > > stubs ..) C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) > > > > CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) > > C2J/manual/glu-manualCodedImplJNI14.c (manual part) > > > > just have a look - and understand, how it is done within the > > manual GLFunc14* counterpart of the NV extension ..: > > > > GL4Java/C2J/manual: > > gl-manualCodedImplJNI1-14.java gl-manualCodedImplJNI14.c > > gl-manualCodedVirt1-14.java > > > > we might want to make the memory managment functions more general > > purpose, so we can use them for e.g. (as you suggested) > > - glTessVertex > > - we should create a native NIO buffer which will be used .., > > straight outta the java application, > > or by a new general purpose GL4Java utility function .. > > > > - all passed NIO buffers might be freed by the glTessEndPolygon > > function or by another one .. if allocated by a GL4Java utility function > > > > - glTessEndPolygon > > - might free all passed NIO buffers, if allocated by a GL4Java utility > > function > > > > so this little concept - please review and make it more clean RFC .., > > might be introduced to all OpenGL functions which handles a big amount of > > data, e.g. textures etc., where the JVM's GC might moves or cleans the > > memory .. > > > > cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PBoRHdOA30NoFAARAmZZAJwMEFkRHaVBqEmK3AA2MaTOtVT9KgCgkVO+ 84T+4Y0FCr02cRS8HIjAAWQ= =dMkU -----END PGP SIGNATURE----- |
787 messages has been excluded from this view by a project administrator.
