I want to fully use OpenGL 3.3 in my program, but glGenVertexArrays segfaults without some special initialization. I've looked at the GLEW source but couldn't find what is done for it to work.
I tried binding to GLEW, but OPTLINK either says the library is invalid (when compiled with VS2012) or the symbol is not found (uint glewInit() in a MinGW dll converted to lib with implib).
If there are only a few lines needed doing what GLEW does (I suppose I don't need 1000 lines of function getting) I would like to do that myself, when it's too much I would appreciate some help on building a lib that D actually accepts.
This is a good start : http://www.opengl.org/wiki/Load_OpenGL_Functions
Follow the links to The OpenGL Registry : http://www.opengl.org/registry/
Here you can find useful header files for your platform. I would recommend using GLEW or similar libs though.
Related
I'm currently working through the LearnOpenGL tutorials, which has been going fine thus far, until I've hit the model loading portion of the tutorial.
LearnOpenGL uses the Assimp library to handle model loading, but I don't seem to be able to get it to build properly (precompiled libraries don't work either for me) - it produces errors within "Display.cpp":
In function 'unzOpenCurrentFile3':
Line 1177: warning: assignment from incompatible pointer type
In member function 'int AssimpView::CDisplay::AddNodeToDisplayList(....'
Line 179 error: 'TVITEMEXW' was not declared in this scope
With the line 179 error appearing to be the main cause of failure. Having looked in the 'Display.cpp' file, the issue is with the following declaration:
TVITEMEXW tvi;
And TVITEMEXW doesn't seem to be declared/included within the file explicitly, but the included headers are stdio.h, stdlib.h, string.h, and "./unzip.h". After some searching, I've found that TVITEMEX is a windows structure with TVITEMEXW as a unicode name (according to this) but I'm fairly new to C++/compilers etc., and don't really know what to do with this information.
I created the Code::Blocks project file with CMake and MinGW from the Assimp 3.2.
Any help would be hugely appreciated, I've been stuck with this for a few days now and can't figure out how to resolve it myself. Apologies if I haven't provided enough/the correct information, I'm not entirely sure exactly what is relevant to the problem.
try replacing TVITEMEXW with TVITEMW and maybe sNew.itemex with sNew.item.
I grepped inside GLEW while trying to solve my other question, concerning missing __glewX* symbols for Mac, and found that they are guarded by GLEW_APPLE_GLX.
When I attempt to build GLEW from source with that flag defined, I get undefined symbols (stuff like _glXGetClientString). Linking against X11 (-lX11) doesn't help.
Question: assuming defining GLEW_APPLE_GLX does indeed make sense, how can I fix the build?
When building an application that uses the X Server (XQuartz) instead of using CGL, you also need to add -lGL.
Ordinarily when building GL software on OS X you use OpenGL.framework (-framework OpenGL) and that gets you OpenGL and CGL/AGL functions but leaves out GLX.
You should also ditch any includes to things like <OpenGL/gl.h> and use <GL/gl.h> instead, as that will point to /usr/X11R6/include/GL/... instead of the OpenGL framework headers.
I built Qt from source (dlls) and am trying to build an application that uses the Qt dlls. I don't have a lot of experience with C++ so I'm running into what I'm sure is a very basic issue.
My builds are failing on the includes with errors like so:
Fatal error: QNetworkProxy: No such file or directory
Here is the g++ command I am using (I also used -L to add the correct folder to the lib path, but that also didn't work):
g++ -l..\..\wkqt\bin\QtCore4.dll -l..\..\wkqt\bin\QtNetwork4.dll -l..\..\wkqt\bin\QtWebKit4.dll -I..\include -Ishared -Ipdf -Ilib -Iimage -o ..\bin\wkhtmltopdf.exe pdf\*.cc lib\*.cc image\*.cc shared\*.cc
I tried in Visual Studio as well (assuming it wouldn't build, but I wanted to see if I could at least include the Qt dlls from there properly) and I am getting the same errors. Am I doing something wrong with the way I am compiling with g++? If I am linking with the Dlls properly then what is the proper way to use Qt functions from my code?
To clarify, I am not looking for how to properly use Qt. My question is: what is the proper way to use functions defined in any Dll from native C++ code? I apologize if this is a very basic question, but I'm unable to find a clear answer on Google and I don't have any experience with C++ and including third party libraries for use from C++ code.
DLLs can be used by dynamicly loading them and calling their used functions.
to call the exposed functions first define their syntax in the begining
suppose function is syntax is
BOOL MyFunction(int a,char* pszString)
then define syntax
#typedef BOOL (WINAPI *PMYFUNCTION)(int a,char* pszString)
then make object
PMYFUNCTION pfnMyFunction;
and get valid pointer by calling GetProcaddress after loadlibrarycall
HMODULE hlib= Loadlibrary("c:\\Mylib.dll");
if(hlib)
{ pfnMyFunction = (PMYFUNCTION)Getprocaddress(hlib,"MyFunction"); }
Hope this helps...
I'm building a DLL that links to OpenGL. But I get a problem when calling some functions such as glGenBuffers, because apparently __glewGenBuffers (and other glew buffer functions) are null. Everything compiles properly, and the same code works in the executable, but not in my DLL. I'm using VS 2010. Any ideas about linking to OpenGL from a DLL?
Edit: I forgot to mention, I'm actually trying to link an engine (static library) to the DLL, and the exe file uses it too (it does almost everything, except a small part that I want to put in my DLL). I would definitely be fine with using just OpenGL calls from the DLL though, instead of linking the engine, if I could get it to work better.
GLEW must do some tricks in order to deal with the context dependent function pointers on some plattforms. One of these plattforms is Windows. A foolproof way to make things working is to
Test if there's actually a OpenGL context bound
call glewInit()
everytime a function in the DLL is called that uses extended OpenGL functionality. I.e.
… some_DLL_exported_function(…)
{
if( NULL == wglGetCurrentContext() ||
GLEW_OK == glewInit() ) {
return …;
}
}
I was about to rebuild my library in Dev-C++, under Windows; however, the shader functionality I've added in the meantime is not supported, the compiler could not find the related functions (::glCreateShader(), ::glCreateProgram(), etc.)
Digging around the internet and the Dev-C++ folder, I've found that the OpenGL implementation (gl.h) is only v1.1. I've found recommendations to download the latest headers from SGI. I have found gl3.h, however, after closer scrutiny I have realized that gl.h is not included in my project anyway, and I should be looking at SDL/SDL_opengl.h.
EDIT: SDL_opengl.h does include gl.h and declares prototypes of the functions in question. So the question is, why ame I given compile-time errors rather than linker errors?
(My library only links against mingw32, libOpenGL32, libSDL, libSDL_Image and libSDL_Mixer, much like under OSX (except for mingw32, of course) where I didn't have any problem.)
How can I use OpenGL v2.0 shaders with Dev-C++ and SDL?
gl.h is only for OpenGL 1.1 (and in some cases up to 1.3 depending on which version of the file you are using and which operating system). For everything else you additionally need glext.h and probably glxext.h (Linux/Unix) or wglext.h (Windows).
All functions from newer versions of OpenGL must be linked at runtime. So in order to use them you must get the right function address and assign it to a function pointer. The easiest way to do this is by using something like GLEW.
The manual way would be something like this:
PFNGLCREATESHADERPROC glCreateShader = NULL;
glCreateShader = (PFNGLCREATESHADERPROC) wglGetProcAddress("glCreateShader");
or for Linux:
PFNGLCREATESHADERPROC glCreateShader = NULL;
glCreateShader = (PFNGLCREATESHADERPROC) glXGetProcAddress((GLubyte*) "glCreateShader");
If you define GL_GLEXT_PROTOTYPES before including glext.h you can omit the first line.
EDIT: SDL_opengl.h looks like it contains a copy of glext.h (not up to date though). So if you use that the above should still be valid. If you want to use a seperate glext.h you must define NO_SDL_GLEXT before including SDL_opengl.h. Also, the function prototypes aren't available as long as GL_GLEXT_PROTOTYPES isn't defined or you write them yourself.
EDIT2: Apparently SDL has its own GetProcAddress function called SDL_GL_GetProcAddress.
Can you load the addresses of the functions at runtime?
typedef GLhandle (APIENTRYP PFNGLCREATESHADERPROC) (GLenum shaderType);
PFNGLCREATESHADERPROC glCreateShader = NULL;
glCreateShader = (PFNGLCREATESHADERPROC)wglGetProcAddress("glCreateShader");
typedef GLhandle (APIENTRYP PFNGLCREATEPROGRAMPROC) ();
PFNGLCREATEPROGRAMPROC glCreateProgram = NULL;
glCreateProgram = (PFNGLCREATEPROGRAMPROC)wglGetProcAddress("glCreateProgram");