Create account / Log in

Roadmap for VASSAL 4

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 11th, 2011, 8:58 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby lancel » May 12th, 2011, 10:29 pm

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
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 14th, 2011, 1:45 pm

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:

http://www.vassalengine.org/~uckelman/test-arb.exe

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

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby lancel » May 15th, 2011, 12:19 am

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.
testdump.zip
Dump of test.exe
(162.21 KiB) Downloaded 239 times
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 15th, 2011, 12:34 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby lancel » May 15th, 2011, 5:40 pm

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:

http://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
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: Roadmap for VASSAL 4

Postby lancel » May 15th, 2011, 6:02 pm

BTW, I just found out that glBindBuffer is available only for OpenGL 1.5 or newer:

http://www.opengl.org/sdk/docs/man/xhtm ... Buffer.xml

Perhaps that has something to do with the crash seen in glDrawArrays?

Lance
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 15th, 2011, 6:17 pm

Thus spake lancel:
> BTW, I just found out that glBindBuffer is available only for OpenGL 1.5
> or newer:
>
> http://www.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.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 15th, 2011, 6:40 pm

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:

http://www.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:
>
> http://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.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 12:52 am

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
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 1:01 am

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.

Lance
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 4:45 am

Would it help if I put the source for the demo in a public git repo?


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
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 16th, 2011, 9:08 am

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.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » May 16th, 2011, 9:09 am

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.
User avatar
uckelman
Site Admin
 
Posts: 8836
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 2:05 pm

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
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 3 guests

cron