Thus spake lancel:
The new test.exe crashed without generating any dump. The previous
version of test.exe crashed but Windows could generate a minidump.
Since I don’t have any symbol files for the test.exe, I don’t know where
it crashes. I am uploading the dumps here for you.
What kind of files are these? I don’t know what to do with them.
Would it help if I put the source for the demo in a public git repo?
–
J.
The Windows mdmp file is like Unix’s core dump file. If I have your build environment, I probably can read it.
On the other hand, I guess your crash is probably the same as the one seen on mine when I used the Visual Studio IDE to build your original code. So, I browsed the web and found this:
objectmix.com/graphics/135701-gldrawarrays.html
I added the lines below in your code to see what I can get on my machines:
GLint value;
glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, &value);
On my netbook, the value is 1024. On my W7 64-bit, it is 2147483647. On my W2k VM, it is only 256 (OpenGL 1.1).
So, I wonder how large your array is. If it is larger than 1024, that may explain it. Is there any way for you to limit the size to something less than 1024 so that I can test it? I am not that familiar with OpenGL so I don’t know right away where I should go to trim off the array that glDrawArrays uses.
Lance
BTW, I just found out that glBindBuffer is available only for OpenGL 1.5 or newer:
opengl.org/sdk/docs/man/xhtm … Buffer.xml
Perhaps that has something to do with the crash seen in glDrawArrays?
Lance
Thus spake lancel:
BTW, I just found out that glBindBuffer is available only for OpenGL 1.5
or newer:opengl.org/sdk/docs/man/xhtm … Buffer.xml[1]
Perhaps that has something to do with the crash seen in glDrawArrays?
The last binary I uploaded uses glBindBufferARB if glBindBuffer isn’t
available, and there’s a check in test.cpp which should print an error
messasge to your terminal and exit if neither are available. This check
comes well before any OpenGL functions are called.
–
J.
Thus spake lancel:
The Windows mdmp file is like Unix’s core dump file. If I have your
build environment, I probably can read it.
Here’s an archive of my working directory, after having just done a
Windows build:
vassalengine.org/~uckelman/v … indows.zip
On the other hand, I guess your crash is probably the same as the one
seen on mine when I used the Visual Studio IDE to build your original
code. So, I browsed the web and found this:objectmix.com/graphics/135701-gldrawarrays.html[1]
I added the lines below in your code to see what I can get on my
machines:GLint value;
glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, &value);On my netbook, the value is 1024. On my W7 64-bit, it is 2147483647.
On my W2k VM, it is only 256 (OpenGL 1.1).
So, I wonder how large your array is. If it is larger than 1024, that
may explain it. Is there any way for you to limit the size to something
less than 1024 so that I can test it? I am not that familiar with
OpenGL so I don’t know right away where I should go to trim off the
array that glDrawArrays uses.
All of the vertex arrays being drawn have 4 elements. I haven’t done
anything fancy yet to pack vertices from multiple objects into larger
arrays.
–
J.
I could not get your code compiled with VS 2010 yet. On checking the working code you just uploaded, I did not find anywhere calling glBindBufferARB though. I suppose if anywhere, that change should be in map.cpp?
Lance
Actually, I never see any error message. Your last binary just crashed after trying to start.
Lance
I don’t know what public git repo is. I guess why not, since we have been struggling with this for a bit too long, I think.
Lance
Thus spake lancel:
I could not get your code compiled with VS 2010 yet.
How did it fail? What were the error message?
On checking the
working code you just uploaded, I did not find anywhere calling
glBindBufferARB though. I suppose if anywhere, that change should be in
map.cpp?
In order to avoid checking for OpenGL 1.5 support every time we use
one of the VBO functions, I set up some function pointers for these
functions (and for all of the other OpenGL functions we use). These
are in the gl namespace, declared in glutil.h and set in glutil.cpp.
Unless I have the wrong test in setup_gl_fptrs() in glutil.cpp, there
shouldn’t need to be any changes made elsewhere.
–
J.
Thus spake lancel:
The last binary I uploaded uses glBindBufferARB if glBindBuffer isn’t
available, and there’s a check in test.cpp which should print an error
messasge to your terminal and exit if neither are available. This
check
comes well before any OpenGL functions are called.Actually, I never see any error message. Your last binary just crashed
after trying to start.
Do the core dumps you have tell you wehere it’s crashing?
–
J.
I don’t know how to read the dump unless I have the symbol files generated with the code compiled. So, I tried to set up your code in a MS IDE to see if that can be compiled. On my first run, the IDE generated the following errors for your function pointer translation lines inside setup_gl_fptrs().
error C2440: ‘=’ : cannot convert from ‘void (__stdcall *)(GLenum,GLuint)’ to ‘void (__cdecl *)(GLenum,GLuint)’
1> This conversion requires a reinterpret_cast, a C-style cast or function-style cast
So, I tried to cast your lines in glutil.h and glutil.cpp to something like this:
extern void (__stdcall *BlendFunc)(GLenum sfactor, GLenum dfactor);
The thing compiled but the link failed with something like the ones below. I have yet to figure out why only the lines below have unresolved external symbols but not all the function pointers that you redefined inside setup_gl_fptrs(). Maybe it is a different problem unrelated to the changes I made.
glutil.obj : error LNK2001: unresolved external symbol __imp____glewGenBuffersARB
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewDeleteBuffersARB
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewBufferDataARB
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewBindBufferARB
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewGenBuffers
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewDeleteBuffers
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewBufferData
1>glutil.obj : error LNK2001: unresolved external symbol __imp____glewBindBuffer
1>glutil.obj : error LNK2001: unresolved external symbol __imp____GLEW_VERSION_1_5
1>glutil.obj : error LNK2001: unresolved external symbol __imp____GLEW_EXT_texture_filter_anisotropic
I stand corrected. I figured out what the problem is. I did not realize that I also needed the glew32mx.lib. After I added that in, it worked. I can now see the map on my netbook. The counters are missing still. Let me check that out next.
Lance
Thus spake lancel:
I don’t know how to read the dump unless I have the symbol files
generated with the code compiled. So, I tried to set up your code in a
MS IDE to see if that can be compiled. On my first run, the IDE
generated the following errors for your function pointer translation
lines inside setup_gl_fptrs().error C2440: ‘=’ : cannot convert from ‘void (__stdcall
*)(GLenum,GLuint)’ to ‘void (__cdecl *)(GLenum,GLuint)’
1> This conversion requires a reinterpret_cast, a C-style cast
or function-style cast
That’s interesting. This is a problem with the function calling
convention. Apparently VS wants __stdcall. I’m not sure why this doesn’t
happen for me. I’ll mess with this a bit to see what’s going on. Maybe
the solution here is a macro defining the right calling convention for
these.
So, I tried to cast your lines in glutil.h and glutil.cpp to something
like this:extern void (__stdcall *BlendFunc)(GLenum sfactor, GLenum dfactor);
The thing compiled but the link failed with something like the ones
below. I have yet to figure out why only the lines below have
unresolved external symbols but not all the function pointers that you
redefined inside setup_gl_fptrs(). Maybe it is a different problem
unrelated to the changes I made.glutil.obj : error LNK2001: unresolved external symbol
__imp____glewGenBuffersARB
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewDeleteBuffersARB
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewBufferDataARB
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewBindBufferARB
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewGenBuffers
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewDeleteBuffers
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewBufferData
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____glewBindBuffer
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____GLEW_VERSION_1_5
1>glutil.obj : error LNK2001: unresolved external symbol
__imp____GLEW_EXT_texture_filter_anisotropic
It looks like the linker can’t find GLEW. I don’t know where you tell
the linker where to look for libraries in VS.
The last two, in particular, are just bools, not function pointers.
–
J.
Thus spake lancel:
I stand corrected. I figured out what the problem is. I did not
realize that I also needed the glew32mx.lib. After I added that in, it
worked.
!
I checked the last Windows archive I uploaded—glew32mx.dll isn’t
included. I’ll be that’s part of why my builds were crashing on Windows.
I wasn’t aware that that DLL was needed.
Thanks for figuring this out!
I can now see the map on my netbook. The counters are missing
still. Let me check that out next.
Are the counter image files in ./images relative to test.exe?
–
J.
Yes. I stepped into the lines that load up the images and there are no exceptions there. The counters just show up blank. I can move the blank counters around on the map though.
I think you don’t see the stdcall error because you are using GCC as Microsoft IDE uses a calling convention different from the other’s.
There is another problem I saw with the build I made. It crashes at the end whenever I close up the app. Maybe the crash won’t happen with a build made with MinGW.
Lance
Thus spake lancel:
Yes. I stepped into the lines that load up the images and there are no
exceptions there. The counters just show up blank. I can move the
blank counters around on the map though.
Hmm. That’s vexing.
There is another problem I saw with the build I made. It crashes at the
end whenever I close up the app. Maybe the crash won’t happen with a
build made with MinGW.
I suspect that’s due to the fact that I’m calling glutDestroyWindow when
the View is destroyed, but that something in GLUT has already called that
when you close the demo. That’s my guess, at least.
Can you look at a core dump to see where it’s crashing?
–
J.
I ran the same binary that I built on my W7 64-bit and it worked like the others. It did not crash on closing the app.
Going back to my netbook, the crash happens inside boost’s bind.hpp at:
template<class F, class A> void operator()(type, F & f, A & a, int)
{
unwrapper::unwrap(f, 0)(a[base_type::a1_], a[base_type::a2_]);
}
Lance
On my W7 game machine, I can see the counters with the same binary. So the counters are blank only on my netbook. Probably still OpenGL version issue here. Maybe that also explains the crash as well.
Lance
Thus spake lancel:
I ran the same binary that I built on my W7 64-bit and it worked like
the others. It did not crash on closing the app.Going back to my netbook, the crash happens inside boost’s bind.hpp at:
template<class F, class A> void operator()(type, F & f, A & a,
int)
{
unwrapper::unwrap(f, 0)(a[base_type::a1_],
a[base_type::a2_]);
}Lance
Can you give me more of the backtrace than that? There are several
places where we’re using boost::bind.
–
J.
Thus spake lancel:
On my W7 game machine, I can see the counters with the same binary. So
the counters are blank only on my netbook. Probably still OpenGL
version issue here. Maybe that also explains the crash as well.
What we need is a backtrace from your laptop for the crash, so we can
see where it’s happening.
What kind of graphics hardware is in your netbook again?
If the program gets to the point of displaying anything at all, then
it’s made it past the check that the OpenGL version is adequate and all
of the extensions we use are supported. I can’t presently think of any
reason why the pieces should be blank but the map tiles ok—they’re
loaded and rendered in almost the same way. Is every piece blank? Could
you post a screenshot?
–
J.