We are trying to make built in game editor for our java framework, that uses GLFW for rendering game.
We want to build editor on top of it, using imgui
which also uses OpenGL, same as GLFW. We cannot touch any code in our java framework.
Is it technically possible to render game using imgui and than let our framework render itself via OpenGL again?
In other case, are there any necessary steps we need to take so it does work? Since each render call swaps buffers etc...
You have another very related question here. I'll answer both.
Let me reword your question: "I have a window which has been rendered with OpenGL in another app (or in a not-touchable code part of my app). How can I add my own render to this window, adding or replacing pixels?"
That other app (let's call it 'appA') has done some tasks: Created a window, created a gl-context (ctxA), set that context as current to some thread (thrA), done rendering and finally used SwapBuffers to see the result in the screen.
The easy case is when appA code is part of your appB code, and appA has not called SwapBuffers yet, and you have the window handle and the ctxA. Then you can do the same proccess: Set ctxA current to your thread (thrB or even thrA if you have access to it, e.g. is the same main thread), do your rendering an call SwapBuffers.
==>But you must know which OpenGL version is used by appA, and do your OpenGL job with the same version.
==>You must also be sure that appA does not execute any OpenGL command while your appB has set ctxA as current for your thread.
A more difficult case is when you can't be sure about appA doing its rendering at the same time appB renders too. You can use a shared context ctxB (so it shares with ctxA most data) which you set as current to your own thread thrB.
==>The issue is that there's no way of knowing who renders first, appA or appB.
If you are getting the whole picture then you see that your main issue is that you need to prevent appA from calling SwapBuffers. If you have this possibility then use your own ctx, thread and OpenGL stuff with the same window. You should be able to read the default framebuffer by ReadPixels.
The worst case is when you have the window and nothing else, or when SwapBuffers has been already called. You still have a chance: use code injection. This technic grabs the call to SwapBuffers from the graphics driver. Then, when it's called, do the pixels modification, and let the SwapBuffers run as before grabbing.
Related
I am building a VR application for VR glasses. Basically, I want to split the screen in two, and have two GLSurfaceViews (one in each side) showing the same in each one of them.
While investigating a bit, I read in some posts that it is not possible to have more than one GLSurfaceViews in one activity (For example: How can I use Multiple GLSurfaceView components in the same Layout?), but I also read (in that same question) that it is indeed possible, so I didn't get a clear picture.
Anyway, I tried to do it by myself. So, in my code, if I just create one instance of GLSurfaceView, everything works fine. However, if I create 2 instances of a GLSurfaceView, I realised that the renderer is created only once (I don't know why).
Thus, since I actually want to draw the same in both surfaces I thought I could just use the same renderer for both surfaceViews. I basically tried to use the first created renderer and use setRenderer() method in the second instance of GLSurfaceView, but this would crash my app.
So, can someone help me to implement two GLSurfaceViews showing the same in the same acitvity (in case this is possible)?
I am working currently with LibGDX and Java.
Im wonder me, why LibGDX give you only a render Mehtod for game logic and rendering.
Why LibGDX do this, why LibGDX does not inherited another mehtod like update ?
And should I handle game Logic and rendering in the render method(Of course I split it in an render and update method)
Both render and update methods would be called consecutively if they existed. So there is not much point in separating them and complicating the API.
Of course, if you like, you can create two different methods and call them in provided render method (if you want to separate stuff). You can also conditionally call them if you sometimes want to call only update or only render.
The point here is that it serves simple purposes to have them combined and if you want advanced stuff you can always extend the functionality.
I am working on an application that uses Swing. I have successfully created a main GUI for the user to work from. However, I would like to allow the user to change his/her settings. How should I go about creating the settings window? Would using a new JFrame called 'Settings' be the best way to handle this, or is there something better to use than a second JFrame?
(Note: The settings JFrame, on exit, will not close the main GUI, it will use the DISPOSE method)
I would like to handle this in a way that consumes the least amount of memory, but maintaining a professionalized look to the application.
Have you considered a CardLayout? http://docs.oracle.com/javase/tutorial/uiswing/layout/card.html
Personally, I find the use of a separate dialogue to be a bit dated for configuration settings. I prefer tabbed layouts, which are card layouts decorated with a tab bar across the top.
You could easily wrap your application in a near-top-level card layout and add a menu action to switch to the configuration card, with the "acknowledgement" or "cancel" buttons switching back to the main application card.
In the end, it is really about what your users prefer, but remember a lot of them might prefer what they know, even if it is not a better solution. You have to find a balance, and if your implementation rocks, then eventually they will want your approach to the problem to be used in other applications.
A perfect example of this is tabbed browsing, as opposed to multiple windows. Personally, I can't imagine going back to multiple-window browsing now that I have become accustomed to browsing tabs, but at one point in time, multiple windows was the only game in town.
In the end, if you find out you made the wrong choice, keep you code clean enough to easily implement with either solution. As long as your configuration screen is just a plain JPanel (or wrapped in just a JPanel), it shouldn't be very hard to do.
here is a class that does just this kind of thing:
http://tus.svn.sourceforge.net/viewvc/tus/tjacobs/ui/dialogs/ParamDialog.java?view=log
you have to look at the ApplicationListener interface, especially at the 'handlePreferences' method of that interface.
I would like to create a custom Android button from 9patches, but without using any XML. I know, it sounds dumb, but the reason is that for some reason my IDE (NetBeans) messes up the whole XML beyond belief. The R.java doesn't get generated half the time (the fixes didn't work for me), and I get random errors, even if I just copy and paste XML from tutorials.
This is how I plan to create the Button:
The button has a setBackgroundDrawable() method
I need to suply this method with a StateListDrawable
Which I need to build up from NinePatchDrawables
So first I need to create the 9patches, then a StateListDrawable from them, and simply pass the StateListDrawable as background for my Button's setBackgroundDrawable() method.
I can't start the 9patches, because I can't find out how the constructors work.
Wouldn't it make more sense for you to invest your time in either:
fixing NetBeans, or
switching to some different editor/IDE?
Trying to do Android development without XML is akin to trying to fly without wings. It's possible, but rockets tend to crash and burn in the end.
Regardless, you do not need to directly work with NinePatchDrawable to use nine-patch PNG files. Android will handle that part for you.
Instead, create an instance of StateListDrawable and call addState() for each one of your states. To get the Drawable for the state, use getResources().getDrawable(R.drawable.this_is_one_of_your_nine_patch_images) from your Activity. Android will detect that this is a nine-patch and will do the right thing.
I am trying to develop an application which responds to multiple digital pens (IRIS Pens) so that if any of the pen writes on paper; I relay the output to a single screen. Thus making a multi-input whiteboard for myself.
In Ubuntu these pens are recognized as mouse and thus can be handled in a similar manner as mouse events are handled.
So now what I plan to do is to handle these events in C/C++ using XLib and pass these events to a Java Swing application using JNI callback. I am able to do this but when the X11 window looses focus no events are transferred to the Swing frame. I also tried to use the root window in X11 but it does not seem to work.
Any help would be really appreciated. Thanking you in advance.
How about maximizing the C/X11 window in front of the Java one, and making it transparent? You should be able to see the Java window while still focusing on the C/X11 one.
Since you are using Ubuntu, you can achieve this using the "Opacity, brightness and saturation" plugin for Compiz. It is in the compiz-plugins-main package, and you can activate it with Compiz Settings Manager (from the compizconfig-settings-manager package). When you activate the plugin, alt+wheel is bound by default to change the transparency of the focused window.
Try reading the mouse directly. I don't remember the exact location, but you should find it in something like '/dev/input/mouseX', where X is the number of your device, ranging from 0 to n-1 devices..
When you read the packet, your application should block until the mouse moves and then your read function will return a raw mouse packet which describes the delta (which is probably more useful then the screen coordinates, in your case) and the mouse button statuses.
The raw packet can be decoded as described here: http://www.computer-engineering.org/ps2mouse/
Create a modal dialog and set it to XmDIALOG_SYSTEM_MODAL (the actual name of the property depends on your toolkit: Motif, Gtk, Qt, ...). Dialogs like this block the whole display and can never loose focus.
The drawback is of course that you can't do anything else while this dialog is on the screen.
This entry in the X11 FAQ might help.