I downloaded SDL 1.2.14
on Windows 7
and I have Mobility Radeon X1800 driver installed.
I'm using Microsoft Visual C++ 2010 Express.
I added the SDL include and library directories in the "VC++ Directories"
I added the following Additional Dependencies:
opengl32.lib;
glu32.lib;
SDL.lib;
SDLmain.lib;
I added the SDL.dll to my program folder
I didn't add any opengl directories!
#include "SDL.h"
#include "SDL_opengl.h"
bool running = true;
int main(int argc, char* args[]) {
SDL_Init(SDL_INIT_EVERYTHING);
SDL_Surface* screen = SDL_SetVideoMode(640,480,32,SDL_OPENGL);
glViewport(0,0,640,480);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0, 640/480, 1.0, 200.0);
while(running) {
glClear(GL_COLOR_BUFFER_BIT |GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_MODELVIEW); // Swich to the drawing perspective
glLoadIdentity();
glTranslatef(0.0,0.0,-5.0);
glBegin(GL_TRIANGLES);
glVertex3f(-0.5f, 0.5f, 0.0f);
glVertex3f(-1.0f, 1.5f, 0.0f);
glVertex3f(-1.5f, 0.5f, 0.0f);
glEnd();
SDL_GL_SwapBuffers();
}
SDL_Quit();
return 0;
}
This program draws a simple triangle.
I include 2 header files above and my Opengl code just works!
I don't know if my triangle is done on a the GPU or CPU. And what openGL version I'm using?
I mean i heard that Microsoft don't update there opengl files any longer and that they use CPU implementation of OpenGL 1.1 or something.
How do I know what version of OpenGL I'm using? And can I check at run time?
How do I know if I'm using a CPU or GPU implementation? And can I check at run time?
Thanks for look at my problem.
call glGetString
Here is Microsoft's documentation for glGetString. It just repeats the SGI doc and tells you the function is found in gl.h and opengl32.lib.
Actually when you install your video card driver it "replaces" the opengl existing in your machine, so you will be using that version.
Multiple versions of OpenGL are present at the same time, and which one is used depends on the HDC used to initialize OpenGL. For example, applications running in the local login session can get hardware-accelerated GL while those running in a remote desktop session get the CPU-based implementation ( Ben Voigt )
The currently header and lib that comes with Visual Studio only has OpenGL 1.1 in it, so to access more modern stuff you need to call the wglGetProcAddress to get pointers to the new functions.
Here you can find more information: http://www.opengl.org/wiki/Getting_started
Related
I have a program that worked on my computer before I wiped the hard drive and reinstalled the operating system. I reinstalled all the necessary compilers and DLLs but im getting linker errors for glut. below is a snippet of the code I am trying to run and what my compile command is.
Here is the main I am trying to run:
/*
* GL01Hello.cpp: Test OpenGL C/C++ Setup
*/
#include <windows.h> // For MS Windows
#include <GL/freeglut.h> // GLUT, includes glu.h and gl.h
/* Handler for window-repaint event. Call back when the window first appears and
whenever the window needs to be re-painted. */
void display() {
glClearColor(0.0f, 0.0f, 0.0f, 1.0f); // Set background color to black and opaque
glClear(GL_COLOR_BUFFER_BIT); // Clear the color buffer
// Draw a Red 1x1 Square centered at origin
glBegin(GL_QUADS); // Each set of 4 vertices form a quad
glColor3f(1.0f, 0.0f, 0.0f); // Red
glVertex2f(-0.5f, -0.5f); // x, y
glVertex2f( 0.5f, -0.5f);
glVertex2f( 0.5f, 0.5f);
glVertex2f(-0.5f, 0.5f);
glEnd();
glFlush(); // Render now
}
/* Main function: GLUT runs as a console application starting at main() */
int main(int argc, char** argv) {
glutInit(&argc, argv); // Initialize GLUT
glutCreateWindow("OpenGL Setup Test"); // Create a window with the given title
glutInitWindowSize(320, 320); // Set the window's initial width & height
glutInitWindowPosition(50, 50); // Position the window's initial top-left corner
glutDisplayFunc(display); // Register display callback handler for window re-paint
glutMainLoop(); // Enter the infinitely event-processing loop
return 0;
}
And here is the command that is being run:
g++ GL01Hello.cpp -o GL01Hello.exe -lglu32 -lopengl32 -lfreeglut
and the errors I am getting are all below:
g++ GL01Hello.cpp -o GL01Hello.exe -lglu32 -lopengl32 -lfreeglut
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x1c): undefined reference to `_imp____glutInitWithExit#12'
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x3e): undefined reference to `_imp____glutCreateWindowWithExit#8'
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x60): undefined reference to `_imp____glutCreateMenuWithExit#8'
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x198): undefined reference to `_imp__glutInitWindowSize#8'
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x1b1): undefined reference to `_imp__glutInitWindowPosition#8'
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x1c2): undefined reference to `_imp__glutDisplayFunc#4'
C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o:GL01Hello.cpp:(.text+0x1cc):
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\Daniel\AppData\Local\Temp\ccC01yPe.o: bad reloc address 0x20 in section `.eh_frame'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 1
Any help in resolving these linker errors would be extremely helpful.
Edit: I edited all the code above to be a very simple example, and I am still getting a very similar linker error. Someone reported this as a similar problem to the generic "what causes linker errors" Post and I have already tried many of those and none of them have helped. Thank you fo the attempt though
Well, everything you do looks right. My best bet is, that the build of FreeGLUT you're using (specifically the .def and .lib linker stubs) don't match (possibly also the .dll). My suggestion would be, to build FreeGLUT from sources using the very same compiler you're also using to build your program. Try that, and report on any differences.
This is the environment I currently use: Eclipse-Luna, C++11 on Linux Mint -Rebecca.
When I try to use modern OpenGL like with VAOs or VBOs I get Compiler Errors such that methods could not be resolved.
For Example:
GLuint VaoID; //GLuint is working
glGenVertexArrays(1, &VaoID);
or:
GLuint VboID;
glGenBuffers(1, &VboID);
glBindBuffer(GL_ARRAY_BUFFER, VboID);
glBufferData(GL_ARRAY_BUFFER, vbo_size, data, usage);
I checked the GL/gl.h, GL/glext.h and noticed that I have only got OpenGL 1.x methods in there.
So I checked my OpenGL version glxinfo|grep "OpenGL". Which seems to be fine:
glxinfo|grep "OpenGL"
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.1.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
Trying to install or update the packages again only states that everything is up-to-date.
sudo apt-get install freeglut3 freeglut3-dev libglew1.5 libglew1.5-dev libglu1-mesa libglu1-mesa-dev libgl1-mesa-glx libgl1-mesa-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libglew1.5-dev' for regex 'libglew1.5'
Note, selecting 'libglew-dev' instead of 'libglew1.5-dev'
Note, selecting 'libglew-dev' instead of 'libglew1.5-dev'
freeglut3 is already the newest version.
freeglut3-dev is already the newest version.
libglew-dev is already the newest version.
libglu1-mesa is already the newest version.
libglu1-mesa-dev is already the newest version.
libgl1-mesa-dev is already the newest version.
libgl1-mesa-glx is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 150 not upgraded.
So is there a way of fixing this without manually messing with the include directory?
And if there isn't how do I get an up to date header fitting my OpenGL version?
I checked the GL/gl.h, GL/glex.h and noticed that I have only got
OpenGL 1.x methods in there.
For GL/gl.h, that is actually how it is supposed to be. If you want to use OpenGL in a platform-independent manner, you can only rely on GL 1.1 being exported by the GL lib, and should also not assume anything more in the headers. GL/glext.h should actually contain something more. But by default, it will not provide function declarations for the newer functions. A recent version of that file can always be obtained from the OpenGL website, btw.
For everything beyond GL 1.1, you should use GL's extension mechanism, which basically means that you have to query the function pointers for each and every GL function >= GL 1.2 at run time. The glext.h header provides the function pointer type declartations, and enum constants, and additional data types. So this basically looks like this for each extension (and new core functionality are considered "extensions" in this context):
#ifndef GL_ARB_vertex_buffer_object
#define GL_ARB_vertex_buffer_object 1
// new types
typedef ptrdiff_t GLsizeiptrARB;
typedef ptrdiff_t GLintptrARB;
// constants for GLenum values
#define GL_BUFFER_SIZE_ARB 0x8764
#define GL_BUFFER_USAGE_ARB 0x8765
#define GL_ARRAY_BUFFER_ARB 0x8892
// ...
// function pointer tpes for every function
typedef void (APIENTRYP PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRYP PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
// ...
#ifdef GL_GLEXT_PROTOTYPES
// function declatations
GLAPI void APIENTRY glBindBufferARB (GLenum target, GLuint buffer);
GLAPI void APIENTRY glDeleteBuffersARB (GLsizei n, const GLuint *buffers);
// ...
#endif
#endif /* GL_ARB_vertex_buffer_object */
So the function declarations are only effective if GL_GLEXT_PROTOTYPES has been defined. But you shouldn't do that. It will only work if the GL lib happens to export these symbols, and that is not required on most platforms.
Usually, one does not want to load hundreds of GL function pointers manually. There are a couple of OpenGL loading libraries which hanlde all this for you under the hood. And GLEW - which you already installed for some reason - is one of those, so you probably want to use it. Note that GLEW has some issues on its own, notably it is somewhat broken when used in conjunction with modern core profile OpenGL contexts, but it can still be used.
I forgot to mention that I had already included GL/glew.h in my headers. But that didn't fix the compile errors. I checked the file glew.h with eclipse and it shows several error messages. The topmost line marked with an error looks like this:
#error glext.h included before glew.h
Apparently order of includes matters here. After some fiddling the problem boiled down to a very simple change of code. Here is what I had:
#include <GLFW/glfw3.h>
#include <GL/glew.h>
Solution looks like this:
#include <GL/glew.h>
#include <GLFW/glfw3.h>
So I just swapped those two lines and it worked. Thanks for your suggestions again.
Also I removed the GL/gl.h completely.
I'm transferring a program from OSX to Windows, but one error is still nagging me. The error occurs during run-time in gdb. Compiling and linking goes all fine.
freeglut (C:\path\to\file.exe): fgInitGL2: fghGenBuffers is NULL
Outside the GDB environment it gives an APPCRASH (windows-shell) or Segmentation fault (mingw64-shell).
My linker flags are:
-std=c++11 -lstdc++ -lz -lm -lmysqlcleint -lpthread -lboost_thread-mgw49-mt-d-1_57 -lboost_system-mgw49-mt-d-1_57 -lboost_regex-mgw49-mt-d-1_57 -lcurl -lfreeglut -lglu32 -lopengl32 -lws2_32 -lwsock32 -U__CYGWIN__
I'm working in msys2 mingw-w64. During runtime, the program tries to open a new window (at least a pictogram rices in the windows taskbar), but the construction of the window won't succeed. The program runs fine on OSX, where I use glut instead of freeglut.
Header (amongst others):
#include <direct.h>
#include <GL/glut.h>
#include <GL/freeglut.h>
CPP (amongst others):
void interface::startInterface(int &argc, char **argv){
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowSize (width, height);
glutInitWindowPosition (1920, 0);
glutInit (&argc, argv);
glutCreateWindow ("TIFAR 2.0");
LoadGLTextures(); // Load The Texture(s) ( NEW )
glClearColor(0.0f, 0.0f, 0.0f, 0.0f); // This Will Clear The Background Color To Black
glClearDepth(1.0); // Enables Clearing Of The Depth Buffer
glDepthFunc(GL_LESS); // The Type Of Depth Test To Do
glEnable(GL_DEPTH_TEST); // Enables Depth Testing
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glShadeModel(GL_SMOOTH); // Enables Smooth Color Shading
glMatrixMode(GL_PROJECTION);
glLoadIdentity(); // Reset The Projection Matrix
gluPerspective(45.0f, (GLfloat) width / (GLfloat) height, 0.1f, 100.0f);
// Calculate The Aspect Ratio Of The Window
glMatrixMode(GL_MODELVIEW);
glutDisplayFunc (interface::display);
glutReshapeFunc (interface::reshape);
glutIdleFunc (interface::idle);
glutKeyboardFunc (interface::processNormalKeys);
glutMainLoop();
}
There are some other parts in the program, like where images are loaded, but I think it will be to much information when I mention everything here.
It took me some time, but the cause of the problem was in the hardware. I was running on a virtual machine (VMware) and although the specifications said that it supported OpenGL up to 2.1 I found out that it doesn't support OpenGL at all.
My solution was to take an old machine, install Windows on it, and copy all files. It compiled and runs as smooth as a can.
If anyone else runs into the same problem I can advise to get it working on a native installation before virtualising. It can safe you a lot of time.
I'm new to this site, and relatively new to programming.
I've been doing some C++ programming for a while using Visual Studio 2010, and I wanted to get into OpenGL, so I bought the OpenGL Superbible to get started. I've gotten stuck on the second chapter's "simple" project.
After hours of research I've been able to download all the necessary files to use freeGLUT and GLtools. I've made sure that everything is in the right place for the program to work.
Now, it appears as though everything has been worked out... except for one odd problem.
I was instructed that I needed to place freeglut.dll into Windows\System32, so I did. The project will build now, but when I go to run it, it tells me
"The program can't start because freeglut.dll is missing from your computer. Try
reinstalling the program to fix this problem."
Now, I am certain that freeglut.dll is in Windows\System32 as it should be, so what's the problem? how do I solve it?
Here's the original code from the book:
#include "../../shared/gltools.h" //OpenGL toolkit
//////////////////////////////////////////////
//called to draw scene
void RenderScene(void)
{
// clear the window with current clearing color
glClear(GL_COLOR_BUFFER_BIT);
//Flush drawing commands
glFlush();
}
////////////////////////////////////////////////////////
//set up the rendering state
void SetupRC(void)
{
glClearColor(0.0f , 0.0f, 1.0f, 1.0f );
}
///////////////////////////////////////////////////////////
//main program entry point
void main(void)
int main(int argc, char* argv[])
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA);
glutCreateWindow("Simple");
glutDisplayFunc(RenderScene);
SetupRC();
glutMainLoop();
return 0;
}
This is the code that actually compiled, but would not run (it's a bit of a mess from all the conflicting data I got from different resources):
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <GLTools.h>
#include <gl/GLUT.h>
//called to draw scene
void RenderScene(void)
{
// clear the window with current clearing color
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}
//set up the rendering state
void SetupRC(void)
{
glClearColor(0.0f , 0.0f, 1.0f, 1.0f );
}
//void main(void)
int main(int argc, char* argv[])
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA);
glutCreateWindow("Simple");
glutDisplayFunc(RenderScene);
SetupRC();
glutMainLoop();
return 0;
}
Try putting the DLL in the same folder as your exe file. The advice to put it in Windows\System32 predates a lot of newer Windows security restrictions.
#ScottMcP-MVP 's answer solved my problem, but I thought I'd add some detail that doesn't really fit in the comment.
My solution:
Add the following subdirectory structure to your solution folder:
In x86, put the 32-bit versions of GLut, GLew and anything else you need.
In x64, put the 64-bit versions of same.
I went ahead and put all .dll, .lib, and .h in the corresponding folders here rather than placing them in the Windows SDK (Or, in Win7+, the "Windows Kits" folder) to ensure that my projects in SVN had the correct version, and checking out on another machine would retrieve all dependencies. This required adding the include and target-specific lib folders to the project properties:
Set your Include Directories field to
$(SolutionDir)ThirdParty\Include\;$(IncludePath)
And your Library Directories field to
$(SolutionDir)\ThirdParty\$(PlatformTarget)\lib\;$(LibraryPath)
Note that all of these should be applied to the "All Platforms" build configuration. The $(PlatformTarget) macro will make sure that the correct lib's and dll's are used. The include folder is target-agnostic, so I've placed it in the root of my ThirdParty folder.
To get the required files into your output folder, add the following post-build event to your project configuration (under "All platforms"):
xcopy $(SolutionDir)ThirdParty\$(PlatformTarget)\*.dll $(OutputPath) /Y
That will copy the correct version of the DLLs to your output folder on build. This keeps you from having to manually put the DLLs in our output folder, and is more compatible with source control where you typically don't want to include your output, bin or debug folders.
Once I had all of this configured, I created a VC OpenGL project template since getting everything configured took 30 minutes of my life I'd rather have back.
I'm trying to get the Unofficial OpenGL SDK Libraries to work and started using the glutil library for the matrixStack functionality. I compiled the source using Visual studio 2010 and moved the libraries to the minGW folder located at my Code::Blocks folder. I moved the header files to the include folder over there as well.
Everything should be in place now and should be compiled for my OS so the following code should work just fine.
// Get rotation matrix
//float rotValue = (glutGet(GLUT_ELAPSED_TIME)) / 10;
glm::mat3 rotMatrix = RotateAxis(0.0f, 0.0f, 1.0f, 0.0f);
// Build final matrix from rotMatrix
glm::mat4 finalMatrix(rotMatrix);
finalMatrix[3].x = camX;
finalMatrix[3].y = camY;
finalMatrix[3].z = camZ - 1.0f;
finalMatrix[3].w = 1.0f;
glutil::MatrixStack stack(finalMatrix);
glutil::PushStack push(stack);
// Object 1
glBindVertexArray(vaoObject); // Advantage of using vao's is that you only have to do all the vertex attribute enabling and buffer stuff once.
glUniformMatrix4fv(modelToCameraMatrixUnif, 1, GL_FALSE, glm::value_ptr(stack.Top()));
glDrawElements(GL_TRIANGLES, ARRAY_COUNT(indexData), GL_UNSIGNED_SHORT, 0);
// Object 2
stack.Translate(glm::vec3(0.0f, 0.5f, 0.0f)); // THIS IS WHERE THINGS GO WRONG
finalMatrix[3].z = camZ - 2.00f;
glUniformMatrix4fv(modelToCameraMatrixUnif, 1, GL_FALSE, glm::value_ptr(stack.Top()));
glDrawElementsBaseVertex(GL_TRIANGLES, ARRAY_COUNT(indexData), GL_UNSIGNED_SHORT, 0, 36/2);
The call to stack.Translate generates the following error: undefined reference to 'glutil::MatrixStack::Translate(glm::detail::tvec3 const&)' which is quite odd since without the translate call the constructors for the MatrixStack and PushStacks work just fine which is odd.
I tried adding -glutil to the linker but didn't solve my problem.
Header includes (related to openGL):
// Open GL and GLUT
#include <gl/glew.h>
#include <gl/glut.h>
// Open GL Libraries
#include <glm/glm.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <glutil/glutil.h>
I'm still not sure how to find out the correct names to link the libraries to since the OpenGL SDK didn't show this information on their website so I'm not sure if -glutil is correct. I'm guessing the problem has something to do with the linking stage.
Are you using C++ code compiled by VC++ under MinGW? You know that ABI's of those compilers are different? Even the name mangling scheme is different, so that could explain why it cannot be linked. Chack if unmangled version of function name from mingw linker (should be somewhere in error report) maches the one exported from glutil - using eg. DLL Export Viewer - or is glutil statically linked? If it doesn't match, you probably need to use the same compiler for both library and your code.