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.
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 am little bit confused how does opengl32.lib library work - without any extensions for opengl version bigger than 1.1.
Does opengl32 lib implement OpenGL 1.1 functions, or just it's retrieving them from graphic driver as new OpenGL functions? If yes, shouldn't GPU vendors implement OpenGL? Does the opengl32 lib work like a part of graphic driver that implements OpenGL? If I won't have graphic driver installed, will opengl32 work(just the base v. 1.1 of course)? Thanks.
Many years ago, those of OpenGL 1.1, opengl32.dll provided all gl-functions needed. When newer versions came in scene it was also the case that vendors implemented "extensions" functions to standard functions. And there was also the case where two different graphics cards may be installed at once. If all of this should be handled by the OS, then man, what a nightmare!
The solution was that each vendor provides his driver, for example Nvidia's nvoglv32.dll. Now opengl32.dll looks in Windows’ system registry and if it finds a vendor driver loads it and let it handles the gl-stuff. If there's not a vendor implementation then opengl32.dll handles gl-stuff, but only for OGL version 1.1.
opengl32.lib (not .dll) is a linker symbol stub. It says that opengl32.dll is needed by the executable.
opengl32.a is the same as opengl32.lib. The .lib is provided by MS VS and the .a is provided by MingGW.
http://opengl.org/ and http://www.khronos.org/ seems to be currently unavailable. Is there any good alternative mirror sites?
I am looking for OpenGL 4.4 Libraries and Includes download for VC.
OpenGL is not a library, it's an API specification. What you can download at http://opengl.org are just the specification documents and reference C include headers. But there are no library downloads there because, well, OpenGL is not a library.
The actual OpenGL implementation ships as part of your GPU's driver. That's also what ultimately determines which version of OpenGL you can use: The GPU on the system the program is executed on. The major OpenGL version designates the hardware class. A OpenGL-3 class GPU can not do OpenGL-4 (but a OpenGL-4 can do OpenGL-3 of course).
For all practical means there's nothing you need to download or to install to get working with OpenGL. This is different from DirectX where you need a special SDK. OpenGL has been included into the ABI (Application Binary Interface) of the major operating systems, including Windows, and hence the standard headers ship with compilers targeted at this system.
In your case you'll find the OpenGL base headers being preinstalled with the default installation of Visual-C++.
However newer versions of OpenGL require additional tokens and functions to be defined. That's where extension headers come into play. But since there's no change in the ABI, the actual functions do not come as part of a library but must be loaded at runtime using wglGetProcAddress for each function.
Since this is a tedious process there are OpenGL extension loader wrapper libraries, like GLEW (available at http://glew.sf.net) which package up the extension headers and some library code to do the whole loading thing with just a single command. Since there are things to consider like namespace pollution and interoperability with other means of extension loading, GLEW patches into the regular OpenGL headers with preprocessor macro definitions, so that all compilation units that include GLEW just use GLEW. This makes it look like GLEW replaces the regular headers and interface libraries, but in reality it just builds on and defers to them.
Well, usually you want to use glew or a similiar library in order to get the OpenGL functions. You can grab a copy of glew here: http://glew.sourceforge.net/. The libraries should come bundled with VC so you simply add OpenGL32.lib to your linker's additional dependencies.
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 want to create a simple game like Space Invaders. I know that I can use Android NDK, but I have to port the libraries that I use. I can not use third-party proprietary libraries.
I will use OpenGL, but OpenGL API seems different on Android. I have to use jpeg and png textures, and write texts. Can I compile libjpeg, libpng and freetype for Android?
I can not have specific implementation of the game engine (C++) and rendering routines (C++ and OpenGL), because that is the complex part.
There are components that I am disposed to implement for each platform. There is no problem with windowing system and user input, because I will use a specific implementation for each system, it is simple for me.
I use SDL and its extensions for audio on PC, but it is easy to use. I can use specific audio libraries for Android.
Thanks
Can I compile libjpeg, libpng and freetype for Android?
Yes you will have to recompile all the native libraries specifically for Android. Yes, you do need the source code for all 3rd party native libs you plan to use simply because Usually when we compile and link these libraries outside Android they are linked to glibc but unfortunately Android doesn't use glibc due to liscence and performance issues. Android uses a watered down version of glibc called libc. It has matching symbol names to glibc for most of the usual functionalities. But as far as i know the libc doesn't have some functionality related to Strings and it definitely doesnt have some posix support. If your native libraries are using any of the deprecated functionality you will have to find workaround for those by using alternative functionality supported by libc and coding your libs accordingly.
Also, as you righty pointed out you will have to use the NDK to interface Java(Android app/fwk) to native world(C++).
Though this sounds pretty simple in my experience compiling native libraries on Android(Android porting) has traditionally been very time consuming with no guarantee of sucesses.