I've got a weird problem that's suddenly appeared across all projects I'm working on. I'm using C++, SDL2 and OpenGL, and one of the first things that happens in my int main is to create an SDL window with an OpenGL flag like below:
int main( int argc, char* args[] )
{
//Minor stuff here e.g. initialising SDL
mainwindow = SDL_CreateWindow("...", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_OPENGL);
}
For some reason this has started to cause a segmentation fault. If I change the flag from SDL_WINDOW_OPENGL to anything else, it does create a window but obviously fails shortly afterwards given the lack of an OpenGL context to do anything with. I've gone as far as to strip out all code except for the SDL and OpenGL initialisation stuff, and it still fails with a segfault error.
This issue has started as of today across two projects that share the same basic int main structure. This leads me to believe it's not a code issue (largely because the code hasn't actually changed), but that something with my setup / environment has gone wrong. So far I've tried the following to no avail:
Redownloaded latest SDL library
Redownloaded latest GLEW library
Reinstalled Codeblocks
Any ideas for a) what might be causing this and b) where I should start looking to fix it?
Thanks
Nathan
And like so many other problems in life, the answer turned out to be drivers. A system-wide update of some kind interfered with the graphics' ability to render any kind of OpenGL. A direct download and install of the latest graphic drivers fixed it.
Related
When using the following BGFX code:
#include "GLFW/glfw3.h"
#include <bgfx/bgfx.h>
int main() {
glfwInit();
GLFWwindow* window = glfwCreateWindow(800, 600, "Hello, bgfx!", NULL, NULL);
bgfx::Init bgfxInit;
bgfxInit.type = bgfx::RendererType::Count; // Automatically choose a renderer.
bgfxInit.resolution.width = 800;
bgfxInit.resolution.height = 600;
bgfxInit.resolution.reset = BGFX_RESET_VSYNC;
bgfx::init(bgfxInit);
}
A black openGL window pops up and appears fine for a second, however, a GLXBadDrawable error then pops up. I do not know what the cause of this error is, and the other question has no answers and has not been active for some time now.
I believe that this is not an issue with the code, but rather my machine, however, I may be wrong.
I currently have a Lenovo T400 laptop, with a Core 2 Duo P9500. I have 2 built-in GPUs, a Mobile 4 Series Chipset integrated graphics chip, along with an ATI Mobility Radeon HD 3450/3470. I am also running Artix Linux with the 6.0.7-artix1-1 kernel. I also am using the glfw-x11 and glfw packages if that helps, along with the i3-gaps window manager.
I have also attempted to use SDL2 instead of GLFW, and the same issue occurs. However, for GLFW a black window shows up, while in SDL2, a transparent(?) window instead shows up. Searching the github issues page also yielded no results.
When I use to draw in c++, the frame comes out fine for 2-3 seconds and then crashes saying:
[xcb] Unknown sequence number while processing queue.
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
I have called the XInitThreads() befor initgraph()
I use Ubuntu 17.10 and g++ 7.2
There seems to be a problem with Ubuntu while using XInitThreads() from what I saw online.
Is there an alternative drawing method? Or can I fix this problem?
A part of my code:
int main()
{
int gd = DETECT, gm;
XInitThreads();
initgraph(&gd, &gm, NULL);
line(100,100,200,200);
delay(10000);
getch();
}
See: xcb.freedesktop.org/tutorial
It seems as if you could use this tutorial. My understanding was that graphics.h was a header for functions included a long time ago, with Borland Turbo-C? If the functionality of that library was directly reproduced, it wouldn't be compatible with xcb or Xlib since it took over the framebuffer entirely.
I found the Basic Windows and Drawing tutorial, which you'll find at the link I provided, to be very helpful. After you create a window and map it to the screen, you can draw in it using the primitives, pixel by pixel if you like.
I'm new to openGL and SDL and I'm having some problems with a basic program I wrote. I've narrowed it down and it seems like the problem is a conflict between the SDL_CreateRenderer function and how SDL manages OpenGL.
Basically the program is a simple game, drawn with OpenGL, and the problem has risen with me creating a menu. Since the game window was created with the "SDL_WINDOW_OPENGL" flag, I created another window for the menu. Whenever I need to switch between game and menu I just hide and show whichever window I need. To draw on the menu window though I need to create a renderer but after doing so, if I try to go back to the OpenGL window everything crashes catastrophically (computer slows down, everything is unresponsive...).
Can anyone guess where the problem could lie? Or can anyone suggest a better way to solve my game-menu problem?
Don't try to inter-op OpenGL and SDL_Renderer: even if you could guarantee that your platform did/did not implement SDL_Renderer in terms of OpenGL the SDL_Renderer API doesn't have any way to properly set/restore the OpenGL state that SDL_Renderer uses.
I have made a very basic SDL application which kept going for a few iterations of the main loop, but then crashed. I have located the error to lie in SDL_GL_SwapWindow, which works the first two times, then crashes. This is a very simplified version that I have actually tried and it did the same thing.
SDL_Init(SDL_INIT_EVERYTHING);
SDL_Window* SDLWindow = SDL_CreateWindow("Balls", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 800, 600, SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN);
SDL_GLContext SDLGLContext = SDL_GL_CreateContext(SDLWindow);
glewInit();
glViewport(0, 0, 800, 600);
SDL_GL_SwapWindow(SDLWindow);
SDL_GL_SwapWindow(SDLWindow);
SDL_GL_SwapWindow(SDLWindow); //crashes here
return 0;
First two calls work just fine, the third one crashes the program. Strangely, the crash occured in igd10umd32.dll and the debugger didn't allow me to read that file. I looked that up on the internet, but no attempts to fix the library worked. Besides, if the problem was in this library, it probably wouldn't appear under such strange conditions.
And what's even weirder is that the program works fine on my second laptop. And when I compiled it there and ran it on this laptop, it also worked fine.
I'm using Windows 10. I've worked with SDL/OpenGL many times and never encountered anything like this. Any ideas what may cause this very chaotic behavior?
Solved. It was nothing more than an NVIDIA bug. Updating the driver got rid of all problems.
This question already has answers here:
Can you create OpenGL context without opening a window?
(3 answers)
Closed 8 years ago.
I want to use the nice z-buffer functions of OpenGL, but I really don't want my program to open a window each time it runs (because I want it run as fast as possible).
I am quite new to OpenGL, and I followed the tutorial to learn it. In the tutorial every example starts with:
initialize GLFW
open a window
initialize GLEW
the real stuff
So I was thinking: hmm, since I only want to keep the real stuff, let's get rid of step 1-3. --I ended up with "segmentation error"
Then I was thinking: well, maybe GLEW is related to my real stuff, but GLFW, by its name, only does the window stuff. So I tried deleting step 1, and deleting step 1-2. --Both gave me a "failed to initialize GLEW"
Now I'm confused... What should I do?
I use OpenGL with GLFW + GLEW in a multi-platform system [Windows, Mac and Linux].
The error you are having smells like missing:
glewExperimental = GL_TRUE;
Google for it so you can understand a little more.
What platform are you on?
Unless I'm confused, GLFW is also responsible for setting up the OpenGL context which you will need regardless if you want to render the buffers to screen or not.