[bug #27630] Black fairy pieces partly transparent

[Sylvain Beucler-4]

URL:
  <http://savannah.gnu.org/bugs/?27630>

                 Summary: Black fairy pieces partly transparent
                 Project: XBoard
            Submitted by: None
            Submitted on: Thu 08 Oct 2009 12:28:24 PM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #1, bug #27630 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #2, bug #27630 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #3, bug #27630 (project xboard):

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??



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #4, bug #27630 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Eric Mullins]

Tim Mann wrote:
> Did I really do that only for xboard and not WinBoard??
>  

It seems you did.  I have often wondered about the difference in piece
representation between the two programs.

I agree with HG on this one-- I prefer the way winboard does it, and
have wanted that in xboard over the years.

Maybe we should consider providing a way at compile time to choose which
way it's built?  I think including an additional directory for the
bitmap differences shouldn't cause much size increase to the source
tarball.  Or maybe it would-- how do we get lzma's soliid archive
feature into the tarball?  Anyway, something to think about.



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Eric Mullins]

anonymous wrote:
> Follow-up Comment #4, bug #27630 (project xboard):
>
> 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.
>  

That's another alternative to providing both bitmap sets.  Again, there
must be an easy way of doing this.  For that matter, it is possible to
perform the conversion at runtime.  I think I know how to do that on
windows anyway.  Doing that might require changes to the source bitmaps
first though.  I'll postpone thinking about the implementation until we
discuss this more.  But I like the idea of selecting at runtime which
representation to use.



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g. muller]

>Maybe we should consider providing a way at compile time to choose which
>way it's built?  I think including an additional directory for the bitmap
>differences shouldn't cause much size increase to the source tarball.  Or
>maybe it would-- how do we get lzma's soliid archive feature into the
>tarball?  Anyway, something to think about.

The XBoard pixmaps are in fact totally ridiculous. Each pixmap comes in two
practically identical copies. That is, the picture is exactly the same, but
it just assigns a different color to the . character (which indicats the
backgrund in all cases). This could have been trivially done at run time.
In fact the same character strings describing the four colors now occur in
every pixmap. Perhaps the compiler is smart enough to collapse all those
copies of the same string to one in initialized read-only data, but perhaps
it is not.

It would be much more efficient to initialize the color indications with
NULL in all the pixmap source files, and put the pointer to the actual
strings there only before converting them to internal format (i.e before
feeding them to XpmCreatePixmapFromData). That would make the dl & ll
pixmaps truly identical to the dd and ld pixmaps, reducing the number of
pixmaps by 2. If this system is used, the black pixmaps can be included as
3-color pixmaps, using a different character for the square color and the
details, but under control of a transparancy option, the color for the
details could be set to the square color in stead of the white-piece color.


_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #5, bug #27630 (project xboard):

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).


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #6, bug #27630 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #7, bug #27630 (project xboard):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Update of bug #27630 (project xboard):

                  Status:                    None => Ready For Test        

    _______________________________________________________

Follow-up Comment #8:

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #9, bug #27630 (project xboard):


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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #10, bug #27630 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #11, bug #27630 (project xboard):

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).


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Sylvain Beucler-4]

Follow-up Comment #12, bug #27630 (project xboard):

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)
    _______________________________________________________

Additional Item Attachment:

File name: bmps.tgz                       Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27630>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard