I've been looking into input handling for an OpenGL application. I want to handle at least two joysticks, keyboard, and mouse. Outsourcing this to python scripting would be a big bonus, but not required.
I look at freeglut, but it only supports one joystick.
Pygame says it's "input queue is heavily dependent on the pygame display module" so that caused me pause.
I'm not familiar with QT or GTK's joystick input handling, and haven't been able to find any document describing my problem concisely.
SDL's python binding says it handles these things "quite well". (A statement I'm not sure what to think about.)
Is my concern over the Pygame problem a moot point when I get into it? Can QT or GTK provide this functionality without issue? Is there another alternative that solves my problem?
All else fails I think I can go straight SDL, but I don't know much about it's performance.
This question really isn't about OpenGL, as OpenGL has very little to do with input handling.
Qt and wxWidgets are not primarily for dealing with input. Obviously they handle mouse and keyboard, but they're basically GUI libraries. Their input systems are designed and intended for that purpose.
SDL's input component is designed for dealing with input. SFML is also an option. Both of them have Python bindings if that's important for you.
Pygame (which uses SDL, from python) works fine with OpenGL.
Use pygame for input events, window creation, etc... (the cross platform stuff) and OpenGL for rendering to the pygame screen.
Related
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.
Besides Qt, GTK, wxWidgets... What are the recommendations for a cross platform, open source GUI framework library that works with OpenGL?
Its not quite a GUI framework. But GLFW is good for an OpenGL window with some extra features like keyboard and joystick handling.
I found the other framework I was looking for. It is SFML. I only used it briefly but I do remember liking it very much. It does contain a lot of nice extras going a step further than GLFW. If I recall correctly the documentation was stellar.
For a full featured cross-platform GUI framework I think you would be hard pressed to beat QT, GTK, or wx.
I'm not sure, but at a guess, the other framework mfperzel was trying to think of might have been fltk (the "fast light tool kit"). Where glfw is mostly an OpenGL window with some ability to read the mouse and keyboard, fltk is a GUI framework that supports OpenGL (but as the name implies it's still quite a bit smaller and faster than most GUI frameworks). I haven't tried it yet, but there's a new GUI builder program for it (FLUID) that looks fairly promising as well. One warning though: FLTK uses its own widgets, which tend to look at least a little foreign to most users.
I have a simulation software (C++) that runs on the command line. It is platform independent (currently compiling and running on Windows, MacOS X and Linux). When the simulation ends, I visualize the result with SDL; it is a very basic 2d view, mainly color squares next to each other.
I would like to have a user interface on top of the simulation so that I can start and pause the simulation, and change the parameters on the fly. Something pretty simple I guess. Well, ideally I will also add a grapher somewhere to see the evolution over time of some parameters.
Now, I am wondering what direction I should go.
Should I try to use one of the UI libraries for SDL ?
Or maybe wxwidget in conjunction with SDL ?
Or simply wxwidget and get rid of SDL ?
Do you have any experience with this ?
Thanks in advance
Barth
PS: I tried to use AGAR, a SDL UI library. It seemed very promising but I couldn't get it working. Not even the helloworld.
It may be worth you time to look into Qt. It is generally the most mature free Gui framework available. It is cross platform. And it has hardware accelerated rendering if your drawing needs some speed.
Here is a comparison posted on WxWidgets site.
In the end if your windowing needs are minimal you should choose the framework you are most comfortable with.
Probably using wxWidgets without SDL would be the easiest way to go. SDL is a media layer -- it's supposed to allow cross-platform media application development. As you only need graphical display, you only need wxWidgets -- and it will be a lot easier too!
You would benefit from SDL if:
you'd need very fast blitting of very large amount of surfaces (we're talking the 60fps range here)
you'd use RLE, color keying or other graphics operations
you'd use other media (sound, advanced real-time input, etc)
you'd need to run the software on embedded systems (handheld consoles, etc)
If the answer to all 4 is "no", then you won't benefit from SDL, and using wx alone will be much easier.
I want to add joystick support into an openGL application.
Is there any class that can help me?
Thanks in advance.
OpenGL is a graphics API. It has no notion of input devices.
Need more info for a better answer such as platform. On Windows there are many options for handling input. Depending on what you want to do that is. Google for more info. But a start would be simple input handling via the Win32 API. This all presumes you use Windows of course.
OpenGL does not provide direct access to the joystick as it is only a graphics library.
For joystick support we will need to know what platform you are targeting.
For example, on Windows you would likely use DirectInput.
Some GLUT implementations have: glutJoystickFunc
As mentioned in other answers, OpenGL is only a graphics rendering API. It doesn't even know how to open a window, not to mention how to handle mouse or keyboard input; something else must do it for it.
If you want a cross-platform I/O wrapper for OpenGL which also provides joystick support, take a look at SDL - Simple DirectMedia Layer. It may scare you at first, but it's still easier than writing I/O and windowing stuff for a single platform, not to mention writing a wrapper for each platform out there (SDL covers many of them).
So, take a look at SDL.
I've been programming opengl using glut as my window handler, lately i've been thinking if there are any advantages to switching to an alternate window handler such as wxWidgets or qt.
Are there any major differences at all or is it just a matter of taste? Since glut provides some additional functions for opengl-programming beyond the window handling features, would there be a point in combining an additional toolkit with glut?
I can only speak from experiential of using QT:
Once you have the basic structure set up then it is a simple case of doing what you have always done: for example, the project I am working on at the moment has an open gl widget embedded in the window.
This widget has functions such as initializeGL, resize...paintGL etc. Advantages include the ability to pass variables to an from the other windows / widgets etc. QT also has additional functions for handelling mouse clicks and stuff (great for 2d stuff, 32d stuff requires some more complex maths)
You need to move from glut as soon as you want more complex controls and dialogs etc.
QT has an excellent openGL widget there is also an interesting article in the newsletter about drawing controls ontop of GL to give cool WPF style effects.
wxWidgets also comes with an opengl example but I don't have much experience of it.
Well - glut is okay to get a prototype going.
It depends on the OS, but later on you may want to prevent the screen-saver from starting, you may want to disable the task switch (only the bad guys do this though), You may want to react to power down events. You may find out that glut can't deal with dead-keys on one or another operation system, or, or, or... There are thousand reasons why you may want to get rid of it.
It's a framework designed to make the start easy and do 90% of the usual stuff you need, but it can never do 100%. You can always hack yourself into glut or lift the init-code, but one day you will find out that it's easier to redesign the init-code from scratch and adjust it to your task.
Opening a window and initializing OpenGL is not rocket-science . Use glut as long as it works for you, but as soon as it makes problems get rid of it. It'll take you just a hand full of hours, so you won't loose much.
For a toy project glut is the way to go though.
SDL, while not just a window handler, will make it easier to use OpenGL than raw Win32 code. However, my experience with Qt, GTK and wxWidgets has not been too bad... certainly not that much better than Win32, its probably a matter of taste in those cases.
I'd recommend avoiding widgets and wrappers like GLUT if you want a fine level of control over the window and resources, but if you are just looking for speed of development then these tools are ideal.