I am Using Java OpenGL(JOGL).
I knew GL context depends on each thread.
But I have to convert Local coordinate to Global one when mouse clicked.
Can I refer the CACHED GL CONTEXT in AWT EVENT THREAD?
If I can not, then is there any alternative logic?
Please read the JOGL user's guide. You mustn't use a GL instance when its OpenGL context isn't current, you mustn't store the GL instance, you should use it in a GLEventListener and you should avoid passing it. You can use GLAutoDrawable.invoke() to execute a task when the drawable is displayed. I don't advise you to make the OpenGL context current even though it's possible.
Are you sure that you need something OpenGL related to convert local coordinates to global ones?
Finally, you should rather ask questions specific to JOGL on our official forum as only a very few JogAmp contributors come here. We can't be everywhere.
Related
TL;DR: Is there any way of forcing Java2D graphics to only go through the OpenGL pipeline, and entirely and completely ignore Direct3D and DirectDraw (desired effect: opengl32.dll should be used before ddraw.dll)?
I have created a game using Java and Swing with the intent of publishing on steam. A problem has arisen: the steam overlay doesn't appear. After asking in this discussion (not view-able for most people, keep reading for gist) the possible source of the problem was identified. The game is initializing Direct3D and DirectDraw before OpenGL, and the overlay is hooking on to the first of these, however OpenGL is the acceleration type supported by the steam overlay.
The problem would hopefully be fixed if Direct3D and DirectDraw are not used. That way the steam overlay will not try to hook on to them first, and just hook on to OpenGL.
I have tried the following flags to disable Direct3D and DirectDraw:
-Dsun.java2d.d3d=false -Dsun.java2d.ddoffscreen=false -Dsun.java2d.noddraw=true This has made no noticeable effect (ddraw.dll is still be used).
OpenGL is programmatically enabled because this is the only way the steam API can be initialize prior to the init of an OpenGL device:
//init steam api here. api init is required before OpenGL device init
System.out.println("The api was initialized successfully")
System.setProperty("sun.java2d.opengl", "True");
//continue with the game initialization, creates a frame, game loop, callbacks, etc.
Console output:
The api was initialized successfully
OpenGL pipeline enabled for default config on screen 0
It is worth noting that JavaFX is also used in the game but purely for audio. Nothing graphical is initialized. I am not sure if this would cause a problem or conflict.
In summary:
I'm trying to use only the OpenGL pipeline for Java2D so that the steam overlay will hook on to the OpenGL device. ddraw.dll (direct draw) is being used just before opengl32.dll is used (making it so that the overlay tries and fails to hook on to ddraw.dll because it's being used first). I'm trying to get it not to use ddraw.dll, so that it will only try to hook on to opengl32.dll.
Side note: I'm not noticing any difference when using OpenGL versus standard Java2D. I'm getting the OpenGL pipeline enabled message (above), but is it possible that it's still not using it somehow?
As far as I know the options you have used only apply to AWT and not JavaFX. So JavaFX could indeed be the problem here. As you are not using any JavaFX graphics anyway it might help to switch off the hardware acceleration of JavaFX via -Dprism.order=sw. To verify that you are actually not using it you could switch on logging too via -Dprism.verbose=true. I am not sure this helps but at least it is woth a try.
I was reading through the java docs and found that it is easy to make a shaped windows, making them translucent and coloured as long as the platform is supporting such feature, but I couldn't find anything about making them glossy.
Is it possible in either awt or just swing to give frame or a panel a metallic look?
I know this might be a horrible idea from cross platform point of view, but I wanted to know if it's possible somehow without resorting to some third party libraries?
I have found a button gloss example here:
http://www.andygibson.net/blog/tutorial/glass-button-tutorial-in-java/
But it is not exactly a metallic look and if I replicate the method to use rectangles instead of circles it may scale poorly.
I've been looking at JavaFX but it seems to be a massive multipurpose package - an overkill if I just want one eyecandy.
note - if you give a minus, be so kind to explain why - else its just being a jerk. I see nothing wrong with this post and I did indicate what I looked at. From what I see I've fulfilled all formal requirements and this is not a subjective type of question.
What your requesting can only be handled by calling the Windows native API. You'd have to cooperate with the Windows DWM (Desktop Windows Manager) facility. Typically it's handled by calling the DwmExtendFrameIntoClientArea function.
Long time ago, I tried to mimic the glass (AKA Aero/Frost) effect using Swing. It was partially possible. One can easily write drawing code which handles this (and surprisingly even quite performant), providing that the drawing happens on the Java side.
That was possible with Swing (see Glass effect for internal panes) and should be even simpler with JavaFX.
However, to handle your precise request - the windows borders - one has to use the native WinApi. From my little research, I only found that SWT does this in limited way (but doesn't expose as publically accessible methods).
I tried to call the Windows Shell API through the JNA project. I successfully managed to change the glass area, but the effect was unpleasant: the Swing wasn't really well prepared (~JDK 7u5) to handle partially transparent JFrames. I remember, that the JFrame code, during a repaint, was clearing the Window using some color. I had to forcefully change it to other one (which matched the one I specified by calling the Windows API), but ended up in a visual mess.
I tried to debug it and I found that certain versions of Java have different code to clear the JFrame's content. So, even if I managed to correctly set the wanted color, it could easily break with the JDK update.
I am currently working on a notification app, using Java.
I need for the window to be shortly (about 10 sec.) on top of any apps. including the ones running OpenGL and DirectX (e.g. computer games). I know that the JFrame.setAlwaysOnTop(true); only works in window based environments, which OpenGL and DirectX is not.
Thought about the OpenGL bindings, but can't seem to find anything about DirectX?
Maybe it is possible using JNI?
Any ideas are welcome :-)
Edit: Thanks for the answers guys, but I actually gave up on it and decided to force the game, of which I am making the overlay for, in windowed fullscreen mode. I´ll just have to wait and see what the beta-testers have to say about the reduced fps :-) thanks again
Don't bother with directx and java. That has an impedance mismatch. Java is cross platform, OpenGL is cross platform. If you insist on using directx you can try SWT since it uses native operating system resources you might have a chance.
For opengl what you are looking for is canvas integration with panel/jframe, you can use JOGL for that. I think lwjgl has a implementation too, but the jogl one is better. Then you can set the alwaysOnTop on that jframe.
kenai.com/projects/jogl
Your problem is not related to your code but the graphic device instead.
The device can have only one accelerated surface in full screen mode. This is Why you cannot launch two DirectX games in fullscreen if you have a dueal head GPU.
Your best bet is to try to find the DX/OpenGL surface pointer and attach to it using the required APIs. I don't know if this can be done in Java however the approach woul be:
get a pointer to the accelerated surface of the game or app that is running
create an accelerated graphic device
create a non-mimpap texture(screenshot) from your UI
get a pointer to the texture surface
use the stretch rectangle from this surface to the one you got in step 1
present
This may introduce flickering if not using Vsync and refresh rate synched repetition for each frame. This may introduce a substantial framerate drop too.
One example of this is FRAPS, that draws the current framerate on the accelerated app.
I am working on an embedded linux device that requires custom java code to draw to the screen. I was wondering if there was any way to create a custom adapter that can update the display based off our drawing code. I have done some digging and haven't found any information as to how Devices are implemented or plugged into Swing/AWT. Any information is greatly appreciated.
Thanks.
I think you need to go beyond what Swing/AWT would typically call an adapter and create the bridge yourself to the graphics device using JNI (Java Native Interface). Have a look at this wiki page which describes the JNI aspects of Javas AWT layer - there are links in that page to details of JNI and Swing which are fairly low-level. Hopefully this will put you on the right track.
How do I create a J2ME app for cellphones with a GUI similar to the menus you see in Java games? I've tried MIDlets with Netbeans but they only show you one GUI element at a time. (textbox, choice, login, etc)
And which Java IDE would you typically design these GUIs in? Netbeans or Eclipse? and is IntelliJ IDEA usable for this aswell?
Do I have to write/get a library that draws GUI controls to screen via bitmap functions .. and keeps track of the keys pressed for focus?
Try to use LWUIT - nice UI toolkit for j2me:
https://lwuit.dev.java.net/
http://lwuit.blogspot.com/
You can also use minime: http://code.google.com/p/minime/
It's an open source GUI library for j2me. miniME works on canvas level (lowest level in j2me) to draw every control so your UI will look exactly the same whatever the handset it'll be running on. Other advantage are:
- miniME uses its own event loop to manage user controlled event (botton pressed, softbar, ..), so you Application will "behave" the same whatever the handset.
- miniME support the concept of Views and stack of view, in order to make navigation between different view/screens very easy.
Here is an example: A View is what you have on the screen at a given moment (for example the main menu screen), then to go to a sub menu, you create a new view, and by calling a simple API, you push it in the stack of Views. The previous view (the main menu) is still existing, but inactive. When the sub menu view complete his work (for example, user press back, or do a selection), you can just go back to the previous view by calling a pop api.
Your question is a bit vague to give a specific aswer, but you might want to check out LWUIT or Polish, you can develop both with either Eclipse or Netbeans.
As far as designing GUIs go, neither IDE will help from a visual perspective. J2ME UI development is all done in code, beyond creating any initial graphics in a proper graphics editor you don't get to see your output until you test.
Read up on the LCDUI package documentation which explains how the UI classes work and the differences between the 'High-level' and 'low-level' APIs.
I can't comment on which IDE to use - but I do know that to create custom UI (like the ones you see in J2ME games), you have to explicitly draw the GUI controls.
Beware that you may need to customize the GUI depending on the target phones. You have to cater for different screen sizes, key pad configurations, default theme etc. This would probably mean that you need different builds for things like different screen sizes which would drive up your Java Verified certification costs (if you need it).
You may be able to find a set of nice looking UI controls that you can buy online and use (try J2ME Polish). The easy way out of course, is to use default J2ME controls :)
Links to many j2me GUI libraries: link1, link2
I know that kuix is not bad and free - watch demo.
But i prefer to make my own gui elements - this is much more flexible (but takes some time).
As for IDE - you may want to make some kind of gui-editor tool, construct interface in it, save result to some file, and read it from your app.
It's way too cumbersome to write your own GUI, especially since there are so many available these days. If you're familiar with desktop development in VB.Net and C#, you might find "J2ME GUI" easy to use. You can download it from http://www.garcer.com/. It has a similar feel and makes it easy to learn. This is the kind of GUI that I expected to come standard with MIDP2 when I started mobile development. Would have solved a lot of issues.
If you are familiar with web stuffs then you can use KUIX (kalmeo.org/home/index) framework having xml and css supports. In place of It you can use also Polish framework (www.j2mepolish.org) it's also uses the xml in easy way rather than kalmeo kuix framework.