MinGW AlphaBlend

[hgm]

Now that I am used to XBoard's nice anti-aliased rendering of SVG pieces, I am getting more and more annoyed by WinBoard's ugly RGB bitmaps. Now it seems that Windows (since Win2k) does support transparancy, and 32 bit/pixel .bmp files with an alpha channel. Strange enough standard Windows programs like MS Paint cannot create this format, though.

But I managed to have XBoard save .bmp files with alpha channel for all its SVG pieces. This seems to have worked, because the images display correctly in Windows in the file-explorer window (with the transparent parts in black, as expected).

I run into an unexpected problem, however. According to MicroSoft documentation I should use the Win API function AlphaBlend() to write the piece images over the chess-board background. But when I added the recommended code to WinBoard,and compilewith gcc under Cygwin, it complains AlphaBlend is an undefined reference. Now I am using a pretty old gcc there, so I also tried it under a recently installed MinGW, but I get the same error. Despite the fact that I added -lmsimg32 to the linker flags. (The MS docs say AlphaBlend should be in the Msimg32.lib.) It knows the library, but AlphaBlend appears not to be in it.

Is MinGW so much behind in development that it does not even support functions that were introduced in Win2k???

[Evert]

Did you try the solution suggested here: http://mingw-notify.narkive.com/SPZ4dXB ... alphablend?
Seems a bit odd to me, but maybe it works?

[hgm]

Hmm, I did not find that one, when I Googled for AlphaBlend + MinGW. But I am not sure what they propose. The problem is that AlphaBlend does not seem to be in the library. Can that be the result of the Windows version being wrong? And which version would count anyway? I am on Windows 8.1, which should certainly be new enough. So is the version that counts the one where the library was created? Should I rebuild the library from source to make it work on my system? I have no MinGW sources, I just loaded a binary package.

I don't understand this library business anyway. A MinGW compile is supposed to use the native Windows run-time system. In this case Msimg32.dll. So what is the function of linking here? I guess that the MinGW version of this library (libmsimg32.a) should only contain wrappers.

[Evert]

I interpreted it as specifying the target version of Windows on which you want the program to run, which you have to define before including MinGW headers.

[hgm]

You are right!

I figured this would somehow default to the version you are compiling on. But apparently not. When I give as extra compiler flag -DWINVER=0x0500 when compiling the .c file to generate the .o, I first got a new error message complaining I did not specify enough arguments to AlphaBlend. (Which was ot really a surprise, because I just put it in the code as a dummy, to see if it was known to gcc. But it means it now sees the relevant part of the #included header that defines AlphaBlend.) When I fixed that, and linked all the .o files, the error message was gone. So it seems I am in business, and can put in some real code.

Thanks!

[hgm]

Wow, it works!



Old bitmaps:



One advantage is that it is totally trivial now to make images for all 2 x 66 piece types at any of the 18 board sizes. I just have to run the XBoard I modified to create the Windows bitmaps. Perhaps I should keep that patch in, under control of an option. Then people could use it to convert any piece theme that is available for XBoard into bitmaps for WinBoard too.

At the moment I use a kludge to decide whether to use AlphaBlend or the old BitBlt to render the pieces: only when the pieceImageDirectory is called "bmaps" it uses AlphaBlend. Also using AlphaBlend does not obey options that would flip the pieces, or forces the use of white images for both sides. (So Shogi players are out of luck.) But even despite all those downsides, it seems a huge improvement.

[Evert]

At the moment I use a kludge to decide whether to use AlphaBlend or the old BitBlt to render the pieces: only when the pieceImageDirectory is called "bmaps" it uses AlphaBlend. Also using AlphaBlend does not obey options that would flip the pieces, or forces the use of white images for both sides. (So Shogi players are out of luck.) But even despite all those downsides, it seems a huge improvement.

Surely those are fixable? Is there any other reason to keep the old method?
Another question: is it necessary to use .bmp files, or can Windows read .png natively?

[Evert]

Glad it works now! I guess a valid question is why in this day and age MinGW still targets Win95/NT4 by default...

[mar]

I would suggest so simply use a RGB DIB (Device independent bitmap) and do the blending manually (lerp), then simply BitBlt changed parts.

I wouldn't worry about performance, in fact my experience (in the past) with graphics-related WinAPI was horrible.

[hgm]

Surely those are fixable? Is there any other reason to keep the old method?

Yes, it will be fixable. But unlike BitBlt, AlphaBlend does not support mirroring (by specifying negative size of the target area). So you would first have to draw a flipped piece in a memory buffer using StretchBlt (hoping it supports bitmaps with alpha channel), and then render that onto the board background with AlphaBlend. So it is a bit cumbersome.

A reason to not use this for the built-in bitmaps (besides Win95 compatibility) could be size. The old bitmaps were 1 bit per pixel, now they are 32 bits per pixel. So the full set of 49x49 bitmaps alone measures already 1.21MB, nearly as big as the entire WinBoard executable is now. And this is a pretty small size; 72x72 would already be twice bigger.

So perhaps I should keep the built-in images as they are, and have the distributed binary package rely on external bitmaps bundled with it. XBoard does rely on exteral images completely, since we swicthed to SVG/PNG images.

Another question: is it necessary to use .bmp files, or can Windows read .png natively?

There seem to be no functions in the WinBoard API that read in a bitmap from a PNG file. But the XBoard pieces are SVG anyway, not PNG.