gamegrid.el and some games

gamegrid.el and some games

[Francesco Potorti`]

I am resending here, hoping to find a bigger audience, a message I had
sent (by error) to emacs-pretest-bug.

1) why
   (featurep 'xpm) => nil
   even though in config.h I have #define HAVE_XPM 1 ?  Is this a bug?
   Or maybe it is a Xemacs thing?


2) there is a bug, I think, in gamegrid.el:

   (defun gamegrid-setup-face (face color)
-->  (set-face-foreground face color)
-->  (set-face-background face color)
     (gamegrid-set-font face)
     (condition-case nil
	 (set-face-background-pixmap face [nothing]);; XEmacs
       ('error nil))
     (condition-case nil
	 (set-face-background-pixmap face nil);; Emacs
       ('error nil)))

   As you can see, foreground and background are set to the same colour,
   thus preventing the possibility of anything different from a coloured
   space.  Is this intentional or a bug?  What I would have done is to
   have a function with a third optional argument for the case when one
   wants something different from a square.  For example, both in
   pong.el and tetris.el, the "dot" should naturally be an asterisk.

   However, this may be intentional, that is, if gamegrid.el is
   willingly trying to deal only with squares on a board (not
   considering other characters if not necessary because of display
   incapability).  Maybe I should directly ask the author, Glynn
   Clements, if no one here cares about gamegrid.

Re: gamegrid.el and some games

[Francesco Potorti`]

What follows is a request for explanation, and it may highlight a
shortcoming of the emacs lisp manual.  Sorry if sometimes my wording is
not correct, I am new to this area of Emacs lisp.

I am trying to understand whether Emacs can use an arbitrary image in a
display table on a window system.  That is, if it is possible to write a
graphical image (a glyph) in a given position of a display table.

I found this in the manual:

| Glyphs
| ------
| 
|    A "glyph" is a generalization of a character; it stands for an image
| that takes up a single character position on the screen.  Glyphs are
| represented in Lisp as integers, just as characters are.
| 
|    The meaning of each integer, as a glyph, is defined by the glyph
| table, which is the value of the variable `glyph-table'.
| 
|  - Variable: glyph-table
|      The value of this variable is the current glyph table.  It should
|      be a vector; the Gth element defines glyph code G.  If the value
|      is `nil' instead of a vector, then all glyphs are simple (see
|      below).  The glyph table is not used on windowed displays.

What is a `windowed display'?  I know about `character terminal' and
`window system', and in fact this wording is used below, but I do not
know what a windowed display is.  

I suspect it is a window system, and if this is true, it means that the
answer to my initial question is NO.

| 
|    Here are the possible types of elements in the glyph table:
| 
| STRING
|      Send the characters in STRING to the terminal to output this
|      glyph.  This alternative is available on character terminals, but
|      not under a window system.

Okay.  So this is for character terminals.  So I suppose that the two
following alternatives do work on window systems, because nothing is
specified there.

| 
| INTEGER
|      Define this glyph code as an alias for glyph code INTEGER.  You
|      can use an alias to specify a face code for the glyph; see below.
| 
| `nil'
|      This glyph is simple.  The glyph code mod 524288 is the character
|      to output, and the glyph code divided by 524288 specifies the face
|      number (*note Face Functions::) to use while outputting it.
|      (524288 is 2**19.)  *Note Faces::.
| 
|    If a glyph code is greater than or equal to the length of the glyph
| table, that code is automatically simple.
| 
|  - Function: create-glyph string
|      This function returns a newly-allocated glyph code which is set up
|      to display by sending STRING to the terminal.

So here I am not yet sure whether it is possible to specify a graphical
glyph inside a display table, and if yes, how to do it.

Re: gamegrid.el and some games

[Richard Stallman]

    |      The value of this variable is the current glyph table.  It should
    |      be a vector; the Gth element defines glyph code G.  If the value
    |      is `nil' instead of a vector, then all glyphs are simple (see
    |      below).  The glyph table is not used on windowed displays.

    What is a `windowed display'?  I know about `character terminal' and
    `window system', and in fact this wording is used below, but I do not
    know what a windowed display is.  

Looking at the code, I think it means anything but a character-only
terminal.  The glyph table is used only on character-only terminals.

    | INTEGER
    |      Define this glyph code as an alias for glyph code INTEGER.  You
    |      can use an alias to specify a face code for the glyph; see below.
    | 

This works on all terminals, since you can put this kind of glyph code
into the display table.

I rewrote the node as follows.  Is this clearer?


@node Glyphs
@subsection Glyphs

@cindex glyph
  A @dfn{glyph} is a generalization of a character; it stands for an
image that takes up a single character position on the screen.  Glyphs
are represented in Lisp as integers, just as characters are.  Normally
Emacs finds glyphs in the display table (@pxref{Display Tables}).

  A glyph can be @dfn{simple} or it can be defined by the @dfn{glyph
table}.  A simple glyph is just a way of specifying a character and a
face to output it in.  The glyph code for a simple glyph, mod 524288,
is the character to output, and the glyph code divided by 524288
specifies the face number (@pxref{Face Functions}) to use while
outputting it.  (524288 is
@ifnottex
2**19.)
@end ifnottex
@tex
$2^{19}$.)
@end tex
@xref{Faces}.

  On character terminals, you can set up a @dfn{glyph table} to define
the meaning of glyph codes.  The glyph codes is the value of the
variable @code{glyph-table}.

@defvar glyph-table
The value of this variable is the current glyph table.  It should be a
vector; the @var{g}th element defines glyph code @var{g}.  

If a glyph code is greater than or equal to the length of the glyph
table, that code is automatically simple.  If the value of
@code{glyph-table} is @code{nil} instead of a vector, then all glyphs
are simple.  The glyph table is not used on graphical displays, only
on character terminals.  On graphical displays, all glyphs are simple.
@end defvar

  Here are the possible types of elements in the glyph table:

@table @asis
@item @var{string}
Send the characters in @var{string} to the terminal to output
this glyph.  This alternative is available on character terminals,
but not under a window system.

@item @var{integer}
Define this glyph code as an alias for glyph code @var{integer}.  You
can use an alias to specify a face code for the glyph and use a small
number as its code.

@item @code{nil}
This glyph is simple.
@end table

@defun create-glyph string
@tindex create-glyph
This function returns a newly-allocated glyph code which is set up to
display by sending @var{string} to the terminal.
@end defun

Re: gamegrid.el and some games

[Oliver Scholz]

Francesco Potorti` <pot@gnu.org> writes:

> I am resending here, hoping to find a bigger audience, a message I had
> sent (by error) to emacs-pretest-bug.
>
> 1) why
>    (featurep 'xpm) => nil
>    even though in config.h I have #define HAVE_XPM 1 ?  Is this a bug?
>    Or maybe it is a Xemacs thing?

It is an XEmacs thing. To test for XPM in Emacs you can use. 

(image-type-available-p 'xpm)

I don't know if it is depreciated to use this function, though. It is
not even mentioned in the Elisp Reference of Emacs 21.2.

I have send a patch some time ago, which enables XPM (and PBM) for
gamegrid. (BTW what happend to this patch?) It uses `display-images-p'
and `find-image' to get the appropriate graphics.

[...]
>    As you can see, foreground and background are set to the same
>    colour, thus preventing the possibility of anything different
>    from a coloured space.  Is this intentional or a bug?  What I
>    would have done is to have a function with a third optional
>    argument for the case when one wants something different from a
>    square.  For example, both in pong.el and tetris.el, the "dot"
>    should naturally be an asterisk.
[...]

I guess gamegrid is mainly supposed to provide simple grids,
i.e. colored squares. The option to use characters is -- I guess --
intended only as a fallback on ttys without color. OTOH: it allows to
utilize arbitrary XPM images ... A simple optional third argument
won't do AFAICS, because gamegrid is supposed to work through the
definition of a spec list for all cases.

You can get a non-colored asterisk for pong by changing the specs for
the ball like this:

(setq pong-ball-options
  '(((glyph colorize)
     (t ?\*))
    ((color-x emacs-tty)
     ;;       ^^^^^^^^                                                                            
     (mono-x grid-x)
     (color-tty emacs-tty))
    ;;          ^^^^^^^^^                                                                         
    (((glyph color-x) [1 0 0])
     (color-tty pong-ball-color))))

    -- Oliver

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

Re: gamegrid.el and some games

[Francesco Potorti`]

   >    (featurep 'xpm) => nil
   It is an XEmacs thing. To test for XPM in Emacs you can use. 
   (image-type-available-p 'xpm)

Ok, thank you.
   
   I don't know if it is depreciated to use this function, though. It is
   not even mentioned in the Elisp Reference of Emacs 21.2.

Probably the manual should be improved.
   
   I have send a patch some time ago, which enables XPM (and PBM) for
   gamegrid. (BTW what happend to this patch?) 

Would you send it to me?  I was just trying to do that.
   
   I guess gamegrid is mainly supposed to provide simple grids,
   i.e. colored squares. 

Yes, after some study I arrived to the same conclusion, so I further
reduced my patch to pong.el, tetris.el, snake.el before installing it.

                         The option to use characters is -- I guess --
   intended only as a fallback on ttys without color. OTOH: it allows to
   utilize arbitrary XPM images 

Yes, for example pong could use a real ball.  But that comes after
changing gamegrid.el to work with glyphs in Emacs.

Re: gamegrid.el and some games

[Oliver Scholz]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

Francesco Potorti` <pot@gnu.org> writes:

[...]
>    I have send a patch some time ago, which enables XPM (and PBM) for
>    gamegrid. (BTW what happend to this patch?) 
>
> Would you send it to me?  

O.K. Attached. The diff is against the version of gamegrid.el that
comes with Emacs 21.2. AFAICS there are some changes in the current
CVS. Could this cause problems? I am not familiar with diff & patch.

> I was just trying to do that.

*hehehe* I was quicker.
    
>    I guess gamegrid is mainly supposed to provide simple grids,
>    i.e. colored squares. 
>
> Yes, after some study I arrived to the same conclusion, so I further
> reduced my patch to pong.el, tetris.el, snake.el before installing it.
>
>                          The option to use characters is -- I guess --
>    intended only as a fallback on ttys without color. OTOH: it allows to
>    utilize arbitrary XPM images 
>
> Yes, for example pong could use a real ball.

Oh, that's easy:

(defvar pong-ball-glyph
"/* XPM */
static char * ball_xpm[] = {
\"16 16 4 1\",
\" 	c Black\",
\"+	c Red4\",
\"-	c Red1\",
\".	c Red\",
\"     ------     \",
\"   ----------   \",
\"  ----....--++  \",
\" ---........+++ \",
\" --..........++ \",
\"---..........+++\",
\"--............++\",
\"--............++\",
\"--............++\",
\"--............++\",
\"---..........+++\",
\" --..........++ \",
\" ---........+++ \",
\"  -+++....++++  \",
\"   ++++++++++   \",
\"     ++++++     \"};")

(defvar pong-ball-options
  `(((glyph [xpm :data ,pong-ball-glyph])
     (t ?\*))
    ((color-x color-x)
     (mono-x grid-x)
     (color-tty color-tty))
    (((glyph color-x) [1 0 0])
     (color-tty pong-ball-color))))

This reveals, however, a problem with my patch:

As I said, I use `display-images-p' and then `find-image' to get
either XPM or PBM; the latter AFAIU is supposed to be always available
if `display-images-p' returns t.

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.

    -- Oliver


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gamegrid.diff --]
[-- Type: text/x-patch, Size: 7394 bytes --]

--- /usr/local/share/emacs/21.2/lisp/play/gamegrid.el	Tue May  7 23:18:49 2002
+++ gamegrid.el	Mon Jul 22 00:46:33 2002
@@ -42,6 +42,10 @@
 (defvar gamegrid-font "-*-courier-medium-r-*-*-*-140-100-75-*-*-iso8859-*"
   "Name of the font used in X mode.")
 
+(defvar gamegrid-face nil
+  "Indicates the face to use as a default.")
+(make-variable-buffer-local 'gamegrid-face)
+
 (defvar gamegrid-display-options nil)
 
 (defvar gamegrid-buffer-width 0)
@@ -115,6 +119,16 @@
 "
   "XPM format image used for each square")
 
+(defvar gamegrid-xbm "\
+/* gamegrid XBM */
+#define gamegrid_width 16
+#define gamegrid_height 16
+static unsigned char gamegrid_bits[] = {
+   0xff, 0xff, 0xff, 0x7f, 0xff, 0x3f, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a,
+   0x57, 0x15, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a,
+   0x57, 0x15, 0x07, 0x00, 0x03, 0x00, 0x01, 0x00 };"
+  "XBM format image used for each square.")
+
 ;; ;;;;;;;;;;;;;;;; miscellaneous functions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
 (defsubst gamegrid-characterp (arg)
@@ -145,7 +159,7 @@
   (if gamegrid-font
       (condition-case nil
 	  (set-face-font face gamegrid-font)
-	('error nil))))
+	(error nil))))
 
 (defun gamegrid-setup-face (face color)
   (set-face-foreground face color)
@@ -153,23 +167,23 @@
   (gamegrid-set-font face)
   (condition-case nil
       (set-face-background-pixmap face [nothing]);; XEmacs
-    ('error nil))
+    (error nil))
   (condition-case nil
       (set-face-background-pixmap face nil);; Emacs
-    ('error nil)))
+    (error nil)))
 
 (defun gamegrid-make-mono-tty-face ()
   (let ((face (make-face 'gamegrid-mono-tty-face)))
     (condition-case nil
 	(set-face-property face 'reverse t)
-      ('error nil))
+      (error nil))
     face))
 
 (defun gamegrid-make-color-tty-face (color)
-  (let* ((color-str (symbol-value color))
-	 (name (intern (format "gamegrid-color-tty-face-%s" color-str)))
+  (let* (;(color-str (symbol-value color))
+	 (name (intern (format "gamegrid-color-tty-face-%s" color)))
 	 (face (make-face name)))
-    (gamegrid-setup-face face color-str)
+    (gamegrid-setup-face face color)
     face))
 
 (defun gamegrid-make-grid-x-face ()
@@ -215,13 +229,16 @@
        gamegrid-mono-tty-face))))
 
 (defun gamegrid-colorize-glyph (color)
-  (make-glyph
-   (vector
-    'xpm
-    :data gamegrid-xpm
-    :color-symbols (list (cons "col1" (gamegrid-color color 0.6))
-			 (cons "col2" (gamegrid-color color 0.8))
-			 (cons "col3" (gamegrid-color color 1.0))))))
+  (find-image `((:type xpm :data ,gamegrid-xpm
+		       :ascent center
+		       :color-symbols 
+		       (("col1" . ,(gamegrid-color color 0.6))
+			("col2" . ,(gamegrid-color color 0.8))
+			("col3" . ,(gamegrid-color color 1.0))))
+		(:type xbm :data ,gamegrid-xbm
+		       :ascent center
+		       :foreground ,(gamegrid-color color 1.0)
+		       :background ,(gamegrid-color color 0.5)))))
 
 (defun gamegrid-match-spec (spec)
   (let ((locale (car spec))
@@ -245,38 +262,35 @@
 	   (vector data))
 	  ((eq data 'colorize)
 	   (gamegrid-colorize-glyph color))
+	  ((listp data)
+	   (find-image data)) ;untested!
 	  ((vectorp data)
-	   (make-glyph data)))))
+	   (gamegrid-make-image-from-vector data)))))
 
-(defun gamegrid-color-display-p ()
-  (if (fboundp 'device-class)
-      (eq (device-class (selected-device)) 'color)
-    (eq (cdr-safe (assq 'display-type (frame-parameters))) 'color)))
+(defun gamegrid-make-image-from-vector (vect)
+  "Convert an XEmacs style \"glyph\" to an image-spec."
+  (let ((l (list 'image :type)))
+    (dotimes (n (length vect))
+      (setf l (nconc l (list (aref vect n)))))
+    (nconc l (list :ascent 'center))))
 
 (defun gamegrid-display-type ()
-  (let ((window-system-p 
-	 (or (and (fboundp 'console-on-window-system-p)
-		  (console-on-window-system-p))
-	     (and (fboundp 'display-color-p)
-		  (display-color-p))
-	     window-system)))
   (cond ((and gamegrid-use-glyphs
-		window-system-p
-	      (featurep 'xpm))
+	      (display-images-p))
 	 'glyph)
 	((and gamegrid-use-color
-		window-system-p
-	      (gamegrid-color-display-p))
+	      (display-graphic-p)
+	      (display-color-p))
 	 'color-x)
-	  (window-system-p
+	((display-graphic-p)
 	 'mono-x)
 	((and gamegrid-use-color
-	      (gamegrid-color-display-p))
+	      (display-color-p))
 	 'color-tty)
-	((fboundp 'set-face-property)
+	((display-multi-font-p) ;???
 	 'mono-tty)
 	(t
-	   'emacs-tty))))
+	   'emacs-tty)))
 
 (defun gamegrid-set-display-table ()
   (if (fboundp 'specifierp)
@@ -287,26 +301,21 @@
 			     'remove-locale)
     (setq buffer-display-table gamegrid-display-table)))
 
-(defun gamegrid-hide-cursor ()
-  (if (fboundp 'specifierp)
-      (set-specifier text-cursor-visible-p nil (current-buffer))))
-
 (defun gamegrid-setup-default-font ()
-  (cond ((eq gamegrid-display-mode 'glyph)
-	 (let* ((font-spec (face-property 'default 'font))
-		(name (font-name font-spec))
-		(max-height nil))
-	   (loop for c from 0 to 255 do
-	     (let ((glyph (aref gamegrid-display-table c)))
-	       (cond ((glyphp glyph)
-		      (let ((height (glyph-height glyph)))
-			(if (or (null max-height)
-				(< max-height height))
-			    (setq max-height height)))))))
-	   (if max-height
-	       (while (and (> (font-height font-spec) max-height)
-			   (setq name (x-find-smaller-font name)))
-		 (add-spec-to-specifier font-spec name (current-buffer))))))))
+  (setq gamegrid-face
+	(copy-face 'default
+		   (intern (concat "gamegrid-face-" (buffer-name)))))
+  (when (eq gamegrid-display-mode 'glyph)
+    (let ((max-height nil))
+      (loop for c from 0 to 255 do
+	    (let ((glyph (aref gamegrid-display-table c)))
+	      (when (and (listp glyph) (eq (car  glyph) 'image))
+		(let ((height (cdr (image-size glyph))))
+		  (if (or (null max-height)
+			  (< max-height height))
+		      (setq max-height height))))))
+      (when (and max-height (< max-height 1))
+	(set-face-attribute gamegrid-face nil :height max-height)))))
 
 (defun gamegrid-initialize-display ()
   (setq gamegrid-display-mode (gamegrid-display-type))
@@ -320,11 +329,13 @@
       (aset gamegrid-display-table c glyph)))
   (gamegrid-setup-default-font)
   (gamegrid-set-display-table)
-  (gamegrid-hide-cursor))
+  (setq cursor-type nil))
 
 
 (defun gamegrid-set-face (c)
-  (unless (eq gamegrid-display-mode 'glyph)
+  (if (eq gamegrid-display-mode 'glyph)
+      (add-text-properties (1- (point)) (point)
+			   (list 'display (list (aref gamegrid-display-table c))))
     (put-text-property (1- (point))
 		       (point)
 		       'face
@@ -351,14 +362,18 @@
 (defun gamegrid-init-buffer (width height blank)
   (setq gamegrid-buffer-width width
 	gamegrid-buffer-height height)
-  (let ((line (concat
-	       (make-string width blank)
-	       "\n"))
+  (let ((line (concat (make-string width blank) "\n"))
 	(buffer-read-only nil))
     (erase-buffer)
     (setq gamegrid-buffer-start (point))
     (dotimes (i height)
-      (insert-string line))
+      (insert line))
+    ;; Adjust the height of the default face to the height of the
+    ;; images. Unlike XEmacs, Emacs doesn't allow to make the default
+    ;; face buffer-local; so we do this with an overlay.
+    (when (eq gamegrid-display-mode 'glyph)
+      (overlay-put (make-overlay (point-min) (point-max))
+		   'face gamegrid-face))
     (goto-char (point-min))))
 
 (defun gamegrid-init (options)

[-- Attachment #3: Type: text/plain, Size: 72 bytes --]


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

Re: gamegrid.el and some games

[Alex Schroeder]

Oliver Scholz <alkibiades@gmx.de> writes:

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

Why does XEmacs have sokoban and Emacs does not?  But I think we
already went through this the last time we talked about gamegrid.
I think I am having a déja-lu experience...  :/

Alex.
-- 
I will be in Istanbul next week.

Re: gamegrid.el and some games

[Richard Stallman]

    Why does XEmacs have sokoban and Emacs does not?  But I think we
    already went through this the last time we talked about gamegrid.

I don't remember, but it might relate to the question of the copyright
on the game patterns.  I think someone told me he had written them himself,
which ought to have made it possible, but maybe that wasn't all of them.

Re: gamegrid.el and some games

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

>     Why does XEmacs have sokoban and Emacs does not?  But I think we
>     already went through this the last time we talked about gamegrid.
>
> I don't remember, but it might relate to the question of the copyright
> on the game patterns.  I think someone told me he had written them himself,
> which ought to have made it possible, but maybe that wasn't all of them.

FYI: according to the comments in sokoban.el, the FSF already holds
the copyright for the Lisp:

,----
| ;; Modified: 1998-06-23, copyright assigned to FSF
`----

But the level files and the images are from another program:

,----
| ;; The game is based upon XSokoban, by
| ;; Michael Bischoff <mbi@mo.math.nat.tu-bs.de>
| 
| ;; The levels and some of the pixmaps were
| ;; taken directly from XSokoban
`----

If sokoban.el were part of GNU Emacs we could replace the penguin
through a gnu ... :-¬

    -- Oliver

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

Re: gamegrid.el and some games

[Luke A. Olbrish]

Oliver Scholz writes:
> 
> If sokoban.el were part of GNU Emacs we could replace the penguin
> through a gnu ... :-¬

I didn't like the icons that came with sokoban.el so I made my own
based on a GPLed icon from this site:

http://jimmac.musichall.cz/i.php3?ikony=16

(defconst sokoban-player-xpm "\
/* XPM */
static char * tux_xpm[] = {
\"32 32 18 1\",
\"      c None\",
\".     c #000000\",
\"+     c #666666\",
\"@     c #C6C6C6\",
\"#     c #FFFFFF\",
\"$     c #FFDC00\",
\"%     c #D8B400\",
\"&     c #FFEB84\",
\"*     c #AF6800\",
\"=     c #FFF1C1\",
\"-     c #FFF1B5\",
\";     c #E9D677\",
\">     c #D8AA00\",
\",     c #D9AB00\",
\"'     c #2D0000\",
\")     c #1C0000\",
\"!     c #AF8A00\",
\"~     c #A99500\",
\"             #######            \",
\"            #.......#           \",
\"           #.....+@+.#          \",
\"          #.......@@..#         \",
\"         #.............#        \",
\"         #..@@+..@@....#        \",
\"         #.+##@+@##@...#        \",
\"         #.#@.++@.+#...#        \",
\"         #.#@.$$$.+#...#        \",
\"         #.+%&$$$$&.....#       \",
\"         #.*&=-$$$$%*...#       \",
\"         #..%$&$$%**....#       \",
\"         #..;>,***%'....#       \",
\"         #..#;%%%$#+....#       \",
\"        #..#########+....#      \",
\"       #..+##########+....#     \",
\"      #...###########@.....#    \",
\"     #...#############.....#    \",
\"    #...+#############+....#    \",
\"    #...@#############@....#    \",
\"    #...###############....#    \",
\"    #....##############@..#     \",
\"    #......+#########......#    \",
\"   #.+$%.....#######)...%$+.#   \",
\"  #..$$$%....#######...%$$$..#  \",
\" #.$$$$$$%..########..%$$$$$$.# \",
\" #.$$$$$$$!.#######+.!$$$$$$$.# \",
\"  #.$$$$$$!.++@##@+..!$$$$$$.#  \",
\" #.$$$$$$!!..........!!$$$$$$.# \",
\" #.~!!!!!!............!!!!!!~.# \",
\"  #........###....###........#  \",
\"   ########   ####   ########   \"
};
")

-- 
Luke Olbrish
<luke.olbrish@cc.gatech.edu>

Re: gamegrid.el and some games

[Richard Stallman]

    I didn't like the icons that came with sokoban.el so I made my own
    based on a GPLed icon from this site:

Thanks, but we would not want to have a penguin icon in GNU Emacs.  It
is quite a problem for us that many people think the GNU system is
"Linux", and we are making considerable efforts to correct the error.
We would not want to do anything in Emacs that would suggest
it is a "LInux program".

See http://www.gnu.org/gnu/linux-and-gnu.html for more
explanation.

Re: gamegrid.el and some games

[Richard Stallman]

Your patch is large enough we need legal papers to use it.  I will
tell you more in another message.  We also need change log entries in
order to install it.  Could you write those?

    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.

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?

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

What do you think?

Re: gamegrid.el and some games

[Oliver Scholz]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

Richard Stallman <rms@gnu.org> writes:

> Your patch is large enough we need legal papers to use it.

I think this is already done. I sent papers for past and future
changes to Emacs some time ago and already got a confirmation from the
FSF's office.

> I will tell you more in another message.  We also need change log
> entries in order to install it.  Could you write those?

Is this o.K?

	* gamegrid.el (gamegrid-face): new variable to emulate a
	buffer-local default face.
	(gamegrid-xbm): new variable; XBM image as a replacement for
	`gamegrid-xpm' on Emacsen compiled without XPM-support.
	(gamegrid-make-color-tty-face): Accept a string (= the colour) as
	well as a symbol (= a variable holding the colour-string) as
	argument.
	(gamegrid-colorize-glyph): Replace XEmacs-code for the generation
	of images through Emacs-code.
	(gamegrid-match-spec): Call `gamegrid-make-image-from-vector' to
	convert XEmacs-type image descriptors.
	(gamegrid-color-display-p): Removed. (Use `display-colors-p'
	instead.)
	(gamegrid-make-image-from-vector): New function. Convert XEmacs'
	image descriptors.
	(gamegrid-display-type): Use Emacs' standard `display-.*-p'
	functions to check for display capabilities. Fix the recognition
	of image-support in Emacs 21 by this way.
	(gamegrid-hide-cursor): Removed.
	(gamegrid-setup-default-font): Ported the code from XEmacs to
	Emacs: create a new face and assign the variable `gamegrid-face'
	to it. Make sure that the face is not higher than the smallest
	image used by the game.
	(gamegrid-initialize-display): Use `(setq cursor-type nil)'
	instead of `gamegrid-hide-cursor'.
	(gamegrid-set-face): If `gamegrid-display-mode' is 'glyph, put an
	image in the buffer, instead of applying a face. [This is because
	Emacs display-tables are not as capable as the display-tables in
	XEmacs. Maybe this function should be renamed to reflect the
	change?]
	(gamegrid-init-buffer): Use `insert' instead of
	`insert-string'. If `gamegrid-display-mode' is 'glyph, put the
	face held by `gamegrid-face' in an overlay over the whole buffer
	to emulate a buffer-local default-face.


I attached the latest version of my patch.

    -- Oliver


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gamegrid.diff --]
[-- Type: text/x-patch, Size: 7268 bytes --]

--- /usr/local/share/emacs/21.2/lisp/play/gamegrid.el	Tue May  7 23:18:49 2002
+++ gamegrid.el	Mon Sep 16 13:14:22 2002
@@ -42,6 +42,10 @@
 (defvar gamegrid-font "-*-courier-medium-r-*-*-*-140-100-75-*-*-iso8859-*"
   "Name of the font used in X mode.")
 
+(defvar gamegrid-face nil
+  "Indicates the face to use as a default.")
+(make-variable-buffer-local 'gamegrid-face)
+
 (defvar gamegrid-display-options nil)
 
 (defvar gamegrid-buffer-width 0)
@@ -115,6 +119,16 @@
 "
   "XPM format image used for each square")
 
+(defvar gamegrid-xbm "\
+/* gamegrid XBM */
+#define gamegrid_width 16
+#define gamegrid_height 16
+static unsigned char gamegrid_bits[] = {
+   0xff, 0xff, 0xff, 0x7f, 0xff, 0x3f, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a,
+   0x57, 0x15, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a,
+   0x57, 0x15, 0x07, 0x00, 0x03, 0x00, 0x01, 0x00 };"
+  "XBM format image used for each square.")
+
 ;; ;;;;;;;;;;;;;;;; miscellaneous functions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
 (defsubst gamegrid-characterp (arg)
@@ -145,7 +159,7 @@
   (if gamegrid-font
       (condition-case nil
 	  (set-face-font face gamegrid-font)
-	('error nil))))
+	(error nil))))
 
 (defun gamegrid-setup-face (face color)
   (set-face-foreground face color)
@@ -153,20 +167,20 @@
   (gamegrid-set-font face)
   (condition-case nil
       (set-face-background-pixmap face [nothing]);; XEmacs
-    ('error nil))
+    (error nil))
   (condition-case nil
       (set-face-background-pixmap face nil);; Emacs
-    ('error nil)))
+    (error nil)))
 
 (defun gamegrid-make-mono-tty-face ()
   (let ((face (make-face 'gamegrid-mono-tty-face)))
     (condition-case nil
 	(set-face-property face 'reverse t)
-      ('error nil))
+      (error nil))
     face))
 
 (defun gamegrid-make-color-tty-face (color)
-  (let* ((color-str (symbol-value color))
+  (let* ((color-str (if (stringp color) color (symbol-value color)))
 	 (name (intern (format "gamegrid-color-tty-face-%s" color-str)))
 	 (face (make-face name)))
     (gamegrid-setup-face face color-str)
@@ -215,13 +229,16 @@
        gamegrid-mono-tty-face))))
 
 (defun gamegrid-colorize-glyph (color)
-  (make-glyph
-   (vector
-    'xpm
-    :data gamegrid-xpm
-    :color-symbols (list (cons "col1" (gamegrid-color color 0.6))
-			 (cons "col2" (gamegrid-color color 0.8))
-			 (cons "col3" (gamegrid-color color 1.0))))))
+  (find-image `((:type xpm :data ,gamegrid-xpm
+		       :ascent center
+		       :color-symbols 
+		       (("col1" . ,(gamegrid-color color 0.6))
+			("col2" . ,(gamegrid-color color 0.8))
+			("col3" . ,(gamegrid-color color 1.0))))
+		(:type xbm :data ,gamegrid-xbm
+		       :ascent center
+		       :foreground ,(gamegrid-color color 1.0)
+		       :background ,(gamegrid-color color 0.5)))))
 
 (defun gamegrid-match-spec (spec)
   (let ((locale (car spec))
@@ -245,38 +262,35 @@
 	   (vector data))
 	  ((eq data 'colorize)
 	   (gamegrid-colorize-glyph color))
+	  ((listp data)
+	   (find-image data)) ;untested!
 	  ((vectorp data)
-	   (make-glyph data)))))
+	   (gamegrid-make-image-from-vector data)))))
 
-(defun gamegrid-color-display-p ()
-  (if (fboundp 'device-class)
-      (eq (device-class (selected-device)) 'color)
-    (eq (cdr-safe (assq 'display-type (frame-parameters))) 'color)))
+(defun gamegrid-make-image-from-vector (vect)
+  "Convert an XEmacs style \"glyph\" to an image-spec."
+  (let ((l (list 'image :type)))
+    (dotimes (n (length vect))
+      (setf l (nconc l (list (aref vect n)))))
+    (nconc l (list :ascent 'center))))
 
 (defun gamegrid-display-type ()
-  (let ((window-system-p 
-	 (or (and (fboundp 'console-on-window-system-p)
-		  (console-on-window-system-p))
-	     (and (fboundp 'display-color-p)
-		  (display-color-p))
-	     window-system)))
   (cond ((and gamegrid-use-glyphs
-		window-system-p
-	      (featurep 'xpm))
+	      (display-images-p))
 	 'glyph)
 	((and gamegrid-use-color
-		window-system-p
-	      (gamegrid-color-display-p))
+	      (display-graphic-p)
+	      (display-color-p))
 	 'color-x)
-	  (window-system-p
+	((display-graphic-p)
 	 'mono-x)
 	((and gamegrid-use-color
-	      (gamegrid-color-display-p))
+	      (display-color-p))
 	 'color-tty)
-	((fboundp 'set-face-property)
+	((display-multi-font-p) ;???
 	 'mono-tty)
 	(t
-	   'emacs-tty))))
+	   'emacs-tty)))
 
 (defun gamegrid-set-display-table ()
   (if (fboundp 'specifierp)
@@ -287,26 +301,21 @@
 			     'remove-locale)
     (setq buffer-display-table gamegrid-display-table)))
 
-(defun gamegrid-hide-cursor ()
-  (if (fboundp 'specifierp)
-      (set-specifier text-cursor-visible-p nil (current-buffer))))
-
 (defun gamegrid-setup-default-font ()
-  (cond ((eq gamegrid-display-mode 'glyph)
-	 (let* ((font-spec (face-property 'default 'font))
-		(name (font-name font-spec))
-		(max-height nil))
-	   (loop for c from 0 to 255 do
-	     (let ((glyph (aref gamegrid-display-table c)))
-	       (cond ((glyphp glyph)
-		      (let ((height (glyph-height glyph)))
-			(if (or (null max-height)
-				(< max-height height))
-			    (setq max-height height)))))))
-	   (if max-height
-	       (while (and (> (font-height font-spec) max-height)
-			   (setq name (x-find-smaller-font name)))
-		 (add-spec-to-specifier font-spec name (current-buffer))))))))
+  (setq gamegrid-face
+	(copy-face 'default
+		   (intern (concat "gamegrid-face-" (buffer-name)))))
+  (when (eq gamegrid-display-mode 'glyph)
+    (let ((max-height nil))
+      (loop for c from 0 to 255 do
+	    (let ((glyph (aref gamegrid-display-table c)))
+	      (when (and (listp glyph) (eq (car  glyph) 'image))
+		(let ((height (cdr (image-size glyph))))
+		  (if (or (null max-height)
+			  (< max-height height))
+		      (setq max-height height))))))
+      (when (and max-height (< max-height 1))
+	(set-face-attribute gamegrid-face nil :height max-height)))))
 
 (defun gamegrid-initialize-display ()
   (setq gamegrid-display-mode (gamegrid-display-type))
@@ -320,11 +329,13 @@
       (aset gamegrid-display-table c glyph)))
   (gamegrid-setup-default-font)
   (gamegrid-set-display-table)
-  (gamegrid-hide-cursor))
+  (setq cursor-type nil))
 
 
 (defun gamegrid-set-face (c)
-  (unless (eq gamegrid-display-mode 'glyph)
+  (if (eq gamegrid-display-mode 'glyph)
+      (add-text-properties (1- (point)) (point)
+			   (list 'display (list (aref gamegrid-display-table c))))
     (put-text-property (1- (point))
 		       (point)
 		       'face
@@ -351,14 +362,18 @@
 (defun gamegrid-init-buffer (width height blank)
   (setq gamegrid-buffer-width width
 	gamegrid-buffer-height height)
-  (let ((line (concat
-	       (make-string width blank)
-	       "\n"))
+  (let ((line (concat (make-string width blank) "\n"))
 	(buffer-read-only nil))
     (erase-buffer)
     (setq gamegrid-buffer-start (point))
     (dotimes (i height)
-      (insert-string line))
+      (insert line))
+    ;; Adjust the height of the default face to the height of the
+    ;; images. Unlike XEmacs, Emacs doesn't allow to make the default
+    ;; face buffer-local; so we do this with an overlay.
+    (when (eq gamegrid-display-mode 'glyph)
+      (overlay-put (make-overlay (point-min) (point-max))
+		   'face gamegrid-face))
     (goto-char (point-min))))
 
 (defun gamegrid-init (options)

[-- Attachment #3: Type: text/plain, Size: 72 bytes --]


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

Re: gamegrid.el and some games

[Richard Stallman]

    > Your patch is large enough we need legal papers to use it.

    I think this is already done. I sent papers for past and future
    changes to Emacs some time ago and already got a confirmation from the
    FSF's office.

Yes, I see.

    > I will tell you more in another message.  We also need change log
    > entries in order to install it.  Could you write those?

    Is this o.K?

Yes.

Re: gamegrid.el and some games

[Oliver Scholz]

[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é!

Re: gamegrid.el and some games

[Richard Stallman]

    > * 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 was thinking that the programmer would supply the image in PBM
format.  This could be in addition to XPM, or instead of XPM.  How
hard is that?

    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.

I guess so.  It would be nice if all image formats (or at least more
of them) supported getting the image from Lisp data rather than from
a file.  Does someone want to work on that?

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

Incompatibilities with the former version of gamegrid are not terribly
important.  Most of the programs that use gamegrid are included in Emacs.
We would change them too.

I doubt the interface will be much less clear.

    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.

That seems like a good method.

Re: gamegrid.el and some games

[alkibiades]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     > * 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 was thinking that the programmer would supply the image in PBM
> format.  This could be in addition to XPM, or instead of XPM.  How
> hard is that?

That's easy. 

However, my misunderstanding caused me to read a bit about the PBM
format. I discovered that my Emacs supports PPM and PGM, too. The
three related image formats PBM (black & white), PGM (grayscale) and
PPM (colour) are supposed to be intermediate formats for image
conversion.

Well, it should be straightforward to convert XPM to PPM. I already
started to write a small library.

I don't know anything about Emacs' internals. Does an Emacs that
supports images always support colours, too? Does an Emacs that
supports PBM alway support PPM, too?

If this is so and if I am not missing something this would mean, that
every Emacs able to display images could display XPMs via some Lisp.

>     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.
>
> I guess so.  It would be nice if all image formats (or at least more
> of them) supported getting the image from Lisp data rather than from
> a file.  Does someone want to work on that?
[...]

Perhaps you like the approach that I chose in my unfinished code
(attached)?

For example:

(let ((pic (make-pixmap 16 16 'colour '(0 0 0))))
  (experimental!-draw-line pic 15 0 0 15 '(255 0 0))
  (experimental!-draw-line pic 0 0 15 15 '(0 0 255))
  (insert-image (experimental!-pixmap-to-image pic :ascent 'center)))

    -- Oliver


[-- Attachment #2: the-gimp.el --]
[-- Type: application/emacs-lisp, Size: 6673 bytes --]

[-- Attachment #3: Type: text/plain, Size: 245 bytes --]


-- 
Oliver Scholz               30 Fructidor an 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: gamegrid.el and some games

[Richard Stallman]

    I don't know anything about Emacs' internals. Does an Emacs that
    supports images always support colours, too?

Emacs always supports colors, but the display in use could be monochrome.
Use display-color-p to test that.

						 Does an Emacs that
    supports PBM alway support PPM, too?

I don't know, but I hope Gerd does.

Re: gamegrid.el and some games

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

> 						 Does an Emacs that
>     supports PBM alway support PPM, too?
> 
> I don't know, but I hope Gerd does.

Yes.  It's always supported because the code for parsing the "portable
<whatever>" formats is built-in (doesn't rely on image support libs).

Re: gamegrid.el and some games

[Oliver Scholz]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     I don't know anything about Emacs' internals. Does an Emacs that
>     supports images always support colours, too?
>
> Emacs always supports colors, but the display in use could be monochrome.
> Use display-color-p to test that.

Pardon my ignorance: what happens with colour images on monochrome
displays? Are they displayed in shades of gray if
`display-grayscale-p' returns nil?  If so, the conversion of XPM to
PPM would probably do for such displays.

Are there any displays for which `display-images-p' returns t, but
both `display-color-p' and `display-grayscale-p' return nil? Is it
necessary to make sure that gamegrid.el DTRT on such displays?

If not, I suggest to simply convert XPMs via some Lisp functions if
Emacs is compiled without XPM-support on the C-level. I have written a
prototype[1] for this. What do you think?


[-- Attachment #2: xpm.el --]
[-- Type: application/emacs-lisp, Size: 9438 bytes --]

[-- Attachment #3: Type: text/plain, Size: 928 bytes --]



    -- Oliver

PS: Could someone who has an Emacs compiled with image-support, but
without XPM-support check if the following gives a coloured image for
him or her, please?

(require 'gamegrid)

(insert-image 
 (xpm-convert-string gamegrid-xpm 
		     '((col1 . "Blue") 
		       (col2 . "Red") 
		       (col3 . "Green")) 
		     :ascent 'center))


Footnotes: 
[1]  I have not read the specification for the XPM-format, yet. (My
ghostscript is b0rked.) My knowledge of the format is based on a few
example XPMs.
Furthermore I am just an amateur. I would appreciate it, if an
experienced programmer could have a quick glance over my code and tell
me if the approach is clean/unclean/silly/sound.
And finally, if you like the idea, this should probably go into
images.el, not into gamegrid.el, and hook there into the functions to
create images.
-- 
Jour du Génie de l'Année 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: gamegrid.el and some games

[Oliver Scholz]

Oliver Scholz <alkibiades@gmx.de> writes:
[...]
> Pardon my ignorance: what happens with colour images on monochrome
> displays? Are they displayed in shades of gray if
> `display-grayscale-p' returns nil?  If so, the conversion of XPM to
                                ^^^
> PPM would probably do for such displays.
[...]

I meant: "... if `display-grayscale-p' returns t".

    -- Oliver

-- 
Jour du Génie de l'Année 210 de la Révolution
Liberté, Egalité, Fraternité!

Re: gamegrid.el and some games

[Eli Zaretskii]

On Wed, 18 Sep 2002, Oliver Scholz wrote:

> Pardon my ignorance: what happens with colour images on monochrome
> displays? Are they displayed in shades of gray if
> `display-grayscale-p' returns t?

AFAIK, yes.

> Are there any displays for which `display-images-p' returns t, but
> both `display-color-p' and `display-grayscale-p' return nil?

I don't think so.

> Is it
> necessary to make sure that gamegrid.el DTRT on such displays?

If it's conceivable, IMHO yes.  It's better not to leave behind hidden 
dependencies like this, because some day we might bump into such a 
display type.

Re: gamegrid.el and some games

[Richard Stallman]

    Pardon my ignorance: what happens with colour images on monochrome
    displays? Are they displayed in shades of gray if
    `display-grayscale-p' returns [non-]nil?

I don't know.  Gerd, can you answer?

    Are there any displays for which `display-images-p' returns t, but
    both `display-color-p' and `display-grayscale-p' return nil? Is it
    necessary to make sure that gamegrid.el DTRT on such displays?

There certainly WERE computers whose displays could only show black
and white.  Using X on those displays, it would be proper for
display-images-p to return t and the other two to return nil.

It is possible that no such displays have been built in recent years.
gamegrid.el should do SOME kind of Right Thing on those displays, but
pretending they cannot draw images might be good enough.

    If not, I suggest to simply convert XPMs via some Lisp functions if
    Emacs is compiled without XPM-support on the C-level. I have written a
    prototype[1] for this. What do you think?

Converting XPM to PPM seems useful, because with this, we can arrange
that Emacs can always display XPM format.  That makes the API specs
simpler.  It would be nice if Emacs always used this conversion method
when you try to display an XPM and the support is not built in.

But why do you prefix this with "if not"?  I know very very little
about these graphics formats, so it isn't obvious to me why this
method would depend on being able to display more than just black and
white.  Can you explain?

Re: gamegrid.el and some games

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

[black-and-white displays]

> It is possible that no such displays have been built in recent years.
> gamegrid.el should do SOME kind of Right Thing on those displays, but
> pretending they cannot draw images might be good enough.

I see.

[...]
> Converting XPM to PPM seems useful, because with this, we can arrange
> that Emacs can always display XPM format.  That makes the API specs
> simpler.  It would be nice if Emacs always used this conversion method
> when you try to display an XPM and the support is not built in.

O.K. I am working on it. 

> But why do you prefix this with "if not"?  I know very very little
> about these graphics formats, so it isn't obvious to me why this
> method would depend on being able to display more than just black and
> white.  Can you explain?

I know nothing about graphical black&white displays. I assume -- but
this is just a wild guess -- that on such a display _every_ coloured
pixel appears as black. I fear that this could lead to the end that
you have to play tetris or snake with black squares on a black
background, which makes it unnecessarily difficult.

So I agree that it's best and safest to use simple ascii-chars on
displays for which

(and (display-images-p) 
     (not (or (display-color-p)
              (display-grayscale-p))))

is t.

    -- Oliver

-- 
Oliver Scholz               Jour du Travail de l'Année 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: gamegrid.el and some games

[Miles Bader]

Oliver Scholz <alkibiades@gmx.de> writes:
> I know nothing about graphical black&white displays. I assume -- but
> this is just a wild guess -- that on such a display _every_ coloured
> pixel appears as black.

I'm not sure what that means.  On a B&W display, there are two colors,
black, and white.

If you ignore the fact that you're on a B&W display, and try to use
_other_ colors, then Gerd says it will try to pick the `nearest'
supported color instead; I guess this means that `dark looking' colors
will show up as black, and `light looking' colors will show up as
white.  For pictures this will probably end up looking awful, but for
simple high-contrast stuff, it may work quite well.

> So I agree that it's best and safest to use simple ascii-chars on
> displays for which
> 
> (and (display-images-p) (not (or (display-color-p) (display-grayscale-p))))

That seems unnecessarily conservative, but whatever, you're doing the work...

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: gamegrid.el and some games

[Oliver Scholz]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Oliver Scholz <alkibiades@gmx.de> writes:
>> I know nothing about graphical black&white displays. I assume -- but
>> this is just a wild guess -- that on such a display _every_ coloured
>> pixel appears as black.
>
> I'm not sure what that means.  On a B&W display, there are two colors,
> black, and white.
>
> If you ignore the fact that you're on a B&W display, and try to use
> _other_ colors, then Gerd says it will try to pick the `nearest'
> supported color instead; I guess this means that `dark looking' colors
> will show up as black, and `light looking' colors will show up as
> white.  For pictures this will probably end up looking awful, but for
> simple high-contrast stuff, it may work quite well.

I was thinking  of the tiles that gamegrid provides  and that are used
by pong, tetris and snake. They are _low_ contrast. I am afraid -- but
I have  not made sure -- that  they would appear as  black squares (or
maybe white squares in case of light colours as yellow, for example).

[using ascii on b/w-displays]
>
> That seems unnecessarily conservative, but whatever, you're doing the work...
[...]

Now that I know that the XPM format allows to specify what to do with
the image in such cases, I prefer to use this mechanism. In fact, it
seems that the differences between colour, grayscale and b/w displays
were a part of the reasons to invent XPM. 

It is easy to change the image `gamegrid-xpm' accordingly. (It may not
be so easy to make sure that gamegrid uses this, but it seems like the
Right Thing (tm) and I find it challenging to implement it.)

    -- Oliver

-- 
Oliver Scholz               Jour de la Raison de l'Année 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: gamegrid.el and some games

[Francesco Potorti`]

   I know nothing about graphical black&white displays. I assume -- but
   this is just a wild guess -- that on such a display _every_ coloured
   pixel appears as black. 

This is not the case.  They usually translate colours into shades of
grey. 

Re: gamegrid.el and some games

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> There certainly WERE computers whose displays could only show black
> and white.  Using X on those displays, it would be proper for
> display-images-p to return t and the other two to return nil.

... and people certainly still use emacs on them; e.g., my former
manager runs emacs on a B&W X terminal.

Anyway, they may not be a very important case these days, but it seems
sloppy to disregard them completely.

-Miles
-- 
We live, as we dream -- alone....

Re: gamegrid.el and some games

[rms]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Richard Stallman <rms@gnu.org> writes:
>> There certainly WERE computers whose displays could only show black
>> and white.  Using X on those displays, it would be proper for
>> display-images-p to return t and the other two to return nil.
>
> ... and people certainly still use emacs on them; e.g., my former
> manager runs emacs on a B&W X terminal.
>
> Anyway, they may not be a very important case these days, but it seems
> sloppy to disregard them completely.
[...]

Reading the XPM spec I realize now that the XPM formats supports a way
to specify how the image should appear on a b/w- or a
grayscale-display respectively. I certainly want to enable this in my
conversion library. Does anybody know how I can setup my XFree 4 to
mono- or grayscale, so I can test this?

    -- Oliver

-- 
Oliver Scholz               Jour de la Raison de l'Année 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: gamegrid.el and some games

[Oliver Scholz]

Ooops, sorry for the false "From"-header in my last mail. I sometimes
forget that something like this may happen with my Gnus setup. I
really have to fix this.

    -- Oliver

-- 
Oliver Scholz               Jour de la Raison de l'Année 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: gamegrid.el and some games

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

>     Pardon my ignorance: what happens with colour images on monochrome
>     displays? Are they displayed in shades of gray if
>     `display-grayscale-p' returns [non-]nil?
> 
> I don't know.  Gerd, can you answer?

Image colors are allocated with a function that allocates the nearest
color available on the display where the image is to be displayed.
That is, one will get something displayed for a color image on a mono
or grayscale display, but I doubt it will be of very high quality.

>     Are there any displays for which `display-images-p' returns t, but
>     both `display-color-p' and `display-grayscale-p' return nil? Is it
>     necessary to make sure that gamegrid.el DTRT on such displays?
> 
> There certainly WERE computers whose displays could only show black
> and white.  Using X on those displays, it would be proper for
> display-images-p to return t and the other two to return nil.
> 
> It is possible that no such displays have been built in recent years.
> gamegrid.el should do SOME kind of Right Thing on those displays, but
> pretending they cannot draw images might be good enough.

I think XFree contains a mono server for VGA displays.

Re: gamegrid.el and some games

[Richard Stallman]

In Emacs, use the variable image-types to see which graphics formats
are supported.

       As you can see, foreground and background are set to the same colour,
       thus preventing the possibility of anything different from a coloured
       space.

It is certainly strange, but whether it is a bug, I do not know.
I wish gamegrid.el had more comments.

      Maybe I should directly ask the author, Glynn
       Clements, if no one here cares about gamegrid.

Please do try to contact him.  If you can get explanations for
this and other things in gamegrid.el, you could write more
comments.

I will also write to him asking him to add comments.