Create account / Log in

Roadmap for VASSAL 4

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: Roadmap for VASSAL 4

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

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
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, 2:29 pm

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

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

Postby uckelman » May 16th, 2011, 2:34 pm

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

Re: Roadmap for VASSAL 4

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

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
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, 3:12 pm

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

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 3:52 pm

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<void>, F & f, A & a, int)
{
unwrapper<F>::unwrap(f, 0)(a[base_type::a1_], a[base_type::a2_]);
}

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:02 pm

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
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, 4:15 pm

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

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

Postby uckelman » May 16th, 2011, 4:25 pm

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

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 4:38 pm

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.

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
0028ed14 010ff044 00000000 00990a60 0028ee08 ig4icd32+0x2308c
0028ee1c 010fee65 00990a5c 0028efe0 0028ef08 vglew!boost::_bi::bind_t<void,void (__stdcall*)(int,unsigned int const *),boost::_bi::list2<boost::_bi::value<int>,boost::arg<1> > >::operator()<unsigned int *>+0x54 [c:\users\lance1\boost_1_46_1\boost\bind\bind_template.hpp @ 33]
0028ef00 010fb972 0028f0c0 0028f420 00302d30 vglew!boost::detail::sp_counted_impl_pd<unsigned int *,boost::_bi::bind_t<void,void (__stdcall*)(int,unsigned int const *),boost::_bi::list2<boost::_bi::value<int>,boost::arg<1> > > >::dispose+0x35 [c:\users\lance1\boost_1_46_1\boost\smart_ptr\detail\sp_counted_impl.hpp @ 145]
0028efe0 010fb905 0028f1a0 0028f420 00302d30 vglew!boost::detail::sp_counted_base::release+0x42 [c:\users\lance1\boost_1_46_1\boost\smart_ptr\detail\sp_counted_base_w32.hpp @ 102]
0028f0c0 010fb89e 0028f284 0028f420 00302d30 vglew!boost::detail::shared_count::~shared_count+0x35 [c:\users\lance1\boost_1_46_1\boost\smart_ptr\detail\shared_count.hpp @ 221]
0028f1a0 0110d8a7 a7daf225 0028f364 0028f420 vglew!boost::shared_ptr<unsigned int>::~shared_ptr<unsigned int>+0x2e
0028f290 0114c6e8 00000001 0028f420 00302d30 vglew!View::~View+0x57
0028f364 5a63839f a7c52d99 00000001 0028f420 vglew!`dynamic atexit destructor for 'view''+0x28
0028f3b0 5a6380d0 00000000 00000000 00000001 MSVCR100D!amsg_exit+0x29f
0028f3c4 5a638f2a a7c52dd1 00000001 0028f420 MSVCR100D!cexit+0x10
0028f3f8 5a638e01 5a5f0000 00000000 00000001 MSVCR100D!_getmainargs+0x1ba
0028f40c 7701af58 5a5f0000 00000000 00000001 MSVCR100D!_getmainargs+0x91
0028f42c 7702387b 5a638de0 5a5f0000 00000000 ntdll!RtlQueryEnvironmentVariable_U+0x85
0028f4d0 770237ee 004b0e78 00000001 00000000 ntdll!RtlExitUserProcess+0x101
0028f4e4 75ec2b04 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x74
0028f4f8 76ce36dc 00000000 0028f53c 76ce3372 kernel32!ExitProcess+0x15
0028f504 76ce3372 00000000 a7c5008d 76bb910f msvcrt!exit+0x32
0028f53c 76ce36bb 00000000 00000000 00000000 msvcrt!dup+0x2a9
0028f550 5be7ae6d 00000000 00000000 7fffffff msvcrt!exit+0x11
0028f584 5be7af55 00000000 0028fc00 0028fbf4 freeglut!glutMainLoopEvent+0xbd
0028f598 0110816d a7dafcb5 00000000 00000000 freeglut!glutMainLoop+0xc5
0028f5a0 00000000 00000000 7ffd3000 cccccccc vglew!main+0x7ad [c:\users\lance1\vassal4-demo\test.cpp @ 156]
lancel
 
Posts: 93
Joined: August 30th, 2010, 3:47 pm
Location: NY, NY

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 4:47 pm

Here is the screenshot on my netbook.

The netbook is pretty typical of its type. It is an Acer Aspire One 532h series. It is equipped with a built-in Intel GMA 3150 Graphics chip.

Lance
Attachments
blankcounters.jpg
blankcounters.jpg (197.57 KiB) Viewed 4620 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 16th, 2011, 4:59 pm

Thus spake lancel:
> 0028f290 0114c6e8 00000001 0028f420 00302d30 vglew!View::~View+0x57

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.

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

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

Postby uckelman » May 16th, 2011, 5:02 pm

Thus spake lancel:
>
> Here is the screenshot on my netbook.
>
> The netbook is pretty typical of its type. It is an Acer Aspire One
> 532h series. It is equipped with a built-in Intel GMA 3150 Graphics
> chip.
>
> Lance

It looks like you're also missing the top row of map tiles. My guess is
that we're exhausting your video RAM.

How much video RAM does your graphics chipset have?

Can you post a screenshot that shows the whole map? I'd like to see
which tile is the last one that loaded successfully.

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

Re: Roadmap for VASSAL 4

Postby lancel » May 16th, 2011, 5:20 pm

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.
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:38 pm

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
>
> 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);

I believe I've fixed this in the current version.

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

PreviousNext

Return to Developers

Who is online

Users browsing this forum: marktb1961 and 2 guests