My goal is to develop a cross-plattform based application in C++ and OpenGL.
Since I am using a Macbook Pro, its natural IDE is Xcode, so I would like to use it. I've successfully compiled pure C++ code in Xcode, by using the Command Line tool as a template for the projects.
My question is how can I compile OpenGL code without messing with Cocoa and Objective-C. The main reason behind this is that since I want to deploy cross-plattform applications, I want to stick to C++ as much as possible.
While this is true, It wouldn't be that much of a problem if I necessary had to use a little of Objective-C and Cocoa. But I would like to get my main project code in C++ and the less possible amount of Objective-C/Cocoa, understanding by "main project code" the code specific to my application, such as my classes, objects, and stuff related to the aim of the application, ie. , the main body of the code.
If using C++/OpenGL without messing with Obj-C/Cocoa is not worth in terms of complexity, then the question could be reformulated as simply what is the way to compile simple OpenGL code in Xcode?
OpenGL is a cross platform API, however it is very specific to performing graphics operations on an existing graphics context and does not encompass creating such a context or handling windowing events or anything else that requires integration with platform specific functionality. That is left to platform specific APIs.
Each platform's OpenGL implementation will include platform specific API's for performing the necessary tasks. Windows has WGL, X11 has GLX, and OS X has CGL at the low level or NSOpenGLView at the high level. OpenGL simply cannot be used without these platform specific APIs being used at some level. Furthermore, just getting a GUI of any kind requires this same sort of platform specific code.
There are projects which have wrapped various platform specific APIs in order to provide a portable API for creating a context and handling Windowing and other events outside the scope of OpenGL. One most commonly used when starting out with OpenGL is GLUT. OS X provides a framework with GLUT, however it has not been updated to use OS X's latest OpenGL support and is still stuck on OpenGL 2.x. There was a large change in the OpenGL API with the introduction of the OpenGL Core profile between 2.x and 3.x. This means that you can't currently use GLUT to write a modern OpenGL program on OS X.
Furthermore, by its cross-platform nature GLUT can never provide a decent GUI that conforms to the platforms' standards. Providing a decent GUI will always mean directly using platform specific APIs, or at least designing the GUI with the specific platform in mind.
Another difference between platforms is that on OS X you can use whatever version of OpenGL is supported just by including the standard OpenGL headers and calling functions and using identifiers as if using any other library. On Windows, the OpenGL headers don't provide anything past OpenGL 1.2, which is ancient, and using any OpenGL facility newer than that means accessing it via OpenGL's extension mechanism. There's another library, GLEW, that's aimed at making using OpenGL under these circumstances tolerable.
So OpenGL is a cross-platform API, but you will most likely need to use some amount of platform specific code around your core OpenGL code in order to use it effectively. GLUT probably would be a good cross-platform option, at least for learning OpenGL, except that it hasn't been updated on OS X to support the OpenGL Core profile introduced with OpenGL 3.x. But even with GLUT you'd have to deal with the differences in how OpenGL facilities are accessed, via the OpenGL extension mechanism or just directly via up-to-date headers.
Since Qt make it easy to make cross platform application it might be nice to consider this API. They have OpenGL module and you can set it up within XCode: http://qtnode.net/wiki/Qt4_with_Xcode.
OpenGL is well worth the time to learn. OpenGL is a C based, platform neutral API
Try starting here to learn the basics of GL.
I recommend using GLUT for you platform independent window work. Find that here
Using freeglut for you platform independent window work will help. Find that here
Related
As a budding game developer here, I am currently practicing with C++ and OpenGL graphics, and the desire is to assemble a skeleton project that I can both use for small game projects, as well as share with some friends with like interest.
The target is OpenGL 3.3+ (using no deprecated mechanisms such as 'glBegin' etc.), using the libraries SDL 2.0, GLEW 1.10.0 (with WGLEW) and GLM 0.9.4.5. I'm developing with Visual Studio 2012, and primarilly for Windows, but multi-platform compatibility is also desireable if possible to achieve.
The problem at hand is that I am now trying to implement Anti- Aliasing. Most sources appear to tell me that in order to achieve this, I first need to create a dummy context, in order to get access to certain OpenGL functionality, activating multisampling, and lastly spawn a proper rendering context. As described on [OpenGLs pages](http://www.opengl.org/wiki/Creating_an_OpenGL_Context_%28WGL%29"Creating an OpenGL Context").
What I ponder then, is this;
Most guides, examples and other, tend to either mix SDL-functionality and OpenGL calls, or build functions focusing entirely on OpenGL calls. While I would be able to reproduce this with some digital elbow grease; half the reason I desire to use SDL is not to have to manage window handles, pixelformats and such too much myself, but let SDL take care of this.
As such I ask you now;
Can I somehow create a dummy context, initiate things such as Multisampling and Anisotropy, and transfer into a proper context solely through support libraries such as SDL 2.0, or will I have to get my hands into the OpenGL API (preferably through GLEW then) and build a few launcher functions such as others have? If I need to myself, would not much of the purpose of SDL be lost?
I am aware that there were similar questions in past few years, but after doing some researches I still can't decide where from and what should I learn.
I would also like to see your current, actual view on modern OpenGL programming with more C++ OOP and shader approach. And get sure that my actual understanding on some things is valid.
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware
(what does it mean?) and set of 'side' libraries, to for example create window.
There is the most common GLUT, which I extremely hate. One of main reason are function calls, which doesn't allow freedom in the way how we create main loop. As some people were telling, it was not meant for games.
There is also GLFW, which actually is quite nice and straight-forward to me. For some reason people use it with GLUT. ( which provides not only window initialisation, but also other utilities? )
And there is also SFML and SDL ( SDL < SFML imo ), whereas both of them sometimes need strange approach to work with OGL and in some cases are not really fast.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
Let's mention education part now. There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
So... currently we have OpenGL 4.2 out, which as I read somewhere requires dx11 hardware (what does it mean?) and set of 'side' libraries, to for example create window.
DX11 hardware is... hardware that has "supports DirectX 11" written on the side of the box. I'm not sure what it is you're asking here; are you unclear on what Direct3D is, what D3D 11 is, or what separates D3D 11 from prior versions?
FYI: D3D is a Windows-only alternative to using OpenGL to access rendering hardware. Version 11 is just the most recent version of the API. And D3D11 adds a few new things compared to D3D10, but nothing much that a beginner would need.
OpenGL is a specification that describes a certain interface for graphics operations. How this interface is created is not part of OpenGL. Therefore, every platform has its own way for creating an OpenGL context. Windows uses the Win32 API with WGL. X-Windows uses the X-Windows API with GLX functions. And so forth.
Libraries like GLUT, GLFW, etc are libraries that abstract all of these differences. They create and manage an OpenGL window for you, so that you don't have to dirty your code with platform-specific details. You do not have to use any of them.
Granted, if you're interested in learning OpenGL, it's best to avoid dealing with platform-specific minutae like how to take care of a HWND and such.
And we have also GLEW, which is extension loading utility... wait... isn't GLUT/GLFW already an extension? Is there any reason to use it, like are there any really important extensions to get interested with?
This is another misunderstanding. GLUT is a library, not an extension. An OpenGL extension is part of OpenGL. See, OpenGL is just a specification, a document. The implementation of OpenGL that you're currently using implements the OpenGL graphics system, but it may also implement a number of extensions to that graphics system.
GLUT is not part of OpenGL; it's just a library. The job of GLUT is to create and manage an OpenGL window. GLEW is also a library, which is used for loading OpenGL functions. It's not the only alternative, but it is a popular one.
Untill now we have window creation (and some utilities), but... OGL doesn't take care of loading textures, neither 3D models. How many other libs do I need?
OpenGL is not a game engine. It is a graphics system, designed for interfacing with dedicated graphics hardware. This job has nothing to do with things like loading anything from any kind of file. Yes, making a game requires this, but as previously stated, OpenGL is not a game engine.
If you need to load a file format to do something you wish to do, then you will need to either write code to do the loading (and format adjustment needed to interface with GL) or download a library that does it for you. The OpenGL Wiki maintains a pretty good list of tools for different tasks.
There is (in)famous NeHe tutorial. Written in C with use of WinApi, with extremely unclear code and outdated solutions, yet still the most popular one. Some stuff like Red Book can be found, which are related to versions like 2.x or 3.x, however there are just few (and unfinished) tutorials mentioning 4.x.
What to go with?
The OpenGL Wiki maintains a list of online materials for learning OpenGL stuff, both old-school and more modern.
WARNING: Shameless Self-Promotion Follows!
My tutorials on learning graphics are pretty good, with many sections and is still actively being worked on. It doesn't teach any OpenGL 4.x-specific functionality, but OpenGL 3.3 is completely compatible with 4.2. All of those programs will run just fine on 4.x hardware.
If you are writing a game, I would avoid things like GLUT, and write your own wrappers that will make the most sense for your game rendering architecture.
I would also avoid OpenGL 4.2 at this point, unless you only want to target specific hardware on specific platforms, because support is minimal. i.e., the latest version of Mac OSX Lion just added support for OpenGL 3.2.
For the most comprehensive coverage of machines made in the last few years, build your framework around OpenGL 2.1 and add additional support for newer OpenGL features where they make sense. The overall design should be the same. If you're only interested in targeting "current" machines, i.e. machines from late 2011 and forward, build your framework around OpenGL 3. Only the newest hardware supports 4.2, and only on Windows and some Linux. If you're interested in targeting mobile devices and consoles, use OpenGL ES 2.0.
GLEW loads and manages OpenGL Extensions, which are hardware extensions from different vendors, as opposed to GLUT which is a toolkit for building OpenGL applications, completely different things. I would highly recommend using GLEW, as it will provide a clean mechanism for determining which features are available on the hardware it is being run on, and will free you from the task of having to manually assign function pointers to the appropriate functions.
OpenGL SuperBible is a pretty good book, also check OpenGL Shading Language. Everything you do with modern OpenGL is going to involve the use of shaders - no more fixed functionality - so your biggest challenge is going to be understanding GLSL and how the shader pipelines work.
I'm currently learning modern OpenGL as well. I've also had hard time finding good resources, but here's what I've discovered so far.
I searched for a good book and ended up with OpenGL ES 2.0 Programming Guide, which I think is the best choice for learning modern OpenGL right now. Yes, the book is about OpenGL ES, but don't let that scare you. The good thing about OpenGL ES 2.0 is that all the slow parts of the API have been removed so you don't get any bad habits from learning it while it's still very close to desktop OpenGL otherwise, with only a few features missing, which I think you can learn rather easily after you've mastered OpenGL ES 2.0.
On the other hand, you don't have the mess with windowing libraries etc. that you have with desktop OpenGL and so the book on OpenGL ES won't help you there. I think it's very subjective which libraries to use, but so far I've managed fine with SDL, ImageMagick and Open Asset Import Library.
Now, the book has been a good help, but apart from that, there's also a nice collection of tutorials teaching modern OpenGL from ground up at OpenGL development on Linux. (I think it's valid on other OSes the name nevertheless.) The book, the tutorials and a glance or two every now and then to the Orange Book have been enough in getting me understand the basics of modern OpenGL. Note that I'm still not a master in the area, but it's definitely got me started.
I agree that it's king of hard to get in to OpenGL these days when all the tutorials and examples use outdated project files, boken links etc, and if you ask for help you are just directed to those same old tutorials.
I was really confused with the NeHe tutorials at first, but when I got a little better understanding of C, compiling libraries on UNIX and other basic stuff, it all fell into place.
As far as texture loading, I can recommend SOIL:
http://www.lonesock.net/soil.html
I'm not sure but I recall I had trouble compiling it correctly, but that may have been my low experience at the time. Give me a shout if you run into trouble!
Another usefull tip is to get a Linux VM running and then you can download the NeHe Linux example code and compile it out of the box. I think you just need GLUT for it to work.
I also prefer GLFW before GLUT, mainly because GLUT isn't maintained actively.
Good luck!
The major point of modern OpenGL is tesselation and new type of shader programs so i would like to recommend to start from a standalone tutorial on OpenGL 4 tesselation, i.e: http://prideout.net/blog/?p=48
After manuals and tutorials a good follow-up is to take a look at the open-source engines out there that are based on top of "new" OpenGL 3/4. As one of the developers, I would point at Linderdaum Engine.
"Modern OpenGL programming with more C++ OOP and shader approach" makes me mention Qt. It hasn't been mentioned yet but Qt is a library that is worth learning and is the easiest way to write cross platform C++ apps. I also found it the easiest way to learn OpenGL in general since it easily handles the initialization and hardware specific code for you. Qt has it's own math libraries as well so all you need to get started with OpenGL is Qt. VPlay is a library that uses Qt to help people make games easily so there are obviously some people using Qt to make games as well.
For a short introduction to Qt and OpenGL see my post here.
I will mention that since Qt abstracts some OpenGL code, if you are trying to use the Qt wrappers, the API is slightly different than just OpenGL (although arguably simpler).
As for my vote for good tutorials or book check out Anton's OpenGL tutorials and Swiftless tutorials. Anton's ebook on Amazon is also rated higher than any other OpenGL published resource I have seen so far (and far cheaper).
I'm writing an implementation for OpenVG and OpenGL|ES in Go, both of which depend on the Khronos EGL API, supposedly to ease portability I guess.
I'm writing an implementation of OpenVG on top of OpenGL ES for fun and educational reasons - I haven't done a lot of rendering work and I'd like to learn more about the open APIs and practice implementing well defined standards (easier to see if I got the right results).
As I understand it, EGL provides a standard API for retrieving a drawing context (or what ever it's rightly called,) instead of using one of the multiple OS provided APIs (GLX, WGL etc)
I have a hard time believing Khronos would go through such effort and leave the standard OpenGL out of the loop but the thing is, I haven't found how or if OpenGL (the real deal) interfaces with EGL or if it's only OpenGL ES. If OpenGL ES can use the drawing context from EGL, would standard OpenGL also work?
I'm really new to all of this which is why I'm excited but the real project I'm doing is a Go widget toolkit that utilizes OpenVG for its drawing operations and uses hardware acceleration wherever possible.
If OpenVG, OpenGL and OpenGL ES depend on EGL, I think my question can be answered with "yes" or "no". Just keep in mind that I dove into this subject head-first last night.
Does OpenGL use or depend on EGL?
Off topic, but there is no EGL tag. Should there be?
You can bind EGL_OPENGL_API as the current API for your thread, via the eglBindAPI(EGLenum api); a subsequent eglCreateContext will create an OpenGL rendering context.
From the EGL spec, p42:
Some of the functions described in this section make use of the current rendering API, which is set on a per-thread basis
by calling
EGLBoolean eglBindAPI(EGLenum api);
api must specify one of the supported client APIs , either EGL_OPENGL_API,
EGL_OPENGL_ES_API, or EGL_OPENVG_API
The caveat is that the EGL implementation is well within its rights not support EGL_OPENGL_API and instead generate an EGL_BAD_PARAMETER error if you try to bind it.
It's also hard to link to libGL without picking up the AGL/WGL/GLX cruft; the ABI on these platforms require that libGL provides those entry points. Depending on what platform you're playing with this may or may not be a problem.
Does OpenGL use or depend on EGL?
No. You can run OpenGL without EGL.
But is possible to have EGL implementation capable to create desktop OpenGL context. That's because EGL's eglBindAPI(int api) allows EGL_OPENGL_API, EGL_OPENGL_ES_API, or EGL_OPENVG_API.
But if you ask:
Does OpenGL-ES use or depend on EGL?
The answer is yes, but there are exceptions.
Currently (2015), you have several implementations of OpenGL-ES that rely on EGL to create graphics context: Google ANGLE, PowerVR, ARM MALI, Adreno, AMD, Mesa, etc.
But on recent releases of NVIDIA and Intel drivers you can also request OpenGL-ES contexts directly, where extensions WGL_EXT_create_context_es_profile and WGL_EXT_create_context_es2_profile are available (Windows). Same thing on Unix platforms where GLX_EXT_create_context_es_profile and GLX_EXT_create_context_es2_profile extensions are available.
The intent of EGL is to ease developers' lives by creating a portable and standard way to initialize and get context of supported graphics API, without worrying about platform specific issues, as WGL, GLX, etc. That is a problem of EGL implementers, not final programmer.
There is no relationship between OpenGL and EGL. EGL generally does not run on desktops, and there is no ability to create a desktop OpenGL context through EGL.
OpenGL contexts are instead created and managed by platform-specific APIs. On Windows, the WGL API is used. On X11-based platforms, GLX is used. And so forth.
There was some noise last year from Khronos about creating a version of EGL that could work on the desktop and make OpenGL contexts, but thus far, nothing came of it.
I'm about to start working on a custom cross platform engine (c++) that will need to be able to support the latest versions of both OpenGL and DirectX. The renderer is chosen before compilation.
I'm looking at cross platform libraries to handle window creation and input that can also handle the latest implementations of DX and OGL - preferably low profile and most importantly: fast. Any recommendations?
Thanks!
SDL is probably the most used cross-platform library for that kinda thing.
You should check out SFML (Simple Fast Media Library). Although SDL is much more well-known due to its older age, SFML is far richer functionality- and design-wise, despite being only a few years old. It can essentially be described as a newer, more modern, and object-oriented SDL (it's C++; SDL is C).
To give you a brief overview of its features:
Cross-platform (Windows, Mac OS X,
and Linux).
Has modules for system-related stuff
(events, timers, etc), windowing,
video (hardware-accelerated OpenGL 2D
graphics), audio, and networking.
Supports all essential and mainstream
image and audio file formats, with
the notable exception of MP3 due to
licensing issues (although this is
available as an extension).
Also supports fonts (FreeType2 is
integrated) and many other things.
I use it for all my projects that need more than just a command line and I love it. I highly recommend it.
It should be able to provide a good base for your idea.
wxWidgets.
The OpenGL and DirectX are somewhat similar yet very different. OpenGL is built with idea to forward developers desire to render to devices if available. DirectX is built with idea to make rendering capabilities of devices available for developer.
Thanks to differences you end up implementing almost everything twice. Manipulating windows is quite minor issue. You do not need exactly same windows since you will use one or another anyway for rendering in them.
It is perhaps best to use different things for creating the windows (like SDL for OpenGL and MS API for DirectX) and wrap it behind common interface. Then the "things" will be also chosen before compilation. Where MS API is not available there you will lack DirectX too, so no need to make it portable.
Irrlicht
Ogre
Both are fast and powerful. They fit great for games, if I'm getting right your intention.
Eventually, when I've finished the game I'm writing, I'd like to port it to XNA. I'm using C++ and OpenGL at the moment. My question is simply this: does XNA support OpenGL (I can switch from C++ to XNA language if need be)?
No, not directly. XNA is built upon DirectX.
You can spin off a separate window, using a wrapper around OpenGL if you want however. You'll need to use a unofficial binding though, in order to do this. Then use XNA constructs within this. I've worked on a project like this and wouldn't reccommend it. There are two ways to use XNA. The by the book approach, which is too limited for most, or the other way. The 'other' way being not making use of the base game classes and handling your own game logic. With the second approach using another rendering method is too much work for no real pay off.
I'd recommend that for your current game the logic and graphics are separate. If you do decide to port at a later date, the transfer should be easier to convert from C++ to C#.
Also, XNA is not a language. It's a framework built using C#.
The XnaTouch implementation runs on iPhone and so uses OpenGL ES under the hood. It uses C# via the Mono project (specifically MonoTouch for the iPhone). This could conceivably be used as a base to port XNA to other platforms that don't support DirectX (eg: Mac, Linux).
(Note: in my experience the XnaTouch implementation is not very good.)
Obviously the Xbox 360 doesn't use OpenGL at all - it uses DirectX - you don't get an option about this.
And I don't even understand why you'd want to use XNA, but with OpenGL under the covers, on Windows when the existing XNA implementation works just fine.