Three possible contributions to text-mode Angband

Archived from groups: rec.games.roguelike.angband (More info?)

Hi folks, I have three potential contributions to make to the
Angband community. I'm querrying for interest in each to see
how much I should sweat to finish them and send patches.

Before I get into them, I should note that my main thrust is
to improve the text-mode experience. I have been playing the *bands
for 8 years now and thoroughly enjoy the concept of screaming when
running into a 'D' at character level 20. I wish to preserve this
experience, but enhance it with a few choice utilities and features.


Angband Glyph Editor
-------------------
A GTK program that allows one to assign new character glyphs and
colors to items, monsters and terrain features with ease. There is
a screenshot available, which probably explains better:

http://img237.exs.cx/my.php?loc=img237&image=angedit5qd.png

It will be released probably GPL so others can tack on more features,
such as a color editor (I might do that, it's easy), and so on.


GTK2 w/ Pango
-------------
I've fixed the gtk2 support in ToME and will backport it to Angband
in time. GTK is the Gimp Tool Kit used in GNOME, which is available
for Linux, Mac, Windows, and a variety of other systems.


Unicode Support
---------------
I believe that the richer Angband variants, such as ToME, are hurt
by the limited character set. It's painful when we have to reuse
characters to represent different classes of objects, such as '^'
for traps and mountains. I intend to fix that problem by adding
support for unicode. That way, we can represent trees with the spade
or club symbols, walls with the drawing blocks, and, best of all,
uniques with accented versions of their representative characters.
What's cooler than runing into a unique orc with an umlaut? Running
into new monster types represented by greek letters! The task of
re-assigning character glyphs will be made painless with the Angband
Glyph Editor.

I need a little input on how to achieve unicode support. There are
two main problems. The first one is that we will need to create,
modify or recommend a _scalable_ font set to distribute with the
game that has enough of the symbols we need. (I wasn't too happy
with the various bitmap fonts available, they are more graphical
than text-mode, not to mention unscalable.)

I've noticed that most truetype fonts define the accented extended
latin up to 0xFF and most define a few greek symbols, some math
symbols, and a few miscellaneous symbols. It would be most convenient
to create our own, but then aesthetic differences will probably arise.
Still, I recommend a font similar to the freely-available Bitstream
Vera Sans Mono. It is the best one I found after all these years. What
it lacks is a good chunk of symbols. There are also icky licensing
issues.

The other problem relates to the use of char in Angband to represent
internal items. On some machines, like mine, char is unsigned. When
file.c parses a preference file, it assings the long value to a char,
which ends up padding the left bits with 1's. Hence, setting a
permanent wall to the block glyph (UTF 0x2588) results in a char value
of 0xFFFF2588 instead of 0x2588, which makes handling unicode in the
main-xxx.c files impossible. The simplest hack will be to alter file.c
and use our own version of strtol(). I don't know what the
consequences of this method are for other features, such as graphics,
so I need some advice.

I'll be glad to hear any feedback. This is not my real name or email,
but you can reach me at fando.magnet at gmail com. Or just post in
this thread.

Cheers,
Fando
25 answers Last reply
More about three contributions text mode angband
  1. Archived from groups: rec.games.roguelike.angband (More info?)

    Hm, I seem to be confused how the char datatype encodes bits above
    0xFF. What I need is a way to store a simple UCS encoding, like 0x2588
    in the example, in a char. The char should be able to hold it, but I'm
    a little murky on how. Any C gurus have any pointers?
  2. Archived from groups: rec.games.roguelike.angband (More info?)

    Nevermind, char can't hold enough info. I'll have to find another way,
    possibly by turning all occurances of x_char into an unsigned int. That
    bites too deeply into angband though...
  3. Archived from groups: rec.games.roguelike.angband (More info?)

    Isn't the glyph editor just a standalone GUI of the % function
    (interact with visuals)? I can't see any additional functionality -
    though that's not to say it wouldn't be welcomed, of course.

    As Paul says, I'd stick with Latin-1 rather than go to unicode.

    CC
  4. Archived from groups: rec.games.roguelike.angband (More info?)

    "fando" <fando.magnet@gmail.com> wrote:
    >Hm, I seem to be confused how the char datatype encodes bits above
    >0xFF. What I need is a way to store a simple UCS encoding, like 0x2588
    >in the example, in a char. The char should be able to hold it, but I'm
    >a little murky on how. Any C gurus have any pointers?

    The type 'char' is exactly one byte long i.e. eight bits. There is
    absolutely no way to portably store any value larger than 255 in an
    unsigned char.

    You need to read up on things like "wide characters" and "multi-byte"
    characters, and I suggest you take your question to
    rec.games.roguelike.development or some similar, more appropriate forum.
    --
    Martin Read - my opinions are my own. share them if you wish.
    My roguelike games page (including my BSD-licenced roguelike) can be found at:
    http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
  5. Archived from groups: rec.games.roguelike.angband (More info?)

    In article <1111566189.941752.51010@z14g2000cwz.googlegroups.com>, fando wrote:
    > Unicode Support
    > ---------------
    > I believe that the richer Angband variants, such as ToME, are hurt
    > by the limited character set. It's painful when we have to reuse
    > characters to represent different classes of objects, such as '^'
    > for traps and mountains. I intend to fix that problem by adding
    > support for unicode. That way, we can represent trees with the spade
    > or club symbols, walls with the drawing blocks, and, best of all,
    > uniques with accented versions of their representative characters.
    > What's cooler than runing into a unique orc with an umlaut? Running
    > into new monster types represented by greek letters! The task of
    > re-assigning character glyphs will be made painless with the Angband
    > Glyph Editor.

    You could achieve much the same result with less pain by sticking with
    latin-1 rather than unicode. You still get a reasonable amount of accents,
    without having to go beyond 8 bits.
  6. Archived from groups: rec.games.roguelike.angband (More info?)

    Yeah, I was confused by the size of the char. Anyway, I don't see how
    unicode can be supported without rehauling the way angband stores
    characters. I'll take this to developers. Thanks!


    magnate wrote:
    > Isn't the glyph editor just a standalone GUI of the % function
    > (interact with visuals)? I can't see any additional functionality -
    > though that's not to say it wouldn't be welcomed, of course.

    Yes, but it's a crucial app for unicode support. You wouldn't want to
    page manually through thousands of characters just to find the right
    glyph. :)
  7. Archived from groups: rec.games.roguelike.angband (More info?)

    It was easier than I thought. Here's a screenshot showing ToME running
    with unicode support with GTK2.

    http://log4r.sourceforge.net/images/uniangband.png

    The clubs, triangles and solid blocks were all specified in the prf
    file with their standard unicode id's. The prf file was created by my
    glyph editor. Kind of neat, huh? :-)

    For the programmers, it involves replacing most instances of char with
    a new type, u16b which I typedefed to uchr. It worked transparently.
  8. Archived from groups: rec.games.roguelike.angband (More info?)

    Good show. I have one additional recommendation: The trouble isn't
    the char vs unicode per se, the trouble is angband uses old-fashioned
    type system.

    Recommended practice is to use additional typedefs for distinct logical
    classes.

    so

    // glyph represents symbol drawn on screen. '@'.
    typedef u16b glyph ;

    // char_t represents a character in a string.
    // Angband is not unicode, much less internationalized.
    // Doing this requires hack in (r)ecall function.
    typedef char_t char;
  9. Archived from groups: rec.games.roguelike.angband (More info?)

    fando wrote:
    > It was easier than I thought. Here's a screenshot showing ToME
    running
    > with unicode support with GTK2.
    >
    > http://log4r.sourceforge.net/images/uniangband.png
    >
    > The clubs, triangles and solid blocks were all specified in the prf
    > file with their standard unicode id's. The prf file was created by my
    > glyph editor. Kind of neat, huh? :-)
    >
    This is beautiful! I would love to see this incorporated into the
    standard sources. ToME, alone of variants, I usually play with tiles,
    just because I feel I lose so much of the richness of its world when
    its viewed through the severely limited ASCII set. I would play
    Unicode ToME in a heartbeat!

    One question: are these changes specific to GTK-2, or could they be
    integrated into any of the ASCII interfaces easily enough (for
    instance, Mac OSX)?

    Looking forward to seeing more of this! - Robert.
  10. Archived from groups: rec.games.roguelike.angband (More info?)

    fando wrote:
    > Yes, it would be better to make the glyphs orthogonal to the
    > 'character class' of the object. That way orcs and orc uniques
    > can have different glyphs (variants of 'o' with accents) and still
    > all be recalled using 'o'. This would mean treating x_char as a
    > unique ID for a class of object rather than the character to display.
    > But it looks like this is going to require more change than my current
    > hack, which was mostly a search-and-replace deal.

    Easiest might be to implement it by using tiles -- add unicode as a tile
    set, and special case it to display unicode symbols rather than actual
    graphical tiles.

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  11. Archived from groups: rec.games.roguelike.angband (More info?)

    Christophe Cavalaria wrote:
    > As far as I know, Unicode is 32bit, not 16bit. With that, you only
    get a
    > very small subset of the Unicode range.

    Right, but at the moment, support up to 0xFFFF, 16 bits, is sufficient.
    The symbol block is around 0x2500 and fantasy scripts go in 0xE000. It
    will be trivial to extend it, but without fonts universally supporting
    characters above 0xFFFF, I don't see the need yet.

    Fando
  12. Archived from groups: rec.games.roguelike.angband (More info?)

    Robert Goulding wrote:
    > This is beautiful! I would love to see this incorporated into the
    > standard sources. ToME, alone of variants, I usually play with
    tiles,
    > just because I feel I lose so much of the richness of its world when
    > its viewed through the severely limited ASCII set. I would play
    > Unicode ToME in a heartbeat!

    That's the idea. When I first started playing ToME, I had difficulty
    getting used to the use of '^' as mountains and the reuse of '#' for
    every kind of terrain feature. I feel graphical tiles are overkill, we
    just need a few extra symbols to make a text-mode, feature-rich band
    enjoyable.

    > One question: are these changes specific to GTK-2, or could they be
    > integrated into any of the ASCII interfaces easily enough (for
    > instance, Mac OSX)?

    Any system that can show unicode will be able to handle this. All that
    needs to be tweaked are the main-xxx.c files for each platform,
    provided that this support is merged into the main tree of your
    favorite variant. I work on linux, and unfortunately my Windows HD
    crashed so I'm limited to GTK/X11. :(

    > Looking forward to seeing more of this! - Robert.

    I'm going off on tangets (cirth names for unidentified objects), but
    I'll keep the list updated about my experiments. :)

    Fando
  13. Archived from groups: rec.games.roguelike.angband (More info?)

    Twisted One wrote:

    > Easiest might be to implement it by using tiles -- add unicode as a
    tile
    > set, and special case it to display unicode symbols rather than
    actual
    > graphical tiles.

    Hm, that's an interesting idea. I haven't inspected the graphics system
    too closely, but what I understand is that the tiles are also limited
    to 256 items. Also, they are referenced by x_char, which isn't
    orthogonal at all. Each item needs a brand new field to allow
    many-to-one mappings of glyphs/tiles to character ID. This means new
    parsing code in file.c, new conditions in z-term.c, etc. It seems like
    a lot of extra work, but it's the right way to go if Angband is to be
    more extensible.

    On the other hand, my search-and-replace char with u16b hack opens up
    the possibility of using 65535 tiles too, not just unicode support. And
    this hack works transparently with current graphics code; nothing
    breaks. It's a hacky hack that just works. :-)

    It's wise to inspect all approaches. I'm going to see how much work
    it'll be to separate the model from the view with respect to Angband
    objects.

    - Fando
  14. Archived from groups: rec.games.roguelike.angband (More info?)

    fando wrote:

    > It was easier than I thought. Here's a screenshot showing ToME running
    > with unicode support with GTK2.
    >
    > http://log4r.sourceforge.net/images/uniangband.png
    >
    > The clubs, triangles and solid blocks were all specified in the prf
    > file with their standard unicode id's. The prf file was created by my
    > glyph editor. Kind of neat, huh? :-)
    >
    > For the programmers, it involves replacing most instances of char with
    > a new type, u16b which I typedefed to uchr. It worked transparently.
    As far as I know, Unicode is 32bit, not 16bit. With that, you only get a
    very small subset of the Unicode range.
  15. Archived from groups: rec.games.roguelike.angband (More info?)

    On Thu, 24 Mar 2005 23:47:29 +0100, Christophe Cavalaria wrote:

    > As far as I know, Unicode is 32bit, not 16bit. With that, you only get a
    > very small subset of the Unicode range.

    Effectively, the current Unicode standard is 21 bit, containing 16 bit
    'planes' - the first of those ("basic multilingual plane")
    describes more than 65000 characters - shouldn't that be enough?

    --
    Christopher
  16. Archived from groups: rec.games.roguelike.angband (More info?)

    Christopher Koppler wrote:

    > On Thu, 24 Mar 2005 23:47:29 +0100, Christophe Cavalaria wrote:
    >
    >
    >>As far as I know, Unicode is 32bit, not 16bit. With that, you only get a
    >>very small subset of the Unicode range.
    >
    >
    > Effectively, the current Unicode standard is 21 bit, containing 16 bit
    > 'planes' - the first of those ("basic multilingual plane")
    > describes more than 65000 characters - shouldn't that be enough?

    It is enouth until you need access to one of the other planes. For
    example, Ghotic chars aren't available like that :)

    With such big change, it would be a good idea to do it right the first
    time. It's not like it'll eat up a lot of memory.
  17. Archived from groups: rec.games.roguelike.angband (More info?)

    Christophe wrote:
    >
    > With such big change, it would be a good idea to do it right the
    first
    > time. It's not like it'll eat up a lot of memory.

    Yeah, it doesn't look like it matters. Systems that want to display
    unicode are already very buff resource-wise. Here's my current approach
    to this hack:

    // h-types.c
    #ifdef SUPPORT_MORE_VISUALS
    typedef uchr u32b; // or u16b
    #else
    typedef uchr char;
    #endif

    Then we replace instances of char with uchr where it matters, such as
    x_char and term_win. I added a uchr_ary_to_utf8_str method to util.c to
    help convert a uchr array to a UTF-8 encoded string:

    /*
    * Accepts a uchr array, the length of the array and a buffer to
    * write the UTF-8 string to. The buffer must be at least 3*length+1
    * (for 16 bit). Returns the number of bytes written (pass it to
    * text_hook in place of length)
    */
    int uchr_ary_to_utf8_str(uchr *a, int length, char *s);

    The reason it's SUPPORT_MORE_VISUALS is because it allows not just more
    characters, but graphical tiles also. But I'm still playing with the
    semantics, so I'd welcome any suggestions. (Currently I'm using ochr
    instead of uchr. It looks ugly though.)

    There is not much extra work for main-xxx.c. The arguments to text_hook
    now accept a uchr pointer instead of a character pointer. It is up to
    the text_hook methods to decide how to display this data. Those that
    can't use SUPPORT_MORE_VISUALS won't have to bother with anything
    because the input will effectively be a char pointer.

    As for making recall work with this system, I figure we can rely on
    d_char, the default character to display, as the character class
    identifier. All that needs to be done is ensure recall goes by d_char
    instead of x_char.

    I got vanilla angband to work with this system, it's just a matter of
    time before I have a patch ready for testing. :)

    Cheers,
    Leon
  18. Archived from groups: rec.games.roguelike.angband (More info?)

    "fando" <fando.magnet@gmail.com> wrote in message
    news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
    > Christophe wrote:
    > >
    > > With such big change, it would be a good idea to do it right the
    > first
    > > time. It's not like it'll eat up a lot of memory.
    >
    > Yeah, it doesn't look like it matters. Systems that want to display
    > unicode are already very buff resource-wise. Here's my current approach
    > to this hack:
    >
    > // h-types.c
    > #ifdef SUPPORT_MORE_VISUALS
    > typedef uchr u32b; // or u16b
    > #else
    > typedef uchr char;
    > #endif
    >
    > Then we replace instances of char with uchr where it matters, such as
    > x_char and term_win. I added a uchr_ary_to_utf8_str method to util.c to
    > help convert a uchr array to a UTF-8 encoded string:
    >
    > /*
    > * Accepts a uchr array, the length of the array and a buffer to
    > * write the UTF-8 string to. The buffer must be at least 3*length+1
    > * (for 16 bit). Returns the number of bytes written (pass it to
    > * text_hook in place of length)
    > */
    > int uchr_ary_to_utf8_str(uchr *a, int length, char *s);
    >
    > The reason it's SUPPORT_MORE_VISUALS is because it allows not just more
    > characters, but graphical tiles also. But I'm still playing with the
    > semantics, so I'd welcome any suggestions. (Currently I'm using ochr
    > instead of uchr. It looks ugly though.)
    >
    > There is not much extra work for main-xxx.c. The arguments to text_hook
    > now accept a uchr pointer instead of a character pointer. It is up to
    > the text_hook methods to decide how to display this data. Those that
    > can't use SUPPORT_MORE_VISUALS won't have to bother with anything
    > because the input will effectively be a char pointer.
    >
    > As for making recall work with this system, I figure we can rely on
    > d_char, the default character to display, as the character class
    > identifier. All that needs to be done is ensure recall goes by d_char
    > instead of x_char.
    >
    > I got vanilla angband to work with this system, it's just a matter of
    > time before I have a patch ready for testing. :)
    >
    > Cheers,
    > Leon
    >
  19. Archived from groups: rec.games.roguelike.angband (More info?)

    "Jeff Greene" <nppangband@spam.spam.spam.spam,> wrote in message
    news:SIednVGq18Bxx9jfRVn-qw@comcast.com...
    >
    > "fando" <fando.magnet@gmail.com> wrote in message
    > news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
    > > Christophe wrote:

    My apologies for that previous post that added nothing. Just a stray
    mouseclick that happened to be on "send messag".

    > >
    > > I got vanilla angband to work with this system, it's just a matter of
    > > time before I have a patch ready for testing. :)
    > >
    Personally, I will add this to NPP when it is ready. I have been reading
    this post, but I have to admit I don't quite understand the mechanics on how
    it works, but I still won't hesistate to use it.

    -Jeff
  20. Archived from groups: rec.games.roguelike.angband (More info?)

    In article <pYmdnf4HxpglxtjfRVn-hQ@comcast.com>,
    "Jeff Greene" <nppangband@spam.spam.spam.spam,> wrote:

    > "Jeff Greene" <nppangband@spam.spam.spam.spam,> wrote in message
    > news:SIednVGq18Bxx9jfRVn-qw@comcast.com...
    > >
    > > "fando" <fando.magnet@gmail.com> wrote in message
    > > news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
    > > > Christophe wrote:
    >
    > My apologies for that previous post that added nothing. Just a stray
    > mouseclick that happened to be on "send messag".
    >
    > > >
    > > > I got vanilla angband to work with this system, it's just a matter of
    > > > time before I have a patch ready for testing. :)
    > > >
    > Personally, I will add this to NPP when it is ready. I have been reading
    > this post, but I have to admit I don't quite understand the mechanics on how
    > it works, but I still won't hesistate to use it.

    Not to start another off topic flamewar, but rgr dgr that!

    > -Jeff
    -Campbell
  21. Archived from groups: rec.games.roguelike.angband (More info?)

    Jeff Greene wrote:
    > "fando" <fando.magnet@gmail.com> wrote in message
    > news:1111816524.377956.313050@f14g2000cwb.googlegroups.com...
    >
    >>Christophe wrote:
    >>
    >>>With such big change, it would be a good idea to do it right the
    >>
    >>first
    >>
    >>>time. It's not like it'll eat up a lot of memory.
    >>
    >>Yeah, it doesn't look like it matters. Systems that want to display
    >>unicode are already very buff resource-wise. Here's my current approach
    >>to this hack:
    >>
    >>// h-types.c
    >>#ifdef SUPPORT_MORE_VISUALS
    >>typedef uchr u32b; // or u16b
    >>#else
    >>typedef uchr char;
    >>#endif
    >>
    >>Then we replace instances of char with uchr where it matters, such as
    >>x_char and term_win. I added a uchr_ary_to_utf8_str method to util.c to
    >>help convert a uchr array to a UTF-8 encoded string:
    >>
    >>/*
    >> * Accepts a uchr array, the length of the array and a buffer to
    >> * write the UTF-8 string to. The buffer must be at least 3*length+1
    >> * (for 16 bit). Returns the number of bytes written (pass it to
    >> * text_hook in place of length)
    >> */
    >>int uchr_ary_to_utf8_str(uchr *a, int length, char *s);
    >>
    >>The reason it's SUPPORT_MORE_VISUALS is because it allows not just more
    >>characters, but graphical tiles also. But I'm still playing with the
    >>semantics, so I'd welcome any suggestions. (Currently I'm using ochr
    >>instead of uchr. It looks ugly though.)
    >>
    >>There is not much extra work for main-xxx.c. The arguments to text_hook
    >>now accept a uchr pointer instead of a character pointer. It is up to
    >>the text_hook methods to decide how to display this data. Those that
    >>can't use SUPPORT_MORE_VISUALS won't have to bother with anything
    >>because the input will effectively be a char pointer.
    >>
    >>As for making recall work with this system, I figure we can rely on
    >>d_char, the default character to display, as the character class
    >>identifier. All that needs to be done is ensure recall goes by d_char
    >>instead of x_char.
    >>
    >>I got vanilla angband to work with this system, it's just a matter of
    >>time before I have a patch ready for testing. :)
    >>
    >>Cheers,
    >>Leon
    >>
    >
    >
    >

    Uh ... where's the original text? All I see is fando's post quoted, plus
    the attribution and headers ... not even a sig.

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  22. Archived from groups: rec.games.roguelike.angband (More info?)

    Here are a few more screenshots.

    1. http://log4r.sourceforge.net/images/unitome2.png

    This is a good example of how unicode enhances text-mode. The spades
    are "small trees" which can be walked over and the bright green clubs
    are "trees" which can't (well not yet). Terrain is much more
    distinguishable this way. The infinity sign is a void jumpgate. :)

    2. http://log4r.sourceforge.net/images/unitome3.png

    I hacked in some Quenya to replace the unknown scroll names. It's just
    random gibberish and I think Cirth would look better. It could be
    enabled if a user has the right font, which we could supply with the
    game. I merged two fonts together to get this result: Bitstream Vera
    Sans Mono and one of the free Quenya fonts.

    3. http://log4r.sourceforge.net/images/angedit1.png

    Buggy screenshot of my glyph editor, used to set the above glyphs.

    Does anyone want to take a shot at creating a good monospace Cirth font
    that would render well? I can make the font if someone supplies
    Scalable Vector Graphics of them. For reference, you could grab,

    http://www.evertype.com/standards/iso10646/pdf/cirth.pdf

    and screencap the runes, then outline them in inkscape or something.
    I've done the first column, but I'm no artist and it's too much extra
    work. :(

    Imagine the startup screen in Angband lined with Cirth like in the LotR
    books.

    Cheers,
    Leon Torres (my real name)
  23. Archived from groups: rec.games.roguelike.angband (More info?)

    fando wrote:
    > Here are a few more screenshots.
    >
    > 1. http://log4r.sourceforge.net/images/unitome2.png
    >
    > This is a good example of how unicode enhances text-mode. The spades
    > are "small trees" which can be walked over and the bright green clubs
    > are "trees" which can't (well not yet). Terrain is much more
    > distinguishable this way. The infinity sign is a void jumpgate. :)
    >
    > 2. http://log4r.sourceforge.net/images/unitome3.png
    >
    > I hacked in some Quenya to replace the unknown scroll names. It's just
    > random gibberish and I think Cirth would look better. It could be
    > enabled if a user has the right font, which we could supply with the
    > game. I merged two fonts together to get this result: Bitstream Vera
    > Sans Mono and one of the free Quenya fonts.
    >
    > 3. http://log4r.sourceforge.net/images/angedit1.png
    >
    > Buggy screenshot of my glyph editor, used to set the above glyphs.
    >
    > Does anyone want to take a shot at creating a good monospace Cirth font
    > that would render well? I can make the font if someone supplies
    > Scalable Vector Graphics of them. For reference, you could grab,
    >
    > http://www.evertype.com/standards/iso10646/pdf/cirth.pdf
    >
    > and screencap the runes, then outline them in inkscape or something.
    > I've done the first column, but I'm no artist and it's too much extra
    > work. :(
    >
    > Imagine the startup screen in Angband lined with Cirth like in the LotR
    > books.
    >
    > Cheers,
    > Leon Torres (my real name)
    >

    That looks awesome! Especially the new scroll names. Nice work man. :)
    And as far as Quenya vs. Cirth... I think either one will work. In
    fact... is there any reason not to use both?
  24. Archived from groups: rec.games.roguelike.angband (More info?)

    BarlowBrad wrote:
    >
    > That looks awesome! Especially the new scroll names. Nice work man.
    :)
    > And as far as Quenya vs. Cirth... I think either one will work. In
    > fact... is there any reason not to use both?

    The quick and dirty answer: No reason at all.

    But the long answer is more interesting,

    Players will want to use different fonts, and not all of them will have
    the desired support for Cirth and Quenya. In fact, I don't think any
    popular monospace fonts do. What you saw in the screenshot was
    something I glued together as a quick and akward hack. I don't even
    like that font, it's too narrow for my tastes. :(

    Font coverage is the biggest issue with unicode support in any
    application. A font that doesn't support Japanese will be useless to
    the Japanese. Likewise, one that doesn't have the symbols we need won't
    be useful to us. We are only beginning to see unicode adopted as an
    industry-wide standard, so we will either have to wait for someone to
    create a monospace Quenya/Cirth font with the desired drawing symbols
    or we do it ourselves. We have the advantage of actually having a need
    to implement this, so we can become a principle driver for the
    ConScript fantasy/sci-fi standard. All we have to do is create the
    fonts and distribute it to players.

    In fact, some dorks in the Linux community have already made the
    Klingon block of unicode pseudo-official by providing font maps for it
    that come with Linux. (Check out Documentation/unicode.txt in recent
    linux kernel sources and http://www.kli.org/). If you fire up fontforge
    under linux, you'll see the Klingon block represented.

    We should do the same for Cirth and Quenya. :)

    Again, for reference, check out the ConScript unicode registry:
    http://www.evertype.com/standards/csur/

    - Fando
  25. Archived from groups: rec.games.roguelike.angband (More info?)

    Just a quick note for anyone using the linux terminal to play angbands.
    Recent Kernels (2.6.x) come with a 'Linux Console' terminal that
    already supports unicode. That's the terminal you get when you press
    CTRL-ALT-1. Not only that, but the main font distributed with it has
    enough drawing blocks and symbols to be useful. Unfortunately, it uses
    ncurses, and only the latest ncurses (version 5) has wide character
    support. There's also an issue with transition from a limit of 512
    characters to full coverage. I'm trying to hack a solution right now.

    Finding out how to set the console font was hard because the
    documentation is sparse. I'll put some resources here for future
    reference:

    o http://linuxgazette.net/issue91/loozzr.html
    o http://www.inp.nsk.su/~bolkhov/files/fonts/univga/index.html
    o Search online with terms: unicode_start linux console

    - Leon
Ask a new question

Read More

Video Games