Roadmap for VASSAL 4

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

Forum seems to have eaten my picture of the command prompt window with the error
output :frowning:

Have to get it later


From: Joel Uckelman uckelman@nomic.net
To: messages@vassalengine.org
Sent: Tue, April 19, 2011 3:23:30 AM
Subject: Re: [messages] Edit: [Developers] Re: Roadmap for VASSAL 4

Thus spake “Tim McCarron”:

No go here

How did it fail? Was there any error output?


J.

I do appreciate Python and I do think it’s a great platform, but I think, in the long run, it might be a hassle to support across multiple platforms.

At least in C++, we can potentially port to iPad at some future point. That’s never going to happen with Python.

I’m voting in favour of freeglut or openglut with C++. If I manage to catch up in the next few weeks, I’ll take a look at my old JOGL program and port it to OpenGL + openglut.

  • M.

On 2011-04-19, at 8:03 AM, bdgza bdegroot@gmail.com wrote:

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


Read this topic online here:
Roadmap for VASSAL 4 - #51 by bdgza


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

Thus spake bdgza:

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

That’s new. On what OS?


J.

Thus spake Michael Kiefte:

I do appreciate Python and I do think it’s a great platform, but I think, in
the long run, it might be a hassle to support across multiple platforms.

At least in C++, we can potentially port to iPad at some future point. That’s
never going to happen with Python.

I’m voting in favour of freeglut or openglut with C++. If I manage to catch u
p in the next few weeks, I’ll take a look at my old JOGL program and port it
to OpenGL + openglut.

You don’t need to do that—porting my Python demo to C++ would take
about an hour, in my estimation. I was planning to do it myself next
week.


J.

MacOS X 10.6.5.

Thus spake bdgza:

“uckelman” wrote:

Thus spake bdgza:

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

That’s new. On what OS?


J.

MacOS X 10.6.5.

No idea, then. I don’t have a VM of MacOS to play with, so I can’t
even start troubleshooting.


J.

Here is my error from command line

[attachment=0]cline.png[/attachment]

Hmmm… website seems to be down.

  • M.

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

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 I 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:
Roadmap for VASSAL 4 - #44 by uckelman


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

Thus spake Michael Kiefte:

Hmmm… website seems to be down.

It’s working for me.


J.

I’ve converted the Python demo I made a few weeks ago to C++. I’m posting a link to an archive containing the source code here for anyone who wants to try it or have a look. The dependencies are only OpenGL, GLUT, and libjpeg. I haven’t had time to do a Windows build yet; I intend to try that this evening. I’m assuming that anyone on Linux will be able to compile this with no problems; hopefully this is also the case on Macs.

vassalengine.org/~uckelman/cpp-test.tar.bz2

The good:

  • Fast. The parts which are in software (as opposed to in the graphics hardware) are much, much faster than in Python. This is unsurprising, but nice to see. The only siginificant thing which happens in software in the demos is image loading. The map image I’ve been using for testing is 8149x3514. On my laptop, it takes about 5 seconds to load this image in Python; in C++, libjpeg loads it in under one second.

  • Very low RAM usage. Image data takes up close to 100% of the memory the demo uses. (This is similar to VASSAL.) The test map is about 81MB in memory. However, once we’ve carved it into texture tiles and handed those off to OpenGL, we can free all the memory we allocated to store image data—OpenGL stores textures in video RAM. The demo was using about 7MB RAM for me after image loading was finished; the max was around 150MB (for a few seconds) during tile carving.

  • Little code. The C++ demo is about 1200 lines, which is approximately twice the number that the Python demo has. Half of the extra “code” comes from lines which are blank or have only a curly brace on them (332 lines); the rest comes from the code which gets data from libjpeg and from managing OpenGL handles properly rather than leaking them.

The bad:

  • I’m not seeing any bad, yet, actually.

The ugly:

  • Building for multiple platforms. I can (probably) make Windows builds on Linux using the mingw cross-compiler. I’ve done that once before, for mkhexgrid. I have no idea whether I can cross-compile on Linux for Mac OS. I’d very much like to be able to build for all platforms in once place.

terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_S_construct NULL not valid
Aborted

This is on Ubuntu

That’s not the most helpful exception I’ve ever seen either.

  • M.

On 3 May 2011 07:13, uckelman uckelman@nomic.net wrote:

[This message has been edited.]

I’ve converted the Python demo I made a few weeks ago to C++. I’m
posting a link to an archive containing the source code here for anyone
who wants to try it or have a look. The dependencies are only OpenGL,
GLUT, and libjpeg. I haven’t had time to do a Windows build yet; I
intend to try that this evening. I’m assuming that anyone on Linux will
be able to compile this with no problems; hopefully this is also the
case on Macs.

vassalengine.org/~uckelman/cpp-test.tar.bz2[1]

The good:

  • Fast. The parts which are in software (as opposed to in the graphics
    hardware) are much, much faster than in Python. This is unsurprising,
    but nice to see. The only siginificant thing which happens in software
    in the demos is image loading. The map image I’ve been using for testing
    is 8149x3514. On my laptop, it takes about 5 seconds to load this image
    in Python; in C++, libjpeg loads it in under one second.

  • Very low RAM usage. Image data takes up close to 100% of the memory
    the demo uses. (This is similar to VASSAL.) The test map is about 81MB
    in memory. However, once we’ve carved it into texture tiles and handed
    those off to OpenGL, we can free all the memory we allocated to store
    image data—OpenGL stores textures in video RAM. The demo was using
    about 7MB RAM for me after image loading was finished; the max was
    around 150MB (for a few seconds) during tile carving.

  • Little code. The C++ demo is about 1200 lines, which is approximately
    twice the number that the Python demo has. Half of the extra “code”
    comes from lines which are blank or have only a curly brace on them (332
    lines); the rest comes from the code which gets data from libjpeg and
    from managing OpenGL handles properly rather than leaking them.

The bad:

  • I’m not seeing any bad, yet, actually.

The ugly:

  • Building for multiple platforms. I can (probably) make Windows builds
    on Linux using the mingw cross-compiler. I’ve done that once before, for
    mkhexgrid. I have no idea whether I can cross-compile on Linux for Mac
    OS. I’d very much like to be able to build for all platforms in once
    place.

[1] vassalengine.org/~uckelman/cpp-test.tar.bz2

Thus spake Michael Kiefte:

terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_S_construct NULL not valid
Aborted

This is on Ubuntu

That’s not the most helpful exception I’ve ever seen either.

Are you specifying the map image as an argument when you run it? I
neglected to mention that you need to do that. My guess is that’s
what’s wrong.

If that’s not the problem, would you mind compiling with debugging on,
running it in gdb and giving me a backtrace?


J.

Oops. Yes, it works. However, strangely it shifts to all blue whenever I
pan the map. But when I move a counter it goes back to normal. For some
reason the R and G channels are getting zeroed out. Initially, I thought it
was because my GPU didn’t support the encoding scheme you have, but it’s
switching back and forth. I’ve never seen that before.

  • M.

On 3 May 2011 10:17, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_S_construct NULL not valid
Aborted

This is on Ubuntu

That’s not the most helpful exception I’ve ever seen either.

Are you specifying the map image as an argument when you run it? I
neglected to mention that you need to do that. My guess is that’s
what’s wrong.

If that’s not the problem, would you mind compiling with debugging on,
running it in gdb and giving me a backtrace?


J.


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


Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151

Thus spake Michael Kiefte:

Oops. Yes, it works. However, strangely it shifts to all blue whenever I
pan the map. But when I move a counter it goes back to normal. For some
reason the R and G channels are getting zeroed out. Initially, I thought it
was because my GPU didn’t support the encoding scheme you have, but it’s
switching back and forth. I’ve never seen that before.

That’s strange. The encoding scheme I’m using is GL_RGB (no alpha, because
the source images are JPEGs). I wonder if converting to GL_RGBA would make
any difference?


J.