Discussion:
Angband with an accent: displaying extended characters
(too old to reply)
Leon Marrick
2005-10-15 12:30:16 UTC
Permalink
Angband with an accent

displaying extended characters


For almost as long as Angband has been in existance, people have
wanted to display more than the basic ASCII set of 128 characters. If
the game can be made to display a full byte range of 256 characters,
then Tolkien names can be properly accented and special terrain can be
made to look more distinctive.

However, results have been decidedly mixed. Fangband introduced
accented artifact names long ago, but they only worked on IBM-PCs. The
objective of this essay is to see how we can reproduce Fangband's
success, and this time make it portable to multiple operating systems.

We discuss fonts first, because this is liable to be the hard
part. The text file and code changes ought not to make us sweat unduly;
they are treated afterwards. More details will be added as interested
people chip in; would you like to help make this happen?


========== Discussion of 256-character fonts in various operating
systems ================


Windows (Windows port):

The author works on Windows, so we will start the discussion
there. It is easy for the Windows port to display 256 characters; all
you have to do is edit a .fon file, put it into the /lib/xtra/font/
folder, and change fonts using the handy menu. An example of an edited
font may be downloaded at:

http://www.runegold.org/angband/pub/8x13x.fon

This font has a series of special terrain icons in character
positions 1-17, leaves positions 18-32 blank for variant terrain
expansion, leaves positions 33-127 unchanged, adds a series of accented
characters and monetary symbols (euro, pound, yen) in characters
128-165, and includes a Purple X Moria-style snake icon in position 159.
The remaining character positions are left blank for additional
customization.

More details on editing and using custom fonts for Windows may be found
in Appendix A.



IBM/DOS/Windows (DOS and IBM ports):

Things aren't any more difficult here; this is the system that
Fangband succeeded with. DOS (and the emulated DOS terminal available
in Windows) can switch fonts. So can the IBM port. You take an
existing font, edit it, add it to the font folder, and use it by
revising "angdos.cfg" (DOS port, text mode).

(don't yet have a program to edit .fnt files, except for the old Angband
one that works only on the IBM port's angband.fnt)


*** Here is where my knowledge ends. Everything from here on needs
correction. ****



Linux and other graphical UNIX systems (X11, xaw, gtk, and other ports):

I have been told that Linux (and other UNIX graphical systems) do
not allow ordinary users to use custom or application-specific fonts,
that one has to be root and that the fonts have to be installed in some
special way. One idea to work around this is to supply custom fonts as
bitmap files in /lib/xtra/. Is there a reason why this wouldn't work
for all graphical UNIX systems?



Macintosh (mac, carbon, and OS X ports):

If there is one operating system that glories in fonts, it is the
Macintosh. I have been told that mac users have better font-handling
tools than anyone. We shall see if this is so!



Terminals (various systems (other than IBM/DOS) without graphical
capacity) (cap, gcu?):

People say that non-graphical terminals refuse to let the user
change fonts. I'd be surprised if that were really so but, for
argument's sake, let us assume that it is. This brings us to:




============== Implementation and Compatibility ==================

OK. So we have some systems that can handle 256-character fonts,
and some that either can't, or that haven't got extended fonts. We need
a way for accented names and other special characters to be 1)
translated into the correct characters for that system (they differ),
and 2) translated into basic ASCII characters if that is all that are
available.

When working on getting 256 colors, among my priorities was to
stay compatible with both GCU and IBM, both 16-color ports. This
required that each "extended" color have a 16-color translation. The
same method will work just dandy for extended characters.


Consider an accented name, such as Luthien. In "artifact.txt", it
is listed as:

# The Shadow Cloak of Luthien

N:49:of Luthien
I:35:6:2
W:40:40:5:45000
P:6:0d0:0:0:20


We want a forward slant accent over that u. Let's change this to:

# The Shadow Cloak of Luthien

N:49:of L^'uthien # see explanation below
I:35:6:2
W:40:40:5:45000
P:6:0d0:0:0:20



Now for some coding.

In the text file pharser, we need something to look at a name.
When it sees a " ^ ", it looks at the second character to figure out
what accent to apply. In this case, we have a forward single quote (" '
"), which means forward slant accent. The third character is the letter
itself; in this case, a lowercase " u ".

We now need a lookup table. Each character set will have a
different character that shows a lowercase u with a forward slant
accent. So we add a preference type, write up the various possible
combinations for recognized accented characters, and let the game read
them into a table on load. If two systems have differing character
sets, then we just have different preference lists for them.

Now we make our move to keep this compatable with 128-character
systems. Whenever we reach the end of our lookup table without finding
the correct accented character, we ignore the accent and use the plain
ASCII "u" for the data file. So people can admire Luthien with or
without accent.

One more wrinkle. The game stores characters as signed bytes.
The input text feeds it unsigned bytes. Translating between the two is
child's play, we just have to remember to do it consistantly.





========================

Appendix A: Editing and installing custom fonts for the Angband Windows
port.

I assume you have a clean copy of Angband 3.0.6 for this
discussion. The methods outlined below will also work for most modern
variants.

1. Download softy, a shareware bitmap font editor, and upzip it.
http://users.breathe.com/l-emmett/

2. Copy an Angband font that you know works to the softy directory - in
this example, we shall copy 8x13.fon. Fire softy up. Notice the
request for money; this program is not freeware.

3. Menu "Font Type -> bitmap". The Bitmap window opens; in this
window, use Menu File -> Open. Choose the font.

4. Your font should now appear. Edit the font header first: use Menu
Font -> Header..., and a dialog box with font header information
appears. Change the font name from (in this example) 8x13 to 8x13a.
The new name must 1) be unique within the Angband fonts folder, and 2)
start with the width and height of the font. All Angband's existing
fonts already do both of these things. When done, click "OK".

5. Edit one character (you might try the '@' symbol). Don't spend much
time, just enough so your work is obvious. The Angband Windows font
reader is fairly unforgiving of newbie mistakes, and you need to make
sure you know how to get the game to recognize your fonts before
spending time on individual characters.

6. Click on some other character. The program will ask if you want to
save the character you've been working on. Carefully say yes. Notice
the character list update.

7. Now that the header name is unique, and any changed characters are
properly closed, you may now save the font. Menu File -> Save As. Save
under *exactly* the same name as appears in your font header, plus the
.fon file extension. In our case, we will save as "8x13a.fon".
Double-check that you are either making a new font or overwriting a
font. Do not let softy add your new font to an existing one; Angband
doesn't understand font packages.

8. Close softy. Copy the font to your Angband game's /lib/xtra/fonts
folder (where all the other .fon files live).

9. Fire up Angband. Change to text mode if you see graphics. Use the
menu and select Window -> Font -> Term-0 window. Choose your new font.

Test #1: Look carefully at the screen. If the overall appearance of
the font has worsened or it just looksdull or "strange", then your font
is not recognized by the game. The most probable reasons are that your
font's header is different than the file name (before the .fon bit), or
you have two or more fonts saved in a common file.

Test #2: Command '%' - Interact with Visuals. Change the player icon
to your new edited character. If test #1 succeeds, then this test
probably will too. However, if you simply cannot see your edited
character, and you are certain you are using your new font, then restart
the game. If this doesn't work, reboot your machine.

If either test fails, try, try again. When both succeed, great!
--
S(all) W/X H+ D c+ f? PV++ s? d- C S !I? !So? RQ V+ F:<<too much data!>>
(website for Angband code down)
Joshua Rodman
2005-10-15 13:02:54 UTC
Permalink
Post by Leon Marrick
I have been told that Linux (and other UNIX graphical systems) do
not allow ordinary users to use custom or application-specific fonts,
that one has to be root and that the fonts have to be installed in some
special way. One idea to work around this is to supply custom fonts as
bitmap files in /lib/xtra/. Is there a reason why this wouldn't work
for all graphical UNIX systems?
There are two different font systems in the X world.

- The old font system which X uses resides in the domain of the X
server, which is often system-installed, and therefore you need to
find a way to get the X server to know about the new fonts.

This may require root or some priveledge or may not, but is system
specific to an extent, and certainly cannot be accomplished by a
normal program.

- The new, more reasonable fontconfig method of managing fonts is
entirely client based. The client sends glyphs to the server, and so
the server does not need to know about fonts. As such Angband could
take care of loading and sending the fonts entirely on its own for
servers which support the new font extension. This innovation
occurred around 1999/2000, and modern unices generally have this
extension, but older ones may not.

Given Angband's attempt to target a very broad set of machines, the
second option may not be interesting, and further, for Angband's needs
of only nonproportional fonts, and no real need to load additional
fonts, your suggestion of bitmaps may be sufficient for all graphical
Angband ports, not just UNIX.
Post by Leon Marrick
Terminals (various systems (other than IBM/DOS) without graphical
People say that non-graphical terminals refuse to let the user
change fonts.
Some consoles (such as the linux console) can load fonts.
Graphical-environment terminals, such as xterm and rxvt can certainly
load fonts.

Given, however, that Linux runs on a wide variety of hardware, not all
the hardware even has the capability of loading software fonts in
character mode.

The main issue, though, is that fonts are not loaded at the request of
a program which is running inside a terminal. There is no way for
Angband, or any other terminal application, to request a specific font
to be loaded. Consider, for example, the case where Angband is running
on a remote machine that I am logged into via a modem, or ssh, or some
such. It would be difficult for Angband to load a font into my local
terminal on the client machine.

One could request that the user arrange to have a font loaded prior to
running Angband, but I view this situation as undesirable.


----

Your approach for handling the text characters seems quite reasonable.
In fact this is how I actually type these characters. COMPOSE + ' + u
results in ú.

In some languages the accented and unaccented versions of a word have
different lengths (eg. groß, gross). Would this be a point of concern
in Angband?


It would certainly be a nice touch to see names like KHAZAD-DÛM in the
game. Thanks for working on this.
--
Grim. Grom. Grümmer.
Christophe Cavalaria
2005-10-15 13:06:28 UTC
Permalink
Post by Leon Marrick
I have been told that Linux (and other UNIX graphical systems) do
not allow ordinary users to use custom or application-specific fonts,
that one has to be root and that the fonts have to be installed in some
special way. One idea to work around this is to supply custom fonts as
bitmap files in /lib/xtra/. Is there a reason why this wouldn't work
for all graphical UNIX systems?
You can always ignore the standard font rendering functions and bind
directly to freetype and display the font yourself. You can do that very
easily with SDL and SDL_TTF and I bet it can be done with any gui lib that
allows graphics which is all of them.
Andrew Sidwell
2005-10-15 13:27:11 UTC
Permalink
On 2005-10-15 14:30:16, Leon Marrick <***@invalid.org> wrote:

*big snip*
Post by Leon Marrick
Now for some coding.
In the text file pharser, we need something to look at a name.
When it sees a " ^ ", it looks at the second character to figure out
what accent to apply. In this case, we have a forward single quote (" '
"), which means forward slant accent. The third character is the letter
itself; in this case, a lowercase " u ".
We now need a lookup table. Each character set will have a
different character that shows a lowercase u with a forward slant
accent. So we add a preference type, write up the various possible
combinations for recognized accented characters, and let the game read
them into a table on load. If two systems have differing character
sets, then we just have different preference lists for them.
You may be planning this already, but if not, here's a suggestion:

Why not use a function hook to translate such things, rather than writing lookup
tables into the main game code? You would define your hook type [1] so that it
took the plain character and a code for the accent. Make a default function
that returns that character without any modification [2] (this means that by
default, if a system doesn't override the hook, they get plain, totally
compatible ASCII characters).

In your main-win.c file, you then write a function that converts it to Windows'
version of extended characters. Same goes for any other platforms that can
support it.

The only issue I can think of is how it will affect character dumps. You'd have
to convert back into ASCII for that, so it might be worthwhile doing another
hook for converting back. I just don't like the idea of trying to write lots
of conversion tables into the main game code.

(Examples)
[1] typedef unsigned byte (*hook_convert_accent)(unsigned char c, byte accent);
(where c is the character, and accent is an index for an accent; 1 could be an
acute, 2 for a grave, etc.)

[2] unsigned byte convert_dummy(unsigned char c, byte accent) { return c; }
--
We must aim for perfection, but settle for progress.
Hallvard B Furuseth
2005-10-15 14:14:00 UTC
Permalink
Post by Leon Marrick
I have been told that Linux (and other UNIX graphical systems) do
not allow ordinary users to use custom or application-specific fonts,
that one has to be root and that the fonts have to be installed in some
special way.
It can also be a problem to discover which character set is in use.
You can check the locale environment variables (LC_CTYPE, LC_ALL etc) -
the locale name, if set, may or may not contain the character set name.

I think you need two steps. First attempt to set the character set if
the display allows that. Then try to discover which character set and
encoding is in use (from the system or a setting from the user), and
fall back on ASCII if you didn't find anything.

Note that with single-byte character encodings, the character set which
a Unix system thinks is in use isn't necessarily the one displayed by
the user's font. X.11 font names often include character set name, but
need not. Due to weird things Unixes choose to do about character sets
and the lack of a standardized way for system and programs to tell each
other about character sets, the user may be handling character set
issues himself and leave the system to think it is running its default.
It's gotten better over the years, but if Angband still tries to support
all kinds of ancient setups...
Post by Leon Marrick
People say that non-graphical terminals refuse to let the user
change fonts. I'd be surprised if that were really so but, for
argument's sake, let us assume that it is.
Depends on the terminal. I've used text terminals where I could select
one of several built-in fonts, and text terminals with only one font.
Whether I'd have wanted to switch font on my terminal just in order to
play Angband is a another matter.
Post by Leon Marrick
OK. So we have some systems that can handle 256-character fonts,
Hold on -- 256-character fonts? If Angband is going to the trouble of
supporting non-ASCII text, at least move to Unicode - maybe only with
support for ASCII and accented ASCII characters.
Windows speaks Unicode. Newer Linuxes has UTF-8 as default.
Single-byte 8-bit characters output to a UTF-8 terminal will not work.
Post by Leon Marrick
We need a way for accented names and other special characters to be 1)
translated into the correct characters for that system (they differ),
and 2) translated into basic ASCII characters if that is all that are
available.
Unicode publishes character tables where accented characters are split
up in ASCII character + accents, upper<->lowercase translations, etc.
Libraries exist to convert between encodings, e.g. libiconv. (Haven't
used it myself, so I don't know if it can "ASCIIfy" characters.)
Post by Leon Marrick
# The Shadow Cloak of Luthien
N:49:of L^'uthien # see explanation below
I think I'd prefer to edit straight UTF-8 or latin-1. Maybe there
should be a tool to translate between that and an ASCII encoding
which everyone can use. The file could be marked at the top with
which character set is in use.

BTW, check out RFC 1345 <http://www.faqs.org/rfcs/rfc1345.html>, which
has already invented such an ASCII encoding.


One other problem:
With non-ASCII character sets in Angband, we'll see non-ASCII postings
in rec.games.roguelike.angband. That will probably include MIME
quoted-printable postings which some newsreaders won't decode, and 8-bit
postings which some news servers might drop (since I think some servers
still only allow ASCII).
It might help if character dumps use an ASCII encoding.
--
Hallvard
pete mack
2005-10-15 15:44:49 UTC
Permalink
'Fando' already did this for full unicode support in ToME in March.
The thread is here:

http://groups.google.com/group/rec.games.roguelike.angband/browse_frm/thread/9a721b75332d8eed/524b06c624a8b14e?q=fando+unicode+TOME&rnum=1#524b06c624a8b14e

Sample picture here:

Loading Image...
Jeff Greene
2005-10-15 17:23:07 UTC
Permalink
Post by pete mack
'Fando' already did this for full unicode support in ToME in March.
http://groups.google.com/group/rec.games.roguelike.angband/browse_frm/thread/9a721b75332d8eed/524b06c624a8b14e?q=fando+unicode+TOME&rnum=1#524b06c624a8b14e
http://log4r.sourceforge.net/images/uniangband.png
AFAIK, he started it. He then communicated with me because he decided that NPPAngband was a better forum for his unicode experiment. Switching to unicode, according to him, required extensive changes throughout the source code. He switched to working on the project in NPPangband, then real life got in the way and his project fell by the wayside.

I haven't kept up with TOME, but if it was completed and TOME has full unicode support, my apologies. But those were my off-line conversations with "Fando".

-Jeff
pete mack
2005-10-15 18:14:30 UTC
Permalink
Post by Jeff Greene
Post by pete mack
'Fando' already did this for full unicode support in ToME in March.
http://groups.google.com/group/rec.games.roguelike.angband/browse_frm/thread/9a721b75332d8eed/524b06c624a8b14e?q=fando+unicode+TOME&rnum=1#524b06c624a8b14e
http://log4r.sourceforge.net/images/uniangband.png
AFAIK, he started it. He then communicated with me because he decided
that NPPAngband was a better forum for his unicode experiment.
Switching to unicode, according to him, required extensive changes
throughout the source code. He switched to working on the project in
NPPangband, then real life got in the way and his project fell by the
wayside.
I haven't kept up with TOME, but if it was completed and TOME has full
unicode support, my apologies. But those were my off-line conversations
with "Fando".
Oh, right. I did a full reread of that thread, and I see that Leon has
a very good idea indeed of what 'fando' did in March.
camlost
2005-10-15 17:51:33 UTC
Permalink
Such pretty trees!

Joshua
Post by pete mack
'Fando' already did this for full unicode support in ToME in March.
http://groups.google.com/group/rec.games.roguelike.angband/browse_frm/thread/9a721b75332d8eed/524b06c624a8b14e?q=fando+unicode+TOME&rnum=1#524b06c624a8b14e
http://log4r.sourceforge.net/images/uniangband.png
Jeff Greene
2005-10-15 16:14:39 UTC
Permalink
Post by Leon Marrick
Angband with an accent
displaying extended characters
people chip in; would you like to help make this happen?
Diego and I are interested, albeit my time is extremely limited and Diego can get busy as well. Diego works on a Linux system, so he can providign the research on that perspective. Still, I think I am speaking for him when I say we are interested. We have been doing some research that may be useful to you. Here is what we have.....
Post by Leon Marrick
This font has a series of special terrain icons in character
positions 1-17, leaves positions 18-32 blank for variant terrain
expansion, leaves positions 33-127 unchanged, adds a series of accented
characters and monetary symbols (euro, pound, yen) in characters
128-165, and includes a Purple X Moria-style snake icon in position 159.
The remaining character positions are left blank for additional
customization.
/*Nitpick*/ IMHO some may need to be preserved for RETURN, ESCAPE, CTRL, and things like that.
Post by Leon Marrick
I have been told that Linux (and other UNIX graphical systems) do
not allow ordinary users to use custom or application-specific fonts,
that one has to be root and that the fonts have to be installed in some
special way. One idea to work around this is to supply custom fonts as
bitmap files in /lib/xtra/. Is there a reason why this wouldn't work
for all graphical UNIX systems?
Diego confirmed with me that Linux does not use the *.fon files at all. I will see what he says about this question. Either he will post or I will.
Post by Leon Marrick
Terminals (various systems (other than IBM/DOS) without graphical
Should be be concerned about Amiga? Not even Vanilla has been compiled for Amiga for several versions.
Post by Leon Marrick
Consider an accented name, such as Luthien. In "artifact.txt", it
# The Shadow Cloak of Luthien
N:49:of Luthien
I:35:6:2
W:40:40:5:45000
P:6:0d0:0:0:20
# The Shadow Cloak of Luthien
N:49:of L^'uthien # see explanation below
I:35:6:2
W:40:40:5:45000
P:6:0d0:0:0:20
Brilliant. There is a chance there is a simpler way, but I don't know if it will allow 100% compatibility with all OSs in all countries. I hand't gotten that far yet. Of the three main OS types out there, Windows uses ANSI, Mac uses MACRoman, and Linux/Unix uses iso-8859-1 (all of which can vary slightly from country to country, that's the problem). All three kernels have the "international letters" we want, so they shouldn't have any trouble reading them from a .txt file. The only thing preventing Angband from actually reading these sybmols is the isprint() check in my_fgets in util.c. The trick is that each OS would store them in different positions, so they would have to be converted, but that is simple.

My source for this is:

http://www.alanwood.net/demos/charsetdiffs.html

Here is a list of characters in the 128-255 set list that are common to all three of these main character sets. I haven't cross-checked with DOS yet, but I think it has most of these....


¡
¢
£
¥
§
¨
©
ª
«
®
¯
°
±
´
µ
·
¸
¹
º
»
¿
À
Á
Â
Ã
Ä
Å
Æ
Ç
È
É
Ê
Ë
Ì
Í
Î
Ï
Ñ
Ò
Ó
Ô
Õ
Ö
Ø
Ù
Ú
Û
Ü
ß
à
á
â
ã
ä
å
æ
ç
è
é
ê
ë
ì
í
î
ï
ñ
ò
ó
ô
õ
ö
÷
ø
ù
ú
û
ü
ÿ

This is the research Diego and I have done in the last couple days. I don't know if that is any help to you at all, or inspires any new ideas for you, but that's where we were.
--
-Jeff


Author of NPPAngband. Check it out at:
http://members.cox.net/nppangband/

replace the ".spam"s with cox.net to reply
Christer Nyfalt
2005-10-16 04:53:22 UTC
Permalink
Post by Jeff Greene
Post by Leon Marrick
Terminals (various systems (other than IBM/DOS) without graphical
Should be be concerned about Amiga? Not even Vanilla has been compiled for
Amiga for several versions.
Or should we make the conclusion that no one cares about compiling on
Amiga anymore?
You people out there with obsure ports, take contact with maintainers
and show your interest in keeping the port up to date.
Report bugs and problems!
We can't test those ports ourselves!
If you are quiet we will conclude that no one cares and we don't need to
support your ancient system anymore.
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.

Christer
--
Christer Nyfalt
Jack Wise
2005-10-19 19:29:31 UTC
Permalink
Post by Christer Nyfalt
Post by Jeff Greene
Post by Leon Marrick
Terminals (various systems (other than IBM/DOS) without graphical
Should be be concerned about Amiga? Not even Vanilla has been compiled for
Amiga for several versions.
Or should we make the conclusion that no one cares about compiling on
Amiga anymore?
You people out there with obsure ports, take contact with maintainers
and show your interest in keeping the port up to date.
Report bugs and problems!
We can't test those ports ourselves!
If you are quiet we will conclude that no one cares and we don't need to
support your ancient system anymore.
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.
Christer
I would very much like to play on OS/2. However there has been no
version since 2.9.1
--
Jack Wise


TEXAS red wine: renowned for its smoky-mesquite-bbq & jalapeno
overtones, the perfect foil for a meal of tacos and refried beans...
Christer Nyfalt
2005-10-20 07:41:23 UTC
Permalink
Post by Jack Wise
Post by Christer Nyfalt
Post by Jeff Greene
Post by Leon Marrick
Terminals (various systems (other than IBM/DOS) without graphical
Should be be concerned about Amiga? Not even Vanilla has been compiled for
Amiga for several versions.
Or should we make the conclusion that no one cares about compiling on
Amiga anymore?
You people out there with obsure ports, take contact with maintainers
and show your interest in keeping the port up to date.
Report bugs and problems!
We can't test those ports ourselves!
If you are quiet we will conclude that no one cares and we don't need to
support your ancient system anymore.
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.
Christer
I would very much like to play on OS/2. However there has been no
version since 2.9.1
Do you know why? No open-source or commerical compliers available for OS/2
anymore? Or is the problem with compiling for OS/2 caused by something else?
--
Christer Nyfalt
Julian Lighton
2005-10-20 19:50:06 UTC
Permalink
Post by Christer Nyfalt
Post by Jack Wise
Post by Christer Nyfalt
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.
I would very much like to play on OS/2. However there has been no
version since 2.9.1
Do you know why? No open-source or commerical compliers available for OS/2
anymore? Or is the problem with compiling for OS/2 caused by something else?
It's probably because whoever was doing the OS/2 compiles stopped
doing them.
--
Julian Lighton ***@fragment.com
/* You are not expected to understand this. */
Antony Sidwell
2005-10-19 22:03:46 UTC
Permalink
Post by Christer Nyfalt
Or should we make the conclusion that no one cares about compiling on
Amiga anymore?
You people out there with obsure ports, take contact with maintainers
and show your interest in keeping the port up to date.
Report bugs and problems!
We can't test those ports ourselves!
If you are quiet we will conclude that no one cares and we don't need to
support your ancient system anymore.
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.
I'd go off on a proper rant, but I should be in bed already, so I'll
just give you the outline and let you pad it out to a proper ranty
length and tone. :)

Firstly, RISC OS is a minority platform, but isn't strictly speaking
ancient. It's got new hardware being made and sold for it, and the
operating system is being maintained, with numerous OS updates this
year. I don't know if Amiga people would say the same, but that's as
maybe, because...

Secondly, RISC OS ports aren't played by many people (I suspect,
anyway), but they are active, reasonably well-supported, and I think I
do a good job of contacting authors with any problems I find when
compiling their code for my platform. I don't recall ever contacting
you about a variant, so I've either never compiled a variant you were
maintaining or didn't have a problem compiling it, I suppose.

I think I've updated about 11 ports at least once this year, and given
the vanishingly small amount of time I'm spending doing anything I want
to on the computer at the moment, that's quite a good record. It's only
made possible by the efforts of authors to code to the best of their
ability and to keep things portable as far as possible.

I hope people continue to make the effort to code portably, because it
simply makes better code than the approach of "It works on Linux and
Windows, therefore it's correct". Or the more sophisticated "It works
on Linux, Macs and Windows, therefore it's correct". :)
--
Antony Sidwell.
Christer Nyfalt
2005-10-20 00:49:13 UTC
Permalink
Post by Antony Sidwell
Post by Christer Nyfalt
Or should we make the conclusion that no one cares about compiling on
Amiga anymore?
You people out there with obsure ports, take contact with maintainers
and show your interest in keeping the port up to date.
Report bugs and problems!
We can't test those ports ourselves!
If you are quiet we will conclude that no one cares and we don't need to
support your ancient system anymore.
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.
I'd go off on a proper rant, but I should be in bed already, so I'll
just give you the outline and let you pad it out to a proper ranty
length and tone. :)
:)
Post by Antony Sidwell
Firstly, RISC OS is a minority platform, but isn't strictly speaking
ancient. It's got new hardware being made and sold for it, and the
operating system is being maintained, with numerous OS updates this
year. I don't know if Amiga people would say the same, but that's as
maybe, because...
Secondly, RISC OS ports aren't played by many people (I suspect,
anyway), but they are active, reasonably well-supported, and I think I
do a good job of contacting authors with any problems I find when
compiling their code for my platform. I don't recall ever contacting
you about a variant, so I've either never compiled a variant you were
maintaining or didn't have a problem compiling it, I suppose.
Well, I don't have my own variant, but I currently maintains and adapts
the Unix/Linux ports for Sangband. Sangband currently have two working
platforms, Windows and Linux/Unix, as far as I (and Leon) knows.
- If RISC OS works for Sangband, let us know that the RISCOS code is valueable.
And let Leon know that Sangband works for RISCOS!
- If it doesn't work and it's impossible make it work, let us known that we
don't need to take it into consideration any more.
- If it's possible to make it wor - well, are you up to the challenge?
Post by Antony Sidwell
I think I've updated about 11 ports at least once this year, and given
the vanishingly small amount of time I'm spending doing anything I want
to on the computer at the moment, that's quite a good record. It's only
made possible by the efforts of authors to code to the best of their
ability and to keep things portable as far as possible.
Do you have a working main-ros.c to share with Leon?

Just give us a status on Sangband and RISCOS, it's annoying to have
RISCOS - status unknown.
--
Christer Nyfalt
Antony Sidwell
2005-10-20 17:02:11 UTC
Permalink
Post by Christer Nyfalt
Sangband currently have two working
platforms, Windows and Linux/Unix, as far as I (and Leon) knows.
- If RISC OS works for Sangband, let us know that the RISCOS code is valueable.
And let Leon know that Sangband works for RISCOS!
- If it doesn't work and it's impossible make it work, let us known that we
don't need to take it into consideration any more.
- If it's possible to make it wor - well, are you up to the challenge?
Post by Antony Sidwell
I think I've updated about 11 ports at least once this year, and given
the vanishingly small amount of time I'm spending doing anything I want
to on the computer at the moment, that's quite a good record. It's only
made possible by the efforts of authors to code to the best of their
ability and to keep things portable as far as possible.
Do you have a working main-ros.c to share with Leon?
Just give us a status on Sangband and RISCOS, it's annoying to have
RISCOS - status unknown.
It doesn't work on RISC OS. I have said this here before, but Leon
probably wasn't around at the time, and anyway might not pay attention
to the RISC OS-y subthreads. However, the RISC OS code (i.e. the
main-acn.c or main-ros.c files) has already been removed from the
distribution, or had in the last one I downloaded, as they were known
not to work.

It is possible to make it work, I believe, because everything compiled
reasonably straightforwardly when I last looked into it. It just lacks
platform specifics. I'd certainly expect a port to be possible, because
there's no particular reason to stray from ANSI (or ISO, whatever) C
except in the frontends, and Leon knows what he's doing. :) What sort
of things are you thinking of when you say "...don't have to take it
into consideration any more", out of interest? Removal of all
platform-specific hooks such as for file and memory handling?

As for whether I intend to provide a port - no, I don't. The
introduction of "hot bigscreen" made it more trouble than it's worth for
me to make and support a port for this platform. It's complicated
enough keeping track of the minor differences over all the variants I
compile without worrying about the larger changes S requires, and at the
moment I have neither the time nor the inclination. The inclination
might come once 1.0.0 comes out, of course. That would seem the most
appropriate time to do a one-off port outside of my usual build system.

(Incidentally, if you're curious as to how many different things there
are to keep track of in the various variants,then
http://ajps.mine.nu/temp/Makefile.frag is the fragment of Makefile I use
for compiling NPP, a pretty straightforward recent variant. Each
variant has its own fragment with its own choice of flags).
--
Antony Sidwell.
Christer Nyfalt
2005-10-21 20:26:11 UTC
Permalink
Post by Antony Sidwell
Post by Christer Nyfalt
Sangband currently have two working
platforms, Windows and Linux/Unix, as far as I (and Leon) knows.
- If RISC OS works for Sangband, let us know that the RISCOS code is valueable.
And let Leon know that Sangband works for RISCOS!
- If it doesn't work and it's impossible make it work, let us known that we
don't need to take it into consideration any more.
- If it's possible to make it wor - well, are you up to the challenge?
Post by Antony Sidwell
I think I've updated about 11 ports at least once this year, and given
the vanishingly small amount of time I'm spending doing anything I want
to on the computer at the moment, that's quite a good record. It's only
made possible by the efforts of authors to code to the best of their
ability and to keep things portable as far as possible.
Do you have a working main-ros.c to share with Leon?
Just give us a status on Sangband and RISCOS, it's annoying to have
RISCOS - status unknown.
It doesn't work on RISC OS. I have said this here before, but Leon
probably wasn't around at the time, and anyway might not pay attention
to the RISC OS-y subthreads. However, the RISC OS code (i.e. the
main-acn.c or main-ros.c files) has already been removed from the
distribution, or had in the last one I downloaded, as they were known
not to work.
It is possible to make it work, I believe, because everything compiled
reasonably straightforwardly when I last looked into it. It just lacks
platform specifics. I'd certainly expect a port to be possible, because
there's no particular reason to stray from ANSI (or ISO, whatever) C
except in the frontends, and Leon knows what he's doing. :) What sort
of things are you thinking of when you say "...don't have to take it
into consideration any more", out of interest? Removal of all
platform-specific hooks such as for file and memory handling?
Well, mainly that there are (or was) several places where unused #ifdefs
clutter the code and making things harder to test and modify.
Things related to RISCOS aren't so bad anymore, fortunately, because I moved
the file handling functions from util.c to z-file.

About platform stuff, the ideal situation would be if all platform dependent
things was located in the main-xxx files and the ordinary *band files
was kept clean of non-include-guard ifdefs.

If something is broken and if the ones who might be interested
in using it doesn't care about fixing it, why should we who doesn't need
it care about support it?

We are at least not in a hurry to remove support for RISCOS, AMIGA or OS/2.
Non-Unix mainframe support is removed. I would rather remove NeXT support
because it has some very ugly hacks (fat binaries, non-standard C library
include names) that are getting on my nerves.
I haven't seen any main-xxx file for NeXT, does any exist?
Post by Antony Sidwell
As for whether I intend to provide a port - no, I don't. The
introduction of "hot bigscreen" made it more trouble than it's worth for
me to make and support a port for this platform. It's complicated
enough keeping track of the minor differences over all the variants I
compile without worrying about the larger changes S requires, and at the
moment I have neither the time nor the inclination. The inclination
might come once 1.0.0 comes out, of course. That would seem the most
appropriate time to do a one-off port outside of my usual build system.
Would a change to non-hot bigscreen help (50-rows only)?
(I'm assuming that hot means the use of dual fonts and ability to change
from 25 to 50 rows and back.)
Post by Antony Sidwell
(Incidentally, if you're curious as to how many different things there
are to keep track of in the various variants,then
http://ajps.mine.nu/temp/Makefile.frag is the fragment of Makefile I use
for compiling NPP, a pretty straightforward recent variant. Each
variant has its own fragment with its own choice of flags).
Looks nasty.
--
Christer Nyfalt
Antony Sidwell
2005-10-21 23:54:23 UTC
Permalink
[Sangband and making it work on RISC OS]
Post by Christer Nyfalt
Post by Antony Sidwell
It is possible to make it work, I believe, because everything compiled
reasonably straightforwardly when I last looked into it. It just lacks
platform specifics. I'd certainly expect a port to be possible, because
there's no particular reason to stray from ANSI (or ISO, whatever) C
except in the frontends, and Leon knows what he's doing. :) What sort
of things are you thinking of when you say "...don't have to take it
into consideration any more", out of interest? Removal of all
platform-specific hooks such as for file and memory handling?
Well, mainly that there are (or was) several places where unused #ifdefs
clutter the code and making things harder to test and modify.
Things related to RISCOS aren't so bad anymore, fortunately, because I moved
the file handling functions from util.c to z-file.
About platform stuff, the ideal situation would be if all platform dependent
things was located in the main-xxx files and the ordinary *band files
was kept clean of non-include-guard ifdefs.
Couldn't agree more, code which uses such things (the mess of checks for
whether to call stat() or not comes to mind in most variants) really
needs rewriting to shift the implementation details into main-xxx files.
My problem when maintaining ports of many variants is that changes that
aren't reflected in all variants makes it that much more trouble to keep
frontends up to date, but I think I covered that already.
Post by Christer Nyfalt
If something is broken and if the ones who might be interested
in using it doesn't care about fixing it, why should we who doesn't need
it care about support it?
We are at least not in a hurry to remove support for RISCOS, AMIGA or OS/2.
Non-Unix mainframe support is removed. I would rather remove NeXT support
because it has some very ugly hacks (fat binaries, non-standard C library
include names) that are getting on my nerves.
Well, yes, but that's a limited definition of "support" really. If I
don't send you fixes for stuff that breaks on my platform you can't make
the changes. I'm supporting the platform, you're being good enough to
incorporate that support back into the main trunk. :)

Removing support for a platform implied to me an effort to remove the
abstractions which currently make it possible to port it to all these
platforms, rather than removing stuff which shouldn't have been there
anyway. The idea isn't to code new assumptions into the game that you
know to be true on the two or three "supported" platforms, just that you
don't want to make life harder for somone who *is* compiling for another
platform by making them reimplement things which work now. Is that
about right?
Post by Christer Nyfalt
I haven't seen any main-xxx file for NeXT, does any exist?
I can't recall ever seeing one, no.
Post by Christer Nyfalt
Post by Antony Sidwell
As for whether I intend to provide a port - no, I don't. The
introduction of "hot bigscreen" made it more trouble than it's worth for
me to make and support a port for this platform. It's complicated
enough keeping track of the minor differences over all the variants I
compile without worrying about the larger changes S requires, and at the
moment I have neither the time nor the inclination. The inclination
might come once 1.0.0 comes out, of course. That would seem the most
appropriate time to do a one-off port outside of my usual build system.
Would a change to non-hot bigscreen help (50-rows only)?
(I'm assuming that hot means the use of dual fonts and ability to change
from 25 to 50 rows and back.)
It's Leon's term, not mine, and that's what I've taken it to mean. :)
Yes, it would be easier to implement it as a single-font, fixed-size
window, and that's where I thought I'd start if I ever got that far. If
it's a fixed size 80x50 window, I'd also have to check that there are
fonts which will still let the game play on smaller displays, and
make a few other changes, but it would be easier at least.
--
Antony Sidwell.
Christer Nyfalt
2005-10-23 18:40:34 UTC
Permalink
Post by Antony Sidwell
[Sangband and making it work on RISC OS]
Post by Christer Nyfalt
Post by Antony Sidwell
It is possible to make it work, I believe, because everything compiled
reasonably straightforwardly when I last looked into it. It just lacks
platform specifics. I'd certainly expect a port to be possible, because
there's no particular reason to stray from ANSI (or ISO, whatever) C
except in the frontends, and Leon knows what he's doing. :) What sort
of things are you thinking of when you say "...don't have to take it
into consideration any more", out of interest? Removal of all
platform-specific hooks such as for file and memory handling?
Well, mainly that there are (or was) several places where unused #ifdefs
clutter the code and making things harder to test and modify.
Things related to RISCOS aren't so bad anymore, fortunately, because I moved
the file handling functions from util.c to z-file.
About platform stuff, the ideal situation would be if all platform dependent
things was located in the main-xxx files and the ordinary *band files
was kept clean of non-include-guard ifdefs.
Couldn't agree more, code which uses such things (the mess of checks for
whether to call stat() or not comes to mind in most variants) really
needs rewriting to shift the implementation details into main-xxx files.
My problem when maintaining ports of many variants is that changes that
aren't reflected in all variants makes it that much more trouble to keep
frontends up to date, but I think I covered that already.
I considered using the main-gtk2 from ToME as the base GTK port for
Sangband, but the liberal use of ifdefs scared me away from it.

Is the following lines in externs.h really neccessary for the RISCOS port?
#ifdef RISCOS
/* main-ros.c */
extern char *riscosify_name(cptr path);
#endif /* RISCOS */

It seems to me that the function shouldn't be declared extern because
it isn't used by the main Sangband code.
Post by Antony Sidwell
Post by Christer Nyfalt
If something is broken and if the ones who might be interested
in using it doesn't care about fixing it, why should we who doesn't need
it care about support it?
We are at least not in a hurry to remove support for RISCOS, AMIGA or OS/2.
Non-Unix mainframe support is removed. I would rather remove NeXT support
because it has some very ugly hacks (fat binaries, non-standard C library
include names) that are getting on my nerves.
Well, yes, but that's a limited definition of "support" really. If I
don't send you fixes for stuff that breaks on my platform you can't make
the changes. I'm supporting the platform, you're being good enough to
incorporate that support back into the main trunk. :)
:)
Post by Antony Sidwell
Removing support for a platform implied to me an effort to remove the
abstractions which currently make it possible to port it to all these
platforms, rather than removing stuff which shouldn't have been there
anyway.
Like rewriting the way z-term works.
Post by Antony Sidwell
The idea isn't to code new assumptions into the game that you
know to be true on the two or three "supported" platforms, just that you
don't want to make life harder for somone who *is* compiling for another
platform by making them reimplement things which work now. Is that
about right?
Yes, we want to find out which ports that might become supported in the
future and which ones are lost cases that none care or compile for anymore.
This makes it easier to make decisions. We have considered getting a platform
independent port however, and have toyed around with GTK and SDL as candidates.
GTK was rejected because it requires quite sizeable libraries to be installed
to Windows.

AFAIK, the port status for Sangband is as follows:
- Windows, Linux and other POSIX.1 compatible Unixes -- supported.
- Mac -- files are in, but not actively supported(???)
- Acorn RISCOS -- not supported, but the relevant main files are
maintained and compiled for other variants.
- OS/2 & Amiga -- not supported, no one has compiled any *band for these
platforms in a long time, but there is player interest.
- The rest -- not supported, no interest, no support in any *band for a long
time.
Post by Antony Sidwell
Post by Christer Nyfalt
Post by Antony Sidwell
As for whether I intend to provide a port - no, I don't. The
introduction of "hot bigscreen" made it more trouble than it's worth for
me to make and support a port for this platform. It's complicated
enough keeping track of the minor differences over all the variants I
compile without worrying about the larger changes S requires, and at the
moment I have neither the time nor the inclination. The inclination
might come once 1.0.0 comes out, of course. That would seem the most
appropriate time to do a one-off port outside of my usual build system.
Would a change to non-hot bigscreen help (50-rows only)?
(I'm assuming that hot means the use of dual fonts and ability to change
from 25 to 50 rows and back.)
It's Leon's term, not mine, and that's what I've taken it to mean. :)
Yes, it would be easier to implement it as a single-font, fixed-size
window, and that's where I thought I'd start if I ever got that far. If
it's a fixed size 80x50 window, I'd also have to check that there are
fonts which will still let the game play on smaller displays, and
make a few other changes, but it would be easier at least.
I wonder if it's possible to code the port in a way that it just refuses to
change the number of rows in use.
I leave further discussion on this subject to you and Leon.
--
Christer Nyfalt
pete mack
2005-10-23 20:49:26 UTC
Permalink
Post by Christer Nyfalt
- Windows, Linux and other POSIX.1 compatible Unixes -- supported.
- Mac -- files are in, but not actively supported(???)
I don't know what 'active support' means. Sangband runs on OS X, or at
least it does on the version I installed some months back. (All it
takes to support OS X is copying the files, and a very few #ifdefs.
It's just BSD unix with some GUI bells and whistles.)
Joshua Rodman
2005-10-23 20:55:08 UTC
Permalink
Post by pete mack
Post by Christer Nyfalt
- Windows, Linux and other POSIX.1 compatible Unixes -- supported.
- Mac -- files are in, but not actively supported(???)
I don't know what 'active support' means. Sangband runs on OS X, or at
least it does on the version I installed some months back. (All it
takes to support OS X is copying the files, and a very few #ifdefs.
It's just BSD unix with some GUI bells and whistles.)
I suspect the old OS9 and earlier support is being fingered as not
supported. As a terminal app, it should pretty much work obviously as
a unix port.

I suspect an OSX "gui" along the lines of windows or Linux/X would be
nice, although I guess the X version probably works with a bit of
effort on the user's part.
--
Grim. Grom. Grümmer.
Julian Lighton
2005-10-23 23:08:15 UTC
Permalink
Post by Joshua Rodman
Post by pete mack
Post by Christer Nyfalt
- Windows, Linux and other POSIX.1 compatible Unixes -- supported.
- Mac -- files are in, but not actively supported(???)
I don't know what 'active support' means. Sangband runs on OS X, or at
least it does on the version I installed some months back. (All it
takes to support OS X is copying the files, and a very few #ifdefs.
It's just BSD unix with some GUI bells and whistles.)
I suspect the old OS9 and earlier support is being fingered as not
supported. As a terminal app, it should pretty much work obviously as
a unix port.
I suspect an OSX "gui" along the lines of windows or Linux/X would be
nice, although I guess the X version probably works with a bit of
effort on the user's part.
There are OS X-native gui versions of Sangband. (I've got 0.9.9b13
here.)
--
Julian Lighton ***@fragment.com
/* You are not expected to understand this. */
Antony Sidwell
2005-10-24 15:54:58 UTC
Permalink
Post by Christer Nyfalt
Post by Antony Sidwell
Post by Christer Nyfalt
Well, mainly that there are (or was) several places where unused #ifdefs
clutter the code and making things harder to test and modify.
Things related to RISCOS aren't so bad anymore, fortunately,
because I moved the file handling functions from util.c to z-file.
About platform stuff, the ideal situation would be if all platform
dependent things was located in the main-xxx files and the ordinary
*band files was kept clean of non-include-guard ifdefs.
Couldn't agree more, code which uses such things (the mess of checks for
whether to call stat() or not comes to mind in most variants) really
needs rewriting to shift the implementation details into main-xxx files.
My problem when maintaining ports of many variants is that changes that
aren't reflected in all variants makes it that much more trouble to keep
frontends up to date, but I think I covered that already.
I considered using the main-gtk2 from ToME as the base GTK port for
Sangband, but the liberal use of ifdefs scared me away from it.
Is the following lines in externs.h really neccessary for the RISCOS port?
#ifdef RISCOS
/* main-ros.c */
extern char *riscosify_name(cptr path);
#endif /* RISCOS */
It seems to me that the function shouldn't be declared extern because
it isn't used by the main Sangband code.
Is that in Sangband? It's in Vanilla (and possibly other Lua-using
variants, I can't remember), because filename translation is done in
script.c there instead of going through some sort of abstraction hook.
It was a quick-and-dirty fix which hasn't (yet) been cleaned up.
Sangband shouldn't need it in externs.h.

[snip]
Post by Christer Nyfalt
Post by Antony Sidwell
Post by Christer Nyfalt
Would a change to non-hot bigscreen help (50-rows only)?
(I'm assuming that hot means the use of dual fonts and ability to change
from 25 to 50 rows and back.)
It's Leon's term, not mine, and that's what I've taken it to mean. :)
Yes, it would be easier to implement it as a single-font, fixed-size
window, and that's where I thought I'd start if I ever got that far. If
it's a fixed size 80x50 window, I'd also have to check that there are
fonts which will still let the game play on smaller displays, and
make a few other changes, but it would be easier at least.
I wonder if it's possible to code the port in a way that it just refuses to
change the number of rows in use.
I leave further discussion on this subject to you and Leon.
I suspect it is, despite the "porting.txt" file saying you can't have a
fully functional port without switching. If I lie to the game and say
it's now a 25 row window and give it no reason to think differently
everything should work. You've talked me into changing my position from
"Maybe I'll have a go eventually." to "I will have a go eventually." :)
--
Antony Sidwell.
Julian Lighton
2005-10-22 19:18:12 UTC
Permalink
Post by Christer Nyfalt
I would rather remove NeXT support
because it has some very ugly hacks (fat binaries, non-standard C library
include names) that are getting on my nerves.
Don't be so quick to remove fat binary support. OS X needs it, and
given its ancestry, I'd expect it looks a lot like NeXT fat binaries.
--
Julian Lighton ***@fragment.com
/* You are not expected to understand this. */
Andrew Sidwell
2005-10-22 21:26:31 UTC
Permalink
In article ,
Post by Christer Nyfalt
I would rather remove NeXT support
because it has some very ugly hacks (fat binaries, non-standard C library
include names) that are getting on my nerves.
Don't be so quick to remove fat binary support. OS X needs it, and
given its ancestry, I'd expect it looks a lot like NeXT fat binaries.
The "fat binary" support for NeXT, as far as I can tell, is totally seperate to
that of any other platform. In V 3.0.6, it merely allows different lib/data/
directories to be used depending on what architecture the code is running on.
I'd say it's probably outdated, and it certainly seems to have nothing to do
with Mac OS.

Andrew Sidwell
--
We must aim for perfection, but settle for progress.
Julian Lighton
2005-10-23 00:12:44 UTC
Permalink
Post by Andrew Sidwell
Post by Julian Lighton
Post by Christer Nyfalt
I would rather remove NeXT support
because it has some very ugly hacks (fat binaries, non-standard C library
include names) that are getting on my nerves.
Don't be so quick to remove fat binary support. OS X needs it, and
given its ancestry, I'd expect it looks a lot like NeXT fat binaries.
The "fat binary" support for NeXT, as far as I can tell, is totally seperate to
that of any other platform. In V 3.0.6, it merely allows different lib/data/
directories to be used depending on what architecture the code is running on.
I'd say it's probably outdated, and it certainly seems to have nothing to do
with Mac OS.
OS X is going to fat binaries with the move to Intel processors.

This means the OS X versions will need to support separate data
directories for the two architectures.
--
Julian Lighton ***@fragment.com
/* You are not expected to understand this. */
Andrew Sidwell
2005-10-23 11:01:40 UTC
Permalink
Post by Julian Lighton
Post by Andrew Sidwell
The "fat binary" support for NeXT, as far as I can tell, is totally seperate to
that of any other platform. In V 3.0.6, it merely allows different lib/data/
directories to be used depending on what architecture the code is running on.
I'd say it's probably outdated, and it certainly seems to have nothing to do
with Mac OS.
OS X is going to fat binaries with the move to Intel processors.
This means the OS X versions will need to support separate data
directories for the two architectures.
I can't see why; if a user is using a x86 Mac, they're not ever going to need
the data files generated on a PPC Mac and vice versa. I can't see a situation
where you need two sets of data files: when you move architecture, then you
just delete the old data files and have them regenerated. I guess there might
be a case for it if you had Angband on a central server with assorted Mac
clients, but there was never anything of the kind for when you had "fat
binaries" containing both 68000 and PPC code.

Plus, the code as it stands now it a little icky and would want rewriting
anyway; it doesn't belong in init2.c (the only place it's ever
mentioned/used).

Andrew Sidwell
--
We must aim for perfection, but settle for progress.
Julian Lighton
2005-10-23 20:29:08 UTC
Permalink
Post by Andrew Sidwell
Post by Julian Lighton
Post by Andrew Sidwell
The "fat binary" support for NeXT, as far as I can tell, is
totally seperate to that of any other platform. In V 3.0.6, it
merely allows different lib/data/ directories to be used depending
on what architecture the code is running on. I'd say it's
probably outdated, and it certainly seems to have nothing to do
with Mac OS.
OS X is going to fat binaries with the move to Intel processors.
This means the OS X versions will need to support separate data
directories for the two architectures.
I can't see why; if a user is using a x86 Mac, they're not ever going to need
the data files generated on a PPC Mac and vice versa. I can't see a situation
where you need two sets of data files: when you move architecture, then you
just delete the old data files and have them regenerated. I guess there might
be a case for it if you had Angband on a central server with assorted Mac
clients, but there was never anything of the kind for when you had "fat
binaries" containing both 68000 and PPC code.
It's a far more likely setup on modern macs than it was back then.

There's also the possibility of carrying your Angband install around
on a portable drive between home and work/school/etc.
--
Julian Lighton ***@fragment.com
/* You are not expected to understand this. */
Andrew Sidwell
2005-10-23 22:20:37 UTC
Permalink
In article ,
Post by Andrew Sidwell
Post by Julian Lighton
OS X is going to fat binaries with the move to Intel processors.
This means the OS X versions will need to support separate data
directories for the two architectures.
I can't see why; if a user is using a x86 Mac, they're not ever going to need
the data files generated on a PPC Mac and vice versa. I can't see a situation
where you need two sets of data files: when you move architecture, then you
just delete the old data files and have them regenerated. I guess there might
be a case for it if you had Angband on a central server with assorted Mac
clients, but there was never anything of the kind for when you had "fat
binaries" containing both 68000 and PPC code.
It's a far more likely setup on modern macs than it was back then.
There's also the possibility of carrying your Angband install around
on a portable drive between home and work/school/etc.
In that case, it needs rewriting. I've put together a smallish patch, available
at http://entai.co.uk/projects/angband/fat-binary-support.v1.diff and appliable
to current Vanilla CVS. I might submit it to Robert if he's still accepting
patches (and it's not wrong). It's a tad hacky, but I think that's pretty much
unavoidable.

(I've noticed that most of the function I had to change in init2.c is full of
hacks - or at least suboptimal code - and still seems to support flat files on
VM/ESA, whatever that is. I thought support for that was dropped yonks ago.
Another thing is that I can't see how you could make any implementation of "fat
binary" without hackery.)

Andrew Sidwell
--
We must aim for perfection, but settle for progress.
Martin Bazley
2005-10-23 16:39:04 UTC
Permalink
On the fourth moon of the second planet of a dying star, Antony
Sidwell was seen to write...
The inclination might come once 1.0.0 comes out, of course. That
would seem the most appropriate time to do a one-off port outside of
my usual build system.
If I were you, I'd wait a while just in case some bugfixes come out.
It would be a huge waste of time porting 1.0.0 and then discovering it
contains a major bug that has just been fixed in a new release. And
version numbers ending in zeros are not renowned for their stability.
:->
--
- Martin Bazley - "Being me is a 24-hour job"
***@bazley.freeuk.com - Wimbledon, London, England
============== ARM 610 17MB RiscPC 600 ==============
================= RISC OS Rules OK! =================
Antony Sidwell
2005-10-24 16:17:14 UTC
Permalink
Post by Martin Bazley
On the fourth moon of the second planet of a dying star, Antony
Sidwell was seen to write...
The inclination might come once 1.0.0 comes out, of course. That
would seem the most appropriate time to do a one-off port outside of
my usual build system.
If I were you, I'd wait a while just in case some bugfixes come out.
It would be a huge waste of time porting 1.0.0 and then discovering it
contains a major bug that has just been fixed in a new release. And
version numbers ending in zeros are not renowned for their stability.
:->
Half a point. :) The fact that Sangband 0.9.9 has got up to beta 19 to
iron out bugs before version 1.0.0 comes out implies that Leon's quite
serious about making 1.0.0 a stable release. However, it would be more
sensible to port a beta before 1.0.0 so that if changes are required they
can be incorporated into the main trunk without damaging that stability.
--
Antony Sidwell.
Harriet Bazley
2005-10-23 03:22:16 UTC
Permalink
On 19 Oct 2005 as I do recall,
Post by Antony Sidwell
Post by Christer Nyfalt
Or should we make the conclusion that no one cares about compiling on
Amiga anymore?
You people out there with obsure ports, take contact with maintainers
and show your interest in keeping the port up to date.
Report bugs and problems!
We can't test those ports ourselves!
If you are quiet we will conclude that no one cares and we don't need to
support your ancient system anymore.
This especially concerns these systems: Amiga, Acorn Riscos,
NeXT, OS/2, VMS and VM.
[snip]
Post by Antony Sidwell
Secondly, RISC OS ports aren't played by many people (I suspect,
anyway), but they are active, reasonably well-supported, and I think I
do a good job of contacting authors with any problems I find when
compiling their code for my platform. I don't recall ever contacting
you about a variant, so I've either never compiled a variant you were
maintaining or didn't have a problem compiling it, I suppose.
I don't get this whole accented characters discussion anyway, Angband
ALREADY allows you to define terrain or monsters using all the
characters from 32 to 255 (at least under RISC OS it does). I used
that ages ago to make all the extra terrain features in Unangband
recognisable for a start. Right now I'm looking at the 'Interact with
visuals' screen and it says

Default attr/char = 15 / 43 << + >>
Current attr/char = 15 / 191 << ¿ >>
--
Harriet Bazley == Loyaulte me lie ==

Motorcar: a four-wheeled vehicle that runs up hills and down pedestrians
Matthias Kurzke
2005-10-15 20:00:12 UTC
Permalink
Post by Leon Marrick
Angband with an accent
displaying extended characters
For almost as long as Angband has been in existance, people have
wanted to display more than the basic ASCII set of 128 characters. If
the game can be made to display a full byte range of 256 characters,
then Tolkien names can be properly accented and special terrain can be
made to look more distinctive.
To make special terrain look more distinctive, the use of 256 characters
seems to be rather limited. Especially considering that we could just
use graphics for the terrain and letters for what moves on the terrain
(looks good, works nice, remember AngbandTK?)
Post by Leon Marrick
However, results have been decidedly mixed. Fangband introduced
accented artifact names long ago, but they only worked on IBM-PCs. The
objective of this essay is to see how we can reproduce Fangband's
success, and this time make it portable to multiple operating systems.
We discuss fonts first, because this is liable to be the hard
part. The text file and code changes ought not to make us sweat unduly;
they are treated afterwards. More details will be added as interested
people chip in; would you like to help make this happen?
Other people have argued for Unicode instead of 8-bit. I think I agree
with them, for two reasons: (1) the differences between 8-bit coding
systems are a pain and (2) the common characters in 8-bit will only give
us accents but not much more. Unfortunately Unicode lacks Elvish support
but still has some nice runes that could be used for scroll names etc.
Plus a really large set of symbols, including circled letters that could
be used for uniques or for stuff like temporary resistance display. (3)
I believe a change like this requires a lot of work, and using Unicode
will give a much better result with not much more work.

Matthias
Hugo Kornelis
2005-10-15 22:29:23 UTC
Permalink
Post by Leon Marrick
Angband with an accent
displaying extended characters
Hi Leon,

I'm very interested in this. Though not for the same reasons that you
have. As you know, I recently started making a new Angband variant.
Though the term "variant" might not be appropriate - it's actually a
translation. My kids are very interested whenever they see me play
Angband, but they can't read English, so they can only play when I'm
sitting next to them to translate all texts on the screen.

In order to enable them to play Angbend whenever they like, I'm trying
to translate Angband into Dutch. Unfortunately, the Dutch language
sometimes requires accented characters. That explains my interest in
this issue. But that also explains why I already ran some tests that you
might not yet have thought of. Details on these tests are further below.
First some comments on your post.
Post by Leon Marrick
An example of an edited
http://www.runegold.org/angband/pub/8x13x.fon
Thanks for that. I had already started adding accented characters to
8x13.fon after you posted a link to softy, but after downloading this
file, it looks like I can stop. At first glance, all accented letters I
need are already there.

(snip non-Windows ports, as I use solely Windows)
Post by Leon Marrick
# The Shadow Cloak of Luthien
N:49:of L^'uthien # see explanation below
Wouldn't it be easier to have the accented character in the .txt file?

N:49:of Lúthien

Would that fail due to incompatabilities between the character encodings
used on various systems that need to run Angband? Or would it be
possible to circumvene these differences by adding a platform-dependent
low-level custom file read function in main-xxx.c?

If it IS possible to get away with just popping the accented characters
in the .txt files, changing them would be a lot easier. This should of
course still be combined with character translation tables - if only for
removal of the accents on systems that can't show them.

If this is NOT possible, then a slightly easier version (to understand
while editing the .txt files - probably not easier to implement) is to
define all of ', ", ^ and ` as special characters, and have translation
rules such as this:
'e ==> é
`e ==> è
"e ==> ë
^e ==> ê
and the custom rule of doubling a character to get a single one:
'' ==> '
"" ==> "
etc.

(Boy, I do hope the lines above make it unhurt over the ancient 7-bit
Usenet ...)

On a side note: are you aware of any other characters that could be used
in the .txt files? Since Dutch pluralization rules are more complicated
than English, I had planned to use ^ in the .txt files to denote
irregular plural forms, but if your proposal to use ^ as a special
character for accented characters is incorporated into a future version
of Angband, I'd rather use a different character right from the of, to
save myself the choice of either losing compatibility or having to
change it later.


(snip excellent description of how to change and install custom fonts)
Post by Leon Marrick
Test #1: Look carefully at the screen. If the overall appearance of
the font has worsened or it just looksdull or "strange", then your font
is not recognized by the game. The most probable reasons are that your
font's header is different than the file name (before the .fon bit), or
you have two or more fonts saved in a common file.
Test #2: Command '%' - Interact with Visuals. Change the player icon
to your new edited character. If test #1 succeeds, then this test
probably will too. However, if you simply cannot see your edited
character, and you are certain you are using your new font, then restart
the game. If this doesn't work, reboot your machine.
If either test fails, try, try again. When both succeed, great!
These tests succeeded. Using the 8x13x.fon file you made available, I
was able to change myself from @ to é and back again (though I did note
that the change only took effect after I moved a step).

I then ran some other tests as well, since support for Dutch requires me
to be able to have accented characters in all texts. Since I'm unable to
properly explain the test results, I'll just describe what I did and
what the results were and leave it to you or others to figure out why
and what to do about it.

1. Opened \lib\file\news.txt in a text editor. Changed the name Robert
Ruehlmann to Robert Rühlmann (probably the official notation anyway) and
saved the file. When starting the game (with 8x13x.fon still the current
font), the last maintainer is now listed as Robert Rhlmann - that is,
the accented character is simply removed.

2. Opened cmd5.c and changed this line:
msg_print("Pray hard enough and your prayers may be answered.");
to
msg_print("Práy hârd ènöúgh and your prayers may be answered.");
Saved, compiled and ran. Opened a warrior's savefile and pressed the 'p'
key. Result: "Pr y h rd n gh and your prayers may be answered." That
is, the accented character is displayed as white space.

3. Opened \lib\edit\monster.txt and changed the wooden torch to:
N:346:& Wooden Törch~
Saved, restarted game and checked inventory and equipent. I was now
carrying some Wooden Trches. In this case, the accented character was
removed again.

My best guess is that issues #1 and #3 are related to the way Angband
reads data from files, and that the accented characters are lost
somewhere in the read routines. For issue #2, that can't be the case, as
the character is hardcoded in the C source. Here, the blanks in the
output show that the display routines will need tweaking as well.

At this point, the only place where I can get Angband to display
accented characters in on the map, by using the Interact with Visuals
menu.

Best, Hugo
--
Your sig line (k) was stolen! (more)
There is a puff of smoke!

(Remove NO and SPAM to get my e-mail address)
Joshua Rodman
2005-10-15 22:47:07 UTC
Permalink
Post by Hugo Kornelis
Post by Leon Marrick
# The Shadow Cloak of Luthien
N:49:of L^'uthien # see explanation below
Wouldn't it be easier to have the accented character in the .txt file?
N:49:of Lúthien
I don't like this solution, since ISO-8859-1 is being phased out, and
the tools that handle unicode are still being grown. If I open up this
file on old unix or riscos or something I will see nonsense.

So your choices for putting the text in directly are:

- UTF-8 and be damned with the older software and tools that don't know
how to handle this. Also there are trip-ups like the header and
encoding. IMHO, a pain.

- ISO-8859-1 and be damned with the platforms that don't use or predate
this also. In addition, this encoding is going to be steadily going
away, and also is not properly supported on some older platforms that
people actually run Angband on.

Moreover your stated goal is localization. Localization with
ISO-8859 is problematic. Eastern europe go to heck?

In short, I think ISO-8859 is a mistake because it will have to be
rewritten in the future at some point (maybe 5 years later?). UTF-8 is
probably a reasonable choice but will cause more platform compatability
problems right now.

So I think flat ascii for input to "developer" files is probably
acceptable as a least big evil.
Post by Hugo Kornelis
On a side note: are you aware of any other characters that could be used
in the .txt files? Since Dutch pluralization rules are more complicated
than English, I had planned to use ^ in the .txt files to denote
irregular plural forms, but if your proposal to use ^ as a special
character for accented characters is incorporated into a future version
of Angband, I'd rather use a different character right from the of, to
save myself the choice of either losing compatibility or having to
change it later.
I kind of like the "solution" for this problem another roguelike
mentioned: require explicit plural forms in all cases.
--
Grim. Grom. Grümmer.
Hugo Kornelis
2005-10-15 23:41:35 UTC
Permalink
Post by Joshua Rodman
Post by Hugo Kornelis
Post by Leon Marrick
# The Shadow Cloak of Luthien
N:49:of L^'uthien # see explanation below
Wouldn't it be easier to have the accented character in the .txt file?
N:49:of Lúthien
I don't like this solution, since ISO-8859-1 is being phased out, and
the tools that handle unicode are still being grown. If I open up this
file on old unix or riscos or something I will see nonsense.
(snip explanation)
Post by Joshua Rodman
So I think flat ascii for input to "developer" files is probably
acceptable as a least big evil.
Yeah, I'll guess we'll have tos ettle for that, then.
Post by Joshua Rodman
Post by Hugo Kornelis
Since Dutch pluralization rules are more complicated
than English, I had planned to use ^ in the .txt files to denote
irregular plural forms, but if your proposal to use ^ as a special
character for accented characters is incorporated into a future version
of Angband, I'd rather use a different character right from the of, to
save myself the choice of either losing compatibility or having to
change it later.
I kind of like the "solution" for this problem another roguelike
mentioned: require explicit plural forms in all cases.
Do you mean that all text were phrased so that they could always take a
plural form? Like for instance: "one of your arrows" instead of "one
arrow"? Or do you mean that all *.txt files had both singular and plural
form in it?

The latter is what I contemplated as well, but I eventually came up with
something that required much less change: the ^ character. They come in
triplets; everything between the first and the second ^ would be used
for the singular form and everytinh between second and third for the
plural. So let's say that I wanted to add "Dead Mouse" to the object
list, then I'd write it as

N:999:& Dead M^ous^ic^e
Post by Joshua Rodman
Moreover your stated goal is localization. Localization with
ISO-8859 is problematic. Eastern europe go to heck?
Actually, my stated goal is a Dutch translation. Everyone in Eastern
Europe -or everywhere else in the world- who reads Dutch can download
and play my version (if I ever finish it).
(And those who don't read Dutch are free to download and play as well,
though I doubt they'll have much fun from it <g>).

Best, Hugo
--
Your sig line (k) was stolen! (more)
There is a puff of smoke!

(Remove NO and SPAM to get my e-mail address)
Pav Lucistnik
2005-10-15 23:59:49 UTC
Permalink
Post by Hugo Kornelis
Post by Joshua Rodman
Since Dutch pluralization rules are more complicated than English, I
had planned to use ^ in the .txt files to denote irregular plural
forms, but if your proposal to use ^ as a special character for
accented characters is incorporated into a future version of Angband,
I'd rather use a different character right from the of, to save myself
the choice of either losing compatibility or having to change it later.
I kind of like the "solution" for this problem another roguelike
mentioned: require explicit plural forms in all cases.
Do you mean that all text were phrased so that they could always take a
plural form? Like for instance: "one of your arrows" instead of "one
arrow"? Or do you mean that all *.txt files had both singular and plural
form in it?
The latter is what I contemplated as well, but I eventually came up with
something that required much less change: the ^ character. They come in
triplets; everything between the first and the second ^ would be used for
the singular form and everytinh between second and third for the plural.
So let's say that I wanted to add "Dead Mouse" to the object list, then
I'd write it as
N:999:& Dead M^ous^ic^e
Note that this is good enough for English and Dutch, but other languages
use more than two forms (singular, plural) - for example Czech have four
different forms (0, 1, 2-4, 5+) ...

If anyone want to start a real translation efforts, he needs to get his
hands dirty with gettext, I'm afraid.
--
Pav Lucistnik <***@oook.cz>
<***@FreeBSD.org>
Christophe Cavalaria
2005-10-16 10:17:51 UTC
Permalink
Post by Joshua Rodman
Post by Hugo Kornelis
Post by Leon Marrick
# The Shadow Cloak of Luthien
N:49:of L^'uthien # see explanation below
Wouldn't it be easier to have the accented character in the .txt file?
N:49:of Lúthien
I don't like this solution, since ISO-8859-1 is being phased out, and
the tools that handle unicode are still being grown. If I open up this
file on old unix or riscos or something I will see nonsense.
- UTF-8 and be damned with the older software and tools that don't know
how to handle this. Also there are trip-ups like the header and
encoding. IMHO, a pain.
Oh please ! Do you know at all how does UTF-8 work ? We can have things like
that without any problems :

N:49:of Lúthien

And there won't be any problem. You don't need an UTF-8 aware editor to do
that as long as you don't want to change the UTF-8 part.

My bet would be to go for the full UTF-8 for all the .txt files and it won't
cause any problems. It's just that people with older software won't be able
to write non ASCII chars or they will have to copy/paste existing blocks.
Of course, people with older software has no cause to be writing non ASCII
chars in the edit files in the first place.

PS : Lúthien is the latin1 representation of Lúthien in UTF-8
Post by Joshua Rodman
- ISO-8859-1 and be damned with the platforms that don't use or predate
this also. In addition, this encoding is going to be steadily going
away, and also is not properly supported on some older platforms that
people actually run Angband on.
Moreover your stated goal is localization. Localization with
ISO-8859 is problematic. Eastern europe go to heck?
In short, I think ISO-8859 is a mistake because it will have to be
rewritten in the future at some point (maybe 5 years later?). UTF-8 is
probably a reasonable choice but will cause more platform compatability
problems right now.
There are as far as I know 15 different ISO-8859 encodings but I agree that
it is a bad idea to do it like that. UTF-8 is a much better choice. Even
Windows XP notepad understands it.
Post by Joshua Rodman
So I think flat ascii for input to "developer" files is probably
acceptable as a least big evil.
ASCII with a new custom multibyte encoding that no existing tool on the
earth understands isn't a good idea.
Post by Joshua Rodman
Post by Hugo Kornelis
On a side note: are you aware of any other characters that could be used
in the .txt files? Since Dutch pluralization rules are more complicated
than English, I had planned to use ^ in the .txt files to denote
irregular plural forms, but if your proposal to use ^ as a special
character for accented characters is incorporated into a future version
of Angband, I'd rather use a different character right from the of, to
save myself the choice of either losing compatibility or having to
change it later.
I kind of like the "solution" for this problem another roguelike
mentioned: require explicit plural forms in all cases.
Plural forms is a problem that is already soved with the GNU translation
libs. If you want to go for that route, it might be a good idea to make use
of that or to at least have a look at how it works.


Of course, there's also the problem of the place to put the translations.
Are we supposed to create copies of all the .txt files with translations ?
But then it'll be a pain to keep them in synch with the next angband
version.

It's better in my opinion to have a translation file for each non english
language, and that way, you can keep the standard .txt files as ASCII. The
problem is that some english is generated by the game and that one is a
pain to translate. Things like a -> an, plural rules coded in a .c file.
Joshua Rodman
2005-10-16 14:41:52 UTC
Permalink
Post by Christophe Cavalaria
Post by Joshua Rodman
- UTF-8 and be damned with the older software and tools that don't know
how to handle this. Also there are trip-ups like the header and
encoding. IMHO, a pain.
Oh please ! Do you know at all how does UTF-8 work ? We can have things like
N:49:of Lúthien
There are two problems

1) People who open the edit files now cannot read or create the text
unless they are using UTF-8 aware programs. There are many people
still using such programs, the world is not only windows notepad.

2) The UTF8 encoding flag at the front of the file will cause problems
in a number of areas.

Some editors do not think such files are text and produce errors.
Angband will need to handle the existence and possible changes in
this encoding flag (unless you plan to control what all the editors
of the world do). Angband will need to pull in code to detect the
flag and work appropriately, which is not a large amount of work,
but is not significantly less work than handling some escape
characters.

Alternatively you could get around some of these problems by
dictating that the files will be in a particlar UTF8 encoding with
or without the header flag. This will limit the number of text
editors which can successfully edit the info files. I am not a big
fan of this approach.
Post by Christophe Cavalaria
Post by Joshua Rodman
Moreover your stated goal is localization. Localization with
ISO-8859 is problematic. Eastern europe go to heck?
In short, I think ISO-8859 is a mistake because it will have to be
rewritten in the future at some point (maybe 5 years later?). UTF-8 is
probably a reasonable choice but will cause more platform compatability
problems right now.
There are as far as I know 15 different ISO-8859 encodings but I agree that
it is a bad idea to do it like that. UTF-8 is a much better choice. Even
Windows XP notepad understands it.
Yes, there are 15 different encodings (although meaningfully only around
8 or so): precisely the problem.
--
Grim. Grom. Grümmer.
Christophe Cavalaria
2005-10-16 15:13:56 UTC
Permalink
Post by Joshua Rodman
Post by Christophe Cavalaria
Post by Joshua Rodman
- UTF-8 and be damned with the older software and tools that don't know
how to handle this. Also there are trip-ups like the header and
encoding. IMHO, a pain.
Oh please ! Do you know at all how does UTF-8 work ? We can have things
N:49:of Lúthien
There are two problems
1) People who open the edit files now cannot read or create the text
unless they are using UTF-8 aware programs. There are many people
still using such programs, the world is not only windows notepad.
Then install a new text editor. It isn't like it will be difficult to find
one that works.
Post by Joshua Rodman
2) The UTF8 encoding flag at the front of the file will cause problems
in a number of areas.
That flag is optional and best left out I say.
Post by Joshua Rodman
Some editors do not think such files are text and produce errors.
Please, an UTF-8 text file cannot trigger such error in a text editor. Do
you know how UTF-8 is encoded ? It is a perfectly valid 8bit text file in
itself.
Post by Joshua Rodman
Angband will need to handle the existence and possible changes in
this encoding flag (unless you plan to control what all the editors
of the world do). Angband will need to pull in code to detect the
flag and work appropriately, which is not a large amount of work,
but is not significantly less work than handling some escape
characters.
Alternatively you could get around some of these problems by
dictating that the files will be in a particlar UTF8 encoding with
or without the header flag. This will limit the number of text
editors which can successfully edit the info files. I am not a big
fan of this approach.
Well that one is easy : ignore the 0xFF and 0xFE chars in the text file.
There is only one way to encode UTF-8 anyway.
Post by Joshua Rodman
Post by Christophe Cavalaria
Post by Joshua Rodman
Moreover your stated goal is localization. Localization with
ISO-8859 is problematic. Eastern europe go to heck?
In short, I think ISO-8859 is a mistake because it will have to be
rewritten in the future at some point (maybe 5 years later?). UTF-8 is
probably a reasonable choice but will cause more platform compatability
problems right now.
There are as far as I know 15 different ISO-8859 encodings but I agree
that it is a bad idea to do it like that. UTF-8 is a much better choice.
Even Windows XP notepad understands it.
Yes, there are 15 different encodings (although meaningfully only around
8 or so): precisely the problem.
That's why UTF-8 is a better choice : it won't change except when adding new
codepoints.
Hugo Kornelis
2005-10-16 14:57:54 UTC
Permalink
On Sun, 16 Oct 2005 12:17:51 +0200, Christophe Cavalaria wrote:

(snip)
Post by Christophe Cavalaria
Plural forms is a problem that is already soved with the GNU translation
libs. If you want to go for that route, it might be a good idea to make use
of that or to at least have a look at how it works.
Of course, there's also the problem of the place to put the translations.
Are we supposed to create copies of all the .txt files with translations ?
But then it'll be a pain to keep them in synch with the next angband
version.
It's better in my opinion to have a translation file for each non english
language, and that way, you can keep the standard .txt files as ASCII. The
problem is that some english is generated by the game and that one is a
pain to translate. Things like a -> an, plural rules coded in a .c file.
Hi Christophe,

I appreciate your comments on this. But just to make sure that nobody is
getting false expectation: there is not going to be a multi-lingual
Angband. At least not until someone decides to make it.

As far as I know, there has been a Russian version (by Alexander
Ulyanov), but it's not maintained anymore. No other translated versions
have ever been released.

There's also some fool who recently started to translate Angband to
Dutch (me, to be exact). I'm not sure if I'll ever finish that, and I'll
only release it if it's finished.

Translating to Dutch is quite enough work for one man. I'll leave the
creation of a multi-lingual Angband to someone with way more free time
on his hands than me. Which very probably means that there will never be
a true multi-lingual version.

Best, Hugo
--
Your sig line (k) was stolen! (more)
There is a puff of smoke!

(Remove NO and SPAM to get my e-mail address)
Alexander Ulyanov
2005-10-17 10:59:11 UTC
Permalink
Post by Hugo Kornelis
(snip)
Post by Christophe Cavalaria
Plural forms is a problem that is already soved with the GNU translation
libs. If you want to go for that route, it might be a good idea to make use
of that or to at least have a look at how it works.
Of course, there's also the problem of the place to put the translations.
Are we supposed to create copies of all the .txt files with translations ?
But then it'll be a pain to keep them in synch with the next angband
version.
It's better in my opinion to have a translation file for each non english
language, and that way, you can keep the standard .txt files as ASCII. The
problem is that some english is generated by the game and that one is a
pain to translate. Things like a -> an, plural rules coded in a .c file.
Hi Christophe,
I appreciate your comments on this. But just to make sure that nobody is
getting false expectation: there is not going to be a multi-lingual
Angband. At least not until someone decides to make it.
As far as I know, there has been a Russian version (by Alexander
Ulyanov), but it's not maintained anymore. No other translated versions
have ever been released.
Wow, someone still remembers that :-). (I gave up because of virtually
zero interest -- for some reason, Russian players seem to prefer ADoM
and NetHack over *bands. Actually Angband-R was not that hard to make;
it took only about a week of work, so I'm a bit surprised that nobody
attempted this for other languages.)

Personally, I don't think that multi-lingual Angband is even
theoretically feasible. GNU gettext is useless here. Angband has to
build lots of sentences dynamically. While in English only
singular/plural issue is important, in many languages (including Russian)
genders and other silly grammar stuff are needed too. I didn't just
translate lib/edit/*.txt files -- I had to make *lots* of ugly ad-hoc
changes to the code. This is acceptable for a version localised for
single language, or maybe for bilingual version (Hengband is English/
Japanese, IIRC). But true international version would be just impossible
to maintain.
Post by Hugo Kornelis
There's also some fool who recently started to translate Angband to
Dutch (me, to be exact). I'm not sure if I'll ever finish that, and I'll
only release it if it's finished.
Good luck to you!
--
Alexander Ulyanov -=- ***@earthsea.org
So this is how liberty dies. With cheering, and applause.
-- Senator Amidala, Star Wars Episode III
Julian Lighton
2005-10-18 02:53:50 UTC
Permalink
Post by Alexander Ulyanov
Personally, I don't think that multi-lingual Angband is even
theoretically feasible. GNU gettext is useless here.
There also might be license issues. (I know some GNU libraries are
GPL, instead of LGPL, which won't fly with Angband's license. Don't
know if gettext is one of them.)
Post by Alexander Ulyanov
Angband has to
build lots of sentences dynamically. While in English only
singular/plural issue is important, in many languages (including Russian)
genders and other silly grammar stuff are needed too. I didn't just
translate lib/edit/*.txt files -- I had to make *lots* of ugly ad-hoc
changes to the code. This is acceptable for a version localised for
single language, or maybe for bilingual version (Hengband is English/
Japanese, IIRC). But true international version would be just impossible
to maintain.
It might not be.

This is the sort of thing Lua would be useful for. Instead of building
the strings in the C code, you call out to a Lua function. Changing
the language becomes as easy as loading a differnt file of Lua
functions.
--
Julian Lighton ***@fragment.com
/* You are not expected to understand this. */
Christophe
2005-10-18 08:59:29 UTC
Permalink
Post by Julian Lighton
Post by Alexander Ulyanov
Personally, I don't think that multi-lingual Angband is even
theoretically feasible. GNU gettext is useless here.
There also might be license issues. (I know some GNU libraries are
GPL, instead of LGPL, which won't fly with Angband's license. Don't
know if gettext is one of them.)
There are more than one implementation of gettext. BSD has one, Python
has one etc... You could say that the tools and the api is the hardest
thing to do here.
Andrew Patrick Schoonmaker
2005-10-18 01:07:01 UTC
Permalink
Post by Hugo Kornelis
As far as I know, there has been a Russian version (by Alexander
Ulyanov), but it's not maintained anymore. No other translated versions
have ever been released.
There is/was a Japanese version of ZAngband, and at least one variant
(Heng was originally only Japanese, and I believe I recall seeing links
to at least one other Japanese-only Angband variant). I don't know if
Vanilla was ever translated.

-Andrew ()
KUSUNOSE Toru
2005-10-18 16:01:48 UTC
Permalink
Hi,
Post by Andrew Patrick Schoonmaker
There is/was a Japanese version of ZAngband, and at least one variant
(Heng was originally only Japanese, and I believe I recall seeing links
to at least one other Japanese-only Angband variant).
There are Japanse versions of Angband, ZAngband, Hengband, ToME,
OAngband, EyAngband, UnAngband, Gumband, CthAngband,
sCthAngband, Animeband and MAngband, according to
http://angband.xrea.jp/ .

There are two Japanese-only variants: TOband (based on Tactics Ogre) and
XAngband.
Post by Andrew Patrick Schoonmaker
I don't know if Vanilla was ever translated.
Actually, Vanilla is the first *band translated to Japanese,
first released in 1996. Every other Japanese versions of *band
are based on it.
--
KUSUNOSE Toru mailto:***@hcn.zaq.ne.jp
konijn_
2005-10-18 16:15:10 UTC
Permalink
Post by KUSUNOSE Toru
There are two Japanese-only variants: TOband (based on Tactics Ogre) and
XAngband.
Isnt XAngband the one with the soul stones ?
If so I played that one in English.
What happened to XAngband ?

T.
KUSUNOSE Toru
2005-10-18 17:19:01 UTC
Permalink
Hi,
Post by konijn_
Post by KUSUNOSE Toru
There are two Japanese-only variants: TOband (based on Tactics Ogre) and
XAngband.
Isnt XAngband the one with the soul stones ?
If so I played that one in English.
What happened to XAngband ?
Probaly what you are thinking is Xband by Chris Watkins.
It has soul gems.
http://pages.prodigy.net/xis/xband.htm
http://www.thangorodrim.net/xband.html
--
KUSUNOSE Toru mailto:***@hcn.zaq.ne.jp
konijn_
2005-10-18 17:47:24 UTC
Permalink
Thanks !
konijn_
2005-10-18 12:36:16 UTC
Permalink
Post by Hugo Kornelis
There's also some fool who recently started to translate Angband to
Dutch (me, to be exact). I'm not sure if I'll ever finish that, and I'll
only release it if it's finished.
Hey fool ;), how far along are you with this translation ?

Met vriendelijke groeten,
T.
Hugo Kornelis
2005-10-21 22:48:27 UTC
Permalink
Post by konijn_
Post by Hugo Kornelis
There's also some fool who recently started to translate Angband to
Dutch (me, to be exact). I'm not sure if I'll ever finish that, and I'll
only release it if it's finished.
Hey fool ;), how far along are you with this translation ?
Met vriendelijke groeten,
T.
Hoi T.

Almost done with the texts in the C code. But that still leaves most of
the work ahead of me: all the descriptive texts in the *.txt files.

And after that, lots of testing and checking to see if I got all
language-specific things such as plurals, possessive, present and past
tense, etc. correct. Care to be in my beta-test?

Groetjes, Hugo

(T. - sorry voor de dubbele ondertekening - ik kon geen manier vinden om
Agent bij dit ene bericht de ondertekening weg te laten)

(all: sorry for the Dutch above - rest assured, there's nothing rude in
it)

Best, Hugo
--
Your sig line (k) was stolen! (more)
There is a puff of smoke!

(Remove NO and SPAM to get my e-mail address)
Leon Marrick
2005-10-16 13:21:49 UTC
Permalink
Let's talk Unicode.

As I see it now - correct me, please, where you find errors - I
see the following advantages and disadvantages to Angband in adopting
some form of Unicode (UTF-8, 16, 32, etc.).


Advantages:
- It's a standard. Pretty well all modern systems understand it.

- There are lots of Unicode system fonts for some systems, especially
Linux and other graphical UNIXs.

- Many UNIX/Linux developers seem to greatly prefer it. Since
UNIX/Linux has the second-largest number of Angband players, this is
important.


Disadvantages:
- Angband doesn't understand Unicode. For it, characters are always
exactly one byte. Changing this systematically is, apparently, so much
work that I have heard of at least three aborted attempts to Unicode
Angband or one of its variants, of which that mentioned in connection
with ToME and NPPAngband is merely the most recent.

- Unicode is a standard. You can't have custom glyphs. Since I have a
lovely collection of customizable fonts in various shapes and sizes
right in front of me (I use Windows and DOS), going backwards like this
doesn't appeal at all. Limit Angband to fixed system fonts? Not a chance!

- Older systems don't understand Unicode. The whole point here is to
offer accents to those who can handle them without bothering those who
can't. Abandoning systems because they don't do variable-length or
32-bit characters just isn't the Angband way.



================================

Well, it's easy to criticize, how about an alternative?

An alternative is making a much more conservative jump from 7-bit
to 8-bit, opening up the range 128 - 255 as extended characters.
Although this range is very much smaller than that offered by Unicode,
Angband doesn't need much. All we really want is:

- Accented characters, those that Tolkien used.
- Accented characters, those most commonly used in major Western
European languages, to make some translations easier.
- Some optional pseudo-graphics for terrain ("look at the pretty
trees"). Some space for variant customization.


Instead of one big leap, this method allows up to make baby steps,
one port and system at a time. This is very appealing.




A closing statement:

A good programmer is lazy. Focused lazy. He uses the simplest
methods consistent with his goals, however vast and enterprising and
daring those goals might be.
The 256-character method is the lazy programmer's way of getting
Tolkien's accents and Angband custom glyphs in text mode.


Leon
Christophe Cavalaria
2005-10-16 13:53:57 UTC
Permalink
Post by Leon Marrick
Let's talk Unicode.
As I see it now - correct me, please, where you find errors - I
see the following advantages and disadvantages to Angband in adopting
some form of Unicode (UTF-8, 16, 32, etc.).
- It's a standard. Pretty well all modern systems understand it.
- There are lots of Unicode system fonts for some systems, especially
Linux and other graphical UNIXs.
- Many UNIX/Linux developers seem to greatly prefer it. Since
UNIX/Linux has the second-largest number of Angband players, this is
important.
Saying it like that feels has if only UNIX can make use of Unicode. All
platforms will benefit from it. And you forgot :
- lots of already existing code to work with
- lots of already existing standard tools like text editors etc ...
Post by Leon Marrick
- Angband doesn't understand Unicode. For it, characters are always
exactly one byte. Changing this systematically is, apparently, so much
work that I have heard of at least three aborted attempts to Unicode
Angband or one of its variants, of which that mentioned in connection
with ToME and NPPAngband is merely the most recent.
It's just a matter of changing 8bits char to 32bits char in all the source
code. It is some work but it can be done.
Post by Leon Marrick
- Unicode is a standard. You can't have custom glyphs. Since I have a
lovely collection of customizable fonts in various shapes and sizes
right in front of me (I use Windows and DOS), going backwards like this
doesn't appeal at all. Limit Angband to fixed system fonts? Not a chance!
Even if it is a standard, nothing prevents you from defining custom code
points. It is what has been done with the elvish runes. They are "assigned"
to the 0xE000 code plane which is a user defined plane.
Post by Leon Marrick
- Older systems don't understand Unicode. The whole point here is to
offer accents to those who can handle them without bothering those who
can't. Abandoning systems because they don't do variable-length or
32-bit characters just isn't the Angband way.
Please. Variable length strings is just a matter of a few functions and
don't tell me you've never defined int32 arrays in C.
Post by Leon Marrick
================================
Well, it's easy to criticize, how about an alternative?
An alternative is making a much more conservative jump from 7-bit
to 8-bit, opening up the range 128 - 255 as extended characters.
Although this range is very much smaller than that offered by Unicode,
Do you know what ? The Tengwar unofficial definition for Unicode takes
nearly 128 code points by itself and you still have Cirth which takes more
or less the same amount of code points. Providing support for those 2
character sets will require far more than the pitiful 128 extended
charaters available with the jump from 7 to 8 bits.
Post by Leon Marrick
- Accented characters, those that Tolkien used.
- Accented characters, those most commonly used in major Western
European languages, to make some translations easier.
- Some optional pseudo-graphics for terrain ("look at the pretty
trees"). Some space for variant customization.
Instead of one big leap, this method allows up to make baby steps,
one port and system at a time. This is very appealing.
A good programmer is lazy. Focused lazy. He uses the simplest
methods consistent with his goals, however vast and enterprising and
daring those goals might be.
The 256-character method is the lazy programmer's way of getting
Tolkien's accents and Angband custom glyphs in text mode.
A lazy programmer won't fall for the NIH syndrom. Make use of existing tech
instead of reiventing the wheel at each occasion.
Antony Sidwell
2005-10-16 13:58:53 UTC
Permalink
Post by Christophe Cavalaria
Post by Leon Marrick
An alternative is making a much more conservative jump from 7-bit
to 8-bit, opening up the range 128 - 255 as extended characters.
Although this range is very much smaller than that offered by Unicode,
Do you know what ? The Tengwar unofficial definition for Unicode takes
nearly 128 code points by itself and you still have Cirth which takes more
or less the same amount of code points. Providing support for those 2
character sets will require far more than the pitiful 128 extended
charaters available with the jump from 7 to 8 bits.
Post by Leon Marrick
- Accented characters, those that Tolkien used.
- Accented characters, those most commonly used in major Western
European languages, to make some translations easier.
- Some optional pseudo-graphics for terrain ("look at the pretty
trees"). Some space for variant customization.
I'd go along with Leon here, though, and say that I don't particularly
want the full Tengwar or Cirth character sets, so the fact we couldn't
fit them in 128 extra characters doesn't bother me at all.

Leon's list and aims seem pretty reasonable, in fact, and the aim of
keeping Angband backwards-compatible so that it can still be used where
the extra characters aren't available seems like a good one too, in
keeping with the usual inclusive approach of Angband.

I'd say that Unicode support, for all its plus points, isn't worth the
effort at the moment whereas expanding to 8 bit character sets where
supported probably is. Let Unicode wait until it's genuinely
all-pervasive rather than just possible to use, or until we want things
it can offer which can't be achieved more easily by other methods.
--
Antony Sidwell.
Christophe Cavalaria
2005-10-16 14:33:57 UTC
Permalink
Post by Antony Sidwell
Post by Christophe Cavalaria
Post by Leon Marrick
An alternative is making a much more conservative jump from 7-bit
to 8-bit, opening up the range 128 - 255 as extended characters.
Although this range is very much smaller than that offered by Unicode,
Do you know what ? The Tengwar unofficial definition for Unicode takes
nearly 128 code points by itself and you still have Cirth which takes
more or less the same amount of code points. Providing support for those
2 character sets will require far more than the pitiful 128 extended
charaters available with the jump from 7 to 8 bits.
Post by Leon Marrick
- Accented characters, those that Tolkien used.
- Accented characters, those most commonly used in major Western
European languages, to make some translations easier.
- Some optional pseudo-graphics for terrain ("look at the pretty
trees"). Some space for variant customization.
I'd go along with Leon here, though, and say that I don't particularly
want the full Tengwar or Cirth character sets, so the fact we couldn't
fit them in 128 extra characters doesn't bother me at all.
Leon's list and aims seem pretty reasonable, in fact, and the aim of
keeping Angband backwards-compatible so that it can still be used where
the extra characters aren't available seems like a good one too, in
keeping with the usual inclusive approach of Angband.
Backward compatible with what ? Among the various platforms which can run
Angband can you find me one which won't be able to use Unicode in one way
or another and won't be able to fall back on unaccentuated chars ?
Post by Antony Sidwell
I'd say that Unicode support, for all its plus points, isn't worth the
effort at the moment whereas expanding to 8 bit character sets where
supported probably is. Let Unicode wait until it's genuinely
all-pervasive rather than just possible to use, or until we want things
it can offer which can't be achieved more easily by other methods.
You mean, let's way until the 0.00001% of platforms that can't handle
Unicode at all die of a deserved death ?
pete mack
2005-10-16 15:20:43 UTC
Permalink
Post by Christophe Cavalaria
Post by Antony Sidwell
I'd say that Unicode support, for all its plus points, isn't worth the
effort at the moment whereas expanding to 8 bit character sets where
supported probably is. Let Unicode wait until it's genuinely
all-pervasive rather than just possible to use, or until we want things
it can offer which can't be achieved more easily by other methods.
You mean, let's way until the 0.00001% of platforms that can't handle
Unicode at all die of a deserved death ?
Well he does say 'at the moment'. Leon is a sufficiently competent
developer that he's unlikely just to replace char* with u_char* and
leave it at that. I say, go with an 8-bit encoding, and use a design
that is geared towards a more complete solution in the future.

Once Leon (or whoever) is done, perhaps someone with a passion for
unicode can do the next step.
Christophe Cavalaria
2005-10-16 16:24:10 UTC
Permalink
Post by pete mack
Post by Christophe Cavalaria
Post by Antony Sidwell
I'd say that Unicode support, for all its plus points, isn't worth the
effort at the moment whereas expanding to 8 bit character sets where
supported probably is. Let Unicode wait until it's genuinely
all-pervasive rather than just possible to use, or until we want things
it can offer which can't be achieved more easily by other methods.
You mean, let's way until the 0.00001% of platforms that can't handle
Unicode at all die of a deserved death ?
Well he does say 'at the moment'. Leon is a sufficiently competent
developer that he's unlikely just to replace char* with u_char* and
leave it at that. I say, go with an 8-bit encoding, and use a design
that is geared towards a more complete solution in the future.
Once Leon (or whoever) is done, perhaps someone with a passion for
unicode can do the next step.
And I say that going for an 8-bit enconding is just a complete waste of time
if you want to go for a more complete solution in the future.

The important things to decide are :
- what to display if the current system cannot display the extended chars
- how to handle the custom symbols in a portable way
Wil Hunt
2005-10-17 15:53:50 UTC
Permalink
Post by Christophe Cavalaria
And I say that going for an 8-bit enconding is just a complete waste of time
if you want to go for a more complete solution in the future.
- what to display if the current system cannot display the extended chars
- how to handle the custom symbols in a portable way
I'd have to disagree with you here. If the goal were to get a 32-bit
Unicode capable version out the door by next week, then I'd agree with you.

But at it stands, Unicode is a nice, but not necessary, goal toward
which we can move. In addition to providing a partial solution to the
problem sooner (and making quite a few people happy in the process),
moving from 7-bit to 8-bit encoding will provide whoever does it with
key insights as to what will be needed when we move to a 32-bit encoding
system such as Unicode.

That said, I'm very much looking forward to a Unicode version of
Angband. The idea of having artifacts and the like with their
descriptions in English as well as Elven runes is exciting to me. But
my ardor for such features does not preclude taking a baby step in the
right direction -- 8-bit accented characters.
--
Wil Hunt
Geek in training.
Jack of few trades, master of none.
Hugo Kornelis
2005-10-16 15:09:47 UTC
Permalink
(snip)
Post by Christophe Cavalaria
Post by Leon Marrick
Well, it's easy to criticize, how about an alternative?
An alternative is making a much more conservative jump from 7-bit
to 8-bit, opening up the range 128 - 255 as extended characters.
Although this range is very much smaller than that offered by Unicode,
Do you know what ? The Tengwar unofficial definition for Unicode takes
nearly 128 code points by itself and you still have Cirth which takes more
or less the same amount of code points. Providing support for those 2
character sets will require far more than the pitiful 128 extended
charaters available with the jump from 7 to 8 bits.
Hi Christophe,

Based on what I've read from Leon so far, he doesn't intend to include
Tengwar and Cirth in the game. He just wants to be able to use the same
accented characters that JRR Tolkien used to transcribe Elvish and
Dwarvish names in English. Sure, Lúthien is not the official spelling of
Lúthien - but it IS the official spelling in English texts, using a
transcription with letters from "our"" alphabet that are as close to the
original pronunciation as possible (just as Moscow isn't the official
spelling for Moscow - ask any Russian - but it IS the English spelling,
since most Americans neither read nor write the Cyrillic alphabet.

My personal wishlist would be:
- Support for accented characters in monster and artifact names, so that
the names can be written just as they are in Tolkien's books;
- Knowledge of what I have to do to get accented characters in messages
on the screen, so that I don't have to avoid Dutch words that need an
accent.

I don't need support for Elvish, Dwarven, Gnome, Orc or whatever other
languagges of Middle Earth. If that support was available in Angband as
an option, I'd switch it off. If it was impossible to switch off, I'd
have to find another game. I refuse to learn a language that is not even
spoken or written anywhere in our real world, just to be able to play a
game.

I do understand that those who already know these languages would love
to be able to use them in Angband. I wouldn't mind this support being
available as an option (that I'd leave off). But if I have to choose
between support for accented characters soon, or support for full
Unicode after a lot of time, I know what I'll pick!!

Best, Hugo
--
Your sig line (k) was stolen! (more)
There is a puff of smoke!

(Remove NO and SPAM to get my e-mail address)
Loading...