[messages] [Developers] Re: Roadmap for VASSAL 4
mkiefte at dal.ca
Sun Mar 27 13:11:47 MST 2011
We would never be able to be completely platform neutral as the VASSAL
engine relies on a very wide list of libraries. What you describe would be
very limiting. Although it sounds like a good idea, we would only be able
to support the lowest common denominator with respect to both platform and
browser. That's great for small apps or very restricted ones, but I can see
us hitting brick walls a lot.
We're actually trying to go in the opposite direction with better defensive
programming practises. In addition, we're currently looking at ways to
expand our capabilities not restrict them further (e.g., better graphics/3D
With respect to a C-based language, conversion from Java is relatively
that make a straight translation very tricky.
I think the frontrunners are still the status quo (Java+Swing), Java+SWT,
Qt, or wxWidgets. They all have their problems, but having to rely on a
webbrowser (who might later decide that a feature we're using is actually an
annoyance) would create more problems in terms of support. Right now, we
support Windows, Mac, and Linux directly, but I can't imagine supporting
multiple web browsers and all the problems they introduce.
On 27 March 2011 12:43, generateui <rtimon at gmail.com> wrote:
> wxWidgets suggested by Michael looks like a good cross-platform
>> framework. It looks to me like higher level entry for developers
>> though, so I don't know if the developers could/would make that step.
> First of all, wxWidgets is indeed cross-platform, but: it's still
> __platform dependant__, as currently every UI library is platform
> dependant. Namely: wxWidgets is dependant on the wxWidgets platform.
> This may sound a bit weird, but the current state of UI toolkits is that
> none of the toolkits/libraries implement a set of standardized
> interfaces. Truly platform independance would be achieved by having a
> set of interfaces for widgets/behaviour defined, and then implemented in
> the various libs/toolkits. Example: Say I make a login window. I *HAVE*
> to tie the code in the loginwindow to the UI lib. I cannot define an
> instance of interface Button. Instead, I have to define wxButton, or
> gwtButton, or javafxButton. If I'd be able to define a Code:
> private button Button;
> , i can have the instance of the button be polymorphic.
>> code, so you will get a huge performance hit from that alone. You'd
>> you'd end up with browser dependent display code (DHTML/CSS) which
>> breaks every few months with updates. Despite the hype nothing serious
>> gets written like this. You have web games, but they are either flash
>> and/or very very simple. There is google apps, but although nicely
>> done, they do nothing as complex as VASSAL. HTML5 adds a lot of
>> features, but is far from final and there is inconsistent support for
>> or Silverlight (ZunTzu 2 is planned to use Silverlight), but the step
>> to just making a desktop app with much more flexibility in what you
>> can do is small
> fast code execution. You can say the old IE <8 and FF <3 engines are
> indeed code interpreters, but newer engines lean towards JIT
> compilation, like Java or .NET. Especially for boardgames, performance
> is not really an issue. The above link to OpenSettlers demo uses 1MB of
> loading locally from SSD, loadtime on a single core 1.5Ghz is below 1
> second. That's surely acceptable. And I even have not yet optimized the
> OpenSettlers code yet. There's a huge set of classes which are not
> really necessary, but are compiled by GWT nevertheless because I needed
> only a few classes.
> GWT only supports features which work in all major browsers. That's the
> reason SVG is not yet supported: it's implementation in the different
> browsers is not yet on par for every major browser. On the other hand,
> canvas _is_ supported by the major browsers, and as such supported by
> GWT 2.2.
> As I noted in my previous post, when there is a UI agnostic codebase, it
> doesnt matter if you want to use SWT of GWT of JavaFX or flash or
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the messages