Roadmap for VASSAL 4

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?

Actually, I think it does! I seem to recall that some graphics cards have
problems with 24bit alignment. That brings back some recollections.

  • M.

Thus spake Michael Kiefte:

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?

Actually, I think it does! I seem to recall that some graphics cards have
problems with 24bit alignment. That brings back some recollections.

Aha. I will adjust that this evening, then. RGB is how it comes from
libjpeg, at least by default. I’ll see whether it’s possible to get
libjpeg to give us 32-bit aligned output instead. If not, I can just
twiddle the scanlines as they come.


J.

Michael, here’s a diff to apply to load_jpeg.cpp which will modify it (in an ugly way) to load JPEGs to to RGBA instead of RGB format. If you recompile with this, does your “blue” problem go away?

[code]diff --git a/cpp-test/load_jpeg.cpp b/cpp-test/load_jpeg.cpp
index 8f86fb3…49df46b 100644
— a/cpp-test/load_jpeg.cpp
+++ b/cpp-test/load_jpeg.cpp
@@ -6,6 +6,8 @@

#include <jpeglib.h>

+#include <boost/scoped_array.hpp>
+
#include “image.h”

Image load_jpeg(std::string filename) {
@@ -44,13 +46,21 @@ Image load_jpeg(std::string filename) {
const unsigned int w = cinfo.image_width;
const unsigned int h = cinfo.image_height;
const unsigned int bpp = cinfo.num_components;

  • boost::shared_array data(new GLubyte[whbpp]);
  • boost::shared_array data(new GLubyte[wh4]);

  • boost::scoped_array scan(new GLubyte[w*bpp]);

    // Extract each scanline of the image
    JSAMPROW j;
    for (unsigned int i = 0; i < h; ++i) {

  • j = data.get() + ((h-(i+1))wbpp);
  • j = scan.get();
    jpeg_read_scanlines(&cinfo, &j, 1);
  • GLubyte *dst = data.get() + ((h-(i+1))w4);
  • GLubyte *src = scan.get();
  • for (unsigned int x = 0; x < w*bpp; ++x, ++dst) {
  •  *dst = *(src + x);
    
  •  if (x % 3 == 2) ++dst; // skip alpha component in dst
    
  • }
    }

// Finish decompression and release memory
@@ -58,5 +68,5 @@ Image load_jpeg(std::string filename) {
jpeg_destroy_decompress(&cinfo);

fclose(fp);

  • return Image(w, h, bpp, bpp == 1 ? GL_LUMINANCE : GL_RGB, data);
  • return Image(w, h, 4, GL_RGBA, data);
    }[/code]

I’m partway there. The MinGW (cross-compiler) setup in Fedora is neat. I have a handful of errors I need to fix before it will compile for Windows.

Is OpenGL and GLUT open-source? Where can one get the libraries otherwise?

Lance

Please ignore my last post. I should have searched a bit more. :slight_smile:

Lance

Thus spake lancel:

Is OpenGL and GLUT open-source? Where can one get the libraries
otherwise?

Both are open-source.

The GLUT implementation I’m linking against is Freeglut:

freeglut.sourceforge.net/

Freeglut uses the X License.

If you’re compiling on and for Linux, you’ll most likely already
have both OpenGL and GLUT. If you’re compiling on Windows, I’m not
exactly sure where you get the headers you need; I haven’t had
time to look yet. I don’t have access to a Mac, but I suspect that
the Mac situation is similar to Linux.


J.

Got it working on Ubuntu. It looks great. I can zoom in and out without any problem.

Lance

Thus spake lancel:

Got it working on Ubuntu. It looks great. I can zoom in and out
without any problem.

Did you need to make any changes in order to get it working?


J.

I did not make any changes.

Lance

On Thu, May 05, 2011 at 02:53:41AM -0700, Joel Uckelman wrote:

Thus spake lancel:

Got it working on Ubuntu. It looks great. I can zoom in and out
without any problem.

Did you need to make any changes in order to get it working?

I ran the original fine on Ubuntu with no changes needed.

Jeff


“The man who does not read good books has no advantage over
the man who cannot read them.”
– Mark Twain

I tried to use Visual Studio 2010 C++ Express to see how far I can go. I was able to compile all the way but whenever I ran it, I would run into a crash at the following line inside map.cpp:

glDrawArrays(GL_TRIANGLE_FAN, 0, 4);

I got the GLee SDK from opengl.org/sdk/libs/GLee/ and recompiled it with VS2010. I got the Win32 version of freeglut. I even recompiled its source but the outcome was the same. I got the jpeglib versions 8c and 6b but both got me the same error. I am curious to see if you also run into the same error with MinGW.

Lance

Thus spake lancel:

I tried to use Visual Studio 2010 C++ Express to see how far I can go.
I was able to compile all the way but whenever I ran it, I would run
into a crash at the following line inside map.cpp:

glDrawArrays(GL_TRIANGLE_FAN, 0, 4);

Any idea why that would cause a crash? The vertex VBO has 4 vertices in
it, so I don’t think the problem is that we’re overrunning the end of
the VBO.

I got the GLee SDK from opengl.org/sdk/libs/GLee/[2] and
recompiled it with VS2010. I got the Win32 version of freeglut. I even
recompiled its source but the outcome was the same. I got the jpeglib
versions 8c and 6b but both got me the same error. I am curious to see
if you also run into the same error with MinGW.

I haven’t been able to successfully compile with MinGW yet, due to my
MinGW headers not having all the extension definitions that my Linux
ones do. I’m just about to try GLEW (glew.sourceforge.net/) for
handling that, so I’ll let you know how it turns out.


J.

Thus spake Joel Uckelman:

I haven’t been able to successfully compile with MinGW yet, due to my
MinGW headers not having all the extension definitions that my Linux
ones do. I’m just about to try GLEW (glew.sourceforge.net/) for
handling that, so I’ll let you know how it turns out.

Huh. On switching to GLEW, I’m now getting a segfault on the first
glGenBuffersARB() call. No idea why.


J.

Thus spake Joel Uckelman:

Thus spake Joel Uckelman:

I haven’t been able to successfully compile with MinGW yet, due to my
MinGW headers not having all the extension definitions that my Linux
ones do. I’m just about to try GLEW (glew.sourceforge.net/) for
handling that, so I’ll let you know how it turns out.

Huh. On switching to GLEW, I’m now getting a segfault on the first
glGenBuffersARB() call. No idea why.

Aha, got it. I was neglecting to initialize GLEW before the call to
glGenBuffers().


J.

I moved the executables to my gaming desktop (Windows 7 Pro) that has a real graphics card and it worked. I was making the builds on my netbook (Windows 7 Starter), whose graphic card may be the problem. Let me see if I can find out what that is.

Lance

Thus spake lancel:

I moved the executables to my gaming desktop (Windows 7 Pro) that has a
real graphics card and it worked. I was making the builds on my netbook
(Windows 7 Starter), whose graphic card may be the problem. Let me see
if I can find out what that is.

Lance

It would be good to know what’s not working/not supported on what
hardware. What kind of graphics card does your netbook have?

I do all of my development on my laptop, which has an Intel 965GM
chipset. That’s pretty old at this point (I bought it in 2007), and it
was a rather anemic video chipset when it was new. Because of that, my
working assumption is that if it performs adequately on my laptop, it
will perform adequately on anything else still in use.


J.

I have what I think is a working Windows demo now:

vassalengine.org/~uckelman/c … indows.zip

To use, unpack and run ‘test.exe map.jpg’ from a terminal.

This runs for me in Wine, which tends to be a good indicator that it will work in real Windows.

Running from terminal pops up the following message on WinXP64

“The application failed to initialize properly (0xc0000142). Click on OK to
terminate the application”

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of uckelman
Sent: Sunday, May 08, 2011 7:42 AM
To: messages@vassalengine.org
Subject: [messages] [Developers] Re: Roadmap for VASSAL 4

I have what I think is a working Windows demo now:

vassalengine.org/~uckelman/c … indows.zip[1]

To use, unpack and run ‘test.exe map.jpg’ from a terminal.

This runs for me in Wine, which tends to be a good indicator that it
will work in real Windows.

[1] vassalengine.org/~uckelman/c … indows.zip


Read this topic online here:
https://forum.vassalengine.org/t/roadmap-for-vassal-4/3769/83

I got the same error on both of my Windows 7 (netbook and desktop) machines.
My netbook is an Acer Aspire One 532h series machine. It has an integrated Intel Graphics Media Accelerator 3150 video processor. I think this kind of setup is typical of netbook.

Lance