Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[DopeGhoti]

Sounds like you-re running on a terminal that doesn't support Unicode characters.  I'm still looking for a way to support that without running an X server. :-/

[Meteorswarm]

The sizing issue in ncurses fixed itself, but when I try to play it in gnome-terminal, xterm or non-graphical console, any of the "special" characters get expanded to something ugly and long, which screws up the alignment of, well, everything.

I'm not 100% certain of this in the case of DF, but I'm incredibly familiar with ncurses + terminals + locale + character encoding on *IX machines.  The *IX build of DF appears to use ncursesw, which is ncurses but with "wide character support", meaning it supports the use of Unicode (specifically UTF-8).  "Wide character support" translates to two (or more!) bytes being used to define a character.  Look up "UTF-16" on Wikipedia for example.

You should check to see what your character set is both in your shell (under gnome-terminal, xterm, rxvt, Konsole, etc.) by using the "locale" command.  Provide the output here and we can probably help you more.  You should also check what kind of character encoding the terminal emulator is set up for; some may default to UTF-8, others may default to iso-8859-1.  You'll need to find the correct one that works with DF (Baughn can probably state which its been tested on).

Locale yields:
name@kongming:~/Desktop/df_linux$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


on all 3 systems I tested it on.  What other things should I check?  I've never had a problem with characters before - even Chinese characters will display properly on my terminals with no deviations from the defaults.

[CobaltKobold]

Suggestion: use 4x4 font. Embark just about anywhere, at least 5x5. Use super-size-'iew (200-250²).

Compare to 80x24(5?) size.

OK, finally tried running base d19.

Code: [Select]

/df_linuxd19$ ./df
./dwarfort.exe: error while loading shared libraries: libSDL_image-1.2.so.0: cannot open shared object file: No such file or directory
Including when [PRINT_MODE:TEXT].

[koitsu]

Can you check what gnome-terminal, xterm, etc. are set up to use for character set encoding?

For gnome-terminal: you'll need to check the Configuration Editor section of the utility to determine what your character encoding/decoding is within the terminal emulator itself (this and what your locale is set to need to match, specifically UTF-8).  I see mention on ubuntuforums.org of something called "Multi-Gnome-Terminal" which fixed wide character support for others.  Relevant links which you'll have fun reading:

http://ubuntuforums.org/showthread.php?t=119520
http://ubuntuforums.org/showthread.php?t=274209
http://www.umiacs.umd.edu/~aelkiss/xml/displaylinux.html
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/89524
http://www.gentoo.org/doc/en/utf-8.xml  (this is for Gentoo, but it'll teach you about character encodings and UTF-8)

For rxvt: you'll have to see if Utuntu offers a build/package called rxvt-unicode, which is (obviously) rxvt which supports UTF-8.  http://software.schmorp.de/pkg/rxvt-unicode.html

For xterm, you'll have to see if Ubuntu offers a build/package which supports wide characters (UTF-8), otherwise you'll have to build it yourself: http://www.cl.cam.ac.uk/~mgk25/unicode.html#getxterm

Welcome to UNIX.  ;-)

[Meteorswarm]

OK, finally tried running base d19.

Code: [Select]

/df_linuxd19$ ./df
./dwarfort.exe: error while loading shared libraries: libSDL_image-1.2.so.0: cannot open shared object file: No such file or directory
Including when [PRINT_MODE:TEXT].

You need to install those libraries; if you're running ubuntu they're in the repositories:
libsdl-image1.2

You'll need another one I think.  Just aptitude search for the first part of its name and look for it.

Can you check what gnome-terminal, xterm, etc. are set up to use for character set encoding?

For gnome-terminal: you'll need to check the Configuration Editor section of the utility to determine what your character encoding/decoding is within the terminal emulator itself (this and what your locale is set to need to match, specifically UTF-8).  I see mention on ubuntuforums.org of something called "Multi-Gnome-Terminal" which fixed wide character support for others.

For rxvt: you'll have to see if Utuntu offers a build/package called rxvt-unicode, which is (obviously) rxvt which supports UTF-8.  http://software.schmorp.de/pkg/rxvt-unicode.html

For xterm, you'll have to see if Ubuntu offers a build/package which supports wide characters (UTF-8), otherwise you'll have to build it yourself: http://www.cl.cam.ac.uk/~mgk25/unicode.html#getxterm

Welcome to UNIX.  ;-)

gnome-terminal is definitely using UTF-8.  It's set that way in gconf-editor and locale confirms it.  I don't really care about xterm or no-x-terminal (what do you call it?) other than that they were reasonable things to crosscheck.  I also know that some special characters (like the block used in the borders) works in other programs, like vim (split the screen vertically and you get them).

For playing DF on my eeepc, the text mode is fantastically fast - a fortress that just embarked with 7 dwarves runs at 13-17 in graphics mode and in the 60s in text mode, so I'd love if this worked.

[dooots]

Would it possible to add a test mode that just randomly changes x-y number of tiles or even every tile every frame? This would be just to test the speed of the new graphics code as I don't see any way to get a fort that would test it.  You wouldn't be able to compare it to 40D but at least it gives a way to see if the graphics code is running at an acceptable speed.

[Toady One]

Baughn is unable to reach the forum right now, but we have this which hopefully helps with some of the windows graphics issues:

http://bay12games.com/dwarves/df_28_181_40d19_2_win.zip

Regarding the earlier arguments, please try to keep it civil.  Baughn is volunteering his time, has skills I don't have and doesn't deserve what he's been catching in here.

[bombcar]

As to the UTF-8 issues; search recent threads. There have been a number of different fixes offered; some involving the locale; some ncurses itself. The fact that you see the ~ indicates it might be a ncurses problem.

Thanks Toady and Baughn! Tonight is 50" DF night!

[The-Moon]

Baughn is unable to reach the forum right now, but we have this which hopefully helps with some of the windows graphics issues:

http://bay12games.com/dwarves/df_28_181_40d19_2_win.zip

Regarding the earlier arguments, please try to keep it civil.  Baughn is volunteering his time, has skills I don't have and doesn't deserve what he's been catching in here.

Im sorry toady my fault.

[Diablous]

Baughn is unable to reach the forum right now, but we have this which hopefully helps with some of the windows graphics issues:

http://bay12games.com/dwarves/df_28_181_40d19_2_win.zip

Regarding the earlier arguments, please try to keep it civil.  Baughn is volunteering his time, has skills I don't have and doesn't deserve what he's been catching in here.

Sweet. Thanks Toady!

[CobaltKobold]

Would it possible to add a test mode that just randomly changes x-y number of tiles or even every tile every frame? This would be just to test the speed of the new graphics code as I don't see any way to get a fort that would test it.  You wouldn't be able to compare it to 40D but at least it gives a way to see if the graphics code is running at an acceptable speed.

Battle Champs was something like that but more organized, I think.

[bombcar]

In theory we could do something with a fortress that is designed to collapse on load; count the FPS as it crumbles to it's end.

[isitanos]

Would it possible to add a test mode that just randomly changes x-y number of tiles or even every tile every frame? This would be just to test the speed of the new graphics code as I don't see any way to get a fort that would test it.  You wouldn't be able to compare it to 40D but at least it gives a way to see if the graphics code is running at an acceptable speed.

Good idea. This test could even be programmed to automatically dump the FPS results in a text file, to weed out any "human subjectivity".
Of course general tests such as just trying to play the game are still necessary, otherwise we won't end with a very playable df.

[shadow_slicer]

gnome-terminal is definitely using UTF-8.  It's set that way in gconf-editor and locale confirms it.  I don't really care about xterm or no-x-terminal (what do you call it?) other than that they were reasonable things to crosscheck.  I also know that some special characters (like the block used in the borders) works in other programs, like vim (split the screen vertically and you get them).

For playing DF on my eeepc, the text mode is fantastically fast - a fortress that just embarked with 7 dwarves runs at 13-17 in graphics mode and in the 60s in text mode, so I'd love if this worked.

What version of what distro are you using? Perhaps we can try to find where the difference is. It works on my system and I'm using Ubuntu 9.10 (x64) with the en_US.UTF-8 locale. I think I'm using gnome-terminal version 2.28.1 with 'Monospace' as the font and bash 4.0.

Also, are you running df within another program such as screen? (Admittedly it works both with and without screen on my system)
Have you tried rxvt-unicode?

[darkedone02]

hey toady, since you did the direct x10 shader mode, are you also working for those that have the latest direct x11?