From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Oliver Scholz Newsgroups: gmane.emacs.devel Subject: Re: gamegrid.el and some games Date: Mon, 16 Sep 2002 14:01:20 +0200 Organization: Olymp Sender: emacs-devel-admin@gnu.org Message-ID: References: <87n0ql94mz.fsf@pot.cnuce.cnr.it> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1032175340 23619 127.0.0.1 (16 Sep 2002 11:22:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 16 Sep 2002 11:22:20 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17qtxK-00068n-00 for ; Mon, 16 Sep 2002 13:22:18 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17quad-0006Q5-00 for ; Mon, 16 Sep 2002 14:02:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17qtxZ-0008At-00; Mon, 16 Sep 2002 07:22:33 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17qtvX-00086T-00 for emacs-devel@gnu.org; Mon, 16 Sep 2002 07:20:27 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17qtvU-00086C-00 for emacs-devel@gnu.org; Mon, 16 Sep 2002 07:20:26 -0400 Original-Received: from main.gmane.org ([80.91.224.249]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17qtvU-000867-00 for emacs-devel@gnu.org; Mon, 16 Sep 2002 07:20:24 -0400 Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17qtvA-00062h-00 for ; Mon, 16 Sep 2002 13:20:04 +0200 Original-To: emacs-devel@gnu.org X-Injected-Via-Gmane: http://gmane.org/ Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17qtdh-0005Ls-00 for ; Mon, 16 Sep 2002 13:02:01 +0200 Original-Path: hermes!nobody Original-Lines: 106 Original-NNTP-Posting-Host: dialin-145-254-203-125.arcor-ip.net Original-X-Trace: main.gmane.org 1032174121 20559 145.254.203.125 (16 Sep 2002 11:02:01 GMT) Original-X-Complaints-To: usenet@main.gmane.org Original-NNTP-Posting-Date: Mon, 16 Sep 2002 11:02:01 +0000 (UTC) X-Operating-System: Linux from Scratch X-Attribution: os X-Face: "HgH2sgK|bfH$;PiOJI6|qUCf.ve<51_Od(%ynHr?=>znn#~#oS>",F%B8&\vus),2AsPYb -n>PgddtGEn}s7kH?7kH{P_~vu?]OvVN^qD(L)>G^gDCl(U9n{:d>'DkilN!_K"eNzjrtI4Ya6;Td% IZGMbJ{lawG+'J>QXPZD&TwWU@^~A}f^zAb[Ru;CT(UA]c& User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i686-pc-linux-gnu) Cancel-Lock: sha1:UP8g2pRPYhV8IyK4Y/ryX+VB3LQ= Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7944 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7944 [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 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é!