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.
Related
As I mentioned in a question before, I am trying to make a simple game engine in C++ with OpenGL.
I am currently using GLFW for drawing the OpenGL context and I chose it because I heard it's one of the faster ones out there. However, it doesn't support widgets and I really don't want to write them myself. So I decided to get into Qt a bit, because it would allow me to have a pane for the render context and different handy bars as well as all the fancy elements for editing a world map, setting OpenGL rules, etc.
I want to use GLFW on the exported version of that game, though. Is that possible without an abstraction layer of some kind?
Thanks in advance! :)
Yes it is definitely possibile, infact I'm writing a 3D engine that is not coupled to any windowing library and can be used with Qt, SDL or whatever.
You of course have just to wrap regular GL calls into a higher level layer, this require you don't call "SwapBuffers" inside your GL code.
If by abstraction layer you mean "inversion of control" so, you don't want to override a "Render/Update" method that's exactly what I done. If by "abstraction layer" you mean you want to use GL directly than it is still possible.
Basically every windowing system have "some place" where you can make your GL calls (between MakeCurrent and SwapBuffers). Just read documentation of your windowing system.
According to MSDN's listing, GDI and GDI+ are both legacy. So when writing an application using the Windows API, what should you use to render 2d graphics?
Direct2D, WIC, DirectComposition (this is new to me), GDI+, GDI?
Note: not 2d games - just 2d images.
Either GDI or GDI+ are fine choices for basic needs.
The OS still uses GDI all over the place, so I'm not really sure what they mean by "legacy". Words like that generally don't have a meaning, so you shouldn't feel too bad ignoring them. The person who labeled these APIs "legacy" is probably one of those people who tell you that all of Win32 is legacy without realizing that these "modern" GUI frameworks that they love so much are built on top of Win32 and wouldn't be able to function without it.
Use GDI+ if you need the extra features it provides (such as transparency, etc.) and/or if you're programming in C++ and prefer its class-based API to GDI's flat C-style API. But note that if your app uses GDI+, you will have to redistribute the Gdiplus.dll library to users running Windows 2000 and earlier versions. GDI-based apps will always work out of the box.
That's not to say that you shouldn't investigate the new contenders. Supposedly, Direct2D is designed to interoperate well with GDI and GDI+. Only problem is, lots of developers are not in a position to require all of their clients to upgrade to Windows Vista or later. Supporting XP still seems like a worthwhile goal (at least providing a minimal subset of functionality for those users), and that's not really possible if you write the entire UI in Direct2D or one of the new fancy frameworks. I haven't really seen the advantage of switching to Direct2D for standard, line-of-business apps (I'm sure there are advantages for games and other programs that need 3D effects). You might be interested in the following comparison between Direct2D and GDI, which are both two-dimensional, hardware-accelerated graphics APIs.
Unless you really have to support XP (let it die already!), I would highly encourage using Direct2D. There are multiple reasons why Direct2D makes sense for all new developments:
generally faster rendering (aliased and anti-aliased rendering)
since Vista was introduced, GDI is not HW accelleration is highly crippeld (due to the new drivermodel)
better integration with Direct3D (if you need it), DirectWrite, DirectComposition, etc.
better utilization of new GPU features
many bitmap effects pre-built-in
GDI is not allowed for Metro-Style apps
Therefore, I would suggest anybody, who is beginning a new application to use Direct2D instead of GDI/GDI+.
I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.
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've been challenged with a C++ 3D application project that will use 3 displays, each one rendering from a different camera.
Recently I learned about Ogre3D but it's not clear if it supports output of different cameras to different displays/GPUs.
Does anyone have any experience with a similar Setup and Ogre or another engine?
At least on most systems (e.g., Windows, MacOS) the windowing system creates a virtual desktop, with different monitors mapped to different parts of the desktop. If you want to, you can (for example) create one big window that will cover all three displays. If you set that window up to use OpenGL, almost anything that uses OpenGL (almost certainly including Ogre3D) will work just fine, though in some cases producing that much output resolution can tax the graphics card to the point that it's a bit slower than usual.
If you want to deal with a separate window on each display, things might be a bit more complex. OpenGL itself doesn't (even attempt to) define how to handle display in multiple windows -- that's up to a platform-specific set of functions. On Windows, for example, you have a rendering context for each window, and have to use WGLMakeCurrent to pick which rendering context you draw to at any given time.
If memory serves, the Windows port of Ogre3D supports multiple rendering contexts, so this shouldn't be a problem either. I'd expect it can work with multiple windows on other systems as well, but I haven't used it on any other systems, so I can't say with any certainty.
My immediate guess, however, is that the triple monitor support will be almost inconsequential in your overall development effort. Of course, it does mean that you (can tell your boss) need a triple monitor setup for development and testing, which certainly isn't a bad thing! :-)
Edit: OpenGL itself doesn't specify anything about full-screen windows vs. normal windows. If memory serves, at least on Windows to get a full screen application, you use ChangeDisplaySettings with CDS_FULLSCREEEN. After that, it treats essentially the entire virtual desktop as a single window. I don't recall having done that with multiple monitors though, so I can't say much with any great certainty.
There are several things to be said about multihead support in the case of OGRE3D. In my experience, a working solution is to use the source version of Ogre 1.6.1 and apply this patch.
Using this patch, users have managed to render an Ogre application on a 6 monitors configuration.
Personnaly, I've successfully applied this patch, and used it with the StereoManager plugin to hook up Ogre applications with a 3D projector. I only used the Direct3D9 backend. The StereoManager plugin comes with a modified demo (Fresnel_Demo), which can help you to set up your first multihead application.
I should also add that the multihead patch is now part of the Ogre core, as of version 1.7. Ogre1.7 was recently released as a RC1, so this might be the quickest and easiest way to have it working.