Roadmap for VASSAL 4

Thus spake Michael Kiefte:

I finished reading the Mozilla documentation on JavaScript, and inheritance
is a nightmare. Since there are not classes, inheritance is based on a
prototype instantiation. The syntax for inheritance is a gigantic kludge and
there appear to be several ways of doing it–none of which are necessarily
intuitive. I have a sudden urge to do everything in assembler. There are a
few other quirks that will make it bug prone – some of which I posted
above. I was against JavaScript before I started investigating it and now
I’m actually much more firm in my opposition. It’s a bad language.

I’m not in favor of it either. Making those demos was an interesting
exercise, but I don’t see that JavaScript is suitable for a large
project. The fact that it’s dynamically, weakly typed will make testing
hard, and the lack of block scoping rules strikes me as error-prone. I
think it would be interesting to have a web-based client, but I think it
shouldn’t be the primary client. Maybe by the time we’re ready to
develop something web-based, browser support will be in a better state
(e.g., WebGL will be available).

I think the next thing I’m going to look into is making the same demo
in Python, using the OpenGL bindings.

–
J.

I thought you hated Python. I’ve never used it but I know it has a lot of fans.

The more I think about it though, the more I like Java. It’s pretty good. Although if we want a better looking UI, we may want to consider SWT instead of Swing.

Java is a good language to attract new developers. And now with Gosling at Google, it may survive the next decade.

• M.

On 2011-03-30, at 7:28 AM, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

I finished reading the Mozilla documentation on JavaScript, and inheritance
is a nightmare. Since there are not classes, inheritance is based on a
prototype instantiation. The syntax for inheritance is a gigantic kludge and
there appear to be several ways of doing it–none of which are necessarily
intuitive. I have a sudden urge to do everything in assembler. There are a
few other quirks that will make it bug prone – some of which I posted
above. I was against JavaScript before I started investigating it and now
I’m actually much more firm in my opposition. It’s a bad language.

I’m not in favor of it either. Making those demos was an interesting
exercise, but I don’t see that JavaScript is suitable for a large
project. The fact that it’s dynamically, weakly typed will make testing
hard, and the lack of block scoping rules strikes me as error-prone. I
think it would be interesting to have a web-based client, but I think it
shouldn’t be the primary client. Maybe by the time we’re ready to
develop something web-based, browser support will be in a better state
(e.g., WebGL will be available).

I think the next thing I’m going to look into is making the same demo
in Python, using the OpenGL bindings.

–
J.

---

messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

Thus spake Michael Kiefte:

I thought you hated Python. I’ve never used it but I know it has a lot of fa
ns.

What I dislike about it is the whitespace rules. Nonetheless, a lot of
people seem to like it, and there are tons of good libraries. So I want
to investigate it to see if it would be appropriate.

The more I think about it though, the more I like Java. It’s pretty good. Al
though if we want a better looking UI, we may want to consider SWT instead of
Swing.

Java is a good language to attract new developers. And now with Gosling at Go
ogle, it may survive the next decade.

The things which worry me the most about Java are:

• Swing bugs
• Image loading bugs
• Jumping through hoops due to heap sizing
• Mac support
• Hard-to-troubleshoot launching problems
• Whether the desktop ecosystem is dying

We could avoid the first one by not using Swing. We could avoid the
second by using some third-party image-loading library, but I haven’t
found a very complete one in the little looking I did. In both cases,
we can’t do much to get the problems fixed—some of the image loading
bugs I’ve encountered are years old. If we were using some library not
part of the JDK, then at least we could patch the thing ourselves and
ship that.

The heap sizing issue is just incredibly annoying, both in terms of
support and the code we have which tries to work around it, and I don’t
see any solution for this on the horizon.

It’s not clear to me what the long-term situation of Java on the Mac is
—we might suddenly find that there is no longer a working JVM there.
Using it also prevents us from having something which could work on iOS.

Because we’re relying on the JVM, we end up with all kinds of weird
launching failure problems on Windows, which wouldn’t happen if VASSAL
were run from its own binary. I’m also not convinced that Google’s
support of Java will help with Java on the desktop—it might mean that
we end up with good Java support on Android phones and tablets, but not
on the desktop.

So, I’m not ruling it out. But it seems saddled with a lot of problems.

–
J.

• Swing bugs

You could substitute those with SWT bugs!

• Image loading bugs

I doubt that would improve with SWT. If anything, SWT is harder to work
with, but it looks nicer.

• Jumping through hoops due to heap sizing

That problem will never go away.

• Mac support

Which is declining apparently.

• Hard-to-troubleshoot launching problems

I haven’t been paying much attention to that.

• Whether the desktop ecosystem is dying

In Java specifically or with desktops in general? Desktops will be around
for quite a long time and there is even some evidence they have gained on
game consoles. But Java may be dying on the desktop.

In other news wxWidgets posted a new release yesterday, so at least they’re
active. Working with wxWidgets is not without some pain, but at least we
can contribute fixes. Qt is still out there, but there’s a lot of news
about whether Nokia will even exist in 5 years given some controversial
decisions they’ve made. Although KDE may save it, KDE will likely not care
about development on new platforms.

wxWidgets doesn’t really have a good record of expanding to new platforms
either. Ironically, what they really need is some corporate sponsorship.

Of course the main advantages of either Qt or wxWidgets is the vast number
of libraries available for C and C++. Oh and I forgot about GTK which is
very hard to use. Has anyone compiled anything with GTK for Windows besides
GIMP?

I’m not sure who to root for.

• M.

Of course the main advantages of either Qt or wxWidgets is the vast number
of libraries available for C and C++. Oh and I forgot about GTK which is
very hard to use. Has anyone compiled anything with GTK for Windows besides
GIMP?

Evidently, someone has:

gtk.org/screenshots.html

Not a lot of diversity. I still have a GTK book lying around somewhere.
Never did anything with it. Lot of hoops to jump through to do OOP in C.

• M.

Presumably the latter. The death of the PC is always over exaggerated

etforecasts.com/products/ES_pcww1203.htm

The sheer size of the PC market indicates otherwise.

Thus spake Michael Kiefte:

• Swing bugs

You could substitute those with SWT bugs!

I can’t imagine the SWT devs being slower to fix things than Sun/Oracle
have been.

• Image loading bugs

I doubt that would improve with SWT. If anything, SWT is harder to work
with, but it looks nicer.

Does SWT use it’s own image loader? I would have thought it would have
used BufferedImages and relied on ImageIO for image loading.

• Whether the desktop ecosystem is dying

In Java specifically or with desktops in general? Desktops will be around
for quite a long time and there is even some evidence they have gained on
game consoles. But Java may be dying on the desktop.

With respect to Java in particular. I don’t expect that the desktop will
go away. I can’t imagine coding on my phone.

Of course the main advantages of either Qt or wxWidgets is the vast number
of libraries available for C and C++. Oh and I forgot about GTK which is
very hard to use. Has anyone compiled anything with GTK for Windows besides
GIMP?

I seem to recall having done that once. I actually kind of like GTK myself.

–
J.

I seem to recall having done that once. I actually kind of like GTK myself.

I thought it was a good idea because I hate C++, but it really is hard to
use. I’m also not keen on function names with 14 underscore characters.
You can use Glade, but VASSAL uses run-time dialog creation (which, in
retrospect, might be hard to do in Qt).

• M

Thus spake Michael Kiefte:

I thought it was a good idea because I hate C++, but it really is hard to
use. I’m also not keen on function names with 14 underscore characters.
You can use Glade, but VASSAL uses run-time dialog creation (which, in
retrospect, might be hard to do in Qt).

I was thinking that we should mandate that all private functions start
with 14 underscores: ______________move(int x, int y).

Seriously, though, the runtime-dialog creation is something we need to
think about. I thought there were systems in C++ which could create
dialogs from text specifications at runtime.

–
J.

You can do that in wxWidgets I believe.

See:
docs.wxwidgets.org/stable/wx_xrc … rcoverview

That’s how the GUI editors for wxWidgets work. Never done it though.

Not sure if there is an equivalent in Qt – I have a lot less experience
with it (like – almost none).

• M.

On 30 March 2011 12:19, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

I thought it was a good idea because I hate C++, but it really is hard to
use. I’m also not keen on function names with 14 underscore characters.
You can use Glade, but VASSAL uses run-time dialog creation (which, in
retrospect, might be hard to do in Qt).

I was thinking that we should mandate that all private functions start
with 14 underscores: ______________move(int x, int y).

Seriously, though, the runtime-dialog creation is something we need to
think about. I thought there were systems in C++ which could create
dialogs from text specifications at runtime.

On Mar 30, 2011, at 5:36 AM, Joel Uckelman wrote:

It’s not clear to me what the long-term situation of Java on the Mac
is
—we might suddenly find that there is no longer a working JVM there.
Using it also prevents us from having something which could work on
iOS.

From what I see (and presumably you as well, since you’re on the
Apple Java developer mailing list) is that Oracle will be taking over
the task of delivering Java VMs for the Mac as well as their current
Windows and Linux/Unix versions. In some ways that is likely to be an
improvement over the current situation where Apple’s release is often
a bit behind the Oracle releases.

Thus spake Thomas Russ:

From what I see (and presumably you as well, since you’re on the
Apple Java developer mailing list) is that Oracle will be taking over
the task of delivering Java VMs for the Mac as well as their current
Windows and Linux/Unix versions. In some ways that is likely to be an
improvement over the current situation where Apple’s release is often
a bit behind the Oracle releases.

It might improve the lag situation. It might mean that nobody is stuck
on Java 1.5 anymore, either, which would be great. I’m not holding my
breath for Oracle to fix the long standing non-Mac-specific bugs that I
was complaining about, though. It might happen that they get fixed in
OpenJDK—I do see a fair bit of activity there—but that’s of no help
to us until everybody on every platform we support can run it.

–
J.

I spent the week before last creating a demo program in Python, to see what is possible there. You can see the result here:

vassalengine.org/~uckelman/pytest.tar.bz2
vassalengine.org/~uckelman/p … indows.zip

To run the non-Windows version, you need Python, pygame, PyOpenGL, and numpy installed. For the Windows version, everything is supposed to be included, but I can’t test it because OpenGL doesn’t work on the Windows XP virtual machine where I built the package. In either case, the way to run the demo is from the command line.

For Windows: threedee.exe map.png

Everywhere else: threedee.py map.png

I was surprised by how little code it took to get this working. It’s only 601 lines, including a bunch of dead code I could remove. Please give this a try, and let me know how it works for you.

On a related note, were we to use Python, how many of us already know it? Are willing to learn it? Similarly, were we to use C++, how many of us already know it? Are willing to learn it?

On 18 April 2011 18:11, uckelman uckelman@nomic.net wrote:

I was surprised by how little code it took to get this working. It’s
only 601 lines, including a bunch of dead code I could remove. Please
give this a try, and let me know how it works for you.

Works for me. I have some questions though. You appear to be using
pygame. Does that limit you in terms of what you can do with OpenGL? For
example, it’s obvious you can do textures (or whatever we’re supposed to
call them now), but can you actually do 3D rendering from pygame? My
impression was that pygame is limited to 2D games.

On a related note, were we to use Python, how many of us already know
it?

Not me.

Are willing to learn it?

Can’t be worse than perl, right?

Similarly, were we to use C++, how many of
us already know it?

I do, unfortunately. Can’t be worse than perl, right?

Are willing to learn it?

As long as we keep it to the subset that is compatible with ANSI C, sure.

• M.

No go here

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of uckelman
Sent: Monday, April 18, 2011 4:12 PM
To: messages@vassalengine.org
Subject: [messages] Edit: [Developers] Re: Roadmap for VASSAL 4

[This message has been edited.]

I spent the week before last creating a demo program in Python, to see

what is possible there. You can see the result here:

vassalengine.org/~uckelman/pytest.tar.bz2[1]

vassalengine.org/~uckelman/p … indows.zip[2]

To run the non-Windows version, you need Python, pygame, PyOpenGL, and

numpy installed. For the Windows version, everything is supposed to be

included, but I can’t test it because OpenGL doesn’t work on the Windows

XP virtual machine where I built the package. In either case, the way to

run the demo is from the command line.

For Windows: threedee.exe map.png

Everywhere else: threedee.py map.png

I was surprised by how little code it took to get this working. It’s

only 601 lines, including a bunch of dead code I could remove. Please

give this a try, and let me know how it works for you.

On a related note, were we to use Python, how many of us already know

it? Are willing to learn it? Similarly, were we to use C++, how many of

us already know it? Are willing to learn it?

[1] vassalengine.org/~uckelman/pytest.tar.bz2

[2] vassalengine.org/~uckelman/p … indows.zip

Read this topic online here:

https://forum.vassalengine.org/t/roadmap-for-vassal-4/3769/44

messages mailing list

messages@vassalengine.org

vassalengine.org/mailman/listinfo/messages

I got an error on my Ubuntu 10.10 VM. I am not sure if the missing soundcard is the cause.

"
there is no soundcard
Traceback (most recent call last):
File “./threedee.py”, line 600, in
main()
File “./threedee.py”, line 361, in main
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
File “/usr/lib/pymodules/python2.6/OpenGL/error.py”, line 208, in glCheckError
baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1280,
description = ‘invalid enumerant’,
baseOperation = glTexParameterf,
cArguments = (
GL_TEXTURE_2D,
GL_TEXTURE_MAX_ANISOTROPY_EXT,
8.0,
)
)
"

Thus spake Michael Kiefte:

I was surprised by how little code it took to get this working. It’s
only 601 lines, including a bunch of dead code I could remove. Please
give this a try, and let me know how it works for you.

Works for me. I have some questions though. You appear to be using
pygame. Does that limit you in terms of what you can do with OpenGL? For
example, it’s obvious you can do textures (or whatever we’re supposed to
call them now), but can you actually do 3D rendering from pygame? My
impression was that pygame is limited to 2D games.

There are two things in the demo which rely on pygame: image loading
and the event queue. We could do image loading with PIL (which is
what pygame uses anyhow) and whatever windowing toolkit we use will
provide an event queue. The only reason I used pygame was that I had
a broken version of GLUT when I started working on the demo. (It’s
since been fixed.

–
J.

Thus spake “Tim McCarron”:

No go here

How did it fail? Was there any error output?

–
J.

Thus spake lancel:

I got an error on my Ubuntu 10.10 VM. I am not sure if the missing
soundcard is the cause.

"
there is no soundcard

No, I doubt that’s the probelm.

Traceback (most recent call last):
File “./threedee.py”, line 600, in
main()
File “./threedee.py”, line 361, in main
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
File “/usr/lib/pymodules/python2.6/OpenGL/error.py”, line 208, in
glCheckError
baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1280,
description = ‘invalid enumerant’,
baseOperation = glTexParameterf,
cArguments = (
GL_TEXTURE_2D,
GL_TEXTURE_MAX_ANISOTROPY_EXT,
8.0,
)
)

It appears that your graphics card doesn’t support anisotropic
filtering. I wasn’t checking for supported OpenGL extensions before
trying to use them. I’ll have to do that.

–
J.

Got the python modules installed. It runs. When I maximized the window:
Fatal Python error: (pygame parachute) Segmentation Fault
Abort trap