GLEW functions can't be found - c++

I am on Ubuntu, writing an application using OpenGL, GLEW and GLFW. I am using Eclipse as my IDE, and am having problems when trying to use functions such as glGenRenderbuffer. I have a very similar structure set up under Windows but can't get it to work on Linux.
I am linking to the libraries glfw and GLEW. I am able to compile and run parts of my application and can initialize both GLFW and GLEW. From these test runs I learn the following:
OpenGL version: 4.2.0 NVIDIA 304.64
Using GLEW 1.6.0
However, I can't get the function glGenRenderbuffer (or other framebuffer functions) to compile. I have tried adding both EXT and ARB to the name, as well as playing around with glex.h without any luck. As far as I know, the purpose of GLEW is to handle all extension issues, right?
The source file (VolumeRenderer.cpp) includes are done like this:
#include <glm/gtc/matrix_transform.hpp>
#include <VolumeRenderer.h>
#include <GL/glew.h>
#include <GL/glfw.h>
Further down, I am trying to use the function like this (only partially complete function, of course):
bool VolumeRenderer::InitFramebuffers()
{
glGenRenderbuffers(1, &renderBufferObject_);
return true;
}
All I get is "function 'glGenRenderBuffers' could not be resolved".
Looking in the GL/glew.h header I am including, I found the following lines among others:
#define glGenRenderbuffers GLEW_GET_FUN(__glewGenRenderbuffers)
#define glGenRenderbuffersEXT GLEW_GET_FUN(__glewGenRenderbuffersEXT)
But the compiler still can't find the function. Is there anything I have forgotten, or maybe some tests and checks I can run to see what is happening?

Alright, so I got it to work by basically copying my Eclipse project file by file into a new, empty project. However, I did some other things before that. First, I moved around the includes as suggested in the helpful comments. I also removed things like glm. No success! Then I made a simple project in Eclipse with one single .cpp file, and linked to glfw and GLEW:
#include <GL/glew.h>
#include <GL/glfw.h>
#include <iostream>
#include <cstdlib>
int main()
{
if (glfwInit() != GL_TRUE) {
std::cout << "glfwInit() failed\n";
exit(1);
}
if (!glfwOpenWindow(800, 600, 8 , 8, 8, 8, 8, 8, GLFW_WINDOW)) {
std::cout << "glfwOpenWindow() failed\n";
exit(1);
}
char *glVersion = (char*)glGetString(GL_VERSION);
if (glVersion) {
std::cout << "OpenGL version: " << glVersion << "\n";
}
GLenum err = glewInit();
if (err != GLEW_OK) {
std::cout << "GLEW init failed: " << glewGetErrorString(err) << "\n";
exit(1);
} else {
std::cout << "Using GLEW " << glewGetString(GLEW_VERSION) << "\n";
}
GLuint buf;
glGenRenderbuffers(1, &buf);
exit(0);
}
That worked like a charm. I then tried to recreate my old problem by making another project with a similar file and include structure, and it seemed to work fine too. I then started a third, empty project where I simply made exact copies of the files that were originally giving me trouble. Now I have an exact copy of the original project (that now had the include order changed) with the exact same libraries linked to it, and it works. I still don't know what happened but I suspect that my project in Eclipse got messed up somehow, and never recovered even though I made some changes.

Related

C++ recursive_directory_iterator miss some files

I'm trying to get all files in directory through c++17 on my visual studio 2017 but I've just encountered a really weird problem. If I specify directory like this I can get all files without any problem:
for (auto& p : std::filesystem::recursive_directory_iterator("C:\\Users\\r00t\\AppData\\Roaming\\Mozilla")) {
if (std::filesystem::is_regular_file(p.path())) {
std::cout << p.path() << std::endl;
}
}
But I need all file list on APPDATA, and I'm trying to get path with getenv() function and when using it "recursive_directory_iterator" function skipping files:
for (auto& p : std::filesystem::recursive_directory_iterator(getenv("APPDATA"))) {
if (std::filesystem::is_regular_file(p.path())) {
std::cout << p.path() << std::endl;
}
}
Is that because of using getenv() function? Some folders that skipping when using getenv;
Mozilla
TeamWiever
NVIDIA
and so on ..
Btw, I'm using C++ last 5 days and definitely don't have any clue what causes for that behavior. Please help me, right now I'm stuck.
EDIT :
for (auto& p : std::filesystem::directory_iterator(getenv("APPDATA"))) {
std::string targetFolder = p.path().string();
for (auto& targetFolderFiles : std::filesystem::recursive_directory_iterator(targetFolder)) {
if (std::filesystem::is_regular_file(targetFolderFiles.path())) {
std::cout << targetFolderFiles.path() << std::endl;
}
}
}
This is also not working, seems like i must put string into function like this:
recursive_directory_iterator("C:\\Users\\r00t\\AppData\\Roaming\\Mozilla")
otherwise definitely not working, LOL ??
EDIT - PROBLEM FIXED
Using experimental library is working with C++14 compiler like as expected.
#include <experimental/filesystem>
Now i can able to get all files without problem.Seems like this is problem about C++17 and filesystem library ..
Thanks for all support guys.
getenv() returns a char* or NULL. <filesystem> is probably operating with wchar_t* strings since you are on Windows. Use SHGetKnownFolderPath(...) to query for where special folders are.
What happens when you run your program is probably that you hit some character that can't be displayed with your current locale ("C" if not set explicitly) so it sets your outstream in fail mode. You can however set your locale to UTF-16LE to remedy this. It works with /std:c++17 and the standard <filesystem> header:
#include <Shlobj.h> // SHGetKnownFolderPath
#include <clocale> // std::setlocale
#include <io.h> // _setmode
#include <fcntl.h> // _O_U16TEXT
Code Page Identifiers
const char CP_UTF_16LE[] = ".1200";
setlocale(LC_ALL, CP_UTF_16LE);
_setmode
_setmode(_fileno(stdout), _O_U16TEXT);
With that in place, the path you get from SHGetKnownFolderPath should work:
PWSTR the_path;
if(SHGetKnownFolderPath(FOLDERID_RoamingAppData, KF_FLAG_DEFAULT, NULL, &the_path) == S_OK) {
for(auto& p : std::filesystem::recursive_directory_iterator(the_path)) {
std::wcout << p.path() << L"\n";
// you can also detect if the outstream is in fail mode:
if (std::wcout.fail()) {
std::wcout.clear(); // ... and clear the fail mode
std::wcout << L" (wcout was fail mode)\n";
}
}
CoTaskMemFree(the_path);
}
You may also find the list of Default Known Folders in Windows useful.

glewInit and building dll

I am developing hobby opengl3 engine and I decided to make a new .dll build of it. It uses GLEW to get opengl3 functions from GPU. I've successfully builded it about 5 months ago, but now I've changed a lot and it doesn't want to get working.
So the .dll builds perfectly (windows7, mingw).
I've made a simple program and it crashes on first call to glCreateProgram which is runned by code from mylib.dll.
in pseudocode:
#include "mylib.hpp"
int main(){
std::cout << (void*)glCreateProgram << "\n";
// displays 0 as glCreateProgram haven't been loaded yet
myspace::Window* = new SDL2BasedWindow(...);
//this constructor is from my .dll and calls glewInit() which returns GLEW_OK
std::cout << (void*)glCreateProgram << "\n";
//this displays proper address
int testGLEW= glCreateProgram();
std::cout << "glCreateProgram from main: " << testGLEW<< "\n";
//this displays 1 which means valid call to glCreateProgram
window->runApplication(new Application(...));
//Application is user-defined class, it further creates myspace::ShaderProgram
//which is imported from my .dll (part of my engine) which then calls
//glCreateProgram in it's initialisation
//(it is first call to any function which should be initialized by GLEW if we count only code imported from mylib.dll)
}
//in ShaderProgram constructor:
std::cout << "trying to call glCreateProgram, address: ";
std::cout << (void*)glCreateProgram << "\n"; //this displays 0 (!)
int id = glCreateProgram(); //this ends execution with SIGSEGV
printf("created program: %d\n", id); //so this one is never called
So my question is, why GLEW works only in code which is not imported from my .dll and how can I fix it?
Btw I've checked nm mylib.dll ant it contains glCreateProgram and other glew dependent functions, I also use #define GLEW_STATIC both in .dll and program that uses this .dll
Thanks for your help!
#define GLEW_STATIC is used to build a static library or executable.
To build a .dll use #define GLEW_BUILD instead.

lodepng, stb_image. Nothing works in my system for image loading in C++

I'm trying to load pngs or bmps into my programs. But none of the libraries I found around the web works. I have no idea why but I always get "incorrect PNG signature, it's no PNG or corrupted" for EVERY png when using lodepng. "unknown pixel format" for EVERY bmp when using SDL_loadBMP. "unknown image type" for every png when using stb_image.
I can't load anything. Maybe there is something wrong with my system ? I'm using OSX Yosemite. Here is the code.
#include <iostream>
#include <string>
#define STB_IMAGE_IMPLEMENTATION
#include <lodepng.h>
#include <stb_image.h>
using namespace std;
int main (){
string name = "res/img_test.png";
const char * cstr = name.c_str();
//lodepng
unsigned char *buffer;
unsigned int w,h;
int result = lodepng_decode32_file(&buffer, &w, &h, cstr);
cout << lodepng_error_text(result) << endl;
//stb_image
int x, y, comp;
FILE *f = fopen(cstr, "rb");
unsigned char *res;
res = stbi_load_from_file(f,&x,&y,&comp,0);
fclose(f);
cout << stbi_failure_reason() << endl;
return 0;
}
I'm using latest cmake to build this with gcc. Any recommendatation is appreciated but consider this. I've tried many files (generated by me or grabbed from internet). Tested same files with other users of the these libraries. Their code worked and mine didn't.
Edit:
Here's the source with complete cmake project >> github.com/onatbas/png_load_test.git
I solved it! Thank you everyone for trying to help.
It wasn't a code issue, afterall. It is a configuration issue. My cmake script damages the pngs and bmps when trying to copy them into destination folder. The code is fine.

How do I make an OpenGL SuperBible 6 application portable?

I'm developing an OpenGL application using the sb6::application framework provided by SuperBible v6, and although it always works fine on my computer (even when I run the executable outside of my DE), no one else who I send it to can get it to run. It can't be an issue with OpenGL versions, since my friend has v4.2. (I have v4.3, but it's an extremely rudimentary program so I highly doubt I've done anything exclusive to v4.3) It might have to do with a missing file since the window just closes instantly when he starts it, but I can't figure out what file. It might be a .dll or something (I've assumed that I can just put any needed .dlls in the same folder as the executable) but I haven't been able to find out which one. I got my friend to run DependencyWalker and I specifically tracked down and sent him the ones that DependencyWalker said he was missing, and there was still no improvement.
SuperBible has absolutely no documentation on the sb6::application class and doesn't give any information about how to set up a project to be portable. Or if it does I haven't been able to find it even after days of searching.
Not sure which parts of the code are relevant to post, but here are the init() and startup() functions from the sb6::application class.
void init()
{
// Redirect output to this file.
//freopen("myoutput.txt", "w", stdout);
ready = false;
static const char title[] = "Forkits";
sb6::application::init();
memcpy(info.title, title, sizeof(title));
}
void save_viewport_size()
{
// Get the size of the window
glGetIntegerv(GL_VIEWPORT, m_viewport);
std::cout << m_viewport[0] << " " << m_viewport[1] << " " << m_viewport[2] << " " << m_viewport[3] << std::endl;
}
void startup(void)
{
// Check version
GLint version = 0;
//glGetFloatv(GL_VERSION, &version);
//glGetIntegerv(GL_VERSION, &version);
//std::cout << "Version number " << glGetString(GL_VERSION) << std::endl;
//printf("%s %s\n", glGetString(GL_RENDERER), glGetString(GL_VERSION));
// Save the size of the initial viewport
glGetIntegerv(GL_VIEWPORT, m_viewport);
std::cout << m_viewport[0] << " " << m_viewport[1] << " " << m_viewport[2] << " " << m_viewport[3] << std::endl;
program = glCreateProgram();
GLuint vs = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vs, 1, vs_source, NULL);
glCompileShader(vs);
print_shader_log(vs);
GLuint fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fs, 1, fs_source, NULL);
glCompileShader(fs);
print_shader_log(fs);
glAttachShader(program, vs);
glAttachShader(program, fs);
glLinkProgram(program);
print_linker_log(program);
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
// Set parameters
glSamplerParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glSamplerParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glSamplerParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
// Set up alpha blending
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
ready = true;
flag_running = true;
int init_success = Forkits::init(&sprites);
logic = new std::thread(old_main);
}
You're right, you should just be able to put the .dlls in the same directory as the executable and it'll work. It's possible that sb6 is reliant on other .dlls that you have but your friend doesn't. Or more likely, your friend's .dlls are out of date. That is one route of investigation. It is interesting that the window opens up successfully, and then closes. To me, that points to a problem setting up your OpenGL context. Can you post the code that you call to set up OpenGL?
Another, and in my opinion, better route to take would be to remove sb6 from your application entirely and switch to another, more portable application framework. Sb6 is only intended for practice, if you want a more robust framework I would switch. Since you've only done a small project using sb6, now is also an excellent time to change over because the code changes would be minimal and (relatively :)) painless. Here are a few libraries I suggest:
SDL - My personal favorite. It'll do everything from setting up a window, handling input, networking, playing sounds, and even threading. And it (claims) to be completely portable. Be warned, however. They just went through a major update (1.2 to 2.0) and the documentation hasn't completely caught up yet.
GLFW - If you're making a dedicated OpenGL application, this might be a better option. Since it's built from the ground up to work with OpenGL (unlike SDL, which first and foremost is a windowing framework and doesn't care what you put in the windows) it's faster to set up to work with OpenGL.
SFML - Appears to be a varient of SDL. To be honest, I haven't used this one before, but if you like it, tell me how it is!
There are others out there as well, but these are the big three I've heard of. Let me know if you have any questions about running them.

Very slow startup using SDL 2 on OS X 10.8

Even using the most basic SDL test, when I run the output file after compiling, I get a pinwheel for about 8 seconds, and then the program starts.
This doesn't happen if I don't use SDL.
I have tried both clang and g++ with the same results.
#include <iostream>
#include <SDL2/SDL.h>
int main(int argc, char **argv){
if (SDL_Init(SDL_INIT_EVERYTHING) != 0){
std::cout << "SDL_Init Error: " << SDL_GetError() << std::endl;
return 1;
}
SDL_Quit();
return 0;
}
Is this normal, or is there a way to fix this? It's really annoying for quickly testing :(
I've found initializing the joysticks tends to take a long time across multiple platforms.
My solution is to initialize just the video to begin with, then later initialize other stuff separately.
SDL_Init(SDL_INIT_VIDEO);
// You can create your window and display a splash screen here
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_InitSubSystem(SDL_INIT_AUDIO);