Menu
▾
▴
gl4java-usergroup
|
From: Kerry L. B. <ke...@vs...> - 2000-03-13 00:08:46
|
At 10:59 AM 1/24/00 +0100, sven goethel wrote: >Of course, the Win32 version, cannot has only dummy functions >for the new OpenGL1.2 functions ..., >because Win32 supports OpenGL 1.1.X only ... Any plans to cut this dependance and support loadable ICD's? I understand that as of Win2K GL is frozen forever at 1.1 and the _only_ way to get anything done is to provide ICD's, and that the SGI OpenGL code can't "SEE" most ICD's due to "registry changes". My friends still in the games industry tell me almost all of the IHV's have accepted this, and everyone is migrating to a manual load strategy. I've been hoping gl4java would insulate me from this issue... |
|
From: Sven <sgo...@ja...> - 2000-03-16 03:08:33
|
Dear GL4Java users, to support loadable additional GL/GLU functions, I do need your help ! The windows version allready uses wglGetProcAddress to support some of the EXT functions ! I need a seperate list of GL/GLU (incl. EXT) functions with prototypes which are new in GL 1.2 or GLU 1.2 ! The mesa GL headers are not enough explizit (not detailed) for me ! So - then I can create an automatism, like it exist for some EXT functions, to load all these functions with wglGetProcAddress ! May be, all these functions should be loaded for the Unix version this way either ! Then we can have something like "boolean gl*Exits()" methods. At this time, GL4Java supports all GL 1.2 methods. If it is compiled with a special GL library, e.g. opengl32.dll or nvidias-mesa 1.1 gl, some missing functions are only represented as dummy functions ! So a dynamic load of these functions may makes sense ... BUT - like for all GL usage, the user may can not use the applications, because of the non std. gl implementation he may use ... Please make a vote - and if you have time, please participate and help ! Thanxs ! Yours, Sven Goethel "Kerry L. Bonin" wrote: > > [NON M$ BASHING, CONSTRUCTIVE QUESTION AT BOTTOM OF EMAIL...] > > At 04:14 PM 3/12/00 -0800, Jon Leech wrote: > >On Sun, Mar 12, 2000 at 04:03:00PM -0800, Kerry L. Bonin wrote: > >> At 10:59 AM 1/24/00 +0100, sven goethel wrote: > >> >Of course, the Win32 version, cannot has only dummy functions > >> >for the new OpenGL1.2 functions ..., > >> >because Win32 supports OpenGL 1.1.X only ... > >> > >> Any plans to cut this dependance and support loadable ICD's? I understand > >> that as of Win2K GL is frozen forever at 1.1 > > > > There will be an 1.2 OPENGL32.DLL in a future Win2K service pack. > > With all due respect, this is completely unacceptable. > > The fact that M$ has shipped an OS without proper OpenGL support MUST be > taken as an indication that the gauntlet has been thrown and even the most > skeptical developer must now bypass M$. If I listed the number of > technologies not important to M$ that "will be supported in a future blah > blah" that never shipped this email would be pages long. > > As a professional developer with over 10 years experience providing > bleeding edge tech in and around Windows, I know to NEVER, EVER trust > ANYTHING that Microsoft says about technologies not deemed strategically > important to Microsoft core business lines. OpenGL is not only not > important to Microsoft, they badly want it to die (I've sat in the audience > at CGDC where they came out and basically said this) - Its intererfering > with their long-term strategies in the games arena. > > I've heard the official reasons why the 1.2 didn't make the driver cut. > That's still unacceptable, see reason above. > > >I'm not sure what you mean by "the only way to get anything done is to > provide > >ICD's" > > OK, I should have been more specific. Are there any plans to make GL4Java > work over a direct load system such as <http://www.glsetup.com/>? -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Virgil W. <vir...@ra...> - 2000-03-16 03:37:42
|
Perhaps I'm just brain dead, but under windows 2000 professional (released version) when I run most any of the demos for gl4java I get a continuous stream of these messages printed out: "gljMakeCurrentNative free-failed" I originally reported this problem a good 4 months ago, but alas got no reply. Back then it was under windows 2000 rc2. Now the problem appears on a completely different machine that is running the released version of windows 2000 professional. This particular error appears when running under jview (version 3229, but I don't think this matters). When running under sun's jdk (using the jni gl4java libraries naturally), this error gets printed: "gljMakeCurrent free-failed" Is anyone else running under windows 2000 without getting this stream of performance killing prints? (Btw, everything seems to work properly... but these prints are killing performance) Thanks, Virgil Wall vi...@ip... |
|
From: Sven <sgo...@ja...> - 2000-03-16 06:19:25
|
Dear Virgil, for me - personally - it is too early for trying win2k ! But thankxs for your bug-finding ! So we have to locate the bug, is it a : 1) GL4Java Bug 2) OPENGL32.DLL Bug 3) a ICD OpenGL driver BUG ! Anyway, I we can remove those printouts outta the native libraries, or can only print em out, if native debug is set to true ! Well, the next version will implement this ... Is this "feature" really needed now ? Thanxs a lot, Sven Virgil Wall wrote: > > Perhaps I'm just brain dead, but under windows 2000 professional (released > version) when I run most any of the demos for gl4java I get a continuous > stream of these messages printed out: > "gljMakeCurrentNative free-failed" > > I originally reported this problem a good 4 months ago, but alas got no > reply. Back then it was under windows 2000 rc2. Now the problem appears on > a completely different machine that is running the released version of > windows 2000 professional. > > This particular error appears when running under jview (version 3229, but I > don't think this matters). > > When running under sun's jdk (using the jni gl4java libraries naturally), > this error gets printed: > "gljMakeCurrent free-failed" > > Is anyone else running under windows 2000 without getting this stream of > performance killing prints? > (Btw, everything seems to work properly... but these prints are killing > performance) > > Thanks, > > Virgil Wall > vi...@ip... > > _______________________________________________ > 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: Virgil W. <vir...@ra...> - 2000-03-17 00:57:29
|
> Dear Virgil, > > for me - personally - it is too early for trying win2k ! > > But thankxs for your bug-finding ! > > So we have to locate the bug, is it a : > 1) GL4Java Bug > 2) OPENGL32.DLL Bug > 3) a ICD OpenGL driver BUG > ! > > Anyway, I we can remove those printouts outta the native libraries, > or can only print em out, if native debug is set to true ! > > Well, the next version will implement this ... > > Is this "feature" really needed now ? Just making the prints conditional on debug mode is probably good enough for the short term. As is, it's nearly impossible to do any println debugging from my own code. I remember looking into this problem several months ago when I first looked at gl4java. At the time I didn't learn much about the problem (other than where in the native code the prints come from and that the call that causes them to be printed shouldn't be "failing".) As for windows 2000, I've had good experiences with it so far. I've used NT4 a lot and windows 98 a good bit as well. The only problems I've had with 2000 so far are trying to use direct3d (using the microsoft vm's jdirect interfaces) in full screen mode. The results aren't very pretty... Speaking of full screen mode (and not to intentionally change the subject:), but can full screen mode be supported with gl4java? Applets are nice, but if a person were to write something like a "real" game they'd want fullscreen support (so folks can do things like bump the edge of the screen to scroll across the game space). Thanks for you feedback, Virgil Wall vir...@ra... Director, R&D Hummingbird Raleigh, NC http://www.hummingbird.com |
|
From: Sven <sgo...@ja...> - 2000-03-17 02:29:20
|
Is there anybody outhere, who wants the full screen support ? If so, how do you think we should support this platform independed ? Only one GL[Anim]Canvas without any other java awt/swing stuff ? I do not now, how it could be managed with the awt/swing stuff, because we can just create a new screen-window for the GL-context, not other java windows ... ? Yours sincerly, Sven -- mailto:sgo...@ja... www : http://www.jausoft.com voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442 |
|
From: Virgil W. <vir...@ra...> - 2000-03-17 03:24:38
|
>
> Is there anybody outhere,
> who wants the full screen support ?
>
> If so, how do you think we should support this
> platform independed ?
There's a cheap way to almost get what looks like fullscreen support.
You do something like this:
import java.applet.*;
import java.awt.*;
import java.awt.event.*;
public class FullScreen {
public static void main(String[] args) {
final Applet a = new gears(); /*from ronsdemos*/
final Window w = new Window(new Frame());
w.setLayout(new BorderLayout());
w.add("Center",a);
a.init();
a.start();
Toolkit tk = Toolkit.getDefaultToolkit();
Dimension screensize = tk.getScreenSize();
w.setBounds(0,0,screensize.width,screensize.height);
w.setVisible(true);
}
}
In short, you create a window to hold your canvas (or whatever component you
like). Window's don't have borders like frames do, so this almost looks
full screen.... (You (Sven) mentioned this in an earlier email I believe.)
Everything is cool except of course for that nasty taskbar on windows. (Durn
it!)
Also, this isn't _really_ full screen mode as an owner of a voodoo2 card
will attest.
I guess there might be some trick under windows using jview to get the
handle to the desktop, treat it as a container and add the canvas to it.
This still wouldn't be real fullscreen mode, but at least the taskbar would
be hidden under windows. Users would be forced to use jview as well
(cough). As for linux, I'm not sure if anyone would actually care about
fullscreen mode in the first place.
As everyone might have guessed, I'm trying to use gl4java for "user
interactive" purposes. Of course games and such work fine in windows, but
fullscreen mode is so much more emersive (if you don't believe me, play
unreal tournament fullscreen and then in a window)...
Shoot, in fact if your using windows set your taskbar to "autohide" and run
the gears demo using the above sample code. Then run it in appletviewer or
just a frame (and maximize the frame)....
Gosh what a psychological different in presentation (IMHO).
That's all I'll bug everyone with regarding the fullscreen issue:) If I
have to, I can live in a window. I just think it'd be really cool to be
able to do fullscreen opengl development in java.
Virgil Wall
>
> Only one GL[Anim]Canvas without any other java awt/swing stuff ?
> I do not now, how it could be managed with the awt/swing stuff,
> because we can just create a new screen-window for the GL-context,
> not other java windows ... ?
>
> Yours sincerly, Sven
> --
> mailto:sgo...@ja...
> www : http://www.jausoft.com
> voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> http://lists.sourceforge.net/mailman/listinfo/gl4java-usergroup
>
|
|
From: Max G. <gi...@li...> - 2000-03-18 00:18:44
|
Sven wrote: > Is there anybody outhere, > who wants the full screen support ? Not now :-) but there's other stuff I'd like to say. > If so, how do you think we should support this > platform independed ? I think it should be a property of GL(A)Canvas. If it would be set to 'fullscreen' (eg. 'true') GL's context would be set fullscreen simply overlaying everything other (doesn't it works like that in native apps?). In this case, the same Java call would call different code under different OSes. But this is the whole point in Java portability, isn't it? :-) I think GL4J should not bother itself much about AWT components because AFAIK they do not support fullscreen, just draw GL on top of everything. I'm not skilled in any OS GL programming so these are just my wild thoughts but I hope it makes sense :-) > Only one GL[Anim]Canvas without any other java awt/swing stuff ? Right! > I do not now, how it could be managed with the awt/swing stuff, > because we can just create a new screen-window for the GL-context, > not other java windows ... ? Java stuff wouldn't be visible anyway so who cares? If it would support (actually it should for being 'proffessional' :-) changing screen mode (resolution, depth) its context must be destroyed before going back from fullscreen anyway. -- Max Gilead (gi...@li...) http://3d.linart.krakow.pl/OfficinaArtificialis ----------------------------------------------------------------------------- |
|
From: Virgil W. <vir...@ra...> - 2000-03-18 04:34:28
|
> I think it should be a property of GL(A)Canvas. If it would be set to > 'fullscreen' (eg. 'true') GL's context would be set fullscreen simply > overlaying everything other (doesn't it works like that in native > apps?). In this case, the same Java call would call different code under > different OSes. But this is the whole point in Java portability, isn't > it? :-) I think GL4J should not bother itself much about AWT components > because AFAIK they do not support fullscreen, just draw GL on top of > everything. > I'm not skilled in any OS GL programming so these are just my wild > thoughts but I hope it makes sense :-) > I guess one other way to do it would be to create something similar to what Apple did in the java quicktime stuff. (Take a look at http://qtj.apple.com/pub/doc/quicktime/app/display/FullScreenWindow.html and http://qtj.apple.com/pub/doc/quicktime/std/movies/FullScreen.html ) I think this might be essentially what you described. In this way, though, you actually would get to do normal java development (and use normal java event handling for things like mousemoves and keypresses). The difficulty with this solution is that it has to be done natively for each platform supported for gl4java. (Meaning there is a different way to create top level window on each platform.) Alternately, one could also write a jni dll that "cheats" and grabs the pdata class scope member data of the window peer. This member data actually just holds the native window handle. Once you have hold of that, then a native call to setWindowPos could make any java window or frame a "top level" window (kind of like the task manager under windows nt/2000... it's always on top of everything (taskbar included)). I don't remember what the equilavent call is under X, but it's there I'm sure. The disadvantage of the second solution is that it is native and specific to each platform as well. It also presumes that some crazy VM vendor didn't go substantially rewrite the java peer code (uh hmmmm, I won't name names, but the comapany name starts with "Micro" and ends in "soft"). Of course, the jdirect code would just look for something other than pdata if it had to. Also, some purest might not like the idea of using a jni library (or jdirect) to cheat and violate java scoping. After all, pdata is package scope and we ain't supposed to know that it even exists much less access it. I kind of like the thing apple did, even though it had to be a royal pain in the butt. Their fullscreen class lets you change the screen resolution and all. As pointed out, this would be a nice feature as well. I'm sure all of the gl purests out there will be quick to point out that none of this has anything to do with opengl, though. However, I'd say this would be a sweet utility for gl support. I don't know if any of the other java gl bindings have any kind of fullscreen support or not. If they don't, the addition of this feature to gl4java would be an excellent distinguishing feature. Anybody who wants to write a game is strongly attracted to this ability. (Oh wait, I said I was going to shut up about all of this :) Virgil Wall |
|
From: Virgil W. <vir...@ra...> - 2000-03-18 20:21:55
|
Well, things under windows 200 are actually worse than just the before mentioned "free-failed" messages. Try running one of the demos (gllandscape for instance) under 2000 and you get this when you try to exit the demo: gljFreeNativeJDirect failed Error code = 6 gljFreeNativeJDirect failed Error code = 6 gljDestroyNativeJDirect: wglMakeCurrent(NULL, NULL) failed Error code = 6 And then the vm doesn't exit (it hangs). (The above output is when running under jview of course). Other than these troubling behaviors, gl4java runs beautifully under windows 2000. Virgil Wall |
×
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