glew patch for unknown error wxWidgets>=3.1.5 (Issue #22710)
mostlyharmlessone
Versions of wxWidgets 3.1.5 and greater using glew throw a runtime glew error : unknown error and fail to display openGL
See https://forums.wxwidgets.org/viewtopic.php?f=23&t=48238&sid=49bfb6df90c9db334c27b6e450b8ce10
See also
https://bbs.archlinux.org/viewtopic.php?id=278127
A patch to glew fixes the problem:
https://aur.archlinux.org/packages/glew-egl-glx
- wxWidgets version you use: [
- 3.1.3 no issues
- 3.1.7, 3.2.0 verified problematic
- wxWidgets port you use: wxGTK
- OS Arch & Manjaro, however reported with other distro unknown
- For wxGTK
- GTK version: Arch/Manjaro
updated - Which GDK backend is used: Wayland
- GTK version: Arch/Manjaro
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I'm very confused, wxWidgets doesn't use GLEW at all, so how can a patch to it fix anything?
Is the problem actually in wxWidgets, i.e. do our OpenGL samples show it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
This is almost certainly a packaging issue for whatever application is showing the error. GLEW must be compiled for each backend separately (a GLEW install compiled for OpenGL won't run on EGL and vice-versa). With the introduction of the EGL backend for wxGLCanvas in wx 3.1.5, the default canvas was switched to using the EGL backend, so any applications that use wx >= 3.1.5 and GLEW need to use either the OpenGL backend and their old GLEW library or the new EGL backend and GLEW compiled to use EGL. If the wx packager just blindly upgraded the wx version without paying attention to this, it would have enabled the EGL backend and the dependent applications would break if they weren't expecting/prepared for it.
There are therefore two options for the packager:
- Have the distribution compile wxWidgets with the OpenGL backend instead of the EGL backend, or
- Link the downstream application using wxGLCanvas against GLEW compiled with EGL support (instead of with OpenGL support).
Either way, there isn't much we can do to fix this unless the wxGLCanvas backends are made runtime switchable (which would probably be an ABI break and not something that could even go into 3.2).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
it is the change to EGL as default which broke existing glew installs. The patch on Arch fixes glew to use EGL. An alternative would be a patch to wxWidgets to restore openGL as default. Hopefully the maintainers of package distributions are paying attention. Perhaps a more prominent announcement could help.
> On Aug 5, 2022, at 18:20, Ian McInerney ***@***.***> wrote:
>
>
> This is almost certainly a packaging issue for whatever application is showing the error. GLEW must be compiled for each backend separately (a GLEW install compiled for OpenGL won't run on EGL and vice-versa). With the introduction of the EGL backend for wxGLCanvas in wx 3.1.5, the default canvas was switched to using the EGL backend, so any applications that use wx >= 3.1.5 and GLEW need to use either the OpenGL backend and their old GLEW library or the new EGL backend and GLEW compiled to use EGL. If the wx packager just blindly upgraded the wx version without paying attention to this, it would have enabled the EGL backend and the dependent applications would break if they weren't expecting/prepared for it.
>
> There are therefore two options for the packager:
>
> Have the distribution compile wxWidgets with the OpenGL backend instead of the EGL backend, or
> Link the downstream application using wxGLCanvas against GLEW compiled with EGL support (instead of with OpenGL support).
> Either way, there isn't much we can do to fix this unless the wxGLCanvas backends are made runtime switchable (which would probably be an ABI break and not something that could even go into 3.2).
>
> —
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
You can use --disable-glcanvasegl configure option to disable EGL support even if it's available when building wxWidgets. We can't force Arch package maintainers to use it if it's necessary however, so there really isn't much we can do here. Please ask the maintainers to contact us (preferably on wx-dev mailing list) if they have any questions about this, but I don't see this as a wx bug at all, so I'm closing it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #22710 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
That can be regarded that as a glew error, or a wxWidgets problem, but it appeared with a change to wxWidgets and I was directed here by the wxWidgets forum moderator. Patching glew apparently fixes the issue created or uncovered by the newer wxWidget.
Please, at the very least a disclaimer/warning or build workaround would be helpful, in case the glew developers decide it is a wxWidgets problem. It might be instructive to know what change from 3.1.4->3.1.5 triggered the incompatibility with upstream glew.
> On Aug 5, 2022, at 17:45, VZ ***@***.***> wrote:
>
>
> I'm very confused, wxWidgets doesn't use GLEW at all, so how can a patch to it fix anything?
>
> Is the problem actually in wxWidgets, i.e. do our OpenGL samples show it?
>
> —
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
The change is that EGL is now used by default if it's available and it's already listed in the change log, although, admittedly, not in the "incompatible changes" section as there is nothing really incompatible about it on its own.
The workaround is to use either "classic" OpenGL or EGL for both GLEW and wx.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
I ran bisect on wxWidgets and found that the first bisect that causes the GL code to stop working is 7cd12a2, which added the EGL backend to 3.1.5 back in 2020, was surmised above. I've also noticed that after using glEnable(GL_DEPTH_TEST) one MUST now use glDepthFunc(GL_LEQUAL), whereas prior to the commit, you could omit it. There also seems to be a subtle problem with the depth buffer which I'm still trying to resolve, which only shows up after the mentioned commit.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
I ran bisect on wxWidgets and found that the first bisect that causes the GL code to stop working is 7cd12a2, which added the EGL backend to 3.1.5 back in 2020, as surmised above
Yes, we know that commit is what would have caused it - we already said that GLEW for OpenGL is not compatible with GLEW for EGL, so using the wxWidgets wxGLCanvas with EGL is not going to work with GLEW for OpenGL. There is nothing wxWidgets needs to do here - everything should be handled by downstream packagers choosing the proper combination of packages for their builds to ensure they work together.
I've also noticed that after using glEnable(GL_DEPTH_TEST) one MUST now use glDepthFunc(GL_LEQUAL), whereas prior to the commit, you could omit it.
The GL_LEQUAL is not the default test for the depth test, the default is GL_LESS. The fact it seems to have worked previously without setting the desired test seems to be a bug, and the program should specifically set the GL_LEQUAL test if it requires that one.
There also seems to be a subtle problem with the depth buffer which I'm still trying to resolve, which only shows up after the mentioned commit. I am not the only person who has noticed this.
This is the first anyone has mentioned this on this issue tracker, where is this being discussed by others?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
There also seems to be a subtle problem with the depth buffer which I'm still trying to resolve, which only shows up after the mentioned commit. I am not the only person who has noticed this.
@imciner2: This is the first anyone has mentioned this on this issue tracker, where is this being discussed by others?
In the master there is a commit that mentions depth buffer but it has issues of its own, see the comments: e11ea1b
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
Another person with depth buffer issues: https://forums.wxwidgets.org/viewtopic.php?p=214372#p214372 I do not know whether they have the same problem that I do.
The person who made the commit about the depth buffer mentioned immediately above apparently is the same individual on the wxWidget forum denying there is a problem, or at least, in my opinion, not being helpful. At least that's the impression that was made on me, you are free to disagree. If code works before a commit, then breaks after a commit, it's a reversion, and there should be an acknowledgement of such, like @imciner2's: comment above about the GL_LEQUAL or GL_LESS which is helpful and acknowledges that the previous behaviour not requiring the glDepthFunc call was different (and a bug). That's helpful, and isn't just "your code is broken".
I didn't have the depth buffer issues before the EGL commit. That's a reversion. I don't have the issue with a non wxWidgets glfw version of the display. Unfortunately glfw didn't meet my UI needs, so I moved to wxWidgets, which worked great until the EGL commit. I do not feel I was heard on the forum. My current workaround is to recode my UI using Qt.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It's a regression in the sense that EGL is, apparently, not 100% compatible with the classic OpenGL -- which is a bit surprising, but not totally unexpected.
The best solution seems to adjust your code to work with both OpenGL and EGL, as surely EGL support is nice to have (if only for Wayland support). If you don't want to do this, another simple solution is to disable EGL support and keep using OpenGL. Rewriting your entire application to use another GUI framework because of this minor issue doesn't seem like a reasonable solution to me, but you certainly know better.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
@vadz, EGL is compatible with modern OpenGL (version > 3.1). It isn't with old OGL, things like 'Stereo' attribute or ancillary buffers (accumulation, auxiliar).
From the wx POV, the relevant change is that wx' EGL implementation for attributes default lacks the 'Depth Buffer' set. It was not needed for the GLX platform because it did set that attr. Other old settings simply are ignored.
From the user POV it's a regression because his app worked before.
There's a lot of confusion, just because a typical user knows about OGL coding, but knows nothing about the previous part, setting the OGL environment (wx' job, for MSW, GLX, EGL, OSX), which is achieved by OS functions, not OGL ones. And so just a bunch of users are aware of differences between GLX and EGL. The rest of users will just blame the first one at sight.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
@vadz Is there a way to disable EGL when linking to wxWidgets during compilation of my code without rebuilding/compiling the wxWidgets library? Ideally I would like the end user to be able to use the OS's/distro's version of the wxWidgets. You are right: I am not happy about recoding in yet another GUI framework. I suppose the alternative is to use a statically linked version.
"The best solution seems to adjust your code to work with both OpenGL and EGL" Did you mean GLX and EGL? All I'm using are (modern > 3.1) gl commands. What exactly are the magic juju beans I'm supposed to add for EGL compatibility? I've set
wxGLContextAttrs ctxAttrs; ctxAttrs.PlatformDefaults().CoreProfile().OGLVersion(4, 1).EndList(); in my code when making my context.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
There is no way to choose between EGL and GLX at run-time right now, it will become possible when #22325 is implemented and I plan to do it, but this hasn't been done yet.
I don't know why EGL wouldn't work with the explicit attributes like this, sorry. If you can reproduce the problem in one of wx OpenGL samples, please open a ticket about it and I'll try to look at it. But I thought this one was only about incompatibility between wx-using-EGL and GLEW-using-GLX, so if you still use them together, you need to also switch to EGL version of GLEW.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
@mostlyharmlessone The attributes you shown are context attributes. They are fine, no problem. The EGL issue rises one step before, when you set visual attributes to wxGLCanvas (RGBA, depth, double buffer, etc).
Please notice that all this OpenGL setup is not done by gl-commands, but by OS (EGL or GLX) commands. The later is what wxWidgets uses internally (e.g. eglCreateContext, glXChooseFBConfig, etc). The former are you OGL code (e.g. glEnable, glDepthFunc, etc). And you need glew to ask EGL or GLX for the pointers to the gl-commands you speak about.
In other words, your OGL code is the same, no matter what MSW/OSX/EGL/GLX manager wxWidgets uses to set the OpenGL environment.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
Just so everyone can see the problem since the referenced commit, I have attached three png files. They all show the same thing: a non-uniformly orange spherical shell, with an irregular edge. The view shown is on edge. In the old wx 3.1.3 version, the object is rendered correctly. In the newer versions (anything after the fatal commit), you can see the distant edge through the front surface. Changing glew for epoxy does not change that; contrary to my first post, it has nothing to do with glew.
I have also recoded in Qt, which, like my earlier glfw version, does not have an issue. My OGL code is as identical as the different gui environments allows ( and obviously identical for the two wxWidget versions). All the gl commands are the same, though obviously the wx specific commands have been replaced with Qt commands and the overall code construction is different (and quite a bit simpler to be honest about it). The model generator is identical.
The only thing which destroys the proper rendering is the wx commit, and it does that independent of the physical hardware, on different machines. It's a regression in wxWidgets. It would be a very weird coding error that works great in glfw, Qt and wxWidgets only before the EGL commit. At some point it feels like gaslighting or denial to blame my code or the OS or the hardware, or the video drivers. Sorry your simple pyramid example isn't sufficiently complicated to show it. If you're genuinely interested in addressing this issue I can probably supply you with sufficient other code details.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Sorry, I don't understand why do you think anybody is gaslighting you. I could be wrong, but from what I understand the problem is due to the difference in behaviour between OpenGL and EGL and both of these statements
- wxWidgets behaviour has changed (because it now uses EGL by default when available).
- Your code doesn't work correctly with EGL.
can be (and, AFAICS, are) simultaneously true.
Please let me know what exactly do you disagree with and, also, what else do you think needs to be done in wxWidgets to address this issue, if you think that anything needs to be done.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
The differences in the images may well be due to "z-buffer fighting". (Two pixels with almost same Z coord, impossible to tell who gets shown, due to parallel GPU rendering). While there are some techniques to solve this issue, the easiest one is to use a more-bits depth buffer.
Perhaps you can try with Depth(24).RGBA().DoubleBuffer() attributes instead of Defaults(), as the last uses 16 bit buffer.
This would explain the differences between Qt, glfw and wx.
If this change in visual attributes doesn't work for you, then the issue is in your code.
See, wxWidgets doesn't use any gl-command. It only can affect the render by the wxGLAttributes used, as happens with Depth() parameter. But, apart from the z-fighting the rest is for sure gl-code, not wx-code, no matter EGL/OGL set.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Just to clarify, again: "the issue is in your code" is not completely correct, there is no issue if OpenGL is used, just as the OP wrote. But because the default attributes are different between OpenGL and EGL, there is an issue when using EGL.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
The only differences I see between EGL and GLX in wx code are some not supported attributes (e.g Stereo) and others (like RGBA) that are not treated by wx because EGL manager has them always, not needed to ask for.
Some weeks ago I checked differences in attributes in both EGL/GLX specifications, just to be sure that wx's EGL-related code was good. I didn't find anything wrong. Just those things that wx has never handled (transparency set, etc). Of course, I may be wrong.
I (still) say "the issue is in your code", because the OP doesn't give enough proofs. Now, he posted some images I can only think of the Depth Buffer, which happens to be a common problem that any OGL coder meets sunner or later.
For example, pyramid copes with z-fighting at myOGLManager::SetStringOnPyr, to avoid the text and a face being in the same plane.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Manolo, the fact that their code behaviour changed after switching to EGL is proof enough.
I start feeling crazy because clearly I'm talking at cross-purposes not to one but to at least two persons here, but IMO things are perfectly clear: with default attributes, things work when using OpenGL, but not when using EGL. So, again, both of the following are true:
- Behaviour of the library changed from the application point of view.
- Application should be fixed to work properly with EGL too, probably by just setting the attributes correctly.
Please let me know if I'm missing something here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
I start feeling crazy because clearly I'm talking at cross-purposes not to one but to at least two persons here, but IMO things are perfectly clear: with default attributes, things work when using OpenGL, but not when using EGL. So, again, both of the following are true:
It seems like it might be more accurate to say GLX instead of OpenGL. GLX and EGL are both implementations of OpenGL.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
Sadly, I'm coming to the unfortunate realization that making EGL the default was probably a bad idea at this point. On Fedora and Debian, I'm planning to rebuild with --disable-glcanvasegl for now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mostlyharmlessone
I had described the problem in words, and even intuited that the depth buffer was at fault, but clearly pictures were better in showing the issue.
The code I used for my example IS basically the pyramid code, with glew or epoxy substituted for the oglpfuncs code and all the texture and string stuff stripped out. I also removed the light source and normals and have a very simplified fragment shader and vertex shader.
I had stripped out the previously unnecessary (in version 3.1.3) DepthFunc() command and it took a long time to realize that the EGL patch now required it, as recognized as a bug in wxWidgets by incimer2.
It's just a simple viewer at this point that shows more than just a pyramid with four vertices. The structure of the code, the classes, all the OGL stuff IS the pyramid code. There are really no additions, other than simpler shaders and a larger structure with more vertices. So to keep insisting "it's the code", well it's YOUR code.
Changing vAttrs.PlatformDefaults().Defaults().EndList(); to
vAttrs.PlatformDefaults().RGBA().DoubleBuffer().Depth(16).EndList();
which is suggested in the pyramid example, did nothing. I had tried that previously.
Changing it to
vAttrs.PlatformDefaults().RGBA().DoubleBuffer().Depth(24).EndList(); fixes it for this image.
Mark it [SOLVED]
Whether I would have to increase it to some other number 32? 64? in the future with some more complicated image is unknown to me, as are any other gotchas. Why the Defaults() and the suggested fix with Depth(16) in the example are so inadequate for a real life image example, I leave you to ponder.
While it's nice to have this problem resolved at this point, and I hope this thread saves someone else a great waste of time, the experience has not been good. Something more helpful along the lines of "that's interesting, could you show us a picture?" might have been better.
"Application should be fixed to work properly with EGL" could now at this point be: "wxWidgets Default() could be fixed to work with EGL"
Suggestions to rebuild the library into something nonstandard from the POV of any distro isn't really a fix either. Theoretically, one wouldn't want users in the future to have to build a custom glx/nonEGL wxWidgets library to build the code.
@vadz "I start feeling crazy.." == gaslighting
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
Scott: "It seems like it might be more accurate to say GLX instead of OpenGL. GLX and EGL are both implementations of OpenGL."
To be precise, both are implementatons of setting an OpenGL environment. This is, they are interfaces between rendering API (such as OpenGL) and underlaying platform (such as X11). The OpenGL code has its own specification, it's not OS-dependant
And I don't think EGL is a bad idea. What kind of problems are you finding?
mostlyharmlessone: I'm glad you solved this issue. And I'm also glad that thanks to this discussion the Depth() thing has been fixed (now all platforms behave the same).
Setting a higher depth (32, 64, n) bits) may not be enough for all cases. For example, pyramid shows a text and a face on the same plane; exactly the same Z coord, depth precision doesn't help here. The solution was to translate the text a very small (but inside depth buffer precision) amount.
You should know in advance what precision you need, and set tne Depth Buffer accordingly. There are more ways, quite sofisticated, rarely needed.
Depth(16) is a common value. That's why Defaults() uses it. And the GPU memory is lower than using 24 or 32 bits (values that may be not accepted for old hardware).
"that's interesting, could you show us a picture?" might have been better.
I agree. My fault not to ask you like that from the beginning.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I'm glad the original problem is solved, but I still don't understand why the default depth of 16 works for GLX[*] but not for EGL.
More importantly, should we actually change something in wx, e.g. use 24 depth by default when using EGL? (we still need to make it possible to select between using GLX and EGL during run-time, but this is a bigger task which will have to wait until somebody has time to do it)
[*] Thanks Scott for correcting my sloppy wording, when I wrote OpenGL I should have written GLX.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
There were two problems:
-
The lack of Depth() at glegl.cpp when using at wxGLCanvas ctor a list of integers instead of wxGLAttributes. Some hardware may set depth=0 while other hardware set depth=16 or so.
This has confused us, thinking it was a wx-EGL issue, that not always was exposed. Somehow it was, because wx-GLX did set depth in such case. -
The need for Depth(24) for the OP issue. It was a z-buffer fighting, nothing to do with wx nor EGL/GLX.
-
was solved by PR #22828
-
has been solved by the OP asking for Depth(24).
I don't think anything needs to be changed in wx. Choosing the depth is a user decision. Depth(24) may be not acepted in old harware.
Selecting EGL/GLX at run time is useful when not both interfaces are available, so no two executables are required.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
What kind of problems are you finding?
The main problems I'm encountering are:
- Other OpenGL support packages do not support EGL (e.g, glew, pyglet, possibly others).
- #22580
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ollydbg
Sorry to bother here, but it looks like I can't use glew library under Windows with wxWidgets 3.2.2.1.
Here is the sample code:
#include <GL/glew.h> // include GLEW header file
#include <GL/gl.h> // OpenGL header file
#include <wx/wx.h>
#include <wx/glcanvas.h>
class MyGLCanvas : public wxGLCanvas
{
public:
MyGLCanvas(wxWindow* parent, wxSize size) :
wxGLCanvas(parent, wxID_ANY, NULL, wxDefaultPosition, size,
wxFULL_REPAINT_ON_RESIZE)
{
m_context = new wxGLContext(this);
SetCurrent(*m_context);
glEnable(GL_DEPTH_TEST);
}
virtual ~MyGLCanvas()
{
delete m_context;
}
private:
void Render()
{
SetCurrent(*m_context);
glViewport(0, 0, GetSize().x, GetSize().y);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
// Define the vertex positions and colors.
float vertices[] = {
// Front face
-0.5f, -0.5f, 0.5f, 1.0f, 0.0f, 0.0f,
0.5f, -0.5f, 0.5f, 0.0f, 1.0f, 0.0f,
0.5f, 0.5f, 0.5f, 0.0f, 0.0f, 1.0f,
-0.5f, 0.5f, 0.5f, 1.0f, 1.0f, 0.0f,
// Back face
-0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 1.0f,
0.5f, -0.5f, -0.5f, 1.0f, 0.0f, 0.0f,
0.5f, 0.5f, -0.5f, 0.0f, 1.0f, 0.0f,
-0.5f, 0.5f, -0.5f, 1.0f, 1.0f, 0.0f,
};
unsigned int indices[] = {
0, 1, 2, // Front
2, 3, 0,
1, 5, 6, // Right
6, 2, 1,
7, 6, 5, // Back
5, 4, 7,
4, 0, 3, // Left
3, 7, 4,
4, 5, 1, // Bottom
1, 0, 4,
3, 2, 6, // Top
6, 7, 3,
};
// Create the vertex buffer.
unsigned int VBO;
glGenBuffers(1, &VBO);
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
// Create the index buffer.
unsigned int EBO;
glGenBuffers(1, &EBO);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);
// Create the vertex array object.
unsigned int VAO;
glGenVertexArrays(1, &VAO);
glBindVertexArray(VAO);
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)0);
glEnableVertexAttribArray(0);
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)(3 * sizeof(float)));
glEnableVertexAttribArray(1);
// Load and compile the shaders.
const char* vertexShaderSource = "#version 330 core\n"
"layout (location = 0) in vec3 aPos;\n"
"layout (location = 1) in vec3 aColor;\n"
"out vec3 fColor;\n"
"void main()\n"
"{\n"
" gl_Position = vec4(aPos, 1.0);\n"
" fColor = aColor;\n"
"}\n";
const char* fragmentShaderSource = "#version 330 core\n"
"in vec3 fColor;\n"
"out vec4 FragColor;\n"
"void main()\n"
"{\n"
" FragColor = vec4(fColor, 1.0);\n"
"}\n";
unsigned int vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexShaderSource, NULL);
glCompileShader(vertexShader);
unsigned int fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentShaderSource, NULL);
glCompileShader(fragmentShader);
unsigned int shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glLinkProgram(shaderProgram);
glDeleteShader(vertexShader);
glDeleteShader(fragmentShader);
glUseProgram(shaderProgram);
// Render the cube.
glBindVertexArray(VAO);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);
glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_INT, 0);
SwapBuffers();
}
wxGLContext* m_context;
// Event handlers.
void OnPaint(wxPaintEvent& event)
{
Render();
}
void OnSize(wxSizeEvent& event)
{
Refresh();
}
wxDECLARE_EVENT_TABLE();
};
wxBEGIN_EVENT_TABLE(MyGLCanvas, wxGLCanvas)
EVT_PAINT(MyGLCanvas::OnPaint)
EVT_SIZE(MyGLCanvas::OnSize)
wxEND_EVENT_TABLE()
class MyFrame : public wxFrame
{
public:
MyFrame()
{
GLenum err = glewInit();
if (GLEW_OK != err) {
//wxLogError("Error: %s\n", glewGetErrorString(err));
printf("Error: %s\n", glewGetErrorString(err));
exit(1);
}
wxBoxSizer* sizer = new wxBoxSizer(wxVERTICAL);
MyGLCanvas* canvas = new MyGLCanvas(this, wxSize(512, 512));
sizer->Add(canvas, 1, wxEXPAND);
SetSizer(sizer);
SetMinSize(wxSize(512, 512));
}
};
class MyApp : public wxApp
{
public:
virtual bool OnInit()
{
MyFrame* frame = new MyFrame();
frame->Show();
return true;
}
};
wxIMPLEMENT_APP(MyApp);
when I run the program, I got the error in the console:
Error: Missing GL version
Anyone knows how to solve this issue? glewInit can't get initialized correctly.
It looks like the code snippet:
GLenum err = glewInit();
if (GLEW_OK != err) {
//wxLogError("Error: %s\n", glewGetErrorString(err));
printf("Error: %s\n", glewGetErrorString(err));
exit(1);
}
My environment is:
msys2's G++, the wx library and glew library are both from msys2 prebuild libs(installed by pacman command)
Another issue is that I have to put the header files:
#include <GL/glew.h> // include GLEW header file
#include <GL/gl.h> // OpenGL header file
Before the wx include header files, if I put glew's header file after wx's header file, I will got compiler warnings.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
This looks a different issue as under MSW you can't be using EGL, so I've extracted it into #23480.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.