Font Studio 4.02 is here! [Archive] - Pascal Game Development

Nitrogen

30-04-2007, 11:41 PM

It's taken more time than I care to think about, but I've finally finished Font Studio 4.0!

It's better in every way than anything before it, and I'm pretty safe in saying that it's one of the best bitmap-font generators out there that I've seen! :)

I'm pushing it out tonight, still hot out of the ide. The unit for loading the font files is also written, it just needs a font demo worthy of it, so that should be coming in the next few days.

In the mean time, you can grab the Studio itself here: http://www.nitrogen.za.org/projectinfo.asp?id=12

http://www.nitrogen.za.org/gallery/fontstudio4.jpg
http://www.nitrogen.za.org/gallery/fontstudio42.jpg

Font Studio is now version 4.0 which comes with the following changes:

* Multithreaded
* Unicode support!
* Drop Shadows and Outlines!
* Characters are packed into the texture optimally, with customisability
* Project files are now separate from exported Font files.
* Exports textures as JPG, BMP, TGA, with a separate alpha file, or as a 32 bit TGA.
* Exports font data as INI, XML or FNT file, which can be attached to the texture file.

*UPDATE*

I've added small font support, cleartype support and no texture size constraint, among other small changes.

AND, I've updated the XML export, so it writes both XNA style xmls and my own style which are a little easier to integrate into your own code.
New version is avaliable for download using the link above.

Nitrogen

30-04-2007, 11:43 PM

The main difference from what you may have seen before is the export functionality.

It can output to 6 different file formats over 3 files, or pack all the data into one file...

Oh and theres' an easter egg in it too :P

01-05-2007, 01:19 AM

I would like to include support for fonts generated by Font Studio in the next snapshot of Asphyre eXtreme II, but unfortunately, there are still numerous bugs to be fixed. :(

First, it would be good if you could specify any texture size, not just those that are predefined (for instance, 128x64). Besides, two options "512x256" and "256x512" are pretty redundant, which gives very little room for freedom.

Second, when the program starts - it freezes for 30 seconds saying "Getting current font dimensions..." Apparently, this happens whenever "Arial Unicode MS" is selected, which is selected by default (maybe using Tahoma or Times New Roman by default would be a better choice).

Finally, "Drop shadow" doesn't seem to work at all. Screenshot:
http://img339.imageshack.us/img339/6223/fontstudiohn2.th.jpg (http://img339.imageshack.us/my.php?image=fontstudiohn2.jpg)

Notice that there are huge blank spaces between letters. Is that intentional?

Using ClearType for antialiasing seems to mess up font slightly and since "smooth" doesn't work for small fonts, the only choise is to not use antialiasing for small fonts at all.

I think it's counterproductive that you test and put default values in Font Studio for very large font sizes (e.g. 32) since after playing for a while I couldn't get a decent output with Tahoma in size 8 (see the screenshot above). I haven't tested it with large fonts though because they are rarely needed.

Sorry for raining with this bug report. Font Studio seems to be progressing quite well, keep up good work!

Traveler

01-05-2007, 07:53 AM

Nice! I'll going to give this a try later today!

savage

01-05-2007, 12:34 PM

Nitrogen

01-05-2007, 04:20 PM

First, it would be good if you could specify any texture size, not just those that are predefined (for instance, 128x64). Besides, two options "512x256" and "256x512" are pretty redundant, which gives very little room for freedom.
Fair enough.

Second, when the program starts - it freezes for 30 seconds saying "Getting current font dimensions..." Apparently, this happens whenever "Arial Unicode MS" is selected, which is selected by default (maybe using Tahoma or Times New Roman by default would be a better choice).

If you had used the program for more than a short while, you would notice that it saves your preferences so next time it'll start up exactly the way you left it.

Also that Getting current font dimensions is the windows API taking it's sweet time, and nothing to do with my program. If you open that font file with microsoft's font viewer, you'll see it go very slowly. Just the way the cookie crumbles!

But I'll consider Arial for default as good practice..

Finally, "Drop shadow" doesn't seem to work at all. Screenshot:

Notice that there are huge blank spaces between letters. Is that intentional?

Yes it's necessary for the dropshadow and outline. uncheck those and you'll have a much smaller border between chars.

The small fonts are a bit of a problem if you need antialiasing... I didnt realise that the smooth fonts stop being smooth at around 10pt. I'll have a look at making it work properly with Cleartype.

I think it's counterproductive that you test and put default values in Font Studio for very large font sizes (e.g. 32) since after playing for a while I couldn't get a decent output with Tahoma in size 8 (see the screenshot above). I haven't tested it with large fonts though because they are rarely needed.

I do test with smaller fonts, but I used a REALLY small font which doesnt have any rounded edges so I didnt pick up on the rounded edges needing AA. Should be fixable.

Nitrogen

01-05-2007, 04:26 PM

This looks great, though I need for find some time to play with it.

Do you happen to know if this format is compatible with XNA's bitmap font format - http://blogs.msdn.com/shawnhar/archive/2007/04/26/bitmap-fonts-in-xna.aspx?

If not it would be another nice string to your Font Studio bow.

No, it's not the same format. If you can give me a technical document describing the layout/format of their XML, I could adapt mine to work.

02-05-2007, 02:45 AM

If you had used the program for more than a short while, you would notice that it saves your preferences so next time it'll start up exactly the way you left it.
I restarted the program several times and it took long to start, but of course, I didn't change the font so it remembered the bad option - only later I realized it only happened with this font. Weird stuff. :D

Yes it's necessary for the dropshadow and outline. uncheck those and you'll have a much smaller border between chars.
So any reason why shadow doesn't work? It doesn't seem to change whether I use outline or not.

I do test with smaller fonts, but I used a REALLY small font which doesnt have any rounded edges so I didnt pick up on the rounded edges needing AA. Should be fixable.
I focused a lot on this topic because most of the time I'm using small fonts, especially for GUI. Normally it is "Tahoma" both with and without bold style enabled. Generally ClearType is pretty ok, especially when converted to grayscale.

Also, I've found several fonts that don't get antialiased no matter what flags you use. You can only antialias these fonts by supersampling them, using Quincunx (http://en.wikipedia.org/wiki/Quincunx), for instance. Maybe this can be added in new version? :)

Nitrogen

02-05-2007, 10:29 AM

So any reason why shadow doesn't work? It doesn't seem to change whether I use outline or not.

They DO work! :) You are not looking at the Mask tab (which is where the shadow is actually applied) and also the background colour is grey (default) which is used for the shadow colour, so you wouldnt see it very well on a default windows form background.

Setharian

02-05-2007, 01:04 PM

is there a reason why the source in unavailable? are you planning to sell it?

Nitrogen

02-05-2007, 09:56 PM

Three reasons:

- It uses 3rd party controls that makes it a hassle to distribute with the source code, and makes it not easily compilable

- The code is not commented or documented so it's not really good as a teaching aid

- I've spent quite a lot of effort on it, and although I'm not going to ask money for it, I'd still like to keep control over my intellectual property.

Sly

02-05-2007, 10:18 PM

ClearType is never a good option for creating smoothed bitmap fonts because ClearType uses sub-pixel rendering based on the contents of the buffer you are rendering the character to. The end result is that you get blue and red fringes on the left and right edges of the characters.

See if you can use a font renderer like FreeType that produces proper anti-aliased output.

Nitrogen

02-05-2007, 11:20 PM

Solved that little problem by grayscaling the characters...

I must say, it works really nicely.

Nitrogen

02-05-2007, 11:32 PM

I've added small font support, cleartype support and no texture size constraint, among other small changes. No changes to the file types yet...
New version is avaliable for download using the link above.

I've tested it with Tahoma 8pt and I think those results are very good.

http://www.nitrogen.za.org/junk/FontStudioSmallfonts.jpg

03-05-2007, 02:11 AM

This version appears to be greatly improved! Thanks for fixing stuff on such short notice!

Can you briefly explain the meaning of values inside XML file? By the way, shouldn't the XML file start with "?" before "xml" (sorry, this forum won't let me insert http://www.afterwarp.net/ykot/xml.gif text, not even inside code tags!). Because currently it has a root node called "xml", which is somewhat misleading. :P

IlovePascal

03-05-2007, 04:36 AM

Hey, I tried the 4.0 version (nt the recently updated one), and I found it weird how the preview (text at the bottom) doesn't work when the letters are too close together or when the shadows are largely offset or when the outline is too thick; well in short, everytime the letters would overlap a bit.
I end up with random letters instead of the text that I ask it to display.

The other thing is how all the characters don't fit in the image if you have too many of them, or if they're a bit too spaced out. Couldn't you just make the image larger?

I found the rest pretty kool and I'll definitely use it!
Cheers ;)

Traveler

03-05-2007, 08:05 AM

The other thing is how all the characters don't fit in the image if you have too many of them, or if they're a bit too spaced out. Couldn't you just make the image larger?

Unless I misunderstand, there's a texture size setting under the general settings tab. Just increase the slider to add more space.

savage

03-05-2007, 12:44 PM

No, it's not the same format. If you can give me a technical document describing the layout/format of their XML, I could adapt mine to work.

I believe the format is fairly standard here is an example...

You can create custom typefaces by arranging a set of character images into a single bitmap, separating the areas between each letter with a pure magenta marker color:
http://blogs.msdn.com/blogfiles/shawnhar/WindowsLiveWriter/Bitmapfonts_B123/image1.png

From that ]This bitmap must include an alpha channel to specify which areas should be solid or transparent, and the alpha in the magenta border region must be set to fully opaque.[/quote]

What do you think?

Nitrogen

03-05-2007, 12:49 PM

Well what about the XML file :)

I dont have XNA studio, but I managed to download a few xml font generators.. I'll adapt mine to fit it, since the xml I'm currently using is not very standardised.

Nitrogen

03-05-2007, 12:52 PM

Hey, I tried the 4.0 version (nt the recently updated one), and I found it weird how the preview (text at the bottom) doesn't work when the letters are too close together or when the shadows are largely offset or when the outline is too thick; well in short, everytime the letters would overlap a bit.
I end up with random letters instead of the text that I ask it to display.

Yea it does assume you know what you doing :P
It'll tell you when there is not enough space for the characters to fit, and then there will be invalid characters because it starts dumping the excess characters at 0x0. But it does give you a large red warning label, so you can just increase the texture size and carry on!

jdarling

03-05-2007, 01:41 PM

Hey Nitrogen, what are the chances of you adding in a way that we can add/write our own exporters. This would allow us to fix the problems :). As an example, I'd love to give this a try, but I've already standardized and spent a lot of time developing around angle. I'd actually take the time to write an exporter for your app that generated a compatible version.

Would be really cool if it were a scripting language to support it, but DLL's would work as well. Just some way that we can customize the output so that it will match what we are currently using :). Also, that would put you a step ahead/above the other font editors out there.

savage

03-05-2007, 02:09 PM

Well what about the XML file :)

I dont have XNA studio, but I managed to download a few xml font generators.. I'll adapt mine to fit it, since the xml I'm currently using is not very standardised.

The XML is generated by XNA Studio when you import the texture ( *.bmp, *.png etc ) and set a property within the editor.

I have XNA so can test it if you want. Or alternatively it is a free download.

Nitrogen

03-05-2007, 04:16 PM

Would be really cool if it were a scripting language to support it, but DLL's would work as well. Just some way that we can customize the output so that it will match what we are currently using :). Also, that would put you a step ahead/above the other font editors out there.

You just trying to get me to do the dirty work arent you :)
Yea, sounds like a cool idea.. I'll leave that for version 4.1 or 4.2 though.

Ok I've released 4.02 which cleans up the XML export, and allows exporting to XNA style xml files. If you have XNA, please give it a try, I hope it works...

jdarling

03-05-2007, 04:37 PM

You just trying to get me to do the dirty work arent you :)
Yea, sounds like a cool idea.. I'll leave that for version 4.1 or 4.2 though.

Hey, I'll do the hard work :). Just give me the source code for the application and a copy of Delphi since its not FPC and I'll add in the exporter support for ya :).

savage

03-05-2007, 06:11 PM

Ok I've released 4.02 which cleans up the XML export, and allows exporting to XNA style xml files. If you have XNA, please give it a try, I hope it works...

XNA just needs the *.bmp, *.jpg or *.png file ( btw any plans to support *.png export? ) not the XML file. It uses the background colour to delimit each character. See my earlier post ( I've just added some more info ) for what the texture should look like and how it is constructed.
Unless it's an option should have set. If so point me to it.

Nitrogen

03-05-2007, 11:05 PM

XNA just needs the *.bmp, *.jpg or *.png file ( btw any plans to support *.png export? ) not the XML file. It uses the background colour to delimit each character. See my earlier post ( I've just added some more info ) for what the texture should look like and how it is constructed.

Are you sure you cant use the XML rather? It contains enough information to draw the font from a generated BMP or PNG. And the character layout is an integral part of the generator so I'm not about to replace/rewrite it.

04-05-2007, 12:26 AM

Sorry to ask again, but can you give a brief explanation of fields inside the exported XML file?

savage

04-05-2007, 08:42 AM

Are you sure you cant use the XML rather? It contains enough information to draw the font from a generated BMP or PNG. And the character layout is an integral part of the generator so I'm not about to replace/rewrite it.

It would certainly be possible to use the XML, but that would require writing a Content Pipeline importer for XNA. Since XNA already has support for bitmap fonts using the format described earlier and there is already another , I'm not sure if writing another Content Pipeline importer would be usefull. To me it makes more sense for FS 4.x to support XNA's format rather than XNA having to support FS's format. It would shift more units of FS that way.
But, I totally understand your reluctance to support their format. I suppose this is where an exporter plug-in system would be useful.

Nitrogen

04-05-2007, 06:38 PM

Hmm, it seems the XNA format wasnt quite what I thought it was. Anyways, I believe the way out of this file format nightmare is a plugin system...

I was thinking along the lines of:

type TPluginInfo = record
Name: string[30];
Type: TPluginType //RGB, Alpha, Both or Data exporter
Extension: string[3];
end;

type TCharData = record
char: widechar;
A,C: cardinal; //A is the leading space added before drawing the char
//C is the trailing space (and charwidth) added after drawing the char.
OriginX, OriginY, CharWidth, CharHeight: integer;
end;

//These functions would be exposed to Font Studio inside your DLL:
function GetPluginInfo: TPluginInfo;

//Only one of these would be called from FS. Depending on what plugin type this is:

//Sends width*height*3 bytes in the data pointer
function SaveRGB(data: pointer; width, height: cardinal): boolean;
//Sends width*height*1 bytes in the data pointer
function SaveAlpha(data: pointer; width, height: cardinal): boolean;
//Sends width*height*4 bytes in the data pointer
function SaveComposite(data: pointer; width, height: cardinal): boolean;

//Width and height are of the texture and spacewidth is the width of the space character (#32)
function SaveData(chars: array of TCharData; count, spacewidth, width, height: cardinal);

jdarling

04-05-2007, 07:11 PM

Here is my two cents:type
TPixelType = ( // This could also just be a byte 0..255 alpha value
piTransparent = 0,
piSolid = 1,
piAlpha = 2
);
TPixelInfo = packed record
PixelType : TPixelType;
Alpha : Single;
end;
PPixelInfo = ^TPixelInfo;
TPixelArray = array of TPixelInfo;
PPixelArray = ^TPixelArray;

TPluginInfo = packed record
Name, Author : ShortString;
Description : AnsiString;
end;
PPluginInfo = ^TPluginInfo;

TCharInfo = packed record
width, height, // The width/height of the character
leading, trailing : integer; // leading and trailing kerning/space
WhatChar : Char; // Character represented
Data : PPixelArray; // Pixel data
end;
TCharSet = array of TCharInfo;
PCharSet = ^TCharSet;

TCharSetInfo = packed record
FontName : ShortString;
Bold, Itialic, Underline : Boolean;
Characters : PCharSet;
end;
PCharSetInfo = ^TCharSetInfo;

procedure GetInfo(InfoRec : PPluginInfo); cdecl; export;
procedure DoExport(CharSetInfo : PCharSetInfo); cdecl; export;

GetInfo would be called by the application with a record pointer that would be created within your application. Then when they click on export the DLL's export method would be called with a pointer array to the character data.

Why all of this you may ask? Well simple; if I build an exporter I might want to support a new image format that you didn't think of. I might want to export to my custom package format. Or I might need to prompt the user for more information. I may want to change the colors or any other option. Thus a single call to the exporter makes more sense. You could add a callback to get process status as well.

Why CDECL? Simple, there are many C/C++ developers out there and as good as this looks they might want to write an extension as well. This is also the reason for pointers and record pointers. They work across development platforms very well (look at SDL).

Finally, CDECL works well between FPC and Delphi. Something that can't be said for Pascal from my own experiences. As I said before, I'd be willing to write a few exporters if not a generic wraper for Lua so others could easily write exporters.

As I said before, I'd be willing to give the plugin system a look and build out some units to help you if you want.

- Jeremy

Nitrogen

04-05-2007, 07:41 PM

Help and feedback is appreciated, but:

You're defeating the purpose of packing the characters into a bitmap! If I wanted to write a PNG exporter with that function, how would I produce a png image from a bunch of disjoint pixel arrays? Would I have to write my own character packing routine when FS has just done that for me?

Further, the exporter should not have to change anything about the visuals of the font: colours, sizes etc. The user would have done this before exporting anyways.

Giving the plugin a raw uncompressed bitmap is the most basic data it can receive, so it should be able to encode this into any data format imaginable, present-day and yet-to-be-discovered. If you want to extract the individual characters out of that data for your own format, you can work the raw bitmap to do that.

I fully agree with C++/FPC compatibility and you are welcome to point out where I should make things AnsiString or packed record or whatnot, I dont have much experience writing cross-compatible procedures.
I also agree with the author, name etc. we'll have to have another procedure which communicates this sort of info between the host and the dll.

I went for 4/5 types of exporters because:
- It splits up the output into multiple files, giving the user more control.
Like if I wanted my alpha in JPG format and rgb in BMP format separate from my data in XML format, you can do that.
- It only has to give the plugin the data it needs, saving processing time.

But I agree it's a very nasty and complex situation because you have to handle:
* RGB and Alpha and Data all separate files
* RGB and Alpha in composite file, Data in separate file
* RGB, Alpha and Data all in one file. //Going to have to add this as another type of exporter.

Nitrogen

04-05-2007, 07:58 PM

Oh, almost forgot:

This is an explanation of the XML format (my own format, not the XNA one)

http://www.nitrogen.za.org/junk/XMLExplained.png

X1,Y1,X2,Y2 - Coordinates ranging from 0..1 so they are texture-size independent.

Wid,Hgt - These are for when you draw the character to the screen, you know how big to make it.

A - This is the amount of space to add before drawing the character, you normally add this to your current 'cursor' position when drawing the font
Also known as the lsb (left side bearing).

C - This is the amount of space to add to get the cursor in position to draw the NEXT character. So it includes the current char's width and any trailing space. Also known as the aw (advance width)

SpaceWidth - This is simply the width in pixels of the space character (#32) Because the space is not really stored as a character (it's just a width really), it's stored in the header as a global value.

jdarling

04-05-2007, 08:27 PM

Maybe I missed something, but I didn't see a pointer to the raw bitmap being passed. Note that you can't pass a TBitmap, you have to pass the pixel pointer and pixel format across to the exporter. If you know that your always running in 24 bit then that makes thing easier.

Just make sure that you mark ALL methods that need to be exporter with cdecl and all strings are PChar, AnsiString (Pascal version of PChar directly compatible), or ShortStrings.

Also, the reason for passing each characters pixel data separately is so that if you need different spacing for your exporter you can easily paste together the image. Of course another method that would work just as well would be to create 3 temporary bitmaps and an XML details file. When the exporter is called then it receives the names of the files only. It then does what it wishes with them.

Extension is not necessary though :). I for one would most likely put more then one export format into a single exporter DLL. Thus prompting the user to select the format they want to save to. Instead just have an export menu with sub menu items containing the exporters that you loaded.

Oh, and if you want a sample of some stuff WILL and I have been working on in FPC that can be loaded by Delphi, C/C++, or whatever download: http://www.eonclash.com/Test2.zip

Nitrogen

04-05-2007, 08:49 PM

Maybe I missed something, but I didn't see a pointer to the raw bitmap being passed. Note that you can't pass a TBitmap, you have to pass the pixel pointer and pixel format across to the exporter. If you know that your always running in 24 bit then that makes thing easier.

/Sends width*height*3 bytes in the data pointer
function SaveRGB(data: pointer; width, height: cardinal): boolean;

The data: pointer, it sends width*height*3 bytes of raw bitmap to the plugin...

Just make sure that you mark ALL methods that need to be exporter with cdecl and all strings are PChar, AnsiString (Pascal version of PChar directly compatible), or ShortStrings.

Will do...

Extension is not necessary though :). I for one would most likely put more then one export format into a single exporter DLL. Thus prompting the user to select the format they want to save to. Instead just have an export menu with sub menu items containing the exporters that you loaded.

The only reason I wanted an extension is so when you browse for a filename to save, it can filter it to the relevant file type!