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: Jean-Yves B. <jea...@wa...> - 2000-07-25 02:28:14
|
Hello dear gl4 users. I try desesperately to read the FRONT buffer and save it in tga file, on my macIntosh G4. I join a small program that show the problem very well : 1. I make two different drawings in FRONT and BACK buffer. 2. Then I save the content of each buffer on two different files: "back.tga" and "front.tga". On windows (jdk 1.2.2), the result is OK: the content of each file are different. On macintosh, the contents of the files are identical and represent the BACK BUFFER contents !!! NB: I use GL4 2.3.1.0 It is a dead problem for my projet. Thank you for any idea. Jean-Yves. Hope all the users are not on the beach !!! -- -------------------------------------- Jean-Yves BRUD POLYQUARK - Ingenierie & Creation 3D Palahou - 31330 LARRA France Tel: 05.62.79.03.33 Fax: 05.62.79.03.38 Mail: jea...@wa... -------------------------------------- |
|
From: Artiste on t. W. <a1...@So...> - 2000-07-21 16:18:59
|
Stuart Fischer wrote:
> > I have discover that the multi-threading can slow down the rendering !
> > Java may wait before really doing the rendering in the rendering thread,
> > and may coalesce rendering. Each frame in my game, i call a rendering,
> > but java coalesce them and i have only 1 real rendering for about 30-60
> > frames...
> Maybe I don't understand your problem, but I don't know if it is related to
> multithreading.
>
> Are you calling repaint() once per frame in your game loop and calling
> sDisplay() in your paint() (or update()) method?
>
> If so, Java WILL coalesce rendering.
>
> If this describes your situation, call sDisplay() instead of repaint() in
> your game loop.
It is OK ! Thanks !
My FPS was about 7 and now it has risen to more than 100 !!!
> Simple example:
>
> public class Game extends GLCanvas implements Runnable {
> boolean gameOver = false;
>
> public void run() {
> while(!gameOver) {
> updateGameStateForFrame();
> sDisplay(); // DON'T call repaint()!
> }
> }
>
> public void paint(Graphics g) {
> sDisplay();
> }
(I can't do this because paint is final in GLCanvas)
> // REST OF Game Class (display()...) goes here
> }
>
> Stuart
A11W
|
|
From: <ar...@di...> - 2000-07-21 10:12:08
|
plz UNsubscribe me from this mailing list ----------------------------------------- Arnar Thor Jensson - ar...@di... Dimon Software - www.dimon.is ----------------------------------------- |--------+---------------------------------------------> | | gl4...@li...urc| | | eforge.net | | | | | | 07/20/2000 19:08 | | | Please respond to gl4java-usergroup| | | | |--------+---------------------------------------------> >----------------------------------------------------------------------------------------------------------------| | | | To: gl4...@li... | | cc: | | Subject: gl4java-usergroup digest, Vol 1 #105 - 4 msgs | >----------------------------------------------------------------------------------------------------------------| Send gl4java-usergroup mailing list submissions to gl4...@li... To subscribe or unsubscribe via the web, visit http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup or, via email, send a message with subject or body 'help' to gl4...@li... You can reach the person managing the list at gl4...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of gl4java-usergroup digest..." Today's Topics: 1. Re: gl functions taking a reference to data, not used till later (Sven Goethel) 2. Profiling (Ben Hesketh) 3. About speed ! (Artiste on the Web) --__--__-- Message: 1 Date: Thu, 20 Jul 2000 03:12:07 +0200 From: Sven Goethel <sgo...@ja...> Organization: Jausoft - Sven Goethel Software Development To: Stuart Fischer <st...@de...> CC: gl4...@li... Subject: Re: [gl4java-usergroup] gl functions taking a reference to data, not used till later Thanx ya all - for your reply ! I just started to analyze the different JVM's (IBM118, IBM13, SUN12, SUN13, ...) - under linux, with the upcoming GL4Java 4.0.1 (just a stabilisation, little new stuff) ! It looks, that the most JVM's uses the pinning method, no COPY ! But the beta version of SUN's JVM 1.3 uses the COPY method for JNI/JAVA arrays a lot :-( ! May be we can add some special client-side state handling later ... Yours, Sven BTW: I do now check the other bug announcments, be patience - please. Stuart Fischer wrote: > > > Are there any other GL functions, > > behave like gl*Pointer (Vertex, Color, ... ?) ! > > Meaning - take a reference of data, and use the data later ? > > (Later means, use the data after return from the function !) > > I think these two match the description: > > glSelectBuffer(int size, int[] buffer); > glFeedbackBuffer(int size, int type, float[] buffer); > > Stuart > > > Where we are not allowed to release the data before > > the usage is finished ? > > > > Please send those function collection to this mailinglist, > > so I can implement the special behavior for these types ! > > > > Thanxs a lot ! > > > > Sven > > -- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup -- 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 --__--__-- Message: 2 From: "Ben Hesketh" <jb...@ho...> To: gl4...@li... Date: Thu, 20 Jul 2000 10:27:44 GMT Subject: [gl4java-usergroup] Profiling Hi, Has anybody else run the JDK1.3 profiler over there code? I did and discovered that the AWT-Event thread (which seemed to contain all my methods) was spending a whooping 85% of its time in glGetError()! Is this a nasty bug in my code or don't I properly understand how gl4java works? Cheers in advance, BEN ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com --__--__-- Message: 3 Date: Thu, 20 Jul 2000 19:31:54 +0200 From: Artiste on the Web <a1...@So...> To: gl4...@li... Subject: [gl4java-usergroup] About speed ! I'm starting a game with GL4Java, and I need a lot of speed ! I have discover that the multi-threading can slow down the rendering ! Java may wait before really doing the rendering in the rendering thread, and may coalesce rendering. Each frame in my game, i call a rendering, but java coalesce them and i have only 1 real rendering for about 30-60 frames... So what is the best method to do "immediate" (= non multi-threaded) rendering ? Should i just call the display method ? Or is it better to keep the multi-threading, but to wait until the rendering is finish ? I think adding such a method in GL4Java can be very interesting, for all who need speed ! Artiste on the Web --__--__-- _______________________________________________ gl4java-usergroup mailing list gl4...@li... http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup End of gl4java-usergroup Digest |
|
From: Stuart F. <st...@de...> - 2000-07-21 01:49:35
|
> I have discover that the multi-threading can slow down the rendering !
> Java may wait before really doing the rendering in the rendering thread,
> and may coalesce rendering. Each frame in my game, i call a rendering,
> but java coalesce them and i have only 1 real rendering for about 30-60
> frames...
Maybe I don't understand your problem, but I don't know if it is related to
multithreading.
Are you calling repaint() once per frame in your game loop and calling
sDisplay() in your paint() (or update()) method?
If so, Java WILL coalesce rendering.
If this describes your situation, call sDisplay() instead of repaint() in
your game loop.
Simple example:
public class Game extends GLCanvas implements Runnable {
boolean gameOver = false;
public void run() {
while(!gameOver) {
updateGameStateForFrame();
sDisplay(); // DON'T call repaint()!
}
}
public void paint(Graphics g) {
sDisplay();
}
// REST OF Game Class (display()...) goes here
}
Stuart
|
|
From: Artiste on t. W. <a1...@So...> - 2000-07-20 17:37:36
|
I'm starting a game with GL4Java, and I need a lot of speed ! I have discover that the multi-threading can slow down the rendering ! Java may wait before really doing the rendering in the rendering thread, and may coalesce rendering. Each frame in my game, i call a rendering, but java coalesce them and i have only 1 real rendering for about 30-60 frames... So what is the best method to do "immediate" (= non multi-threaded) rendering ? Should i just call the display method ? Or is it better to keep the multi-threading, but to wait until the rendering is finish ? I think adding such a method in GL4Java can be very interesting, for all who need speed ! Artiste on the Web |
|
From: Ben H. <jb...@ho...> - 2000-07-20 10:28:14
|
Hi, Has anybody else run the JDK1.3 profiler over there code? I did and discovered that the AWT-Event thread (which seemed to contain all my methods) was spending a whooping 85% of its time in glGetError()! Is this a nasty bug in my code or don't I properly understand how gl4java works? Cheers in advance, BEN ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com |
|
From: Sven G. <sgo...@ja...> - 2000-07-20 01:12:42
|
Thanx ya all - for your reply ! I just started to analyze the different JVM's (IBM118, IBM13, SUN12, SUN13, ...) - under linux, with the upcoming GL4Java 4.0.1 (just a stabilisation, little new stuff) ! It looks, that the most JVM's uses the pinning method, no COPY ! But the beta version of SUN's JVM 1.3 uses the COPY method for JNI/JAVA arrays a lot :-( ! May be we can add some special client-side state handling later ... Yours, Sven BTW: I do now check the other bug announcments, be patience - please. Stuart Fischer wrote: > > > Are there any other GL functions, > > behave like gl*Pointer (Vertex, Color, ... ?) ! > > Meaning - take a reference of data, and use the data later ? > > (Later means, use the data after return from the function !) > > I think these two match the description: > > glSelectBuffer(int size, int[] buffer); > glFeedbackBuffer(int size, int type, float[] buffer); > > Stuart > > > Where we are not allowed to release the data before > > the usage is finished ? > > > > Please send those function collection to this mailinglist, > > so I can implement the special behavior for these types ! > > > > Thanxs a lot ! > > > > Sven > > -- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup -- 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 |
|
From: Stuart F. <st...@de...> - 2000-07-18 06:48:57
|
> Are there any other GL functions,
> behave like gl*Pointer (Vertex, Color, ... ?) !
> Meaning - take a reference of data, and use the data later ?
> (Later means, use the data after return from the function !)
I think these two match the description:
glSelectBuffer(int size, int[] buffer);
glFeedbackBuffer(int size, int type, float[] buffer);
Stuart
> Where we are not allowed to release the data before
> the usage is finished ?
>
> Please send those function collection to this mailinglist,
> so I can implement the special behavior for these types !
>
> Thanxs a lot !
>
> Sven
> --
|
|
From: Artiste on t. W. <a1...@So...> - 2000-07-12 10:24:58
|
Rob Grzywinski wrote: > I am using MSJVM v5.00.3167 under Win95 and I just > upgraded to GL4Java2.4.0.0. My application, which > uses display lists extensively, now displays all > objects as if their 1st coordinate was at infinity (so > all objects have an infinite line shooting out from > them). Also selection against any object causes an > invalid page fault in module MSJAVA.DLL. I'm working > to isolate the problem and post the code, but I wanted > to get the word out to see if anyone else has a > similar problem. > > Rob Grzywinski > rgr...@ya... I have a similar problem with the jdk 1.3 (version beta) from sun on Linux. The problem is also due to vertex (and other) arrays; the last (or the first ?) point of the array is strangely displayed (maybe like Rob : as if one coordinate was infinite). Without arrays it's ok. A11W |
|
From: Erwin V. <kl...@fr...> - 2000-07-08 08:26:52
|
> I've got a strange problem with blending in my GL4Java program. > When I have a (GL_ONE, GL_ONE) blend function, there seems to be something > wrong with the dept buffer (look at the screenshot). The model seems to be > drawing on top of itself with all kinds of artefacts showing up. > When I use a (GL_ONE, GL_ZERO) blend function (that is, no blending :-) > everything works fine. > > The strange thing is that I never saw this problem with my old video drivers > (Detonator 3.x), while I do see it with the new Detonator 5.x. > > Does anybody have an idea what might be causing it and how to fix/work > around it. No offense taken by any of your remarks Sven :-) Now, if somebody just could given me some help with this (fingers crossed!).... KLR8 |
|
From: Sven G. <sgo...@ja...> - 2000-07-08 03:04:12
|
Dear mailing list participants, I want to make some rules :-) - Before posting a File >40k, please ask to do so ! - Before posting a File >40k, please ask to do so ! Also, before email me a File >100k, please ask to do so ! - If you have found a error/bug/etc : Email me: - OS vendor/version/name - Architecture (e.g. ppc, intelx86, ...) - OpenGL vendor/version/name - Graphic Card vendor/version/name - Java VM (incl. Browser if necessary) vendor/version/name - .... (what you think is usefull ...) Thanxs a lot ! I hope this will help us a lot ! Yours sincerly, Sven -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Sven G. <sgo...@ja...> - 2000-07-08 02:54:33
|
Dear Erwin, I must apologize, if my last words were to stupid and disrespectful ! So - I am sorry. I want to say this to the public either, because my rude response was to the public either ! Your, Sven -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Sven G. <sgo...@ja...> - 2000-07-06 23:31:25
|
Dear Erwin, you ARE a professional, so please do not send big amount of data unzipped and unasked - please ! Also, a little demo program for validation would me nice too ! I really love your Q3Viewer ! Yours, Sven BTW: Ok, I still have no logo, but just add my jausoft logo with the GL4Java note on your side -- you point to the others either :-) -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Erwin V. <er...@cs...> - 2000-07-06 21:36:30
|
Hello, I've got a strange problem with blending in my GL4Java program. When I have a (GL_ONE, GL_ONE) blend function, there seems to be something wrong with the dept buffer (look at the screenshot). The model seems to be drawing on top of itself with all kinds of artefacts showing up. When I use a (GL_ONE, GL_ZERO) blend function (that is, no blending :-) everything works fine. The strange thing is that I never saw this problem with my old video drivers (Detonator 3.x), while I do see it with the new Detonator 5.x. Does anybody have an idea what might be causing it and how to fix/work around it. Erwin 'KLR8' Vervaet kl...@fr... |
|
From: Sven G. <sgo...@ja...> - 2000-07-06 20:32:45
|
Please read my last email first ! QUESTION: Are there any other GL functions, behave like gl*Pointer (Vertex, Color, ... ?) ! Meaning - take a reference of data, and use the data later ? (Later means, use the data after return from the function !) Where we are not allowed to release the data before the usage is finished ? Please send those function collection to this mailinglist, so I can implement the special behavior for these types ! Thanxs a lot ! Sven -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Sven G. <sgo...@ja...> - 2000-07-06 20:28:54
|
Dear Users, Dear Rob,
I analysed the problem of using VertexPointer (-> Arrays) !
Now, we do have a problem :-)
The semantics of the gl*Pointer methods is,
that the data referenced by the pointer (which is passed to GL as an
argument), is used LATER !
One GL Context hold's the data pointer for each:
- vertex array
- normal array
- color array
- ...
The data's pointer can be hold, after calling
glEnableClientState(GLEnum.GL_VERTEX_ARRAY);
So - at all time, the data, to which the reference points,
must be AVAIABLE till the next call of the appropiate:
glDisableClientState(..)
In GL4Java, we use the following code:
JNIEXPORT void JNICALL
Java_gl4java_GLFuncJauJNInf_glVertexPointer__III_3B (
JNIEnv *env, jobject obj,
jint size,
jint type,
jint stride,
jbyteArray ptr)
{
static void (CALLBACK *__func_ptr__)(GLint, GLenum, GLsizei, const
GLvoid *) = NULL; jbyte *ptr3 = NULL;
if(__func_ptr__==NULL) {
__func_ptr__ =
(void (CALLBACK *)(GLint, GLenum, GLsizei, const GLvoid
*))
getGLProcAddressHelper("glVertexPointer", NULL, 1, 0);
if(__func_ptr__==NULL)
return;
}
if(ptr!=NULL)
{
ptr3 = (*env)->GetByteArrayElements(env, ptr, 0);
}
__func_ptr__ ( (GLint) size, (GLenum) type, (GLsizei)
stride,
(const GLvoid *) ptr3 );
if(ptr!=NULL)
{
(*env)->ReleaseByteArrayElements(env, ptr, ptr3, 0);
}
}
The problem is, that the JVM can implement two ways for accessing
arrays:
- make a copy
- "pinning" - just pass the real pointer
Both methods use a garbage collection lock on the used array !
A JVM, which uses pinning, just passes us the pointer of such an object
!
The GL machine can use the data later - well, if the garbage collector
does not removed the non-locked data (by us) !
Well, if the copy method is used, a horrible scenario exists !
The GL machine accesses data, referenced by the given pointer before,
but the data is de-allocated / freed by the Release call !
The solution is:
IF used the copy method,
for each type (Vertex, Color, ...) AND for each GL-Context:
- not call Release, till:
- a new gl*Pointer call is made
- a glDisableClientState(*) is called
So the data must being hold that long !
IF used the pinning method:
- nothing must be changed ...
But we can use the upper implementation, to be sure,
that the garbage collector has not release the ressources !
Generally, I am currently optimizing the array implementation !
The usage of identifying the method (copy,pinning) and using
this for the Release call (0, JNI_ABORT) !
The redundant call of Set*ArrayRegion is removed now !
This optimisation and bugfix, will be released with
GL4Java 2.4.1 !
Yours, Sven Goethel
Rob Grzywinski wrote:
>
> I am using MSJVM v5.00.3167 under Win95 and I just
> upgraded to GL4Java2.4.0.0. My application, which
> uses display lists extensively, now displays all
> objects as if their 1st coordinate was at infinity (so
> all objects have an infinite line shooting out from
> them). Also selection against any object causes an
> invalid page fault in module MSJAVA.DLL. I'm working
> to isolate the problem and post the code, but I wanted
> to get the word out to see if anyone else has a
> similar problem.
>
> BTW: when I use Sun's JRE1.1.8 on the same machine
> with 2.4.0.0 everything is fine (all objects render as
> they did under 2.3.X.X).
>
> BTW2: yes, I recompiled and restarted the machine :)
>
> Rob Grzywinski
> rgr...@ya...
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup
--
mailto:sgo...@ja...
www : http://www.jausoft.com
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
|
|
From: Max G. <gi...@li...> - 2000-07-05 22:16:14
|
Hi! Updated version of GL4Java FAQ can be found at http://3d.linart.krakow.pl/OfficinaArtificialis/OpenGL/GL4Java-FAQ.html Updated: - added solution to 'GL components doesn't show when adding several of them to a panel' problem - reorganized whole document for better readability (check it!). * If you have solved a problem which solution was hard to find, submit its solution so all GL4Java users can benefit from your knowledge. * FAQ is a document written by users for users, so send your suggestions, fixes, enhancements and questions (preferably with answers ;-) Bye, Max -- Max Gilead (gi...@li...) http://3d.linart.krakow.pl/OfficinaArtificialis ----------------------------------------------------------------------------- |
|
From: Andreas M. <and...@iv...> - 2000-07-05 08:38:35
|
Hi,
On Tue, Jul 04, 2000 at 09:42:40PM -0700, noisebrain wrote:
> RH6.2,
> added Xfree86 4.0.0
> Nvidia Geforce2 chip (Elsa card), using their closed-source driver
> (an expert told me this is the current fastest card for my application)
You are posting faster than me. ;-)
Nevertheless, I got the exact same configuration running here since yesterday.
The performance is amazing (really). Not all OpenGL functionality seems to be
implemented correctly right now, however most things seem to work (including
Alpha-Blending, which is extremely important to us) and the thing runs very
stable so far.
Another configuration that works is Matrox G400 with 3D Accelerated-X from
Xi-Graphics. However, we have not extensively tested this configuration yet.
> Calling thru the latest GL4Java, from several jdks including the
> latest 1.3.
We are still using Java3D with Blackdown JDK1.2.2rc4 or alternatively JDK1.3.0
beta from SUN. Both work.
We have also tested GL4Java, but hope that Java3D is fast enough for our
application, because it is far more easy to cope with.
> Java Swingset and such still run fine but this card does not
> speed up java2d significantly.
Unfortunately. Amongst other things we abuse Java3D for Cross-Fading between
2D components. Does anyone know a better solution (other than JNI)?
bye...
Andreas Micklei
P.s. On the LinuxTag I have seen the new Linux boxes from SGI. SGI claims them
to be roughly eighty percent faster than a normal PC equipped with a GeForce2.
They also have their own drivers. Has anyone tested these?
--
Andreas Micklei
IVISTAR Kommunikationssysteme AG
Ehrenbergstr. 19 / 10245 Berlin
http://www.ivistar.de
|
|
From: noisebrain <zi...@id...> - 2000-07-05 04:47:33
|
Slightly off topic, but I was able to get a opengl card to work under linux and call it successfully from Java. This took about 1.5 days of configuring, between Xfree86 4 and the particular card. The result is dramatically faster for textured renders. Particulars are: RH6.2, added Xfree86 4.0.0 Nvidia Geforce2 chip (Elsa card), using their closed-source driver (an expert told me this is the current fastest card for my application) Calling thru the latest GL4Java, from several jdks including the latest 1.3. Java Swingset and such still run fine but this card does not speed up java2d significantly. |
|
From: Sven G. <sgo...@ja...> - 2000-07-04 22:32:30
|
Dear Jean, please send me a demo piece of code, so I can test it (ZIP, or TGZ format <= 200kByte) ! BTW: Where is your java3d implementation ? New links ? Sorry, I lost it ! Yours, Sven -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Sven G. <sgo...@ja...> - 2000-07-04 22:21:45
|
Jean-Marie ABISROR wrote:
>
>
> Hi,
>
> I Have a big problem in the conception of my programs with gl4java
> (Windows version) :
>
(doesn't care, if it is the dirty win32 os :-)
> I Have a subdirectory opengl in which I want to describe geometrics
> shapes (box,cylinder, etc.).
> In that subdirectory, I have a program named BoxNodeOpenGL.java where
> I have the display() routine for the description of the box.
>
> In the main directory, I have a program where I'd like to call (only
> once) the constructor cvs = new MyCanvas(640,480), in order to be able
> to call display() in BoxNodeOpenGL.class, CylinderNodeOpenGL.class,
> and so on.
>
> Is that possible ? How do you implement this kind of structure ?
> Do I need to use GLAnimCanvas with a thread ?
> If you have an example, please send it ...
> Thank's for your help.
>
> Looking forward to reading from you.
>
>
> Jean-Marie ABISROR
>
>
>
>
Well, I guess you have something like a scenegraph,
a data structure of items, which are renderable !
Just let them implement GLEnum and GLUEnum (just for your convinience),
and design them like:
public interface Node {
protected Node(GLFunc gl, GLUFunc glu);
public void draw();
public void init();
public void tick(long ms);
}
public class LineNode
implements Node, GLEnum, GLUEnum
{
protected LineNode(GLFunc gl, GLFunc glu)
{ save the gl, glu paras. }
public LineNode(GLFunc gl, GLUFunc glu, point p1, point p2)
{ this(gl, glu); save the p1, p2 }
public void init()
{ some initialisations ... }
public void draw()
{ draw from p1 till p2, using gl and glu }
public void tick(long ms)
{ move the element with its behavior to its new place,
assuming that ms milliseconds are passed (speed, vector, ...)
FOR ANIMATION !
}
}
Threads has nothing todo with this design !
Yours, Sven
--
mailto:sgo...@ja...
www : http://www.jausoft.com
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
|
|
From: Sven G. <sgo...@ja...> - 2000-07-04 22:01:59
|
Stuart Fischer wrote:
>
> Is it possible to use OpenGL extensions from GL4Java? ie. multitexture
>
> Stuart
>
Well, the new GL4Java 4.0.0 version does support
many extensions, and GL 1.2 also !
You can query, if the function exists, while calling e.g.:
boolean t = GLContext.gljTextGLProc("glBegin", true /* verbose */);
thats it !
Then you can savely call glBegin() :o),
this works for all supportet OpenGL methods !
If you call the GL4Java wrapper method for an
unimplemented OpenGL function, nothing will happen - safe !
Yours, Sven
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup
--
mailto:sgo...@ja...
www : http://www.jausoft.com
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
|
|
From: Jean-Yves B. <jea...@wa...> - 2000-07-04 15:00:43
|
Hello. I got a problem while using tesselation while HotSpot is enabled on Windows Platform. The problem does'nt appears on Mac platform or on windows with HotSpot disabled. The problem is that the END_CALLBACK is invoqued by OpenGL/GL4 but only few VERTEX_CALLBACK are invoked before, and the hole is not filled. If the tesselation is quite simple, the problem does not occurs! The solution is to disable hotSpot but the java slows down. HotSpot seems to create problem because it compiles in native code. Is there any conflict with OpenGL/GL4 ? Is it the reason and is there any other solution ? Thanxs. -- -------------------------------------- Jean-Yves BRUD POLYQUARK - Ingenierie & Creation 3D Palahou - 31330 LARRA France Tel: 05.62.79.03.33 Fax: 05.62.79.03.38 Mail: jea...@wa... -------------------------------------- |
|
From: Stuart F. <st...@de...> - 2000-07-03 05:59:40
|
Is it possible to use OpenGL extensions from GL4Java? ie. multitexture Stuart |
|
From: Rob G. <rgr...@ya...> - 2000-06-30 21:53:35
|
I am using MSJVM v5.00.3167 under Win95 and I just upgraded to GL4Java2.4.0.0. My application, which uses display lists extensively, now displays all objects as if their 1st coordinate was at infinity (so all objects have an infinite line shooting out from them). Also selection against any object causes an invalid page fault in module MSJAVA.DLL. I'm working to isolate the problem and post the code, but I wanted to get the word out to see if anyone else has a similar problem. BTW: when I use Sun's JRE1.1.8 on the same machine with 2.4.0.0 everything is fine (all objects render as they did under 2.3.X.X). BTW2: yes, I recompiled and restarted the machine :) Rob Grzywinski rgr...@ya... __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ |
787 messages has been excluded from this view by a project administrator.
