Okay playing latest unofficial beta version of Sang, problem is vista won't display walls in the extended fonts, or pure ascii. So I downloaded the wall fix from Nick's Oangband page and replaced the font file, I now have acii walls like they should be. The difference though is that using the extended fonts, the walls are bright white and the special graphics are displayed as acii characters, a boulder uses the # mark and so on. I am using pure acii because of this and looks really nice, except that breath, ball spell colors aren't displaying correctly. They are all showing as black, at least I can see it, except I wish the color was there, Is it possible to get a fix for vista users?
Sangband wall fix for windows vista
Collapse
X
-
Tags: None
-
Okay playing latest unofficial beta version of Sang, problem is vista won't display walls in the extended fonts, or pure ascii. So I downloaded the wall fix from Nick's Oangband page and replaced the font file, I now have acii walls like they should be. The difference though is that using the extended fonts, the walls are bright white and the special graphics are displayed as acii characters, a boulder uses the # mark and so on. I am using pure acii because of this and looks really nice, except that breath, ball spell colors aren't displaying correctly. They are all showing as black, at least I can see it, except I wish the color was there, Is it possible to get a fix for vista users?
CC"Been away so long I hardly knew the place, gee it's good to be back home" - The Beatles -
I have no experience whatsoever with fonts and how they work, but it seems that depending on the system, the fonts included in the lib/xtra/fonts folder can behave in a different way.
Maybe it has something to do with the way Windows handles Unicode or whatnot, but on standard Windows XP, the character list looks like this:
Then, after going to the regional settings and installing Asian language support, it changes into this:
Now that I'm on Vista. It looks almost the same as Windows XP with Asian language support. The only difference is that the character number 127 is also missing.
I even opened the fonts in a font-viewer. Vista simply doesn't see the changed characters. I believe there is some Microsoft magic going on in the background, but this seems as if Vista couldn't recognise the characters and substituted them with some default values.
Could anyone try to recreate the fonts with, I don't know, some different character codes or what not. I'm guessing each character has a "character code" which allows programs to guesstimate what character should be used when the explicit number was not provided. That code is somehow overlapping with established Unicode values and this confuses Windows.Last edited by Fuma; March 29, 2009, 09:19.www.snowleopard.org - International Snow Leopard TrustComment
-
Comment
-
I think that all of the font handling woes of recent years show that Angband really shouldn't be using Windows' own font-handling functions for what it does...takkaria whispers something about options. -more-Comment
-
I'm glad I was of use
I think that all of the font handling woes of recent years show that Angband really shouldn't be using Windows' own font-handling functions for what it does...www.snowleopard.org - International Snow Leopard TrustComment
-
It's certainly possible to emulate the behavior of the TextOut function using standard GDI calls that don't mess with fonts, just standard bitmap blitting. I don't know off the top of my head what the performance penalty would be.
Think I'll give it a try real quick... I'll post the results when I'm done.Comment
-
Ghetto 10MHz systems carved in rock with transistors welded by hand by the owner may have some performance issues.
Think I'll give it a try real quick... I'll post the results when I'm done.www.snowleopard.org - International Snow Leopard TrustComment
-
Just finished the test. I used a continuously-refreshing window to measure performance. The simulated console size was 80 x 50 characters, and the font size was 8 x 13. For each frame I filled the entire console with random characters and foreground colors.
Current Angband method - TextOut
The current method of drawing the console (for Windows) is to use the TextOut function. On my system this method gets about 260 fps.
Plain old bitmaps method
This method uses FillRect to fill the target area with the foreground color and then calls BitBlt to output the character(s) with the SRCAND raster operation, effectively drawing your tile/character in whatever foreground color you want. On my system this method gets about 104 fps.
So basically using plain bitmaps instead of TextOut is a little more than twice as slow. But, you don't have to put up with any Vista / XP font quirks, and it's fast enough for Angband. Really old systems will probably be using a much smaller console size anyway (80x25), and that would double the performance.
It should also be possible to extract appropriate bitmaps directly from the .FON files which are already distributed with Angband. I didn't do this for my test, though... I just used a custom bitmap with 8x13 tiles.Comment
-
An other alternative is to grab one of the dozen "font to bitmaps" programs floating around the 'net and use that to write a bmp/png in the same format as the tiles.
Integrating freetype so you can use any random ttf symbol font installed on the machine (Wingdings! Sauron as a frowny face!), is of course an exercise for the reader.Comment
-
My inclination is to ditch the .FON files entirely and switch to .BMP. They're just easier to work with, and users can then modify the fonts (if desired) using any standard paint program. Is there any reason why this is a bad idea?Comment
-
Comment
-
"Been away so long I hardly knew the place, gee it's good to be back home" - The BeatlesComment
-
Correct me if I'm wrong, but legacy terminals already don't use the .FON files. The only platform affected by this change would be the Win32 stuff which is already using GDI to display the terminal, and GDI has full support for these bitmap operations going all the way back to Windows 95.Comment
-
Correct me if I'm wrong, but legacy terminals already don't use the .FON files. The only platform affected by this change would be the Win32 stuff which is already using GDI to display the terminal, and GDI has full support for these bitmap operations going all the way back to Windows 95.takkaria whispers something about options. -more-Comment
Comment