Menu
▾
▴
gl4java-usergroup
|
From: Sven G. <sgo...@ja...> - 2000-08-25 13:16:41
|
aNt wrote: > > hopw u are well ? > > but how do i make it use different hardware ? i have a pc with a voodoo card > in it and it uses the shity built in ATI. and on the Mac i wont it to use > software :) to see if the accum buffers work. > > aNt > puhh ... I am not a MAC specialist :-( On Linux and Windows: You have to install the correct OpenGL drivers/libraries you want, e.g. software rendering or hardware rendering, or what else. GL4Java uses the installed OpenGL implementation of your OS. So it is different for every OS, how to switch to a different OpenGL impl. E.g., for Linux, I have tell the OS, to use this libGL.so, I do so, while putting my libGL.so in a directory, which is in the 1st place of the LD_LIBRARY_PATH environment variable. I believe, for Windows, you can put the opengl32.dll library into the working directory, so it is used instead of the one installed under c:\windows\system32 ! For MAC ? I do not know ! You should install the Vodoo OpenGL driver/library properly, so if any OpenGL application uses it, GL4Java will use it too ! You can check the the library which GL4Java uses with: java gl4java.GLContext -info on the command line. 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 |
|
From: aNt <an...@to...> - 2000-08-25 13:44:51
|
what if i just wont to stop it from using hardware. i dont wont my users to have to start removing extentions.. works with the hardware on the mac great at the moment... just wont to turn it off in my final app aNt > aNt wrote: >> >> hopw u are well ? >> >> but how do i make it use different hardware ? i have a pc with a voodoo card >> in it and it uses the shity built in ATI. and on the Mac i wont it to use >> software :) to see if the accum buffers work. >> >> aNt >> > > puhh ... > > I am not a MAC specialist :-( > > On Linux and Windows: > You have to install the correct OpenGL drivers/libraries > you want, e.g. software rendering or hardware rendering, or what else. > > GL4Java uses the installed OpenGL implementation of your OS. > So it is different for every OS, how to switch to a different OpenGL > impl. > > E.g., for Linux, I have tell the OS, to use this libGL.so, > I do so, while putting my libGL.so in a directory, > which is in the 1st place of the > LD_LIBRARY_PATH environment variable. > > I believe, for Windows, you can put the opengl32.dll library > into the working directory, so it is used instead of the one > installed under c:\windows\system32 ! > > For MAC ? > I do not know ! > > You should install the Vodoo OpenGL driver/library properly, > so if any OpenGL application uses it, GL4Java will use it too ! > You can check the the library which GL4Java uses with: > > java gl4java.GLContext -info > > on the command line. > > 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 |
|
From: Sven G. <sgo...@ja...> - 2000-08-25 15:59:23
|
aNt wrote: > > what if i just wont to stop it from using hardware. i dont wont my users to > have to start removing extentions.. works with the hardware on the mac great > at the moment... just wont to turn it off in my final app > > aNt > This is not a GL4Java issue ! Really ! But I will check it out, while doing the Mac port ! But I guess, you have to turn the "extension (hardware accelerated OpenGL)" manually on and off ... 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 |
|
From: Virgil W. <vir...@ra...> - 2000-08-28 23:05:00
|
I have not spent much time investigating this, however I have been using gl4java 2.3.1.1 and just recently switched to version 2.4.1.0. After switching to 2.4.1.0 if I click with the mouse pointer rapidly in a test app that is drawing an animation, I see a screen flash. The flash is worse if the window is made larger. It's also easier to notice if the window has a light colored background (a black background makes it hard to detect). When I run the same test app under 2.3.1.1, no flash occurs. Anyone else noticed this behavior? (Note that my test application is a game, that's why I'm clicking rapidly. Also, note that it doesn't matter if I have a mouseListener registered or not) Thanks, Virgil Wall |
|
From: Virgil W. <vir...@ra...> - 2000-08-28 23:13:16
|
In addition, after switching to version 2.4.1.0, I see these error messages printed out when my app runs: GL ERROR : invalid operation GL ERROR : 1282 == 0x502 I don't see these when using version 2.3.1.1. Any idea what they mean? Thanks, Virgil Wall |
|
From: Artiste on t. W. <a1...@So...> - 2000-08-30 07:17:16
|
Virgil Wall wrote: > > In addition, after switching to version 2.4.1.0, I see these error messages > printed out when my app runs: > GL ERROR : invalid operation > GL ERROR : 1282 == 0x502 > > I don't see these when using version 2.3.1.1. > > Any idea what they mean? > > Thanks, > Virgil Wall I am making a game too (http://perso.club-internet.fr/b_lamy). I think the click calls a repaint (through AWT refrshing event - not mouse listener), in a different thread that your game's one (the AWT event thread). If your game calls a rendering at the same time, there may be a synchronization problem, leading to openGL error and bad rendering (the flash). This is just an idea, but i think you should disable AWT rendering in your game's canvas, if your game is rendering 3D permanently, by adding : public void update(Graphics g) { } public void repaint( ) { } public void repaint(long l) { } public void render() { sDisplay(); } in your canvas's class. To draw the 3D, you'll use the new render() method. A11W |
|
From: Max G. <gi...@li...> - 2000-08-30 18:57:36
|
Virgil Wall wrote: > In addition, after switching to version 2.4.1.0, I see these error messages > printed out when my app runs: > GL ERROR : invalid operation > GL ERROR : 1282 == 0x502 > > I don't see these when using version 2.3.1.1. > > Any idea what they mean? Nobody will be able to help you until you send more detailed info: a piece of code where is occurs and precise command after this error is signaled (yes it means putting gljCheckGL() after each OpenGL command in this chunk of code to spot the bug). Max -- Max Gilead (gi...@li...) http://3d.linart.krakow.pl/OfficinaArtificialis ----------------------------------------------------------------------------- -- Duck season! Rabbit season! Duck season! Rabbit season! ELMER SEASON!!! -- |
|
From: Sven G. <sgo...@ja...> - 2000-08-30 22:00:19
|
Max Gilead wrote: > > Virgil Wall wrote: > > > In addition, after switching to version 2.4.1.0, I see these error messages > > printed out when my app runs: > > GL ERROR : invalid operation > > GL ERROR : 1282 == 0x502 > > > > I don't see these when using version 2.3.1.1. > > > > Any idea what they mean? > > Nobody will be able to help you until you send more detailed info: a piece of > code where is occurs and precise command after this error is signaled (yes it > means putting gljCheckGL() after each OpenGL command in this chunk of code to > spot the bug). > ... where glGetError is allowed ... !!! gljCheckGL() exists within the default implementation of: - GLAnimCanvas: - init - display gljCheckGL calls the OpenGL command glGetError, so it is restricted like glGetError is restricted ! The GL ERROR number which is printed is the error, glGetError receives .. You may want to add a Exception e.printStackTrace(...), if gljCheckError returns true ! 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 |
|
From: Virgil W. <vir...@ra...> - 2000-08-31 01:48:43
|
> > In addition, after switching to version 2.4.1.0, I see these error
messages
> > printed out when my app runs:
> > GL ERROR : invalid operation
> > GL ERROR : 1282 == 0x502
> >
> Nobody will be able to help you until you send more detailed info: a piece
of
> code where is occurs and precise command after this error is signaled (yes
it
> means putting gljCheckGL() after each OpenGL command in this chunk of code
to
> spot the bug).
>
Ok, I think I've got it figured out. Version 2.3.1.1 was letting me get
away with all sorts of tom foolery. For starters, the paint method of
GLCanvas is being called, which is in turn calling my display. All of this
is happening before I've set up appropriate data structures ,etc. My test
application is written to basically do this kind of thing (rewritten for
simplicity):
public void run(){
setupdata();
while(true){
modifydata();
canvas.sDisplay();
}
}
My display method in canvas draws things based on data structures that it
expects will already have been initialized in setupdata(). However, the
paint method of GLCanvas is getting called before I start the above
thread... and paint is calling display (So I'm trying to draw things based
on uninitialized data structures... hence the errors). The paint method of
GLCanvas is getting called before I Start my thread since I am creating a
frame (and showing it) which holds a GLCanvas before I start the above
thread.
Additionally, I used to have a quad that had a texture mapped to it, but no
bindtexture had been called first. (Silliness, basically)
2.3.1.1 was lets me get away with these two errors without chastising me
(not sure why). 2.4.1.0 doesn't (which is a good thing :)
Thanks,
Virgil
> Max
|
|
From: Sven G. <sgo...@ja...> - 2000-08-31 03:58:24
|
Virgil Wall wrote:
> Ok, I think I've got it figured out. Version 2.3.1.1 was letting me get
> away with all sorts of tom foolery. For starters, the paint method of
> GLCanvas is being called, which is in turn calling my display. All of this
> is happening before I've set up appropriate data structures ,etc. My test
> application is written to basically do this kind of thing (rewritten for
> simplicity):
>
> public void run(){
> setupdata();
> while(true){
> modifydata();
> canvas.sDisplay();
> }
> }
>
Dear Virgil,
I want to encourage you to use GLAnimCanvas,
or hte way GLAnimCanvas uses the animation update methods !
I see it in many demos, that you use the threaded sDisplay call for
default !
This only works within a very good native multithreading JVM,
and does steals a lot of ressources ...
You can see, that the GLAnimCanvas demos does have the option to
refresh directly (useRepaint... method), but it is disabled for default.
I think, that the repaint method should be fast enough for us ... >= 20
fps :-)
Of course, the direct way gives us quiet the same fps, like the native
application, but we do pay responsiveness of the JVM for it !
Please check the PERFORMANCE mail from me to the mailinglist,
and the PerformanceLog's within the demos/MiscDemos directory !
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
|
|
From: Virgil W. <vir...@ra...> - 2000-08-31 22:59:17
|
> Dear Virgil, > > I want to encourage you to use GLAnimCanvas, > or hte way GLAnimCanvas uses the animation update methods ! > > I see it in many demos, that you use the threaded sDisplay call for > default ! > This only works within a very good native multithreading JVM, > and does steals a lot of ressources ... > > You can see, that the GLAnimCanvas demos does have the option to > refresh directly (useRepaint... method), but it is disabled for default. > > I think, that the repaint method should be fast enough for us ... >= 20 > fps :-) > > Of course, the direct way gives us quiet the same fps, like the native > application, but we do pay responsiveness of the JVM for it ! > > Please check the PERFORMANCE mail from me to the mailinglist, > and the PerformanceLog's within the demos/MiscDemos directory ! > > Yours, Sven Well, the reason I have to call sDisplay in a loop is that I need to very accurately track how long it takes to do the display. GLAnuimCanvas tracks frames per second by using System.currentTimeMillis(). This only yields timing accurate to around 16ms (on a good day). This isn't really that good (for a game anyway). Since I'm writing a game, I want very high frame rates and I need to know very precisely how long each update takes (so I can move game objects at the right rate). To solve this problem, I make a call into a jni library I've written to more accurately calculate time. (Using the system clock on windows to achieve near microsecond accuracy). Also, I do a Thread.sleep() once per loop (in order to set a maximum fps). In summary, I pretty much do what GLAnimCanvas does, I just need to be able to very precisely track how long each update takes (and using System.currentTimeMillis() isn't good enough) (For the curious, the Magician Java opengl crap has a percision timer call... it's pretty each to do, but one might argue that it has nothing to do with opengl) Virgil |
|
From: Virgil W. <vir...@ra...> - 2000-08-31 22:59:27
|
> Dear Virgil, > > I want to encourage you to use GLAnimCanvas, > or hte way GLAnimCanvas uses the animation update methods ! > > I see it in many demos, that you use the threaded sDisplay call for > default ! > This only works within a very good native multithreading JVM, > and does steals a lot of ressources ... > > You can see, that the GLAnimCanvas demos does have the option to > refresh directly (useRepaint... method), but it is disabled for default. > > I think, that the repaint method should be fast enough for us ... >= 20 > fps :-) > > Of course, the direct way gives us quiet the same fps, like the native > application, but we do pay responsiveness of the JVM for it ! > > Please check the PERFORMANCE mail from me to the mailinglist, > and the PerformanceLog's within the demos/MiscDemos directory ! > > Yours, Sven Well, the reason I have to call sDisplay in a loop is that I need to very accurately track how long it takes to do the display. GLAnuimCanvas tracks frames per second by using System.currentTimeMillis(). This only yields timing accurate to around 16ms (on a good day). This isn't really that good (for a game anyway). Since I'm writing a game, I want very high frame rates and I need to know very precisely how long each update takes (so I can move game objects at the right rate). To solve this problem, I make a call into a jni library I've written to more accurately calculate time. (Using the system clock on windows to achieve near microsecond accuracy). Also, I do a Thread.sleep() once per loop (in order to set a maximum fps). In summary, I pretty much do what GLAnimCanvas does, I just need to be able to very precisely track how long each update takes (and using System.currentTimeMillis() isn't good enough) (For the curious, the Magician Java opengl crap has a percision timer call... it's pretty each to do, but one might argue that it has nothing to do with opengl) Virgil |
|
From: Sven G. <sgo...@ja...> - 2000-08-31 23:17:32
|
Virgil Wall wrote: > > > Dear Virgil, > > > > I want to encourage you to use GLAnimCanvas, > > or hte way GLAnimCanvas uses the animation update methods ! > > > > I see it in many demos, that you use the threaded sDisplay call for > > default ! > > This only works within a very good native multithreading JVM, > > and does steals a lot of ressources ... > > > > You can see, that the GLAnimCanvas demos does have the option to > > refresh directly (useRepaint... method), but it is disabled for default. > > > > I think, that the repaint method should be fast enough for us ... >= 20 > > fps :-) > > > > Of course, the direct way gives us quiet the same fps, like the native > > application, but we do pay responsiveness of the JVM for it ! > > > > Please check the PERFORMANCE mail from me to the mailinglist, > > and the PerformanceLog's within the demos/MiscDemos directory ! > > > > Yours, Sven > > Well, the reason I have to call sDisplay in a loop is that I need to very > accurately track how long it takes to do the display. > GLAnuimCanvas tracks frames per second by using System.currentTimeMillis(). > This only yields timing accurate to around 16ms (on a good day). This isn't > really that good (for a game anyway). Since I'm writing a game, I want very > high frame rates and I need to know very precisely how long each update > takes (so I can move game objects at the right rate). To solve this > problem, I make a call into a jni library I've written to more accurately > calculate time. (Using the system clock on windows to achieve near > microsecond accuracy). > Also, I do a Thread.sleep() once per loop (in order to set a maximum fps). > > In summary, I pretty much do what GLAnimCanvas does, I just need to be able > to very precisely track how long each update takes (and using > System.currentTimeMillis() isn't good enough) > Really ? I thought that even 50ms precision should be enough -> about 20 fps (more or less :-) ! Well - anyway, if you really have to be that precisous, i wonder, how you handle the _very_ unprecise Thread.sleep() call ? Because you are guaranteed to be woke up in the right time ... > (For the curious, the Magician Java opengl crap has a percision timer > call... it's pretty each to do, but one might argue that it has nothing to > do with opengl) > Ok ... so why don't you offer your native function to GL4Java ? If the implementation uses the Unix like time functions, I guess we can add it for ALL OS/platforms ! I love to add it into the next release, if you are fast :-) enough .. Currently I am working for: - Linux*, Solaris-, SGI/Irix*, HP-UX- - MacOS- - Win32* ports of GL4Java ! (* well done, - some platform specific problems, but under work) Well, please do not make OS depended stuff - if possible. Your application should run on all of our GL4Java platforms, right ? So just try to minimize special native things, and offer them (the native atoms) to the gl4java project - no problem ! > Virgil 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 |
|
From: Virgil W. <vir...@ra...> - 2000-08-31 23:44:13
|
> Really ? > I thought that even 50ms precision should be enough > -> about 20 fps (more or less :-) ! The visual quality of using the more precise clock is pretty apparent in some situations. The human eye is pretty good at catching "glitches" in anticipated motion. Pretty much any commercial game uses more accurate timing. > > Well - anyway, if you really have to be that precisous, > i wonder, how you handle the _very_ unprecise Thread.sleep() call ? > Because you are guaranteed to be woke up in the right time ... Because I time the sleep too. What matters is how much time elapsed since the last update, Thread.sleep/Thead.yield and all. The only reason to sleep/yield at all is to prevent thread starvation. So naturally, you have to take a time stamp, sleep a little, take another timestamp and repeat. > > > (For the curious, the Magician Java opengl crap has a percision timer > > call... it's pretty each to do, but one might argue that it has nothing to > > do with opengl) > > > > Ok ... so why don't you offer your native function > to GL4Java ? Because I'd have to make it work on windows, unix and mac:) (windows and unix are no problem,btw) Also, if I'm going to go to all of this trouble, then I'd probably offer more than just a few timing calls. For instance, I use native calls to change the screen resolution and make the fullscreen window a top level window (so it would be possible to do full screen things at some resolution other than what the user's desktop is set to). > > If the implementation uses the Unix like time functions, > I guess we can add it for ALL OS/platforms ! > I love to add it into the next release, if you are fast :-) enough .. > Currently I am working for: > - Linux*, Solaris-, SGI/Irix*, HP-UX- > - MacOS- > - Win32* > ports of GL4Java ! > (* well done, - some platform specific problems, but under work) > > Well, please do not make OS depended stuff - if possible. > Your application should run on all of our GL4Java platforms, right ? Nope :) to be honest, I could care less if anyone on HPUX can play this game or not. If I'm going to care about HPUX then I'm also going to care about AIX... which isn't in your list. By the time I'm done, I'm also probably going to be using DirectInput on windows (so I can poll the keyboard directly and use a force feedback joystick). I might also use directsound.... So, a native timing function is the least of my concern. > So just try to minimize special native things, I hear you.... and I do just as any person might (its much easier to manage). > and offer them (the native atoms) to the gl4java project - no problem ! Virgil |
|
From: Sven G. <sgo...@ja...> - 2000-09-01 00:14:48
|
Virgil Wall wrote: > > > Really ? > > I thought that even 50ms precision should be enough > > -> about 20 fps (more or less :-) ! > > The visual quality of using the more precise clock is pretty apparent in > some situations. The human eye is pretty good at catching "glitches" in > anticipated motion. Pretty much any commercial game uses more accurate > timing. > > > > > Well - anyway, if you really have to be that precisous, > > i wonder, how you handle the _very_ unprecise Thread.sleep() call ? > > Because you are guaranteed to be woke up in the right time ... > > Because I time the sleep too. What matters is how much time elapsed since > the last update, Thread.sleep/Thead.yield and all. The only reason to > sleep/yield at all is to prevent thread starvation. So naturally, you have > to take a time stamp, sleep a little, take another timestamp and repeat. > well, it must be interesting ... may be some kind of stereo capabilities will need this quality also. > > > > > (For the curious, the Magician Java opengl crap has a percision timer > > > call... it's pretty each to do, but one might argue that it has nothing > to > > > do with opengl) > > > > > > > Ok ... so why don't you offer your native function > > to GL4Java ? > > Because I'd have to make it work on windows, unix and mac:) (windows and > unix are no problem,btw) > Also, if I'm going to go to all of this trouble, then I'd probably offer > more than just a few timing calls. For instance, I use native calls to > change the screen resolution and make the fullscreen window a top level > window (so it would be possible to do full screen things at some resolution > other than what the user's desktop is set to). > Sounds fine, if all platforms can handle it - I guess so ! A nice extension to the GLContext class ?! So please - just send your code if it is done, piece for piece. Or will you hold things proprietary ? :o) > > > > If the implementation uses the Unix like time functions, > > I guess we can add it for ALL OS/platforms ! > > I love to add it into the next release, if you are fast :-) enough .. > > Currently I am working for: > > - Linux*, Solaris-, SGI/Irix*, HP-UX- > > - MacOS- > > - Win32* > > ports of GL4Java ! > > (* well done, - some platform specific problems, but under work) > > > > Well, please do not make OS depended stuff - if possible. > > Your application should run on all of our GL4Java platforms, right ? > > Nope :) to be honest, I could care less if anyone on HPUX can play this game > or not. If I'm going to care about HPUX then I'm also going to care about > AIX... which isn't in your list. Ooops ... AIX should work also :-) AIX was my official 1st Unix port of GL4Java, but now, i do not have access to this machine, to produce binaries ... All Unix machines with X11R6 (and hopefully gcc), should work ! Just need some time and machine access ... > By the time I'm done, I'm also probably > going to be using DirectInput on windows (so I can poll the keyboard > directly and use a force feedback joystick). I might also use > directsound.... So, a native timing function is the least of my concern. > Puhh ... Well, this looks very native .. may be not interesting. But all the parts, like timing funcs etc. :-), are portable .. > > So just try to minimize special native things, > > I hear you.... and I do just as any person might (its much easier to > manage). > > > and offer them (the native atoms) to the gl4java project - no problem ! > > Virgil Sorry for being that non diplomatics and shrill, just want to force you to show me something :o) 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 |
|
From: Virgil W. <vir...@ra...> - 2000-09-01 00:41:16
|
>... > Sounds fine, if all platforms can handle it - I guess so ! > A nice extension to the GLContext class ?! > > So please - just send your code if it is done, piece for piece. > Or will you hold things proprietary ? :o) Once I get the interface worked out the way I like it (and make sure it works on unix), I'd be happy to submit stuff for inclusion. Some stuff might not work on all platforms, though. For instance, I'm not sure the screen resolution changing stuff will work everywhere (under X on unix for instance). Somebody else with more experience might know if you can do this. As such, I doubt that the gl4java project would be interested in such things. I suppose I could always put the platform specific utilities together into their own package. That way, folks could use them if they wanted, but not expect platform specific functionality to be available on all platforms. > > >... > Puhh ... > Well, this looks very native .. may be not interesting. > But all the parts, like timing funcs etc. :-), are portable .. As soon as you can plug a force feedback joystick into HPUX (and have it work), I"ll start to worry about the native code to control the joystick. This stuff is all specific to my project, though, so it has no impact (actual or intended) on gl4java. Since the topic kinda came up, though, I'll point out that I'm not using java because I want my software to run "everywhere". I'm using java because I enjoy using the language. As you might expect, my target audience for a game is 98/ME/2000/NT/linux (in that order). Ignore linux, and I should be using c++/direct3d. But, I like opengl and java better. That's why I'm playing with gl4java. Soon, my senses will probably come around and I'll write the opengl rendering code in C, and only use java for the game logic. But for now, it's nice to prototype everything in java. > > Sorry for being that non diplomatics and shrill, > just want to force you to show me something :o) > No problem. gl4java is a great project/product. I have nothing but the highest regards for everyone involved with the project. Virgil |
|
From: Artiste on t. W. <a1...@So...> - 2000-09-02 07:08:26
|
Sven Goethel wrote: > Virgil Wall wrote: > > > Really ? > > > I thought that even 50ms precision should be enough > > > -> about 20 fps (more or less :-) ! No, for a game, 30 fps is the minimum ! And it's often quickier 50 - 60 - ... 100 ! > > The visual quality of using the more precise clock is pretty apparent in > > some situations. The human eye is pretty good at catching "glitches" in > > anticipated motion. Pretty much any commercial game uses more accurate > > timing. Personaly i use the average time of the ten last rendering, returned by System.currentTimeMillis(), but i know your way is better... Such a time function will be very interesting. > > By the time I'm done, I'm also probably > > going to be using DirectInput on windows (so I can poll the keyboard > > directly and use a force feedback joystick). I might also use > > directsound.... So, a native timing function is the least of my concern. > > > > Puhh ... > Well, this looks very native .. may be not interesting. > But all the parts, like timing funcs etc. :-), are portable .. I think that for changing screen resolution or joystick, SDL (free) is better than directX because of its portability (at least window + Linux, i'm not sure for Mac). A11W |
|
From: Sven G. <sgo...@ja...> - 2000-08-30 22:21:58
|
Virgil Wall wrote: > > I have not spent much time investigating this, however I have been using > gl4java 2.3.1.1 and just recently switched to version 2.4.1.0. > After switching to 2.4.1.0 if I click with the mouse pointer rapidly in a > test app that is drawing an animation, I see a screen flash. The flash is > worse if the window is made larger. It's also easier to notice if the > window has a light colored background (a black background makes it hard to > detect). > > When I run the same test app under 2.3.1.1, no flash occurs. > > Anyone else noticed this behavior? > > (Note that my test application is a game, that's why I'm clicking rapidly. > Also, note that it doesn't matter if I have a mouseListener registered or > not) > > Thanks, > Virgil Wall > Dear Virgil, the classes GLCanvas (and therefor GLAnimCanvas) in the package gl4java.awt, adds itself as a mouselistener, to repaint if: mouseClicked ... So, if you use GLCanvas or (especially) GLAnimCanvas, just overwrite mouseClicked with a no operation implementation, or whatever you want to do. I made this as an easy solution for the incomplete window refresh, if an "own window" is used and it is shown again after hidden by another window. 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 |
|
From: Virgil W. <vir...@ra...> - 2000-08-31 01:12:33
|
> Dear Virgil, > > the classes GLCanvas (and therefor GLAnimCanvas) in the package > gl4java.awt, > adds itself as a mouselistener, to repaint if: > mouseClicked > ... > > So, if you use GLCanvas or (especially) GLAnimCanvas, > just overwrite mouseClicked with a no operation implementation, > or whatever you want to do. > > I made this as an easy solution for the incomplete window refresh, > if an "own window" is used and it is shown again after hidden by another > window. Yep, that did the trick. Guess I've been out of touch for too long. Looking at the 2.3.1.1 source I still have I see that the GLCanvas used to not add itself as a mouselistener. I was calling sDisplay myself so I had not bothered overriding update. So, every mouse click was calling repaint, which caused an eventual update, etc. Overriding mouseClicked (and update and paint for completeness) got rid of the flash. Thanks Sven and A11W, Virgil > > 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 > |
|
From: Virgil W. <vir...@ra...> - 2000-08-31 01:13:26
|
> Dear Virgil, > > the classes GLCanvas (and therefor GLAnimCanvas) in the package > gl4java.awt, > adds itself as a mouselistener, to repaint if: > mouseClicked > ... > > So, if you use GLCanvas or (especially) GLAnimCanvas, > just overwrite mouseClicked with a no operation implementation, > or whatever you want to do. > > I made this as an easy solution for the incomplete window refresh, > if an "own window" is used and it is shown again after hidden by another > window. Yep, that did the trick. Guess I've been out of touch for too long. Looking at the 2.3.1.1 source I still have I see that the GLCanvas used to not add itself as a mouselistener. I was calling sDisplay myself so I had not bothered overriding update. So, every mouse click was calling repaint, which caused an eventual update, etc. Overriding mouseClicked (and update and paint for completeness) got rid of the flash. Thanks Sven and A11W, Virgil > > 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X