[DoomCRAP] ZDoom Font Generator

bagheadspidey · Post by **bagheadspidey** » Sat Oct 20, 2007 10:36 pm

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

wildweasel · Post by **wildweasel** » Sat Oct 20, 2007 11:11 pm

This is something I've wanted for a while - any chance you could add an option to generate an STCFN* font too?

bagheadspidey · Post by **bagheadspidey** » Sat Oct 20, 2007 11:38 pm

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.

MDenham · Post by **MDenham** » Sat Oct 20, 2007 11:41 pm

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.

bagheadspidey · Post by **bagheadspidey** » Sat Oct 20, 2007 11:51 pm

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?

wildweasel · Post by **wildweasel** » Sun Oct 21, 2007 12:09 am

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.

bagheadspidey · Post by **bagheadspidey** » Sun Oct 21, 2007 12:18 am

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.

Post by **Graf Zahl** » Sun Oct 21, 2007 2:01 am

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.

Post by **Nash** » Sun Oct 21, 2007 2:06 am

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)

MDenham · Post by **MDenham** » Sun Oct 21, 2007 2:07 am

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.

Post by **Graf Zahl** » Sun Oct 21, 2007 2:15 am

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.

bagheadspidey · Post by **bagheadspidey** » Sun Oct 21, 2007 2:20 am

@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

bagheadspidey · Post by **bagheadspidey** » Sun Oct 21, 2007 2:21 am

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?

Post by **Graf Zahl** » Sun Oct 21, 2007 2:42 am

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.

bagheadspidey · Post by **bagheadspidey** » Sun Oct 21, 2007 2:56 am

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 =/