If I want to begin learning OpenGL and am not concerned about portability at the moment, would it be unwise to use OpenGL and Windows Programming together? (I am developing on Windows)
Not at all. If you already know the Windows API/message pump, adding the OpenGL context management bits won't be too much of a problem.
If you're new to both Windows programming AND OpenGL, I'd recommend starting with GLUT or similar frameworks that will let you focus on the OpenGL bits without worrying too much about interacting with the window system.
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.
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 need a cross-platform GUI toolkit with OpenGL support. I also need to be able to draw on a canvas or panel from an image buffer. The candidates I've chosen so far are FLTK (it can do OpenGL windows -- I don't know about canvases), Qt, and wxWidgets.
Any idea which would be the best?
Thanks!
I would say Qt. But that might be argumentative question...
Hey Deep, XVT support openGL. It's a GUI cross-platform toolkit for C and C++ www.xvt.com
For simple things I would suggest GLUT or something similar. But for anything above a simple window into which you render some OpenGL, I strongly recommend Qt. But as tibur said, its probably a matter of taste.
Checkout the Ecere SDK. It's a feature rich cross-platform GUI toolkit, and it supports a variety of graphics driver (e.g. GDI, X11, OpenGL, Direct3D). It has a built-in 3D engine, but you can mix it with your own OpenGL code as well, there are samples showing you how to do just that. It was originally designed as a GUI system for in-game menus, so it supports full screen mdoe as well as windowed mode, but is now a general purpose SDK.
In just about all books I read it mentions windows APIs(e.g. DirectX) when talking about C++ and game programming.
What APIs are for Mac when using C++ or what can be used for multi-platform development?
I want to create games using C++ and am currently on a Mac. I have no problem switching between Unix and Windows if it is needed.
What is recommended for C++ game development and will programming for mac be a drawback?
Or should I just go with C++ and OpenGL and use it for all platforms? :P
I would recommend SFML and OpenGL. SFML is a more modern, C++ oriented, cross platform framework that allows you to write common code for window, keyboard and mouse handling. You would then write the bulk of your game using OpenGL, which is cross platform anyway.
I am using SFML and OpenGL myself to target Mac OS X, Linux and Windows, primarily developing on Mac (I can triple boot into any of the three OSs to develop on them).
EDIT: I've had a change of heart on this as I am a bit spooked by the Mac support in SFML; I am now going to use Qt as it is better supported, provides better tools, better documentation and better examples.
You can use OpenGL wich is cross platform, and use GLUT or SDL for handling input and windows and stuff or use just SDL. (I would go with mixing OpenGL and SDL and because its easier to manage input that way and is still cross platform. Unless your making a 2D game, then use SDL as SDL is for making 2D games).
Ohh and one addition thing about OpenGL on Mac is the header for OpenGL is a little different from most tutorials:
#include <OpenGL/OpenGL.h>
Don't spend hours on that like I did...
Oh, and if you plan to use glut:
#include <GLUT/glut.h>
If you're making a 2D game I would also recommend you try SFML; it's a fairly young library that has the same scope as SDL. It's pure C++ (as opposed to SDL which is just C) so development should be somewhat easier for you, if you like OOP.
It would also appear that SFML is significantly faster than SDL:
► http://www.sfml-dev.org/forum/viewtopic.php?t=43
Glut seems rather old, and SDL also as if it's not the youngest anymore - what is being used as (cross-platform) window manager for OpenGL nowadays?
Cross platform UI toolkit
1. wxwidgets
2. fltk
3. qt
4. glut(freeglut)
5. sdl
I have used glui. Sucks real bad(in terms of performance). There huge difference in performance penalty just by including glui(without actually using it) in your apps.
To be honest, i prefer platform specific UI toolkit. Faster. Reliable.
Depends on how you want to use it. Don't think there is a clear winner.
I like to use Qt because I'm familiar with it so it feels easy to me, and because I use it for other UI elements in my mostly windowed openGL apps.
Haven't tried it myself, yet, but want to in my next project. It seems to be very popular.
SFML . It`s the "successor" to SDL written in C++
I am using freeglut, but it is just a bit improved glut.
You can also use QT
I think GLFW is the best choice for small to medium applications/games. This type of libraries should be easy,small and fast with no extra services such as image helper functions and so on. GLFW is going to remove all helper functions to focus on the main goal.
QT is the best for graphics applications but not for games or small applications.