Page 1 of 8
[DoomCRAP] ZDoom Font Generator
Posted: Sat Oct 20, 2007 10:36 pm
by bagheadspidey
Notice:
this tool is now part of
DoomCrap.
__________________________________
This tool is designed to work together with imagetool (and, optionally, image editing software of your choice) to create font lumps.
-- UPDATES --
Last version: 0.2.7
* Major bug fixes
* Project home page updated somewhat
link -
http://doomfontgen.sf.net/ (old, please use DoomCrap link above)
-- OLD STUFF --
Last version: 0.2.6
* Conversion tools
* Documentation
* Bug fixes
Old version: 0.2.5
* Imagetool support!
* More crap I'm too lazy to write about. Check it out for yourself!
Old version: 0.2.4
* STCFN* save bug fixed
* User- configurable character templates
* Load / save character sets
* Added "zoom" feature
* Fixed palette when exporting bigfont
Old version: 0.2.3
* STCFN* font support - added option to save font as a folder full of images
* Fixed palette when exporting indexed console font (thanks, ImageMagick
* Console font characters are now centered when using a variable width font
Posted: Sat Oct 20, 2007 11:11 pm
by wildweasel
This is something I've wanted for a while - any chance you could add an option to generate an STCFN* font too?
Posted: Sat Oct 20, 2007 11:38 pm
by bagheadspidey
wildweasel wrote:This is something I've wanted for a while - any chance you could add an option to generate an STCFN* font too?
Can you link me to some info on STCFN* fonts? Don't know anything about it.
Posted: Sat Oct 20, 2007 11:41 pm
by MDenham
bagheadspidey wrote:wildweasel wrote:This is something I've wanted for a while - any chance you could add an option to generate an STCFN* font too?
Can you link me to some info on STCFN* fonts? Don't know anything about it.
They're the 8x8 HUD-message characters, typically in red (since that's what the color translations for them are set to work from).
If more information is needed, I can elaborate, but that should be enough for graphics purposes.
Posted: Sat Oct 20, 2007 11:51 pm
by bagheadspidey
from imagetool.txt:
confont
-------
This produces a file of type FON1.
The source image for a console font must have 256 characters of identical size arranged in a 16x16 grid. Palette entry 0 indicates transparency, palette entry 1 is the darkest color a character can have, and palette entry 255 is the lightest color. Values in between range between the two. The source image's palette is ignored when the font is created, so you should design the font with a palette like this to best visualize how it will appear in-game.
font
----
This produces a file of type FON2. Unlike FON1, this format supports custom palettes and characters of varying widths. You also don't need to supply a full 256 characters and, in fact, cannot do so without scripting.
The source image should have each character surrounded by a box made p of palette entry 255. Like confonts, palette entry 0 indicates transparency, but unlike confonts, all the other 254 colors in the source image's palette re used to colorize the font, so you can use any palette you want when esigning the font.
When converting with the command line, the first character must be a pace, and the box surrounding it must start in the upper-left corner of the ource image. These restrictions are relaxed if you use scripting, which I will discuss later.
You can use this font (or a confont) with a ZDoom hudmessage by executing the ACS command setfont("fontname") first. The fontname passed to setfont should be the same as the font's lump name inside a wad. If you use a hudmessage color of CR_UNTRANSLATED, then the font will use the palette you designed it with. Otherwise, it will be recolored to a single hue of differing shades.
Do STCFN* fonts not work like this? how do they work?
Posted: Sun Oct 21, 2007 12:09 am
by wildweasel
The STCFN* fonts are just one individual graphic lump for each letter/number/symbol. It's used by ZDoom to display the pickup messages and obituaries, among other things. You can find the entire font in your Doom.wad.
Posted: Sun Oct 21, 2007 12:18 am
by bagheadspidey
wildweasel wrote:The STCFN* fonts are just one individual graphic lump for each letter/number/symbol. It's used by ZDoom to display the pickup messages and obituaries, among other things. You can find the entire font in your Doom.wad.
Ok, I see them - STCFN033 - STCFN121. That feature will be easy to add.
Posted: Sun Oct 21, 2007 2:01 am
by Graf Zahl
But don't limit yourself to 33-121. ZDoom can handle the extra characters located at 192++.
MDenham wrote:They're the 8x8 HUD-message characters, typically in red (since that's what the color translations for them are set to work from).
There is no need to make the font red. To colorize a font ZDoom first desaturates the colors and then re-colorizes them with the new color. The Strife font is yellow, for example, the Quake font found in several mods is brown and the font in Hacx is blue but all of them are properly colorized.
Posted: Sun Oct 21, 2007 2:06 am
by Nash
Finally!
I was beginning to think this will never happen.
No more painstakingly long hours in Photoshop just to make new fonts...
(if this app will work with Windows, that is)
Posted: Sun Oct 21, 2007 2:07 am
by MDenham
Graf Zahl wrote:But don't limit yourself to 33-121. ZDoom can handle the extra characters located at 192++.
MDenham wrote:They're the 8x8 HUD-message characters, typically in red (since that's what the color translations for them are set to work from).
There is no need to make the font red. To colorize a font ZDoom first desaturates the colors and then re-colorizes them with the new color. The Strife font is yellow, for example, the Quake font found in several mods is brown and the font in Hacx is blue but all of them are properly colorized.
That's good to know. Apologies for the incorrect information.
Posted: Sun Oct 21, 2007 2:15 am
by Graf Zahl
Well, unfortunately that doesn't look too good on Windows Vista. Apparently you try to output UTF-8 formatted text directly which Windows doesn't support. As a result all non-ASCII characters are completely garbled. Have a look at the screenshot I made.
Also this program hogs 100% CPU power which even on my Core2 Quad system makes it quite unresponsive.
Posted: Sun Oct 21, 2007 2:20 am
by bagheadspidey
@Graf: Thanks for the info =)
@Nash: It should work under windows once we get a unicode build of wxLua. It is designed to run on either linux or windows. If you want to help, here's some links:
http://www.wxwidgets.org/wiki/index.php ... MSYS-MinGW
http://wxlua.sourceforge.net/docs/insta ... _makefiles
Posted: Sun Oct 21, 2007 2:21 am
by bagheadspidey
graf: i am aware that the windows build is totally screwed, thus the notices all over the place
a unicode build of wxLua should clear that up - but unfortunately I am windows-boxless at the moment
edit - so windows graphics handling routines cannot handle unicode strings _at all_? How the hell do you handle unicode in windows then?
Posted: Sun Oct 21, 2007 2:42 am
by Graf Zahl
Windows can handle Unicode, in fact it's its native text format. Unfortunately WxWidgets screws this up totally. Their ASCII build is utterly incapable of handling any kind of Unicode internally.
Posted: Sun Oct 21, 2007 2:56 am
by bagheadspidey
Graf Zahl wrote:Windows can handle Unicode, in fact it's its native text format. Unfortunately WxWidgets screws this up totally. Their ASCII build is utterly incapable of handling any kind of Unicode internally.
Well, it sounds like it should be easy enough to do a unicode build of wx on windows then. I don't know when i'll have access to a windows dev environment though... That's kind of the whole reason i used an interpreted language, so I wouldnt have to build anything on windows =/