I’m running the latest DDA experimentals (curses-build) on a Linux i686 machine. The game runs fine in a terminal-emulator running atop X but when I try to run in the virtual-console the interface gets all strange with weird glyphs instead of the lined-drawing characters and the game goes all laggy and strange when I view the map, to the point that it becomes unplayable.
I know that the virtual-terminal isn’t able to display UTF-8 glyphs and that’s why Nethack with DECgraphics option shows strange characters while using the IBMgraphics option corrects the problem. Unfortunately DDA comes with no such option.
Is there any way I can run DDA in a virtual-terminal without actually changing anything on my system? Can’t I can configure the game to use this:
|---------|
|..Stuff..|
|---------|
instead of this:
┌────────┐
│..Stuff.│
│..Stuff.│
└────────┘
Or perhaps some other solution (such as the IBMgraphics option in Nethack)??
I found a nifty piece of software called fbgrab (http://fbgrab.monells.se/) which allows me to take the screenshot of a linux-framebuffer, including all the ttys connected to the machine.
So anyways I was able to take a screenshot of what I’m experiencing here and hopefully can make you guys understand the problem better:
As you can see, the display is distorted with wierd glyphs all over the place, making it impossible to play the game. I don’t really like living in the virtual-terminal but it runs much faster than my X-desktop with makes playing cataclysm a lot less laggy.
It isn’t really possible to translate those glyphs at the moment. DDA uses UTF-8 internally, so we’d need something like a table for replacement or even a layer of abstraction taking character names and outputting glyphs.
Aren’t there X-less framebuffer virtual terminals? I recall there being a middle ground between pure kernel console and full X mode.
I just use Wineskin to run CDDA on my mac. It basically turns the program into an app. I am actually running the Launcher, which runs the game nowadays for easier updates, but the launcher doesn’t seem to update itself nearly as well. But it makes play real easy, and I’ve never had a “me” specific problem since I did so.
Would it be possible to use a terminal that actually supports UTF-8?
There are many teminals easy to setup this way, from xterm (uxterm) to rxvt (urxvt) to xfce-term, gnome-term, terminator etc.
Even if you got no admin rights, maybe you could try getting the VT binary & use it from somewhere in your home folder?
I was able to figure out how to run dda in a virtual-console with UTF-8 mode enabled. Turns out I just had to “start” unicode-support of my console but it isn’t an easy process so most distros provide ready-to-use scripts for this purpose, mine had one called “unicode_start” and “unicode_end” for ending it.
Code
#!/bin/sh
# 0. Check whether we're on a console
TTY="`/usr/bin/tty`"
case "$TTY" in
/dev/console|/dev/vc*|/dev/tty[0-9]*)
;;
*)
echo "unicode_start skipped on $TTY" >&2
exit 0
;;
esac
# Enables Unicode processing in the current console.
#
if [ ! -e /proc/self/fd/0 ] ; then
echo "Won't set unicode mode: Can't determine console type;" >&2
echo " Please ensure that /proc is mounted." >&2
exit 1
fi
readlink /proc/self/fd/0 | grep -q -e /dev/vc -e '/dev/tty[^p]' -e /dev/console
if [ $? -eq 1 ]; then
echo "Won't set unicode mode: not a VT." >&2
exit 1
fi
# 1. The input side: the keyboard driver.
# Set the keyboard driver in Unicode mode. (Default is ASCII mode.)
# This really does nothing with the way normal keys are handled in
# the kernel. All it does is:
# - It is necessary for `dumpkeys' in order to not drop U+XXXX
# entries from the keymaps.
# - It is necessary for `loadkeys' in order to avoid warnings.
# - Unicode characters typed as Alt-x1 ... Alt-xn (where x1,...,xn
# are digits on the numeric keypad) will be emitted in UTF-8.
kbd_mode -u
# Change the keyboard mapping in such a way that the non-ASCII keys
# produce UTF-8 encoded multibyte sequences, instead of single bytes
# >= 0x80 in a legacy 8-bit encoding.
# Non-root users are allowed to change the unicode mode of their console, but
# not the global keymap. root will have to load the keymap in unicode mode
# explicitly.
uid="`id -u 2>/dev/null`" ||:
if [ "$uid" = '0' ]; then
# There is no way of reverting the effect of "dumpkeys | loadkeys --unicode",
# the memory of the earlier keymap is lost. Therefore, try
# to save a copy of the original keymap to be able to reload it in unicode_stop.
# (see also http://mail.nl.linux.org/linux-utf8/2003-08/msg00053.html):
[ -n "$HOME" -a "$HOME" != '/' ] ||
HOME='/root'
if [ -d "$HOME" -a -w "$HOME" ]; then
[ -d "$HOME/.kbd" ] ||
mkdir -- "$HOME/.kbd"
[ ! -w "$HOME/.kbd" ] ||
dumpkeys > "$HOME/.kbd/.keymap_sv"
fi
# redirect stderr and stdout of loadkeys to /dev/null to avoid the confusing
# "plus before udiaeresis ignored" warnings.
dumpkeys | loadkeys --unicode > /dev/null 2>&1
fi
# 2. The output side: the console screen.
# Tell the console output driver that the bytes arriving are UTF-8
# encoded multibyte sequences.
if [ -t 1 -a -t 2 ]; then
printf '\033%%G'
fi
stty iutf8
# Tell the graphics card how to display Unicode characters not
# contained in the IBM 437 character set (on PCs). The font should
# have a Unicode map attached, or explicitly specified, e.g.,
# by giving `def.uni' as a second argument.
case "$#" in
2)
setfont "$1" -u "$2"
;;
1)
setfont "$1"
;;
0)
;;
*)
echo "usage: unicode_start [font [unicode map]]"
;;
esac
Would it be possible to use a terminal that actually supports UTF-8?
There are many teminals easy to setup this way, from xterm (uxterm) to rxvt (urxvt) to xfce-term, gnome-term, terminator etc.
Even if you got no admin rights, maybe you could try getting the VT binary & use it from somewhere in your home folder?
No, when you don’t have an X desktop installed (which is the case for most server machines) or is unavailable then a terminal is all you have. Besides, if you’re on a different machine you can only use xterm and changing the font or font-size of an xterm is a real pain. Virtual consoles are great tools and (on my machine) dda doesn’t really lag much as it does when I run it from gnome-terminal in fullscreen.
