bugXBoard - Bugs: bug #27630, Black fairy pieces partly...

 
 

bug #27630: Black fairy pieces partly transparent

Submitter:  None
Submitted:  Thu 08 Oct 2009 12:28:24 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 17 Oct 2009 10:43:34 PM UTC, comment #12: 

I manually removed all leakings and stray pixels I could find, and attached them (hope that works). I did it with gimp/linux in the bmp files, so you can use them too, if you want. I could only test the resulting pixmaps after conversion, but they are ok.


(file #18894)

Anonymous
Sat 17 Oct 2009 09:43:46 PM UTC, comment #11: 

Historical note: For the orthodox pieces, the xboard bitmap pieces are the originals.  They were generated using MetaFont from a chess font that was designed in MetaFont format, then hand-tuned to some extent (especially the smaller sizes).  The WinBoard pieces were made using a batch conversion process (using the ImageMagick command-line tools, iirc).

Tim Mann <mann>
Group administrator
Sat 17 Oct 2009 06:49:39 PM UTC, comment #10: 

The unsigned-char bug in pixmaps/convert.c will be fixed. The md?33.xpm bitmap was defective because the WinBoard original winboard/bitmaps/m33s.bmp was accidentally saved as a 16M-color bitmap in stead of a monochrome bitmap. This should already be fixed in git now.

Like you say, there will be a similar bug in bitmaps/convert.c. This, however, is a utility that should be considered obsolete anyway. It is very cumbersome to use, as it did not do batch conversion, but hd to be called bitmap for bitmap. In fact these convert.c utilities were never meant for distribution; they were one-time efforts, serving only to obtain Linux-format bitmaps and pixmaps for the fairy pieces that WinBoard already had bitmaps for. There are no 129x129 fairy bitmaps, and if bitmaps for orthodox pieces were obtained by the conversion this should be considered a mistake; the orthodox XBoard bitmaps should simply be taken from earlier distributions of XBoard.

Similarly pixmaps/w??54.xbm and winboard/bitmaps/w54?.bmp are present in git only by mistake. There is no complete set of 54x54 fairy pieces, and w is one of the less important pieces anyway. These files should simply be deleted from git, they are not included in any XBoard or WinBoard build even when they are present.

H.G. Muller

Anonymous
Sat 17 Oct 2009 11:05:15 AM UTC, comment #9: 


Another problem in convert appears on systems (like mine) where "char" defaults to "signed char".
Pieces of size 129 aren't handled by Load() because "char h,w;"
are negative in that case and the for loops are skipped.

"unsigned char h,w;" should work on all systems.

A similar bug seems to be responsible for the contents of e.g. bitmaps/q129s.bm:
#define q129s_width -127
#define q129s_height -127
static unsigned char q129s_bits[] = {

};

Apart from some leakages and stray pixels (e.g. cvld54.xpm) the bitmap "m33s.bm" and the original (before running convert) pixmaps "md?33.xpm" show just a single line. w??54.xpm also is defect.

Anonymous
Sat 17 Oct 2009 02:17:12 AM UTC, comment #8: 

updated convert.c with version from HGM. Also uploaded new pixmaps. Does this fix this issue?

Arun Persaud <apersaud>
Group administrator
Thu 15 Oct 2009 03:18:28 PM UTC, comment #7: 

The new convert program segfaults. Reason is in main():
char *name    doesn't allocate space for the string so sprintf(name,...) dies.

char name[80] works better.

So currently not all pixmaps are correct.

Anonymous
Tue 13 Oct 2009 09:38:18 AM UTC, comment #6: 

As this is a matter of taste I expected it to be a hotly debated issue. Which is why I copied the originl XBoard pixmaps back over those converted from the WinBoard bitmaps.

I have enhanced the pixmaps/convert.c utility in the source distribution such now that it can do conversion of the WinBoard bitmaps to both transparent and opaque pixmaps, under control of a flag argument -t (for transparent). Problem is that the "opaque" pixmaps are obtained by flood-filling the outside from the 4 corners, and that some of the pieces (especially the orthodox pieces, and some unorthodox pieces that have stolen the Knight symbol as part of their design) are leaky, so that some of their details become transparent as well.

So we could remove the pixmaps from the source distribution and include their generation from WinBoard bitmaps as part of the build process, if we build transparent pixmaps. Generation of opaque pixmaps is not of acceptble quality without manual interference.

The most viable alternative seems to include only a set of 3-color pixmap templates, to be used for both light and dark squares, and derive the actual light- and dark-squared pixmaps from it at run time. Deciding on the actual color names only at run time then also allows the choice between opaque (details = white) and transparent (details = square color) black pieces under control of a command-line option.

H.G. Muller

Anonymous
Tue 13 Oct 2009 09:16:24 AM UTC, comment #5: 

As an xboard user I vote for "ugly and primitive". But I already have my private version of the pixmap dir (with the steamrollered bishop as an archbishop and opaque details added manually for the 2 pieces I need).

Anonymous
Mon 12 Oct 2009 05:10:50 PM UTC, comment #4: 

It seems you did. Being raised with WinBoard I am of course highly biased to pefer the transparant pieces. To me the white details look ugly and primitive.

I guess a flood-fill should be easy to program. I am pretty sure there are no leaks in the fairy pieces, I drew the by hand, pixel by pixel. So it is just a matter of programming a floodfill in the conversion program, and as we do not care about efficiecy, that should be quite trivial.

Perhaps in the future we should distribute the source with WinBoard bitmap files only, and decide with an option on the conversion program if the user wants to make transparent or opaque pixmaps for the black XBoard pieces.

H.G. Muller

Anonymous
Mon 12 Oct 2009 04:31:35 PM UTC, comment #3: 

Can we make the fairy pixmap pieces opaque too?  IIRC, the standard pieces are opaque because there were a lot of requests for that.  I think I went through with a bitmap editor and did the appropriate flood-filling by hand, cleaning up by hand in the few cases where there was a "leak".  My memory is pretty fuzzy on this, though.

Did I really do that only for xboard and not WinBoard??


Tim Mann <mann>
Group administrator
Mon 12 Oct 2009 07:23:56 AM UTC, comment #2: 

I still would like opinions on this:

Should we distribute 4.4.1 with all black pieces transparant?

A compromise would be to make all pieces transparent only in the sizes for which built-in fairy pieces are provided (i.e. petite, middling and bulky), and leave opaque details for the other sizes. This is not entirely satisfactory, as some fairy pieces (Archbishop, Chancelor, Amazon) are supported in all sizes from petite to bulky, so the mixture of styles would continue to exist there.

H.G. Muller

Anonymous
Thu 08 Oct 2009 04:38:18 PM UTC, comment #1: 

Indeed, the unorthodox pieces are converted from the WinBoard bitmaps, by the convert.c program that is in the pixmaps directory of the source distribution. WinBoard has transparant black pieces. That program converts all bitmaps, including the orthodox pieces, which would make all black pieces consistently transparant. That would be a change from the XBoard tradition, though, where the black pixmap always had white details. So I copied the original pixmaps back after running convert.c.

Personally I like the transparent piece better, and it would be quite easy to make everything tranparent. Filling in the details of the unorthodox pieces with white would require a smarter conversion program, one that floodfills the outside of the pieces from the 4 corners.

H.G.Muller

Anonymous
Thu 08 Oct 2009 12:28:24 PM UTC, original submission:  

The new fairy pieces for black (pixmap) are partly transparent,
where the standard pieces have "opaque internal details".
This looks a bit strange.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #18894:  bmps.tgz added by None (2KiB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by apersaud (Posted a comment)
  • -email is unavailable- added by mann (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-02-09 apersaud StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2009-10-17 None Attached File- Added bmps.tgz, #18894
    2009-10-17 apersaud StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code