Roadmap for VASSAL 4

I did some more testing on W2k VM 32-bit, XP SP3 32-bit, W7 32-bit and W7 64-bit. All of them failed but on checking the Filemon logs, I got a clue when I noticed that something seemed to happen when glew32.dll was loaded. So I went to glew32.dll’s SourceForge location to download its latest. After replacing the file, my W7 64-bit works but all others still fail.

I then looked at the log files produced by running the glewinfo.exe utility that comes with the glew32 download. The log files suggest that the OpenGL binaries on my 32-bit machines are no newer than 2 whereas my gaming W7 64-bit is patched all the way to 4. I think that because my W7 64-bit has a real graphics card, when its drivers were installed, its installation package probably automatically upgraded the W7 system with the latest OpenGL binaries whereas all my other 32-bit machines are still using those default ones that come with the OS. For example, I think the glDrawArrays call works only if the OpenGL is at least of version 3.1 or above.

Lance

Checking over OpenGL’s API doc, glDrawArrays should work on GL 1.1 or higher.

Lance

Thus spake lancel:

I did some more testing on W2k VM 32-bit, XP SP3 32-bit, W7 32-bit and
W7 64-bit. All of them failed but on checking the Filemon logs, I got a
clue when I noticed that something seemed to happen when glew32.dll was
loaded. So I went to glew32.dll’s SourceForge location to download its
latest. After replacing the file, my W7 64-bit works but all others
still fail.

So you replaced the glew32.dll that I built, and then it worked on
64-bit Windows? I don’t know what to make of that. The glew32.dll I
supplied is 32-bit, but if it’s just a bitness issue, then I would
expect the one I suppied to work on the other systems you tried. What
happens if you dump in the 32-bit GLEW DLL from their site and try that
on your 32-bit systems?

I then looked at the log files produced by running the glewinfo.exe
utility that comes with the glew32 download. The log files suggest that
the OpenGL binaries on my 32-bit machines are no newer than 2 whereas my
gaming W7 64-bit is patched all the way to 4. I think that because my
W7 64-bit has a real graphics card, when its drivers were installed, its
installation package probably automatically upgraded the W7 system with
the latest OpenGL binaries whereas all my other 32-bit machines are
still using those default ones that come with the OS. For example, I
think the glDrawArrays call works only if the OpenGL is at least of
version 3.1 or above.

Here’s a complete list of the OpenGL functions the demo uses, sorted by
the minimum version of OpenGL which supports them:

OpenGL 1.1

glBindTexture
glBlendFunc
glClear
glClearColor
glColor4f
glColorPointer
glDeleteTextures
glDisable
glDisableClientState
glDrawArrays
glEnable
glEnableClientState
glGenTextures
glGetDoublev
glGetFloatv
glGetIntegerv
glLoadIdentity
glMatrixMode
glPixelStorei
glReadPixels
glShadeModel
glTexCoordPointer
glTexImage2D
glTexParameterf
glTexParameteri
glVertexPointer
glViewport

OpenGL 1.5

glBindBuffer
glBufferData
glDeleteBuffers
glGenBuffers

The OpenGL 1.5 functions we’re using are also present in the
ARB_vertex_buffer_object extension. It might be that the way we need to
handle this is by calling the ARB versions on Windows. I thought part
of the point of GLEW was that the function pointers for the core
functions would point to the ARB versions on Windows in the event that
the core ones weren’t there… Possibly I’ve misunderstood this, but
then I’m not sure what exactly GLEW is for if not that.


J.

On the 32-bit machine, if your glew32.dll is used, then it will generate the initialization error that was reported before:

“The application failed to initialize properly (0xc0000142). Click on OK to terminate the application”

If the glew32.dll from SourceForge is used, then it will crash a bit farther down with no error message like the one above. In other words, the initialization is okay with the SourceForge’s glew32.dll.

On my netbook, the glewinfo.exe has the following output below. I guess that means the graphic chips can work only with OpenGL version up to 1.4? If that is true, then the crash probably makes sense if you are using some methods available only in OpenGL 1.5.


GLEW Extension Info

GLEW version 1.6.0
Reporting capabilities of pixelformat 3
Running on a Intel Pineview Platform from Intel
OpenGL version 1.4.0 - Build 8.14.10.2230 is supported
etc etc

Thus spake lancel:

On the 32-bit machine, if your glew32.dll is used, then it will generate
the initialization error that was reported before:

“The application failed to initialize properly (0xc0000142). Click on OK
to terminate the application”

If the glew32.dll from SourceForge is used, then it will crash a bit
farther down with no error message like the one above. In other words,
the initialization is okay with the SourceForge’s glew32.dll.

On my netbook, the glewinfo.exe has the following output below. I guess
that means the graphic chips can work only with OpenGL version up to
1.4? If that is true, then the crash probably makes sense if you are
using some methods available only in OpenGL 1.5.

I did a build which uses the ARB functions in case OpenGL 1.5 isn’t
supported:

vassalengine.org/~uckelman/test-arb.exe

Try this, instead of the orignal text.exe. Does this work where test.exe
doesn’t?


J.

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.[attachment=0]testdump.zip[/attachment]

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.