I'm interested in converting to Haxe as my primary programming language, and it's been awesome so far, however one of my requirements is that I can use OpenGL 3.3 with the C++ target for some 3D game work.
However, this seems to be an odd thing to do as I can find very little info online about using OpenGL in Haxe. I've found some libraries, especially hx-ogl and foo3d (abstracted ogl-like) but they're all unmaintained and I can't get them to work. I've also found some 3D engines but I'd like to use pure OpenGL. Also, I only need to target C++ so cross-platformness isn't required.
Has anyone successfully got OpenGL working with Haxe C++?
Haxe guys work on OpenGL wrapper continuously but at the moment Haxe (NME) supports the OpenGL ES 2.0 API for both desktop and mobile, which means you can use a programmable shader pipeline on both desktop and mobile. You can see a code example here.
But if you say:
I only need to target C++ so cross-platformness isn't required
Then why won't you use just C++ with whatever OpenGL version you want?
Related
I'm developing a game, actually my first game, so I'm new in this world, I'm using OpenGL with NDK and C++ for the render part, and I call it from java with JNI. I'm stuck with the textures topic, since I need to use PNG with alpha channel and use TTF for some text.
I can include the libpng, but since I'm using the experimental gradle puglin, I don't know how to add the library and use it, I saw that the library can be precompiled and be added, but from what I saw, only for one architecture, then, I don't know if I'm wrong, but I think if I add the source code of the library and compile it with the program, I think, it will be compiled for the architectures that I need (MIPS, 64-bit ARM, x86, 64-bit x86, ARM), so that is one, I was thinking in pre-convert the png in raw RGBA and use that vector directly with opengl but again, I dont know how to do this.
and with the TTF issue, well I am in blank, if you have any advice for this I would greatly appreciate it.
Thanks for your help.
You can build the whole FreeType engine into your code, or you can just use what's already part of Android: use Canvas to render glyphs to a Bitmap. You can find an example of this in Android Breakout. The game is written in Java rather than C++, but the Java-language GLES code is just a thin wrapper around the native stuff, so it's pretty similar.
There's a pretty good blog post about GLES text on Android here.
On a similar note, you already have a copy of libpng in your app. You can call through the Bitmap API to use it.
If you have as a goal the creation of an entirely self-contained native app, then the approach of calling into Canvas/Bitmap isn't viable. I don't think that's a particularly useful goal, however. You're better off separating the "game engine" from the game logic, e.g. have platform-specific "decode PNG" and "pass this pile of RGBA pixels into glTexImage2D()" functions, and platform-agnostic "use texture N".
Taking that one step further, your best approach is to use an existing graphics engine or game engine, and focus on creating the game rather than writing the engine. Learning about engines by writing one is a worthwhile endeavor, but if your actual goal is to write a game then you should focus on the game itself.
I am using Open GL 3.0
I am trying to update this example to modern OpenGL :
http://qt-project.org/doc/qt-4.8/opengl-hellogl-es.html
I am also looking at this example:
http://qt-project.org/doc/qt-5/qtopengl-cube-example.html
I am looking at the OpenGL ES examples, because they compiled and rendered easily on my machine, and the OpenGL ES 2 example uses some programmable pipelining.
I want to use the pipeline functions referenced in this tutorial:
http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/
For instance glGenBuffers()
However, this does not seem to come up in open Qt. If I try to compile a program that uses glGenBuffers, or glBindBuffer.
Why can I use some Open GL functions but not others?
Looking at the second example (OpenGL ES2) There is a type "QGLShaderProgram" which seems to wrap some of the shading functions, but I am at loss as to how to follow even a simple open GL tutorial with full access to the rendering functions.
For instance, the openGL tutorial references at least half a dozen functions I can't seem to use. I would be fine with this, but I can't seem to find where the Qt folks have explained what functions are wrapped, or covered up, or are absent.
Could I be missing an include or something?
I am including #QGLWidget and #QtOpenGL
See below for my answer to your question. However, it seems likely you are looking for a simpler OpenGL example with Qt like the triangle one you linked to. I also made an introductory post here where you can learn the basics of how Qt and OpenGL work together before you start an example.
First of all use Qt 5.5 now. It is configured with the -opengl dynamic option by default which might solve your problem. If you don't have -opengl desktop configure option set in your pre 5.5 build of Qt then you won't have access to modern OpenGL functions other than the subset of OpenGL ES 2 that is supported by all the platforms Qt supports.
Second, don't use the QGL* functions or classes as they are old/deprecated now. They were replaced by the QOpenGL* functions and classes.
As for includes, you will need a QOpenGLFunctions or QOpenGLFunctions_3_0 to know for sure which set of functions you are getting. You will also need any other classes like QOpenGLBuffer QOpenGLVertexArrayObject... or just include QtGui as that is where all the OpenGL functions and classes are now.
I'm just trying to get a grasp on OpenGL that I can build from, so all I'm looking for is something basic to build windows etc. One of the things I'm noticing as I read tutorials and such is that it seems like a lot of the information is out of date - for example a lot of tutorials (many of which were written a number of years ago) refer to using GLUT, but GLUT hasn't been updated in over 10 years - eons in computer time. What do people use nowadays? I know freeglut is out there, but there isn't a whole lot of info on it - how to get it set up, etc... what do most people do? What's the simplest way to get a simple window system up and running so that I can start playing around with OpenGL?
You should first understand the difference between Legacy OpenGL which is a fixed function pipeline, and modern OpenGL which is a completely shader driven pipeline. Most online tutorials teach legacy OpenGL because it is easy to get started and has been around a long time. Legacy still works fine, but you probably want to get into modern OpenGL (at least version 3.0). Modern OpenGL is cleaner, and more flexible, but also harder to get started in, and therefore has fewer tutorials. It requires a lot more setup and libraries by the user and there is no "one way" to do things making it difficult to structure a quick tutorial around.
Some good resources for learning modern OpenGL are:
http://www.opengl-tutorial.org/ - Great lessons written by Stack overflow user.
http://opengles-book.com/ - OpenGL ES 2.0 programming guide - OpenGL ES 2.0 is directly compatible with OpenGL 3.0, so it works great for getting started. Even if you don't want to buy the book you can download sample code which is excellent.
http://www.swiftless.com/ - Swiftless Tutorials - Great OpenGL 4.0 and WebGL tutorials.
To your main question I know of 3 main libraries for cross platform OpenGL window creation. I would recommend GLFW for a cross platform tool kit. You could also learn a lot by creating a context directly in your respective platform (WGL window creation on Windows, Cocoa on MacOS X etc) rather than using a windowing library.
GLUT - you are correct it has not been updated in years. It still works, especially for legacy OpenGL, but I'm not sure how good the modern support is.
SDL - Also old and legacy OpenGL (I think this is resolved with 2.0), and includes a lot more cross platform features beyond OpenGL like threads. It is a pretty heavyweight library but I still prefer it over GLUT. A modern, updated SDL was in the works, but i haven't seen anything for it in a long time, possibly discontinued... It also has a nasty license associated with it so watch out for that.
GLFW - My personal favorite. It is clean and lightweight like GLUT and allows you to target modern OpenGL contexts on most major desktop platforms.
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 am working on a gaming framework of sorts, and am a newcomer to OpenGL. Most books seem to not give a terribly clear answer to this question, and I want to develop on my desktop using OpenGL, but execute the code in an OpenGL ES 2.0 environment. My question is twofold then:
If I target my framework for OpenGL on the desktop, will it just run without modification in an OpenGL ES 2.0 environment?
If not, then is there a good emulator out there, PC or Mac; is there a script that I can run that will convert my OpenGL code into OpenGL ES code, or flag things that won't work?
It's been about three years since I was last doing any ES work, so I may be out of date or simply remembering some stuff incorrectly.
No, targeting OpenGL for desktop does not equal targeting OpenGL ES, because ES is a subset. ES does not implement immediate mode functions (glBegin()/glEnd(), glVertex*(), ...) Vertex arrays are the main way of sending stuff into the pipeline.
Additionally, it depends on what profile you are targetting: at least in the Lite profile, ES does not need to implement floating point functions. Instead you get fixed point functions; think 32-bit integers where first 16 bits mean digits before decimal point, and the following 16 bits mean digits after the decimal point.
In other words, even simple code might be unportable if it uses floats (you'd have to replace calls to gl*f() functions with calls to gl*x() functions.
See how you might solve this problem in Trolltech's example (specifically the qtwidget.cpp file; it's Qt example, but still...). You'll see they make this call:
q_glClearColor(f2vt(0.1f), f2vt(0.1f), f2vt(0.2f), f2vt(1.0f));
This is meant to replace call to glClearColorf(). Additionally, they use macro f2vt() - meaning float to vertex type - which automagically converts the argument from float to the correct data type.
While I was developing some small demos three years ago for a company, I've had success working with PowerVR's SDK. It's for Visual C++ under Windows; I haven't tried it under Linux (no need since I was working on company PC).
A small update to reflect my recent experiences with ES. (June 7th 2011)
Today's platforms probably don't use the Lite profile, so you probably don't have to worry about fixed-point decimals
When porting your desktop code for mobile (e.g. iOS), quite probably you'll have to do primarily these, and not much else:
replace glBegin()/glEnd() with vertex arrays
replace some calls to functions such as glClearColor() with calls such as glClearColorf()
rewrite your windowing and input system
if targeting OpenGL ES 2.0 to get shader functionality, you'll now have to completely replace fixed-function pipeline's built in behavior with shaders - at least the basic ones that reimplement fixed-function pipeline
Really important: unless your mobile system is not memory-constrained, you really want to look into using texture compression for your graphics chip; for example, on iOS devices, you'll be uploading PVRTC-compressed data to the chip
In OpenGL ES 2.0, which is what new gadgets use, you also have to provide your own vertex and fragment shaders because the old fixed function pipeline is gone. This means having to do any shading calculations etc. yourself, things which would be quite complex, but you can find existing implementations on GLSL tutorials.
Still, as GLES is a subset of desktop OpenGL, it is possible to run the same program on both platforms.
I know of two projects to provide GL translation between desktop and ES:
glshim: Substantial fixed pipeline to 1.x support, basic ES 2.x support.
Regal: Anything to ES 2.x.
From my understanding OpenGL ES is a subset of OpenGL. I think if you refrain from using immediate mode stuff, like glBegin() and glEnd() you should be alright. I haven't done much with OpenGL in the past couple of months, but when I was working with ES 1.0 as long as I didn't use glBegin/glEnd all the code I had learned from the standard OpenGL worked.
I know the iPhone simulator runs OpenGL ES code. I'm not sure about the Android one.
Here is Windows emulator.
Option 3) You could use a library like Qt to handle your OpenGL code using their built in wrapper functions. This gives you the option of using one code base (or minimally different code bases) for OpenGL and building for most any platform you want. You wouldn't need to port it for each different platform you wanted to support. Qt can even choose the OpenGL context based on the functions that you use.