The Dark Mod Readables TTF Fonts

[greebo]

Is the sourcecode for these apps available somewhere?

[Hyeron]

exportfonttodoom3 : http://members.optusnet.com.au/~g.davies/ExportFontToDoom3/ (just browsed through, though not understanding the code, it seems to take 256 characters into account. Export only gives basic ASCII though. I don't get it.  )

 

	// Doom 3 supports 256 characters.
 static const int numCharactersToExport = 256;

 

q3font I couldn't find. Google returns very few results, and its official site being down doesn't help either :/

 

 

[greebo]

Ah, yes complete with project and all, very nice.

 

Have you seen this section in the readme?

 

-xOffsetFix

 

As a result of the limitation in Doom 3's font renderer outlined below (in

"Known limitations : The Doom 3 X offset issue."), one of two fixes can be applied,

each with its own drawback. These fixes are also outlined in the section below.

 

The types are: none, glyph (modifies the glyphs but does not fully correct

glyphs with negative x offsets), and font (modifies all glyphs but will render at a

slightly offset location on the x axis - this is the default).

 

If "none" is specified, the X offset value is exported to the "pitch" member of the

"glyphInfo_t" structure in Doom 3. Using Doom 3's default font renderer will render

data exported using this type very poorly. However, using this type allows changes

to be made to the Doom 3 SDK that will render the font perfectly. Code to render

a glyph contains a line similar to the following:

 

fYPosition -= k_rGlyph.top * fScale;

 

If another line is added to the rendering algorithm along the lines of the following:

 

fXPosition += k_rGlyph.pitch * fScale;

 

Then the in-game rendered text will render perfectly. However, GUI text will still

render poorly if exported under this mode since the GUI font rendering code is not

exposed in the Doom 3 SDK. Therefore, it may be wise to have 2 exports of the font:

one for the in-game rendering with the code changes and exported using the "none" fix

mode, and another which is exported as dds files using the "font" fix mode for the GUI

font rendering.

 

If "font" is specified, the amount of pixels that the font has been offset by is exported

to the "pitch" member of the "glyphInfo_t" structure of every glyph in Doom 3. This

may help to re-align text.

 

eg. ExportFontToDoom3 times.ttf -xOffsetFix none

eg. ExportFontToDoom3 times.ttf -xOffsetFix glyph

eg. ExportFontToDoom3 times.ttf -xOffsetFix font

 

[Hyeron]

'course I did.

 

It certainly would help if the program exported all of the chars... But every parameter still has the same problem compared to q3f: it stops at ASCII char #127 (or 126, doesn't really matter), and the accented characters are 128 to 165 (roughly). Those are never exported, xOffsetFix or not.

(and q3f only has the following options: -create, -decompile, -create, -createex, with createex having the subparameters -size, -imagesize and -tcdebug. No help. :/)

 

 

[greebo]

I'll try to investigate this, but I can't make any promises when I'll get around to do so.

[Hyeron]

Don't worry, I'm not against fiddling with fonts for days, as long as it's on and off. It's just a very limited way to work, I don't see mapper lambda banging his head on the walls trying to get his font to render correctly. I've got the dds, I can export and modify them. It'll just take a LONG time playing with the .fnt then modifying the textures. 't was just so people would know where they're going  if they are to add fonts with accents.

[Crispy]

I looked at this and don't immediately see why it's not exporting accented characters. Trying to build it so I can investigate properly, but as usual got into dependency hell. Sigh. At the moment it's asking for an il_wrap.lib, which is an object-oriented C++ wrapper around DevIL's procedural C interface, but il_wrap.lib doesn't appear to ship with DevIL...

 

EDIT: Seems like il_wrap.lib doesn't exist any more, and yet the latest version still ships a header file for it! Anyway, I found what looks like the wrapper source code and simply added it directly to the ExportFontToDoom3 project, and it compiles (after I moved the class implementation out of the header!) but doesn't output any image files, despite claiming to. Buh? Two steps forward, one step back!

 

EDIT2: I do so love it when people omit error checking from their code. Turns out EFTD3 is incompatible with the Unicode version of DevIL, and since it doesn't check for errors it was failing silently. So it wasn't my build, it was just a combination of the wrong DevIL DLLs and someone not checking their return values.

 

Okay, 1.5 hours to get it building, not too bad! Maybe now I can finally debug this puppy.

[Crispy]

Fixed. It will now export Unicode characters up to 255 (and can easily be modified to support more if necessary, e.g. for Asian languages, though I hate to think how large the character maps would be for something like Chinese). Download modified version here. I'd appreciate it if someone could mirror that file, otherwise it'll probably disappear at some point.

 

In case anyone's interested: The loop iterating over character codes from 0 to 255 was an int (which is why it worked at all), but Font::getGlyphIndexForCharacterCode (a wrapper around the FreeType function FT_Get_Char_Index) was taking an argument of type char. Here's a fun little-known fact: The char type is signed, which means its range is not 0 to 255 as you might expect, but rather -128 to 127. OOPS!

 

So I just changed it to unsigned long (the type actually accepted by FT_Get_Char_Index) and everything works fine. Hurrhurr.

 

I haven't bothered uploading modified source code, since the fix is so simple (just change Font::getGlyphIndexForCharacterCode and the code that calls it to use unsigned long instead of int/char).

[greebo]

Thanks, Crispy for beating me to it. I also got to the point where it compiled fine (I too copied the il_wrap definitions over from some other place), but after that I had to leave. Nice to hear that it's fixed. I suspected it was that function, but didn't spot the error on just reading the code.

 

Should we check in the source code to darkmod_src?

[Hyeron]

Wow. Just wow.

 

Someday I'll really have to learn a few things about C.

 

Thanks a lot once again, guys.

 

 

 

 

Now I'm baffled by the fact the original is STILL bolder than mine. Well, the issues are smaller every time, it's all that matters, a bit of texture editing never killed anyone

 

 

 

[Crispy]

You're welcome Hyeron. TDM should be accessible to as many people as possible, I reckon.

 

I guess the boldness is potentially something that could be tweaked in the application. Let me know if editing the image file manually is too much of a pain.

 

Thanks, Crispy for beating me to it. I also got to the point where it compiled fine (I too copied the il_wrap definitions over from some other place), but after that I had to leave. Nice to hear that it's fixed. I suspected it was that function, but didn't spot the error on just reading the code.

No problem, it's nice to be able to do some TDM work again (since all my uni work is in). And yeah, I was checking it out in the debugger and everything, it was a very subtle problem to spot (though the debugger only helped me narrow down the issue, and in the end the solution did come from careful code reading, plus following up a hunch).

 

Should we check in the source code to darkmod_src?

Good idea. I'll email the guy and ask him (since he hasn't put a licence on it). I'll tell him about the bug while I'm at it. (EDIT: Done.)

Edited November 12, 2009 by Crispy

[Fidcal]

Any special arguments in q3font that might affect boldness? I never really looked too closely at it but only used it for repair. In fact that explains why the ones I did were still bold - I originally converted with fonttodoom3 then back with q3font then restored by q3font so it was using the fonttodoom3 data whereas you used q3font from the beginning. Anyway, since that is now presumably what you will be doing it should all be OK. But isn't there still that vertical cropping problem after modifying via q3font? We also sometimes see that in the inventory.

[Fidcal]

@Crispy: maybe that wasn't a 'bug' but deliberate to save bloat? Dunno how Doom3 handled foreign language versions though.

[Crispy]

The label "bug" is admittedly arguable, since it works fine for the original English-specific purpose, but I doubt it was wholly intentional since there is a constant in the code called "numCharactersToExport" which is set to 256.

 

The versions with accents are a little bit larger, but not to a degree that id Software would have cared about. They were shipping on a DVD after all; plenty of space for an extra MB or two. Note that ExportFontToDoom3 is not an id Software tool, it was made by a modder.

[Hyeron]

Well the french version of D3, at least, was accented and all (or did I misunderstand again? ). I also think it's something completely unintentional - why numCharactersToExport = 256; otherwise?

 

For the rest... First I wondered why my characters suddenly became tiny, found the scaling at the end of the .fnt, worked alright when doubling it, got the correct size (why it didn't do it automatically when q3font does is above me)...

 

Now why exportfonttodoom3 gives me a tga with thinner font than the dds of tdm_font01... I tried several image formats: same boldness everywhere, so it seems it doesn't happen while exporting - looks more like image handling differences. I could be wrong though... Would you mind doing a basic export just for fun?

 

 

 

 

I could try editing with a trial version of photoshop too, just for fun... And even if that does not help, I can always delete the letters then copy/paste/edit from the original dds for a bit more quickness.

 

Thee vertical misalignment is still present, too - though a bit less pronounced if I'm not mistaken. Weird. All in all it seems q3font and exportfonttodoom3 don't make such a difference in the end.

 

It's all very, very interesting. Never had so much to learn with just one project. It really is a pleasure. 

 

 

[Crispy]

For the rest... First I wondered why my characters suddenly became tiny, found the scaling at the end of the .fnt, worked alright when doubling it, got the correct size (why it didn't do it automatically when q3font does is above me)...

Not sure what this issue is. I didn't change anything about ExportFontToDoom3 except the ASCII issue. Are you saying that your characters are halving in size with the new version (that I posted) of ExportFontToDoom3, as compared to the old version?

 

Now why exportfonttodoom3 gives me a tga with thinner font than the dds of tdm_font01... I tried several image formats: same boldness everywhere, so it seems it doesn't happen while exporting - looks more like image handling differences. I could be wrong though...

I bet it's just a font rendering difference (different font renderers deal with font "hinting" slightly differently). I guess I could play around with that within the next couple of days, though I have plenty of other things to do still.

 

For my own reference: FreeType's FT_LOAD_TARGET_LIGHT flag gives rendering that is "more like Mac OS X" (fuzzier, but more true to the intended shape - compare this to Windows, which "hammers text into pixel boundaries", according to one memorable quote). Maybe that would help.

 

Would you mind doing a basic export just for fun?

I'm not sure what you mean.

 

Thee vertical misalignment is still present, too - though a bit less pronounced if I'm not mistaken. Weird. All in all it seems q3font and exportfonttodoom3 don't make such a difference in the end.

If you give me clear instructions on what needs to change to fix this (and other rendering issues), I may be able to automate them in ExportFontToDoom3 itself. Ideally nobody should have to make manual adjustments to font files. We do have the source code to an exporting tool, after all.

[Hyeron]

Not sure what this issue is. I didn't change anything about ExportFontToDoom3 except the ASCII issue. Are you saying that your characters are halving in size with the new version (that I posted) of ExportFontToDoom3, as compared to the old version?

 

No idea either. It certainly doesn't come from your modification. But here's the issue - well, it's not a big deal, takes 10 seconds to correct, but anyway - while exporting with q3font, the font was automatically scaled to 2.0 (penultimate line in the .fnt). Here it doesn't scale. Didn't look at it with the "first" exportfonttodoom3 version though, so it may be normal. It may also come from the xOffsetFix, I should have a few more tries tonight to check that.

 

 

I bet it's just a font rendering difference (different font renderers deal with font "hinting" slightly differently). I guess I could play around with that within the next couple of days, though I have plenty of other things to do still.

 

For my own reference: FreeType's FT_LOAD_TARGET_LIGHT flag gives rendering that is "more like Mac OS X" (fuzzier, but more true to the intended shape - compare this to Windows, which "hammers text into pixel boundaries", according to one memorable quote). Maybe that would help.

 

See below

 

 

I'm not sure what you mean.

 

The point was to have a comparison point for both fonts - one done in the same conditions as originally for the Mod, one done in my conditions. Just to check if it's not an OS problem or whatever, and to compare the tga file produced with the dds used in TDM. Given I don't know if the original version has the same problems, it might be an interesting little test. (hope I'm clear ^^")

 

 

 

 

If you give me clear instructions on what needs to change to fix this (and other rendering issues), I may be able to automate them in ExportFontToDoom3 itself. Ideally nobody should have to make manual adjustments to font files. We do have the source code to an exporting tool, after all.

 

That's yet another question. I don't know if that vertical misalignment was present when Carleton (or any other font for that matter) was originally included in the mod. Don't know if the OS plays a role (7 here). If the scaling problem was present. If... If... If... So I don't think I can give a clear answer yet. And I don't think there will ever be one, unless the result is always the same on every computer... Hence the (limited) interest of the test above.

 

 

 

[Crispy]

It uses cross-platform libraries that I'm 99% sure will work identically on all platforms (even all the various versions of Linux and Mac and FreeBSD and whatever else, let alone Windows 98/ME/XP/Vista/7), so I doubt that's an issue.

 

Well, my email to the author bounced due to a full mailbox. He's Grid on D3W, so I've sent him a PM there instead.

[Hyeron]

Thanks for the tip on the libraries. I'll edit the textures this weekend and post the raw results so anyone can have a look at the differences. Top still seems to be the biggest bugger.

 

Full mailbox and under 100 messages in 5 years certainly are bad omen.

 

Him uploading the source points to an open license, but which one? Published in 2005, I'd say GPL or BSD, with GPL being the favorite (BSD is underused imho) but those are wild guesses at best.

 

Or could he be another DWTFYWWI fan ?

 

 

[Hyeron]

As a side-note : random stuff that's completely missing from the original, accents not taken into account of course :

 

£ ¥ µ ¬ ± © ® § and a few others. Those are pretty useless (though I guess £ could have its uses),

 

but more "importantly" those are also missing: « and » (now those would be SO good to see instead of good old ') - EDIT: there's also ¿ and ¡ (quite useful for the spanish taffers out there if I'm not mistaken)...

 

On the funny side of things, the original isn't just bolder. Some characters are also 1px larger or higher. Same font. Same tool. I'll never understand that. As for the edition, well, it's less boring than I originally thought. You could even call it fast. Or at least it is for accented fonts: it's a matter of quickly copy/pasting, aligning on a new layer, and destroying the underpinning layer once the pasting is done, bolding accents a bit manually on the go (é is just e with ´ after all). There are just so many characters where it won't work (Æ or Œ for example - and those we're used to see as Ae and Oe ever since typing machines. People are often too lazy to correct themselves about this nowadays, so once again it's not a big deal)...

 

Where it WILL become messy is once I hit unaccented fonts: it will still be as easy to add accents to unaccented letters. But WHERE do I put them? They won't appear anywhere after export.

 

So I'd like your thoughts about this question: q3font exports the font in ASCII order, no matter what. Doesn't care about cramming as many characters as possible in one tga, unlike eftd3, which happily exports a mess where a thief wouldn't find a gold statue... And I already know the "unbolding" of the font isn't q3f's fault. Are there any other known glitches preventing the use of q3f as first exporter? This seemingly tiny advantage would become huge for this purpose if there's no other limitation. Sure it doesn't have xOffsetFix. But isn't this just a matter of playing with xSkip? Or did I misunderstand the purpose of xOffsetFix?

 

 

 

 

BTW - uploaded your version of eftd3 to my 4shared, Crispy... It's not much, but it's better than nothing already, I guess: http://www.4shared.c...3_modified.html

[Hyeron]

 

http://img81.yfrog.com/i/31799457.jpg/

 

Question (damn, that's a triple post, sorry about that :/): Which parameters controls the space between the lines (description of the FM)? I think I've messed around with all of them, and nothing changes. Except for aligning and fine-tuning the letters it's all that's left to do for Carleton 24.

[Fidcal]

You'll have to find out by trial and error I'm afraid. Start with height but you might find the line height is hard wired into the font height so reducing it may reduce the height of the font along with the line height.

[Hyeron]

GOT HIM!

 

At long last  

 

So I screwed every possible parameter in the fnt. Ended up with a font where the lines were so close vertically it was almost impossible to read through.

 

Re-exported a clean one, deleted the tga's and compared the two fnt's.

 

Decided to fool around with parameters, one by one, and around 10/20 characters at a time, instead of taffing with Top to align them directly...

 

Height it is, indeed. Some characters had a height around 10 too high. Diminished that all around step by step. Ended up with a font that's EXACTLY the same as yours. Top wasn't involved in the process at all.

 

So to make it short : export the correct, accented font. Copy/paste Fidcal's version to get the boldness back. Play hide and seek with Height until both look the same. All that's left now, is xSkip. NOW I can say I'm getting closer. At least for Carleton 24. The other sizes and accented fonts won't be nearly as tough now. Only problem left : the unaccented fonts, where the original question remains : will q3font be enough?

 

Oh well, I'm getting somewhere at least. I'll repack a foolish-toy version when I'm done, so the french people may compare and criticize. It'll just be the menus, but one step at a time is better than not pushing forward at all.

 

 

 

 

Comparison shots:

 

(didn't upload a psd/xcf, the size is driving my connection crazy  )

 

 

[Tels]

Very cool! Germans (and other Europeans) will love you, too!

 

So this means we can drop your font files into the next update, and then it will be possible to have accented characters, automatically, too? Cool!

[Hyeron]

Well if the rest comes along smoothly and the team wants them, yeah, I guess. It's very good news anyway, the worst people would have to do is swap tdm_fonts01.pk4. No impact on english FM's, slight impact on foreign FM's.