I'm getting started with OpenGL and decided to go with OpenGL 2.1. The reason I want to do this is, because it's easier and I want my programs to be compatible with old hardware. However I don't know if I can get a compatibility profile in linux.
Can I get OpenGL 2.1 program working in a linux machine with mesa (let me be more specific there, a mesa's version that implements the OpenGL 3.x+)?
If not, using OpenGL 2.1 makes my programs being less compatible with new hardware (in linux)?
Don't know what to do here. Any help is apreciated
I am a Linux developer.
OpenGL 2.1 has no concept of compatibility profiles; that only appears in OpenGL 3.x+, where using the compatibility profile adds back the features that were removed.
If you request an OpenGL 2.1 context and you get it, you're all set. And yes, Mesa supports OpenGL 2.1.
Using an old version of GL could, in theory, make your program incompatible with a driver that only supports OpenGL 3.1+ with only the core profile. In practice though, virtually every desktop GPU driver still supports old OpenGL.
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 read that macOS Mojave does not support OpenGL anymore. I have to make a small C project for University with OpenGL using gcc.
Does macOS Mojave not supporting OpenGL anymore mean that I wont be able to compile such files anymore under macOS? Or will it still be possible?
Or do I have to install Linux / Windows for that?
OpenGL does still work, and can be compiled against, under Mojave (i.e. the OpenGL.framework is still in System/Library/Frameworks, and you can select the framework in in Xcode for development).
However, Apple announced that it is deprecated from now on. This means that it might be removed in any later version and limited development will go into it (i.e. don't expect bug fixes any more).
I am working on a game engine and it has evolved greatly. Because the engine needs to work on mac also, I am still using OpenGL 3.2 and GLSL 1.2 :-(.
I use GLEW which I assumed would solve extension issues for me.
EDIT: Meanwhile, part of the question is answered - read on at the next EDIT:
I was always able to make shaders work on both windows and mac, sometimes I would have to add a line in the GLSL code like #extension GL_EXT_gpu_shader4 : enable to make it work on Mac. It then seems that my Windows version will give a warning when compiling the same shader, but it will work.
But ever since I started using geometry shaders, my nightmare has begun. For some reason, mac expects me to use #extension GL_EXT_gpu_shader4 : enable while windows expects me to use #extension GL_EXT_geometry_shader4 : enable. This makes it less obvious to create a platform independent shader.
Also, and this is even more annoying:
Windows version wants me to use: glTransformFeedbackVaryings and I would think that GLEW would make it available to the mac but there I explicitly need to use glTransformFeedbackVaryingsEXT which will not work on the windows version. So I need to #ifdef for APPLE to use what's needed.
Same problem with glBeginTransformFeedback and glBeginTransformFeedbackEXT.
But both accept glProgramParameteriEXT, there I don't need the distiction...
I understand that it's only with the transform feedback that I am having the problem, but... what is this all about?
I thought I understood how OpenGL extensions worked, but I am starting to lose that understanding.
It's getting to a point where I think that when I run the code on another windows system or another mac system or another linux system, I will have new problems because there are different graphics adapters or something.
Can anyone help me understand this? I have read the OpenGL manual about extensions, so I am missing something obvious. How can I make sure that my code will always work?
EDIT: By removing GLEW entirely from the Mac version and fully using the Mac's own OpenGL 3.2 implementation, all the namings are normal and I can entirely remove the #extension GL_EXT_gpu_shader4 : enable from my shaders.
The only thing that makes me worry now is that for geometry shaders, I need the function glProgramParameteri which doesn't seem to exist, but glProgramParameteriEXT does. For some reason, this function also works on Windows. Why? Can I be certain that it will work on all systems/hardware?
EXT means that you are using an extension for the geometry shader. This should work on windows as well. Geometry shader should be core functionality in OpenGL 3.2, but right now you are instead using the extension (Basically you are using functionality of older OpenGL versions not actual 3.2). To use the core geometry shader you have to switch to GLSL 1.5.
I am not that well versed in OpenGL but my assumption is, that glProgramParameteri() is actually not necessary anymore if you start using core functionality, that is why it is missing in the library headers.
Your life will be easier if you stick to matching OpenGL/GLSL versions.
http://en.wikipedia.org/wiki/OpenGL_Shading_Language
Pick from:
OpenGL 2.1, with GLSL 120 + GL_EXT_gpu_shader4 + GL_EXT_geometry_shader4
OpenGL 3.2, with GLSL 150
OpenGL 3.3, with GLSL 330
If you are already happy using OpenGL 3.2, then step up to GLSL 150, as it's closer to modern GLSL 330+. If you want the most compatibility, use OpenGL 2.1, GLSL 120, plus geometry shader extensions. (though I'm not sure how much more compatibility it buys you)
ONLY when using GLSL 120 plus extensions, you need to use glProgramParameteriEXT() to specify the geometry shader in/out primitive type, and vertex count. For example:
glUseProgram(prog);
glProgramParameteriEXT(prog, GL_GEOMETRY_INPUT_TYPE_EXT, GL_TRIANGLES);
glProgramParameteriEXT(prog, GL_GEOMETRY_OUTPUT_TYPE_EXT, GL_TRIANGLE_STRIP);
glProgramParameteriEXT(prog, GL_GEOMETRY_VERTICES_OUT_EXT, max_output_verticies);
https://wiki.engr.illinois.edu/display/graphics/Geometry+Shader+Hello+World
In OpenGL 3.2, GLSL 150+, you specify this information in your shader, using a declaration like:
#version 150
layout (triangles) in;
layout (triangle_strip, max_vertices = 3) out;
http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/geometry-shader/
Compiler is mingw32. Language is C99. OS is windows. Graphics card is Nvidia 260GTX
I can link against opengl32/glu32 and build against it, but nothing from OpenGL 3.x is included... in fact, I would say its probably missing 2.x extensions!
GLEW and GLM are both C++ and doesn't work with straight C. Glee doesn't have any mingw32 binaries (and doesn't build cleanly on my system).
I'm using SDL and that has some OpenGL functions (??), but again, looks way outdated.
I just I don't understand the fundamental problem on why it's so difficult to get C/OpenGL working on windows? Why is is so unique? Why doesn't the Khronos provide an SDK/libraries/headers, etc?
I do OpenGL via Java/lwjgl and takes no time to set it up and get it compiling/running.
In Windows anything above OpenGL-1.1 is only accessible through extensions. This is how it has been designed and how it goes. GLEW works perfectly well with plain C (if I'm not mistaken GLEW is written in plain C).
Khronos cannot provide a SDK because actually providing the OpenGL API is a task left to the operating system vendor and in Windows the graphics drivers are required to provide the implementation. In the case of Windows this is Microsoft, who left the ARB some years ago, in favour of their proprietary Direct3D technology; there used to be heated debates which was the better API, but now that the whole world, except Microsoft settled on OpenGL this time of arguing is over.
Anyway, if you want things to be really easy, instead of GLUT, SDL, etc. use GLFW http://glfw.org, a really excellent OpenGL framework, that does all the hard things for you, does extension loading and OpenGL-3 context setup if you ask it so (you still need some extension wrapper to use extensions in your own code – however creating a pure OpenGL-3 context requires some proxy context, loading a few extensions using that and use the functions obtained to create a real OpenGL-3 context. Just for clarification).
i know c and I want to develop applications with GUI for Mac OS. Where do I start?
Learn Objective-C.
Then pick up Cocoa (and all of the Frameworks that go with it)
Buy Apple computer
Install XCode from supplied DVD
Run Software Update from system menu
Run XCode
Select Help menu, select "Developer Documentation"
Click on any of the many things that say things like "Quick Start" or "Getting Started with XCode".
Read
Program
GoTo 7.
Downloading xcode would be your first step. It's the main development environment for mac development and it's free. Then you'd want to get a book on Cocoa w/ Objective-C or Carbon w/ C. Apple is pushing Cocoa more.
The Simple DirectMedia Layer (SDL) library is yet another option. It is a cross-platform development library that can be used to write GUI-based applications for Mac OS in C.
While there is Carbon, it's a framework that's not first-class going forward. If you want to make sure that you can access all of the features of Mac OS X, you'll want to learn Objective-C and use Cocoa.
I believe all Macs nowadays come with a complete set of development tools. They're not pre-loaded on the Mac, but are in the CD-ROM or DVD-ROM package. Alternately, you can go to Apple's site and poke around until you find the development section, and download Xcode. (It'll be the same thing, but possibly a newer version.)
Mac OSX uses a language called Objective-C, which is C extended with OO abilities that are more like Smalltalk than the more usual Simula type (in C++, say). While you don't actually have to use it much, it is how you'll be writing interface code.
Further, it uses the Cocoa framework. There was a framework called Carbon, which was a cleanup and redesign of the pre-Mac OSX Macintosh system facilities, but it's being left behind.
You can find free information on either if you look, or you can buy books on them. Books are probably a better resource to learn from.
You can also try with QT and C++. Try here:
http://qt.nokia.com/products/platform/qt-for-mac