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.
Related
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
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).
Does anyone have experience writing professional OpenGL games on Windows? For the Mac, due to apple's control, the OS seems quite "uniform". For windows, due to different hardware, different drivers installed, etc ... the hardware base seems to have many many different configurations.
In theory, OpenGL provides a API that abstracts all this away. In practice, many drivers are often buggy and have weird cases -- has this been a problem for developing games on Windows?
Thanks!
The two biggest GPU vendors (Nvidia and ATI) both provide OpenGL 3.x drivers, which take advantage of the latest features of modern hardware. As Chris points out, the main issue is that the user will need to install the latest drivers from the vendors themselves, as Windows ships with the most rudimentary OpenGL support (thanks to Microsoft, who seem to do everything they can to knife OpenGL and push DirectX). So provided they have recent drivers, you should be fine.
There are inevitably some (mostly minor) differences between the drivers. For example, I've noticed Nvidia's GLSL compiler is a little more picky than ATI's, and rejects some shader code that otherwise works fine. Bottom line is you need to test on both (which you would be doing anyway).
The gDebugger tool seems to be pretty good at tracking down performance issues. (The OpenGL tools that ship free with Xcode are pretty awesome though.)
You'll need to get glext.h from the OpenGL extensions registry and figure out the base requirements for your app. You probably don't want to have alternate code paths based on which extensions are available, if you can help it! And as epatel mentions, there are a few libraries (such as GLEW and GLEE) which help with the process of extension management. I ended up writing my own, as I didn't like those implementations.
There's lots of engines and scene graphs for OpenGL, if you haven't already chosen your toolset.
I've found a few little bugs along the way, but nearly all were easy to work around. These days things are pretty good.
The biggest problem you will face is simply this: Windows 7 does not ship with a hardware OpenGL. If the user does not take the action to replace the default video drivers with updated versions from the vendors site the only OpenGL support they have will be a ~v1.0 software renderer.
I haven't yet made a professional OpenGL game on Windows, but I think one important thing is to query the OpenGL drivers about what capabilities (extensions) are available and handle those functions. There is also a package to handle this in a platform independent way with the GLEW library. Think that is a good start to understand how to handle different OpenGL capabilities.
The OpenGL Extension Wrangler Library (GLEW) is a cross-platform open-source C/C++ extension loading library. GLEW provides efficient run-time mechanisms for determining which OpenGL extensions are supported on the target platform. OpenGL core and extension functionality is exposed in a single header file. GLEW has been tested on a variety of operating systems, including Windows, Linux, Mac OS X, FreeBSD, Irix, and Solaris.
One thing I always shy away from is 3d graphics programming, so I've decided to take on a project working with 3d graphics for a learning experience. I would like to do this project in Linux.
I want to write a simple 3d CAD type program. Something that will allow the user to manipulate objects in 3d space. What is the best environment for doing this type of development? I'm assuming C++ is the way to go, but what tools? Will I want to use Eclipse? What tools will I want?
OpenGL/SDL, and the IDE is kind-of irrelevant.
My personal IDE preference is gedit/VIM + Command windows. There are tons of IDE's, all of which will allow you to program with OpenGL/SDL and other utility libraries.
I am presuming you are programming in C, but the bindings exist for Python, Perl, PHP or whatever else, so no worries there.
Have a look online for open-source CAD packages, they may offer inspiration!
Another approach might be a C#/Mono implementations ... these apps are gaining ground ... and you might be able to make it a bit portable.
It depends on what exactly you want to learn.
At the heart of the 3d stuff is openGL, there is really no competitor for 3d apps, especially on non-windows platforms.
On top of this you might want a scenegraph (osg, openscengraph, coin) - this handles the list of objects you want to draw, their relationship to each other in space the ability to move one relative to the others, selecting objects etc. It calls opengGL to do the actual rendering.
Then on top of this you need a gui library. Qt, Fltk, wxWigets or one built into the scene library or written directly in openGL. This handles the menus, dialogs frames etc of your app. It provides an openGL canvas to draw into.
Personal choices are openscenegraph and Qt
For the 3D part, I strongly recommend the SDL Library with the OpenGL library
You can get some tutorials here
Qt has a pretty decent OpenGL-based graphics module.
Maybe you should consider using a graphics rendering engine such as OGRE. Coding a CAD program from scratch using OpenGL will take lots of time.
On Linux you have no competition to OpenGL.
It's one of the big players in the 3D field, so it's definitely worth learning.
This site has some excellent guides and code examples (on various languages).
You can use OpenGL with many languages, naturally on C and C++ but also for example with JAVA using LWJGL or other API's.
If you want to program at "a higher level" than opengl, use vtk. It is quite easy to get started and has bindings to many languages.
See www.vtk.org
you may use OpenSceneGraph for rendering.. it is an OpenGL based library..
and you may use OpenCascade.. it is good for 3D modelling...
we are implementing such an IDE at work and we use these things.. using pure OpenGL may be hard for you... anyway you may try...
for interface it is good to use Qt..
and i suggest you to use Eclipse if it is Linux..
(if it was Windows, suggestion would be Visual Studio)
For a C/C++ IDE, you have the following options:
KDevelop - KDE-based
Anjuta - GTK-based
Netbeans
Eclipse
Of course, you could also use a language like C# or Java:
Best OpenGL Wrappers for Mono and .Net
JOGL
There's really no reason why a simple CAD application would have to be written in C++.
After reading a discussion on Ubuntu Forums concerning GLUT vs. FreeGLUT.
Is GLUT dead for graphics programming? Is SDL all the rage now for OpenGL programming?
In my opinion, GLUT is still great to learn programming OpenGL in. It is no longer maintained, as far as I know.
Do look at : http://www.opengl.org/resources/libraries/glut/ for the official word
Extract from the above link -
"The GLUT library has both C, C++ (same as C), FORTRAN, and Ada programming bindings. The GLUT source code distribution is portable to nearly all OpenGL implementations and platforms. The current version is 3.7. Additional releases of the library are not anticipated.
GLUT is not open source. Mark Kilgard maintains the copyright."
Also look at : http://www.opengl.org/resources/libraries/windowtoolkits/ for alternatives.
You may also want to check out GLUX : http://code.google.com/p/glux/
As far as SDL being the rage, it is great for cross-platform stuff and many people are using it. I personally use Qt for my OpenGL work. Other windowing system alternatives also exist. It is also possible to program natively for windows or X.
Edit Feb 28 2017:
I should clarify that the student looking to jump into the practicalities of OpenGL would be better served by starting with SDL or Qt. As #TM rightly notes in his comment, using GLUT is far removed from the realities of programming a real world rendering application in OpenGL. My opinion that GLUT is good for learning comes from the thought that it is easier to learn when one separates the concern of learning an OpenGL from the concern of learning about the specifics of a Windowing system. Naturally, this may not match your needs.
GLUT is rather simplistic for serious game development. SDL is used by numerous commercial game porting companies. GLUT happens to be good for studying OpenGL and for simple demos. Something like SDL is quite good for actual games.
SDL with its abstractions for other things, such as audio, and SDL's various addon libraries (SDL_image, SDL_mixer, ...) help a lot when writing a full game. Having control over the main loop is also pretty important.
If you are working on an OpenGL application which needs some native GUI as well (for example, a 3D modeler) you may be more interested in using wxWidgets or, as batbrat suggested, Qt.
GLUT is a very useful learning guide, but it's not full featured or useful enough for most real-world applications. I've also encountered minor issues with a few different GLUT implementations and support in some environments, so I've learned to stay away from it for anything but quick demos.
My OpenGL experience has generally been on embedded systems where I have complete control over the output, and there I use X Instrinsics to get the basic OpenGL Window up. It's a bit painful, but it's a small amount of code to get to OpenGL, where the bulk of the work is done.