I got the same problem too. So I tried to build it on my Windows machine to see if I can do some debugging. I am still in the process of building the Boost libraries. Previous demo builds did not need these strange boost lib files. For bjam, what are the parameters used to build the Boost libraries used to make the demo binaries here?
Lance
Thus spake lancel:
I got the same problem too. So I tried to build it on my Windows
machine to see if I can do some debugging. I am still in the process of
building the Boost libraries. Previous demo builds did not need these
strange boost lib files. For bjam, what are the parameters used to
build the Boost libraries used to make the demo binaries here?
I couldn’t say. I didn’t build boost_system and boost_filesystem myself.
There should be some instructions here:
boost.org/doc/libs/1_46_1/mo … ndows.html
–
J.
It looks to me that when test.exe tries to process this line in test.cpp for map.jpg:
const Image mimg(loader.load(in));
It will call JPEGLoader::recognized in jpegloader.cpp and for some reason, the “in” pointer is not pointing to position 0. If I add a line like in.seekg(0) before the in.read statement, then the sig array will be correctly filled with the same elements as JPEG_MAGIC. However, even I get past this point, I will run into another error in JPEGLoader::load when it tries to process jpeg_read_header. This call will cause jpeglib to end it all with an error message as follows:
Invalid JPEG file structure: two SOI markers
I then compared the code between this and the last version. I noticed that in this version, there is a new jpeg_istream_src call. I think may something is not being implemented in the right way in this new method and that causes jpeglig’s routine to mistake the same map.jpg file as having two SOI markers. Not sure if what I am seeing at this point is correct and some artifact introduced when I added the in.seekg(0) line above.
Lance
With regards to platform direction, I’m thinking that mobile gaming is the future. Clearly, many of the bigger game companies are betting this way.
Being a browser based solution would be a great first step as it would give Vassal a way to migrate their fanatical user base from PC’s to the platform of the future as people are increasingly replacing their lap tops with smart phones and tablets like the iPad. Mobile gaming on an iPad or tablet would make huge sense for gamers as they would be able to play their games any time from any place from any device and is something that other competitors do not do. If Vassal where to make the jump to a browser based system I think they would ensure their relevance for years to come.
Are there any browser based games available in iPad?
I think we have already rejected JavaScript.
I think you’re right that we need a more portable solution but even Apple rejected browser apps for the iPhone years ago.
On 2011-07-02, at 12:01 PM, jeb123 fjt_us@yahoo.com wrote:
With regards to platform direction, I’m thinking that mobile gaming is
the future. Clearly, many of the bigger game companies are betting this
way.Being a browser based solution would be a great first step as it would
give Vassal a way to migrate their fanatical user base from PC’s to the
platform of the future as people are increasingly replacing their lap
tops with smart phones and tablets like the iPad. Mobile gaming on an
iPad or tablet would make huge sense for gamers as they would be able to
play their games any time from any place from any device and is
something that other competitors do not do. If Vassal where to make
the jump to a browser based system I think they would ensure their
relevance for years to come.
Read this topic online here:
Roadmap for VASSAL 4 - #189 by ftarzanin
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
The next version of Warplanner seems to be designed to run within a browser on even an iPad or Android. My guess is that since the current version of Warplanner is coded in C#, the next version is probably done in C# ASP.NET. A dedicated server may be needed to run this, I suppose. Since Vassal supports many more games, I wonder what kind of server is needed for such a design.
Lance
Interesting. Shame there isn’t a demo.
On 2011-07-06, at 1:49 PM, lancel lanceleu@mindspring.com wrote:
The next version of Warplanner seems to be designed to run within a
browser on even an iPad or Android. My guess is that since the current
version of Warplanner is coded in C#, the next version is probably done
in C# ASP.NET. A dedicated server may be needed to run this, I suppose.
Since Vassal supports many more games, I wonder what kind of server is
needed for such a design.Lance
Read this topic online here:
Roadmap for VASSAL 4 - #191 by lancel
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
Let me see if I can play with some ASP.NET stuffs here a bit for a demo. I know only some C#. It sounds like an interesting side-project to pick up something.
Lance
Probably jumping the gun too soon. It is purely my guess that it is being done in ASP.NET on the basis of their current release. Perhaps their next version is done in a totally new architecture. Until it comes out, no one knows. I will keep the ASP.NET in mind anyway to see how feasible it is to run a game like that. Perhaps the next version of Warplanner will be out by then and we will all find out.
Lance
On further thoughts, I don’t remember this topic ever mentions anything about converting Vassal modules into Java applets and / or running the converted Java applets along with Javascript. Wouldn’t it be more cost-efficient to convert them into applets if it is feasible?
Lance
Java doesn’t really have anything to do with Javascript. It would be just
as easy to convert Java in C++.
If memory serves me correctly, the original Warplanner was done in Visual
Basic. Did they do a complete reimplementation?
On 6 July 2011 15:42, lancel lanceleu@mindspring.com wrote:
On further thoughts, I don’t remember this topic ever mentions anything
about converting Vassal modules into Java applets and / or running the
converted Java applets along with Javascript. Wouldn’t it be more
cost-efficient to convert them into applets if it is feasible?Lance
_____________**
Read this topic online here:
vassalengine.org/**forum/vie … 0#**p23660<Roadmap for VASSAL 4 - #195 by lancel_____________**
messages mailing list
messages@vassalengine.org
vassalengine.org/**mailman/listinfo/messageshttp://www.vassalengine.org/mailman/listinfo/messages
The original Warplanner was done in VB? I have no idea. I just so happened to look up for Empire of the Rising Sun module, which Vassal still does not have and came upon this Warplanner. I was a bit surprised that it was written in C#.
About Java applet, if it is converted from the current Java app, wouldn’t it run inside a browser too? Has the Vassal Engine ever been converted to run as a Java applet?
Lance
It wouldn’t help you running it on an iPad. iPad doesn’t support Java at
all whether it’s an applet or not.
On 6 July 2011 21:22, lancel lanceleu@mindspring.com wrote:
The original Warplanner was done in VB? I have no idea. I just so
happened to look up for Empire of the Rising Sun module, which Vassal
still does not have and came upon this Warplanner. I was a bit
surprised that it was written in C#.About Java applet, if it is converted from the current Java app,
wouldn’t it run inside a browser too? Has the Vassal Engine ever been
converted to run as a Java applet?Lance
Thus spake lancel:
About Java applet, if it is converted from the current Java app,
wouldn’t it run inside a browser too? Has the Vassal Engine ever been
converted to run as a Java applet?
It would not be easy to convert VASSAL 3 to be a Java applet, and maybe
not even possible, because:
It needs access to your disk. It might be possible to give an
applet the privileges is needs for that, but I suspect it would involve
signing the applet and so on, which would make it impossible to use
with custom classes.
You will run into problems with the heap size. I don’t know what the
maximum heap is for Java applets, but I’ll bet it’s less than what’s
needed for most modules, and won’t be adjustable from inside the applet.
Lastly, if you can run Java applets, it means you have Java, so you
could run the regular application.
–
J.
Thus spake lancel:
On further thoughts, I don’t remember this topic ever mentions anything
about converting Vassal modules into Java applets and / or running the
converted Java applets along with Javascript. Wouldn’t it be more
cost-efficient to convert them into applets if it is feasible?
The similarity between Java and JavaScript is that the former is a
substring of latter. As languages, they’re entirely distinct—Java is
strongly, statically typed and has class-based inheritance, while JS is
dynamicly, weakly typed, has first-class functions and closures, and
uses prototype-based inheritance. It’s unfortunate that JS is known by
the name that it is.
Any conversion from Java to JavaScript is going to be nontrivial (and
in the wrong direction, in my opinion, as complex codebases are harder
to maintain in dynamic, weakly typed languages).
It’s not clear to me how applets can interact with JS, as JS acts on the
DOM, as from that point of view, an applet is just an opaque XML element.
So, you’d have that problem (which there might be some solution for, I
don’t know) in addition to the other problems I mentioned with running
as an applet.
–
J.
Javascript can call up fields in a Java applet. I have seen that done. I just browsed the Javascript Bible and saw some simple examples there too. I was not aware though that iPad does not support Java at all until it was brought up yesterday. (I don’t have an iPad myself.)
Lance
Sorry to bump in in the middle without a clue, but are you really planning to rewrite the (core) vassal in c++?! If so, please do count me in.
Yes, I have ridiculous schedule and a pile of kids to look after but this is something I have been looking after for so long. Or even if you are just planning to rework the current engine so that it could run on Android system… count me in on that too! 
MVC model is a good for responsibility separation and doing at least the Model part in C++ might be a viable solution. Adding a scripting language support such as Python or Lua should not be a big issue and with JNI Java/Android interface should not be a problem either. IPad etc. on the other hand might be an issue: I really don’t know how Objective-C and C++ plays out, but I have heard rumors that it should be OK.
–
Rami
Thus spake rami:
Sorry to bump in in the middle without a clue, but are you really
planning to rewrite the (core) vassal in c++?!
Yes.
If so, please do count me in.
We’d like the help. We need to do a bit of design work before diving
in; criticizsm of the proposed design would be helpful at the moment.
MVC model is a good for responsibility separation and doing at least the
Model part in C++ might be a viable solution.
I already have C++ demo of the GUI View. It doesn’t handle much yet, but
it can draw pieces and a map and handles user interaction.
–
J.
I have been reading this thread with great interest. I can see you that you have decided to develop Vassal 4.0 in C++.
All though I love Java, I fully understand why you want to make the move to a C++ implementation, and I’m very happy to see that you are so focused on making a cross-platform implementation.
You have been looking at different libraries, such as wkWidget and boost. I would suggest that you take a look at Qt. Qt has a large range of advantages compared to most other GUI libraries. I’ll list some of them here:
You can find the Qt homepage here: http://qt.nokia.com/products/
Instructional videos can be found here: http://developer.qt.nokia.com/elearning
If you want a quick overview of Qt, here is a good introductional video: http://developer.qt.nokia.com/elearning/watch/qt_programming_essentials_by_ics_part_1
I haven’t been programming in C++ for the last 10 years (mainly Java), but I would like to contribute to the Vassal 4.0 project, if possible (Vassal is somehow very dear to my heart 
, me being a passionate board gamer ). I will need to brush up on my C++ though
Anyhow, I think it is worth giving Qt a look. I think it would be a perfect fit for a new Vassal 4.0 C++ engine.
QT was already brought up earlier although I can’t say why it is no longer mentioned anymore…