Create account / Log in

Roadmap for VASSAL 4

Discussion area for the development team.

Moderators: Tim M, uckelman

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

Postby uckelman » May 16th, 2011, 9:41 pm

Thus spake Joel Uckelman:
> 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.
>

I've uploaded a new Windows build:

http://www.vassalengine.org/~uckelman/v ... indows.zip

It includes the missing glew32mx.dll; this might mean that this build
will work with my MinGW build of GLEW.

Also, it should resolve the problem with crashing on close.

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

Re: Roadmap for VASSAL 4

Postby uckelman » May 16th, 2011, 10:11 pm

lancel wrote: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.


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.

blankcounters.jpg
Lance's netbook screenshot
blankcounters.jpg (45.48 KiB) Viewed 4152 times


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

Re: Roadmap for VASSAL 4

Postby lancel » May 17th, 2011, 4:23 am

I've uploaded a new Windows build:

http://www.vassalengine.org/~uckelman/v ... indows.zip

It includes the missing glew32mx.dll; this might mean that this build
will work with my MinGW build of GLEW.

Also, it should resolve the problem with crashing on close.


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."

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

Re: Roadmap for VASSAL 4

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

I think I sort of know why this latest also failed on my 32-bit. The dll files included in the package are built for 64-bit machines.

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 20th, 2011, 8:47 pm

Thus spake lancel:
> I think I sort of know why this latest also failed on my 32-bit. The
> dll files included in the package are built for 64-bit machines.
>

Are you *sure*? I thought that all of the DLLs were 32-bit, as there's
no 64-bit MinGW compiler in Fedora 14. (There will be both 32- and 64-
bit in Fedora 15.)

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

Re: Roadmap for VASSAL 4

Postby lancel » May 21st, 2011, 4:12 am

Hmm... maybe not then.

Taken from your package, the file size of the glew32.dll is 387kb and glew32mx.dll is 178kb. When I downloaded the latest glew from SourceForge, their respective sizes are 316kb and 224 kb. Anyway, I can't really test it since I don't have the libstdc++-6.dll any more and the old links to your previous packages do not work.

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 21st, 2011, 9:48 am

Thus spake lancel:
> Hmm... maybe not then.
>
> Taken from your package, the file size of the glew32.dll is 387kb and
> glew32mx.dll is 178kb. When I downloaded the latest glew from
> SourceForge, their respective sizes are 316kb and 224 kb. Anyway, I
> can't really test it since I don't have the libstdc++-6.dll any more
> and the old links to your previous packages do not work.

I'm not surprised that DLLs built by different compilers have different
sizes.

Here's an archive with the DLLs:

http://www.vassalengine.org/~uckelman/lib-windows.zip

I'm traveling now, so I've been delayed in getting the NPOT texture bug
fixed and all of the code into a repository.

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

Re: Roadmap for VASSAL 4

Postby lancel » May 22nd, 2011, 4:53 pm

The package you submitted on 5/16 can run on my XP 32-bit after I put in your libstdc++-6.dll but the same setup still cannot run on my W7 64-bit. (Note that I did not need to replace the glew32.dll and glew32mx.dll on my XP 32-bit to get it to run.) I don't have my netbook right now as my wife took it for her trip. My current suspicion is that the libstdc++-6.dll or some other dll may have compatibility issue with W7.

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

Re: Roadmap for VASSAL 4

Postby Brent Easton » May 23rd, 2011, 6:38 am

Hi Joel,

Have spent today catching up on forum news and have read this thread with interest, though it seems to have been sidetracked into implementation language issues rather than the larger design issues.

Various ides follow.
Regards,
Brent

Essentially you are proposing to write a Vassal MkII from the ground up, incorporating all of the hard lessons we have have learned along the way. Modules are not going to be compatible, but presumably we could write some sort of importer that may be able to convert a Vassal MkI module to a Vassal Mk II module. I presume Vassal MkI would be 'mothballed' and left as is for people to keep using if they wished.

One of the best things about Java was that it came along just in time so that I did not have to learn C++ :) However, I would be interested in picking up C++ and taking part in a well organised project to write a new Vassal. C++ has a number of advantages.

Just going over some of your issues you noted in your first post:

- Peer-to-peer communication between clients.
Yes, definitely. Rodney started moving in this direction by writing a Vassal Jabber module that would allow Vassal to run on any Jabber Server. I was doing a lot of work on trying to get this working before my break. Building server capabilities into the clients would be a much better solution.

- Moving to XML.
We have discussed this before and it is still my strong belief that the impenetrable nature of the build file has saved endless problems for us. Manipulating the build file through the Vassal interface ensures that it is edited correctly and remains consistent. If you allow free-for-all editing of the build file, you will get endless errors edited in that will be difficult to debug. I am not against a move to full XML, but it must include an industrial strength verifier that can detect any errors introduced by hand editing, or generation by non-vASSAL tools. The Vassal definition languange is still going to be immensely complex.

- Model-view separation.
Sure, needed without doubt.

- Hooks for change-listening scripts.
I understand your proposals here and this sort of facility should definitely be included. This is really the key to the success of the project, a fundamental redesign of how Vassal will provide the services we are after for Game Pieces.

The current trait system is built on the Java Decorator pattern and was developed by Rodney very early on as a demonstration of how to use Decorator. That was many, many years ago and the drawbacks of this system only really became apparent recently as the complexity of modules increased. This was greatly exacerbated by all of the new traits I wrote to extend functionality and add 'programmability' while staying constrained to to the Decorator model.

------------------------
This particular thread has become a bit sidetracked on the issue of language. While important, it is really a side-issue. The big issues/questions that I see (not necessarily in order of importance) are:

1. Cross-platofrm.
We want to keep supporting as many platforms as we do know.

2. Implementation language and libraries.
Very much related to 1.

3. Clean code.
Start clean, keep it that way. Extensive Unit tests, built from the start.

4. Client/Server/Networking model.
Who 'owns' the game. How do you find an existing game and connect to it. What happens if the current 'server' goes down.

5. Easy to create simple modules.
As Joel said, it should be very easy as to create a simple module. Wizards?

6. Game Piece Implementation.
How to implement the myriad behaviour we have now in something that is easier to use and understand? How do we add additional functionality? Scripting is necessary. Which scripting language? I did a lot of work on Beanshell which makes sense in a Java environment, but less so in another environment.
User avatar
Brent Easton
 
Posts: 2758
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

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

Postby uckelman » May 24th, 2011, 8:39 pm

Thus spake swampwallaby:
> Hi Joel,

Hi! Welcome back!

> Essentially you are proposing to write a Vassal MkII from the ground up,
> incorporating all of the hard lessons we have have learned along the
> way. Modules are not going to be compatible, but presumably we could
> write some sort of importer that may be able to convert a Vassal MkI
> module to a Vassal Mk II module. I presume Vassal MkI would be
> 'mothballed' and left as is for people to keep using if they wished.

That's the idea, yes.

> One of the best things about Java was that it came along just in time so
> that I did not have to learn C++ :) However, I would be interested in
> picking up C++ and taking part in a well organised project to write a
> new Vassal. C++ has a number of advantages.

C++ has an undeserved bad reputation, which it got largely from people
who didn't know better misuing it. (One might say that same thing happend
with Java on the desktop...) I'm using C++ myself daily now; I'm happy
to teach.

> - Moving to XML.
> We have discussed this before and it is still my strong belief that the
> impenetrable nature of the build file has saved endless problems for us.
> Manipulating the build file through the Vassal interface ensures that it
> is edited correctly and remains consistent. If you allow free-for-all
> editing of the build file, you will get endless errors edited in that
> will be difficult to debug. I am not against a move to full XML, but it
> must include an industrial strength verifier that can detect any errors
> introduced by hand editing, or generation by non-vASSAL tools. The
> Vassal definition languange is still going to be immensely complex.

It should be possible to use XSD for validating XML. There are numerous
validating parsers out there. The thing about XML which is more
"semantic" than our buildFiles is that it won't be so easy to get wrong
in the first place.

I should also direct you here, to a long-running discussion at BGG about
an overlapping topic:

http://www.boardgamegeek.com/thread/637 ... nts/page/1

> - Hooks for change-listening scripts.
> I understand your proposals here and this sort of facility should
> definitely be included. This is really the key to the success of the
> project, a fundamental redesign of how Vassal will provide the services
> we are after for Game Pieces.

This is the point where some conceptual work is needed. I don't yet have
a clear picture of what hooks in to the "core" are necessary to make this
part work well.

> This particular thread has become a bit sidetracked on the issue of
> language. While important, it is really a side-issue. The big
> issues/questions that I see (not necessarily in order of importance)
> are:
>
> 1. Cross-platofrm.
> We want to keep supporting as many platforms as we do know.
>
> 2. Implementation language and libraries.
> Very much related to 1.
>
> 3. Clean code.
> Start clean, keep it that way. Extensive Unit tests, built from the
> start.

I think we're all agreed on these, at least as goals.

> 4. Client/Server/Networking model.
> Who 'owns' the game. How do you find an existing game and connect to
> it. What happens if the current 'server' goes down.

This one is going to require some planning regarding how we'd like it to
work. Fortunately, it's mostly separate from other concerns.

> 5. Easy to create simple modules.
> As Joel said, it should be very easy as to create a simple module.
> Wizards?
>
> 6. Game Piece Implementation.
> How to implement the myriad behaviour we have now in something that
> is easier to use and understand? How do we add additional functionality?
> Scripting is necessary. Which scripting language? I did a lot of work on
> Beanshell which makes sense in a Java environment, but less so in
> another environment.
>

I was thinking of providing hooks into the "core", which can call and be
called from Python scripts.

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

Re: Roadmap for VASSAL 4

Postby Brent Easton » May 25th, 2011, 2:30 am

Hi Joel,

I'm going to split some specific discussion off to other threads.

One thing, I have not been able to run your test program on my 32bit Vista. I get 'The application fails to initialize properly (0xc0000142). It also fails on my XP system, a window briefly appears, then dissapears, no message.

B.
User avatar
Brent Easton
 
Posts: 2758
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Roadmap for VASSAL 4

Postby Brent Easton » May 25th, 2011, 5:11 am

I think something we really need to do is to set some specific goals that the new project will aim for. We need to look at what is it that VASSAL does well? What is it that VASSAL does badly? Then set some specific goals that we want to achieve. At each stage of the technical development, we can then refer back to those goals and make sure we are meeting them, or re-work the goals.

Some of the goals may be big and wishy-washy (User friendly, modern interface etc.), but most should be fairly specific. For example, I am concerned that we solve the security issues with hidden information right from the start. I'll start some new threads to discuss this and build up a new section in the Wiki to summarise this.
User avatar
Brent Easton
 
Posts: 2758
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

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

Postby uckelman » May 25th, 2011, 7:51 pm

Thus spake swampwallaby:
> Hi Joel,
>
> I'm going to split some specific discussion off to other threads.
>
> One thing, I have not been able to run your test program on my 32bit
> Vista. I get 'The application fails to initialize properly
> (0xc0000142). It also fails on my XP system, a window briefly appears,
> then dissapears, no message.
>

This is the same problem that everyone has had. I'm back from Heidelberg
now, so I should be able to devote some time to getting the remaining
demo issues fixed this week.

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

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

Postby uckelman » May 29th, 2011, 8:09 pm

Thus spake lancel:
> The package you submitted on 5/16 can run on my XP 32-bit after I put in
> your libstdc++-6.dll but the same setup still cannot run on my W7
> 64-bit. (Note that I did not need to replace the glew32.dll and
> glew32mx.dll on my XP 32-bit to get it to run.) I don't have my netbook
> right now as my wife took it for her trip. My current suspicion is that
> the libstdc++-6.dll or some other dll may have compatibility issue with
> W7.
>
> Lance
>

I've uploaded some new files here:

http://www.vassalengine.org/~uckelman/v4-demo/

The "images" archives contain the images (which I can't check in to a
repository at SF). The two archive are the same, use the one you prefer.

There is an archive containing a binary compiled for 64-bit Linux, one
compiled for 32-bit Windows, and two source archives (again, with the
same contents).

I haven't had time yet to fix the NPOT texture bug, so you'll still
see that. I believe I have all of the DLLs included with the Windows
build this time. Do these builds run for everyone?

Also, can anyone build on a Mac?

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

Re: Roadmap for VASSAL 4

Postby lancel » May 30th, 2011, 5:02 am

I did a quick test on my Ubuntu 64-bit but when executing test, I got an error "cannot execute binary file". On the Windows 7 64-bit, it is the same "the application was unable to start correctly..." I think you have all the dlls this time but somehow I think one or some of the dlls are not compatible with W7 and/or Vista.
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 2 guests