Re: gamegrid.el and some games

[Oliver Scholz <alkibiades@gmx.de>]

[I wrote:]
>     This is o.k. for all games that come with Emacs. But it could lead to
>     unexpected results for packages like sokoban.el or for pong if you add
>     the image above: if an Emacs is compiled without support for XPM,
>     there is no PBM as a fall-back.

[Correction: I realize now that I used XBM, not PBM in my patch. The
very reason for this is that the Gimp on my machine supports only XBM
so far. However, this should not make a difference for the
discussion.]

Richard Stallman <rms@gnu.org> writes:  
> That is a problem we should fix.  I see two solutions:
>
> * Use a PBM form of the same image.  How hard is that?  Does it have
> drawbacks?

You mean, if a package provides only XPM we should calculate a PBM/XBM
image from that XPM via manipulation of the data strings? I do not
know yet how to do that. I find the problem excitingly interesting,
though. I will look for the specs of the PBM- or XBM format on the
web. But I do not promise anything. I am still working on my "frames
as workspaces"-idea, which I think is more important. And I am very
slow as a programmer.

It is a pity that Emacs does not provide any means to create and
change an image in the image cache directly. This could make this task
(and some others) much easier.

> * Change gamegrid so that it can check for support for a specific
> bitmap type before deciding to use a bitmap of that type.
[...]

I am not sure. Depending on how it is done it could either introduce
incompatibilities to the former version of gamegrid or it could make
gamegrid's interface even less clear.

Gamegrid checks the "environment" (i.e. display capabilities in the
running Emacs) and uses a number of symbols to distinguish some types
of environments. Then the game can setup it's "sprites" for the
different environments using those symbols. The symbol `glyph' stands
for an environment that is able to display images in general.

With my patch the order of "environments" is as follows:

----------
[Emacs is able to display images: 'glyph]

1. use XPM

2. use XBM

[Emacs is able to display colours: 'color-x, 'color-tty]

3. use colored blocks (= spaces with a different background-colour)

[Nothing of the above: 'mono-x, 'mono-tty, 'emacs-tty]

4. use ascii-characters
----------

Now, ignoring the score- and timer-functions for the sake of the
argument, gamegrid has two different scopes:

a) as a library that allows to place a character or image in
   2D-coordinate system, i.e. on a specified column and row.

b) as a library that provides simple tiles for grid-based games.

As I said, I introduced the distinction between XPM and XBM via
`find-image'. This makes perfectly sense for the games that use
gamegrid for b). This affects the games that come with Emacs, which
use only the most simple tiles: pong.el, snake.el and tetris.el. Those
games "want" only coloured squares, their code does not care if those
squares are XPM or PBM. The keyword in gamegrid for this is
`colorize', meaning: "use the standard glyph and change it to colour
XYZ".

But it introduces the problem in question for games that use gamegrid
mainly as a library to place images in a 2D-coordinate-system: this
affects AFAICS only sokoban.el and maybe some future games, not yet
written.

I guess, instead of applying `find-image' we could introduce new
environment types for Emacsen compiled with and without support for
XPM. Then we could fix pong.el, tetris.el and snake.el to be aware of
that distinction. The keyword would then be 'glyph for an Emacs with
support for XPM (for the sake of compatibility) and 'xbm-glyph or
'simple-glyph or whatever for an Emacs that support nothing but the
image types not relying on external libraries.

about jpeg, png or gif? We could justifiedly say that we want to cater
only to sokoban.el (it is IMHO one of the best games available for
Emacs). But then again, we could leave it as it is: sokoban.el
provides a variable to turn off images in general and the user has to
tweak some variables anyways to make sokoban.el work with GNU Emacs.

Hmm, I will look how difficult it is to translate XPM to XBM/PBM,
though ...

    -- Oliver

-- 
29 Fructidor an 210 de la Révolution
Liberté, Egalité, Fraternité!