I am developing an OpenGL application and need to use the glew library. I am using Visual Studio C++ 2008 Express.
I compiled a program using gl.h, glu.h, and glut.h just fine and it does what it's supposed to do. But after including glew.h it still compiles just fine, but when I try:
glewInit();
if (glewIsSupported("GL_VERSION_2_0"))
printf("Ready for OpenGL 2.0\n");
else {
printf("OpenGL 2.0 not supported\n");
}
It keeps printing:
"OpenGL 2.0 not supported".
I tried to change it to glewIsSupported("GL_VERSION_1_3") or even glewIsSupported("GL_VERSION_1_0") and it still returns false meaning that it does not support OpenGL version whatever.
I have a Radeon HD 5750 so, it should support OpenGL 3.1 and some of the features of 3.2. I know that all the device drivers are installed properly since I was able to run all the programs in the Radeon sdk provided by ATI.
I also installed Opengl Extensions Viewer 3.15 and it says OpenGL Version 3.1 Ati Driver 6.14.10.9116. I tired all of them GLEW_VERSION_1_1, GLEW_VERSION_1_2, GLEW_VERSION_1_3, GLEW_VERSION_2_0, GLEW_VERSION_2_1, GLEW_VERSION_3_0 and all of these return false.
Any other suggestioms? I even tried GLEW_ARB_vertex_shader && GLEW_ARB_fragment_shader and this is returning false as well.
glewIsSupported is meant to check and see if the specific features are supported. You want something more like...
if (GLEW_VERSION_1_3)
{
/* Yay! OpenGL 1.3 is supported! */
}
there may be some lack of necessary initialization. I encounter the same question. And here is how I solve the question: you need to include the glCreateWindow() ahead. Include this function and try again.
Firstly, you should check whether glew has initialized properly:
if(glewInit() != GLEW_OK)
{ // something is wrong };
Secondly, you need to create the context before calling glewInit()
Thirdly, you can also try:
glewExperimental=true;
Before calling glewInit()
I encountered the same problem when running a program through windows RDP, then I noticed that my video card may not working properly when using RDP, so I tried teamviewer instead, both glewinfo.exe and my program start to work normally then.
The OP's problem may be solved for a long time, just for others' infomation.
Related
So I installed OpenCV WITH_OPENCL_SVM=ON thinking that I was going to eventually get a GPU with OpenCL 2.0 on it (currently only 1.1.) However now when I try to run any programs with OpenCV I get an
Error on line 2629 (ocl.cpp): CL_DEVICE_SVM_CAPABILITIES via clGetDeviceInfo failed: -30
I believe when I create a cv::UMat. The line of code in ocl.cpp is dependent on HAVE_OPENCL_SVM being defined, I assume it then does a check for the SVM capability and fails that check because I don't have 2.0. I tried:
#undef HAVE_OPENCL_SVM
in my code and modifying cvconfig.h (honestly don't know how/when that file is referenced) so that it is not defined as well as un-defining it there again... and the error persists.
Thanks!
I am having Problem loading SDL_TTF font.
my program is so big, so there's a piece of code which is creating problem.
TTF_Font *font = NULL;
SDL_Color textColor = {255, 255, 255};
if(SDL_Init() == -1 || TTF_Init() == -1)
return 0;
font = TTF_OpenFont("calibri.ttf", 28);
if(font == NULL)
return 0;
Now please tell me why the funtion TTF_OpenFont is not working.
font remains NULL after the funtion and the program exits...
EDIT:
I cannot cout or printf TTF_GetError() but i used breakpoints to see which function is not working correctly and found the function TTF_OpenFont() returning null every time.
(BTW if there any way to print the Erroe on screen the tell please).
TTF_Init() is working correctly.
FOR PEOPLE WHO ARE ASKING TO INSTALL SDL_TTF SEPARATELY:
I have written the link below from which i am learning SDL in first tutorial it guides how to install SDL and integrate it which project, In 3rd lesson comes the SDL_IMAGE extension library which is to be needed to install separately (which i did and used all image functions easily), In 7th lesson it didn't teach how to install SDL_TFF rather says to do the same steps as for SDL_IMAGE but this time for SDL_TTf so i downloaded SDL_TTF and intalled and you know the rest after....
Windows 8.1, CodeBlocks, MinGW32, SDL1
Here's the link i am learning SDL from
SDL Tutorials
This is how i installed the Extension Library(SDL_TTF)
Setting Up Extention Library
If font is NULL you should use TTF_GetError to know what went wrong.
If the error message is opaque you may want then to take a look at TTF_OpenFont source.
Suggestions:
1) substitute this code for TTF_Init():
if(TTF_Init()==-1) {
printf("TTF_Init: %s\n", TTF_GetError());
exit(2);
}
2) Make sure you call it before any other SDL_ttf functions.
If you're still having problems, please specify
your platform (Windows? Linux?)
how you installed your TTF fonts.
3) See also: https://www.libsdl.org/projects/SDL_ttf/docs/SDL_ttf.html
===================================================================
I'm sorry you're still having problems displaying fonts. A few additional suggestions:
1) I'm sure the tutorial you're using is very good. But you can't assume that just because you followed all the steps, you didn't inadvertantly miss something. To resolve the problem, you're going to have to "look beyond" the tutorial.
2) For starters, we need to confirm whether or not TTF_Init() succeeded. We must be able to see TTF_Init() return status, and TTF_GetError() messages.
Q: What is the return value of TTF_Init?
There are several ways you can display "TTF_GetError":
Start your program from a command prompt ("cmd"):printf("TTF_Init: %s\n", TTF_GetError());
Copy the error to a string and look at it under a debugger: char[80] msg; strcpy (msg, TTF_GetError());
Use a Win32 MessageBox to display the error in a pop-up: MSDN - MessageBox function
3) Make sure you have these .dll's on your filesystem:
libfreetype*.dll
SDL2_ttf*.dll
zlib*.dll
4) Look at the fonts you have installed on your filesystem, for example: C:\Windows\Fonts\*.ttf
See also SDL_ttf - Font directory/Where do fonts go?
PROBLEM SOLVED.
Thanks EveryOne for giving your time...
the problem was program was not recognizing font(candara )
so it copy pasted in my project folder.
I know this was already answerd but i ran into a similar problem with SDL2_ttf under Visual Studio 2015 and want to share my solution to help maybe others in the future.
My problem was that when i started my SDLe application that used SDLe_ttf it could not load the font that was placed in the same directory. But when i executed the the build executable manualy from the command line everything was fine.
I think the problem is that Visual Studio 2015 executes the build executable from a different directory and since i used only the font file name(Sans.ttf) it could not load the font because it treats it as a relative path.
My soultion was to just prefix the font file name with the execution directory which can be optained by calling SDL_GetBasePath.
I am trying to get started with EDSDK to control my Canon 500D. I'm new to cpp, and windows XP apps and I'm using visual studio. After a great deal of blind trial and error I have finally managed to get the app to compile the basic sample code from the documentation. To do this I have the EDSDK.h, EDSDKTypes.h and EDSDKErrors.h headers in the right places and the EDSDK.dll and EDSDK.lib in the same folder as the code. It seems to be picking these up. I have got the 500D to be recognised by the PC so I believe the USB drivers are there.
The code is just trying to pick up the camera:
EdsError err=EDS_ERR_OK;
EdsCameraListRef cameraList=NULL;
err = EdsGetCameraList(&cameraList);
if(err == EDS_ERR_OK)
{...}
However, when I run this console app the error is picked up as 10 - which suggests, according to the document, that there is a missing subcomponent. This happens both if the camera is connected or not, so I'm thinking this is something missing from the compile. But I am getting nowhere with the documentation.
I have installed the edsdk 2.4 Windows version from a download not the official route, so this may be an issue.
Can anyone help? Specifically how can I find out what the missing subcomponent might be so I might include it. Is this a subcmponent of the build like a header file or something like a driver?
I know, old question but still it might help someone with the same problem.
From the documentation:
All DLLs are required in order to execute an EDSDK client application.
All of the modules in the DLL folder must be copied into the same folder where the EDSDK client application is in.
This means you'll have to have all DLLs beside your *.exe. Namely these DLLs:
DPPDLL.dll
DPPLibCom.dll
DPPRSC.dll
EDSDK.dll
EdsImage.dll
Mlib.dll
Ucs32P.dll
I want to use CGL or NSOpenGL to create an OpenGL window without using XCode (compile with command line gcc). I am developing something that is cross platform, and I'd like to keep the code divergence to a minimum if I can! My codebase is fully C++ at the moment. Is this at all possible? I am new to OSX and I haven't touched objective C. I looked through the developer docs and grabbed some example files. They are all using xcode. I successfully compiled the source and linked with the right framework, but the whole app bundle, xib, and info.plist thing seems a bit over the top.
This is bare-bones as one can get:
// g++ glInfo.cpp -o glInfo.x -framework OpenGL
#include <OpenGL/OpenGL.h>
#include <OpenGL/gl3.h>
#include <stdio.h>
int main(int argc, char **argv)
{
CGLContextObj ctx;
CGLPixelFormatObj pix;
GLint npix;
CGLPixelFormatAttribute attribs[] = {
(CGLPixelFormatAttribute) 0
};
CGLChoosePixelFormat( attribs, &pix, &npix );
CGLCreateContext( pix, NULL, &ctx );
CGLSetCurrentContext( ctx );
printf("Vendor: %s\n", glGetString(GL_VENDOR) );
printf("Renderer: %s\n", glGetString(GL_RENDERER) );
printf("Version: %s\n", glGetString(GL_VERSION) );
printf("GLSL: %s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));
return 0;
}
Both fltk and SDL should have enough AGL/CGL code. I've built and run cmdline GL apps on OS X with fltk-1.3.0. It uses the AGL sub-system however, which is deprecated. SDL uses CGL and NSOpenGL for its Quartz video layer: ./src/video/quartz
Use the obj-c flags for the compiler, if you need to build a src.m, and let the native g++, llvm-g++, clang++, or whatever, take care of the linking. You might need to add -framework CGL -framework OpenGL as well as ApplicationServices and Cocoa. A lot of the answer depends on what you mean by 'code divergence'.
You can build apps without using Xcode, but if you want users who aren't sys admins to use them, you'll need an app bundle (and hence .plist) and (unless it's a game) a user interface beyond what OpenGL offers. You don't need to create a .xib for your UI. You can do it all programmatically, though using .xibs is far easier for most things. Why don't you want to use the tools designed to help you? I'm not saying they're the best, but they beat using only a command-line interface. (Once you have an Xcode project for your app, though, you can build it from the command-line and even automate building it.)
Well, you can do it "by hand" (I used to do it at NeXTStep times), but it is a pain before it works for the first time.
XCode uses makefiles under the hood. You can find and adopt the makefiles in
/Developer/Makefiles
(pre XCode 4.3)
or for XCode 4.3 in
/Applications/Xcode.app/Contents/Developer/Makefiles
Good luck!
For the build system, I recommend CMake/CPack which will help you to keep it cross-platform and to build app bundles. For NSGL, it's possible using Obj-C++, but I don't have any code at hand.
I've successfully built SDL from source using bcc 5.5.1 but any SDL test application using it crashes right away at startup. I'm looking for some help and/or guidance on how to resolve this issue.
Just to fill in some info, SDL-1.2.14 was used. The project's compiled as a dll with multithreading enabled and linked to C runtime dynamically. I've also rebuilt it with debugging info. When I step through with a debugger up to the point of crash it seems to be coming from redirect_stdout in the sdlmain. If I remove sdlmain.lib and use the source file sdl_win32_main.c directly in the SDL test project then that doesn't crash anymore. Instead it just crashes later on at SDL_Init routine.
I've already checked the calling conventions used and they all seem to match up -- everything is using cdecl. I've also checked and made sure the compiled sdl.dll and the test application was using the same dynamic c runtime instead of statically linked.
The SDL wiki under Borland section mentions to use the -b to make sure enum's are same size as int but that option is enabled by the compiler by default unless explicitly turned off. I did rebuild SDL with that compiler/linker switch just to be sure though.
When it crashes, it's always a access violation in trying to write to some address(c000005). Like for example during a typical SDL init attempt like this:
// initialize SDL video
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
printf( "Unable to init SDL: %s\n", SDL_GetError() );
return 1;
}
After the call into SDL_Init(), control doesn't flow back into the test application. Instead it crashes somewhere bizarre like somewhere in ntdll.dll with something having to do with NTDLL.RtlEnterCriticalSection. When I inspect the stack trace at that point I usually get something like this:
:77982269
:0044A04C
:0043F02B
:0043F7C4
:0043EF25
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
//and it keeps recursing... looks like a stackover? :P
I'm not sure whatelse to try at this point as I'm pretty stumped. If anyone have any suggestions or need me to provide more info please feel free to add it to the comments.
Thanks
Alright, I finally found out what the issue was a couple days ago. The reason for the crash was because the wrong source file was compiled for the given platform.
The project file I used kept compiling SDL_sysmutex.c from threads\generic. The correct SDL_sysmutex.c to use under win32 should have been from threads\win32. I found this out when I was tracing the test programs side by side and the threading modules had different lines of code!
With this little oversight fixed the crashing problems have all but disappeared and all the test demos are running as they should :)