I am learning OpenGL with the help of tutorials found online. Many of them use GLUT library, even though it is generally recommended to use freeglut instead. How will replacing GLUT header file with freeglut header affect the compilation ? Is such a simple replacement possible ? Are there many differences in terms of syntax, function names and usage ?
As mentioned by Andon, replacing the header will do next to nothing. The FreeGLUT about page has a good description of the what and why (http://freeglut.sourceforge.net/index.php).
Why not to use GLUT, from the above link:
The original GLUT library seems to have been abandoned with the most
recent version (3.7) dating back to August 1998. Its license does not
allow anyone to distribute modified library code. This would be OK, if
not for the fact that GLUT is getting old and really needs
improvement. Also, GLUT's license is incompatible with some software
distributions (e.g., XFree86).
As for the syntax and function names, if your code currently compiles fine with GLUT, it should compile fine with FreeGLUT. You may need to tell the compiler to use/link against FreeGLUT instead of GLUT (and where to find it).
A quick Google search produced this result (using FreeGLUT), might be useful... http://peon-developments.blogspot.com.au/2011/04/creating-opengl-window-with-freeglut-in.html
Related
I have been searching to get the source code of the header file <graphics.h> and its associated library in order to integrate it with my C++ program.
At the same time, I am interested in those cross-platform libraries that works on more than one compiler. Just to be more explicit, I am talking about those libraries that are used for drawing shapes, lines, and curves in C++.
<graphics.h> is very old library. It's better to use something that is new
Here are some 2D libraries (platform independent) for C/C++
SDL
GTK+
Qt
Also there is a free very powerful 3D open source graphics library for C++
OGRE
<graphics.h> is not a standard header. Most commonly it refers to the header for Borland's BGI API for DOS and is antiquated at best.
However it is nicely simple; there is a Win32 implementation of the BGI interface called WinBGIm. It is implemented using Win32 GDI calls - the lowest level Windows graphics interface. As it is provided as source code, it is perhaps a simple way of understanding how GDI works.
WinBGIm however is by no means cross-platform. If all you want are simple graphics primitives, most of the higher level GUI libraries such as wxWidgets and Qt support that too. There are simpler libraries suggested in the possible duplicate answers mentioned in the comments.
There is a modern port for this Turbo C graphics interface, it's called WinBGIM, which emulates BGI graphics under MinGW/GCC.
I haven't it tried but it looks promising. For example initgraph creates a window, and
from this point you can draw into that window using the good old functions, at the end closegraph deletes the window. It also has some more advanced extensions (eg. mouse handling and double buffering).
When I first moved from DOS programming to Windows I didn't have internet, and I begged for something simple like this. But at the end I had to learn how to create windows and how to handle events and use device contexts from the offline help of the Windows SDK.
The Borland Graphics Interface, the library fronted by the graphics.h header, has been re-implemented atop SDL. This brings support for modern hardware and operating systems (multiple operating systems, in fact, since SDL is fairly portable).
It can be downloaded here prebuilt for a variety of common desktop targets.
Or if you wish to (or must) build it from source, here is a github mirror.
Note that it is a port of a very old software library and will run atop modern tools, so you should check with the instructor if you intend to use it for class assignments. It would be irritating to fail an assignment because you used idioms that require support from a modern compiler and find that they do not compile on a marking system from the 1980s.
You may find it better to get and develop with a virtual machine clone of the marking system to prevent nasty surprises.
graphics.h appears to something once bundled with Borland and/or Turbo C++, in the 90's.
http://www.daniweb.com/software-development/cpp/threads/17709/88149#post88149
It's unlikely that you will find any support for that file with modern compiler. For other graphics libraries check the list of "related" questions (questions related to this one). E.g., "A Simple, 2d cross-platform graphics library for c or c++?".
I recently came across code that includes calls to the functions CUDA_SAFE_CALL, CUT_CHECK_ERROR and CUT_DEVICE_INIT. [note, my question is a general one regarding these kinds of function calls, so I'm not copying the code which is irrelevant here.]
After getting errors on these 3 functions calls, I found that they belong to cutil.h which is no longer a supported library (was used only for SDK examples).
I've found a solution for CUDA_SAFE_CALL which seems to work, here: What is the canonical way to check for errors using the CUDA runtime API?
However, haven't found yet a solution for the other two functions- CUT_CHECK_ERROR and CUT_DEVICE_INIT.
Do you know of anything that can replace these functions specifically and cutil's functions in general?
Don't know if this is relevant - but I'm using CUDA v 6.0, Visual Studio 2010 and windows 7.
You can find replacements in the current CUDA samples. This will require some programming ability on your part, the replacements are not exact drop-ins.
Or you can download a previous cuda SDK package (e.g. CUDA 4.2) which contains those functions, and build the necessary libraries under your current toolchain. You should then be able to link against the function directly for a drop-in replacement.
I can't seem to find where GL_UNSIGNED_INT_8_8_8_8_REV is defined. Googling around, I only seem to find places where it had been defined manually:
#define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367
It doesn't appear to be in gl/GL.h or gl/GLU.h or even anywhere in Windows.h.
Windows ships with an outdated version of <gl/GL.h> (the Windows version of this file was obsolete back in 1998, as of 2013 it still hasn't been updated). You will need to use something like GLEW to get access to modern OpenGL features on Windows. This will provide a complete OpenGL header, as well as a library to automatically detect OpenGL extensions.
From OpenGL wiki:
"For most libraries you are familiar with, you simply #include a header file, make sure a library is linked into your project or makefile, and it all works. OpenGL doesn't work that way."
I work on Windows 64 and I need OpenGL to use it in C++ application. What library I should use? Does microsoft provide its implementation ( I use MinGW, I do not have MS Visual C++ )?
The one that comes with your GPU drivers that you have installed on your machine, Microsoft also provides a software layer for OpenGL emulation but it's stuck at the version 1.1 and it's really old and useless.
What library should I use?
I recommend using GLEW for easy access to functions of OpenGL 1.2 and higher, GLM for mathematics, and one of these image loading libraries.
Does microsoft provide its implementation (of OpenGL)?
Microsoft provides you with the necessary header files and library files to access the OpenGL API. However, in order to use OpenGL functions of version 1.2 and higher, you must use extensions. GLEW does this implicitly for you.
Take a look at glew. It loads needed extensions and core functions.
I have been searching to get the source code of the header file <graphics.h> and its associated library in order to integrate it with my C++ program.
At the same time, I am interested in those cross-platform libraries that works on more than one compiler. Just to be more explicit, I am talking about those libraries that are used for drawing shapes, lines, and curves in C++.
<graphics.h> is very old library. It's better to use something that is new
Here are some 2D libraries (platform independent) for C/C++
SDL
GTK+
Qt
Also there is a free very powerful 3D open source graphics library for C++
OGRE
<graphics.h> is not a standard header. Most commonly it refers to the header for Borland's BGI API for DOS and is antiquated at best.
However it is nicely simple; there is a Win32 implementation of the BGI interface called WinBGIm. It is implemented using Win32 GDI calls - the lowest level Windows graphics interface. As it is provided as source code, it is perhaps a simple way of understanding how GDI works.
WinBGIm however is by no means cross-platform. If all you want are simple graphics primitives, most of the higher level GUI libraries such as wxWidgets and Qt support that too. There are simpler libraries suggested in the possible duplicate answers mentioned in the comments.
There is a modern port for this Turbo C graphics interface, it's called WinBGIM, which emulates BGI graphics under MinGW/GCC.
I haven't it tried but it looks promising. For example initgraph creates a window, and
from this point you can draw into that window using the good old functions, at the end closegraph deletes the window. It also has some more advanced extensions (eg. mouse handling and double buffering).
When I first moved from DOS programming to Windows I didn't have internet, and I begged for something simple like this. But at the end I had to learn how to create windows and how to handle events and use device contexts from the offline help of the Windows SDK.
The Borland Graphics Interface, the library fronted by the graphics.h header, has been re-implemented atop SDL. This brings support for modern hardware and operating systems (multiple operating systems, in fact, since SDL is fairly portable).
It can be downloaded here prebuilt for a variety of common desktop targets.
Or if you wish to (or must) build it from source, here is a github mirror.
Note that it is a port of a very old software library and will run atop modern tools, so you should check with the instructor if you intend to use it for class assignments. It would be irritating to fail an assignment because you used idioms that require support from a modern compiler and find that they do not compile on a marking system from the 1980s.
You may find it better to get and develop with a virtual machine clone of the marking system to prevent nasty surprises.
graphics.h appears to something once bundled with Borland and/or Turbo C++, in the 90's.
http://www.daniweb.com/software-development/cpp/threads/17709/88149#post88149
It's unlikely that you will find any support for that file with modern compiler. For other graphics libraries check the list of "related" questions (questions related to this one). E.g., "A Simple, 2d cross-platform graphics library for c or c++?".