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?
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:
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.
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:
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.
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?
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.
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?
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.
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?
Weird stuff as I can’t trace really that far back. When it exits, it just starts making calls that don’t seem to come from your code. Here is the entire stack trace taken from Windbg. Vglew is the name of the executable that I built. I just found out that ig4icd32.dll is Intel’s OpenGL dll.
This is the information I needed. The crash is happening in the View
dtor, which calls the dtor of the shared_ptr holding the GLUT window
handle, which in turn calls the delete function for the handle. This
is as I had guessed. I’ll do something to make sure this doesn’t
happen when the handle has already been freed.
The full screenshot exceeds the limit allowed to upload. I can send it to you via email.
Reading off the numbers from the Control Panel, the netbook’s total available graphics memory is 256MB. System video memory is 64MB and shared System memory is 192 MB.
I ran the same binary on my other XP laptop (using ATI Radeon Xpress 200M) that runs OpenGL 1.4.5014 and I could see the counters although the app did crash on exit.
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:
This is the information I needed. The crash is happening in the View
dtor, which calls the dtor of the shared_ptr holding the GLUT window
handle, which in turn calls the delete function for the handle. This
is as I had guessed. I’ll do something to make sure this doesn’t
happen when the handle has already been freed.
Thanks for sending the screenshot. I’m glad I asked for it, because I was surprised by what I saw. (I’m attaching a scaled-down version of it here so everyone can see it.)
The order of texture creation for map tiles is from left to right, then bottom to top. Piece textures are created after map tile textures. When I saw the truncated version of the screenshot, where you can see the blank pieces and the blank tiles in the top row, what I thought was happening was that texture memory was running out—the top row and the pieces are the last textures to be loaded—so I expected to see a last non-blank map tile somewhere in the second row from the top toward the right end. But you can see from the full screenshot that the rightmost column of tiles is also blank, so some tiles are failing to get their textures when there’s still a great deal of memory
left for textures.
[attachment=0]blankcounters.jpg[/attachment]
I have a new theory about what we’re seeing here: The blank map tiles and pieces are all and only the textures which are not squares where the width and height are a power of 2. (All of the pieces are 76x76, IIRC. The map tiles in the top row and right column are not square, because the dimensions of the map are not divisible by 512.) Support for non-power-of-two (NPOT) textures was added in OpenGL 2.0; most current hardware supports it, but it’s better not to use it unless it’s necessary, because NPOT textures are slower and can’t be mipmapped (or can’t be mipmapped as well).
I think what we need to do is ensure that all textures are made square and have their dimensions padded out to the next highest power of 2. I’ll do that tomorrow, it should be easy.
Unfortunately, libstdc+±6.dll is missing. After copying this dll from one of your previous packages, running test.exe still generates the Application Error messagebox “The application was unable to start correctly (0xc0000142). Click OK to close the application.”