Jump to content
The Dark Mod Forums

Zbyl

Member
  • Posts

    37
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Zbyl

  1. If you'd like to check out the "decompose" function you'd need it.
  2. Here it is: https://docs.google.com/file/d/0B0pkDNTfAmoedHZvT1VJV2tpbGs/edit?usp=sharing Required DLL: https://docs.google....dit?usp=sharing Also remember to install: ImageMagick-6.8.6-8-Q16-x86-dll.exe (or x64 - I'm not sure). Edit: This tool has a simple GUI now - when run without parameters.
  3. Update on my work: - Unicode language files work ok, - BFG fonts now render similarily as the old fonts. It's not pixel perfect, but close. - I've created a tool to create BFG fonts (https://github.com/Zbyl/BFGFontTool). It has some support for porting old Doom 3 fonts to new Doom 3 BFG fonts. The code is not entirely final, but since the interest in those features is low my work on this is done for now. If anyone will be interested in this code - let me know.
  4. I've implemented generation of fake old .dat files during creation of a BFG font, but it turns out they won't be good enough to use in the GUI editor. It turned out that generation of scaled fonts is a complex task. Even more difficult considering that they have to satisfy additional constraints that Doom 3 BFG impose. In other words - too much work to be worth the effort.
  5. For TDM it would not be necessary. Old fonts can be changed into BFG fonts with legacy_sizes.dat. And new fonts will have auto-generated legacy_sizes.dat files. Moreover some font files, like stone font for example, do not adhere to the specification. They have a hack embedded to circumvent old .dat file limitations. It would be counter-productive for me to try and re-implement those hacks. I could try to make a simple, no-hack, exporter - but I don't see a use for it. Edit: What do you need old Doom 3 fonts for?
  6. I know it uses Flash for menus, and old GUI for surfaces. But in both of them it uses .dat files exclusively. No TTFs, nor OTFs are used. Old Doom GUI made with old tools will work with new fonts. Wheather they will work in Doom 3 BFG out of the box - probably. But that's another matter, which I'm not concerned with at the moment. No. What I'm saying is this: either old .dat files, or new legacy_sizes.dat file is necessary for fonts to be scaled properly.
  7. BFG uses old .dat files for one thing only: taking the maxCharWidth and maxCharHeight from them. Nothing else. 100% certain. BFG fonts are self contained. Old maxCharWidth and maxCharHeight are used to figure out how to scale the new font to be the same size as the old font. Nothing else. Rendering dosen't use old .dat files at all. If GUI Editor uses old font system - then it's probably because it wasn't updated. After all Doom 3 BFG uses Flash for all new GUI, and the scaling-compatibility-layer ensures that even GUI made with old editor will display properly in game.
  8. It's either: - 3 old .dat files, 1 new .dat file and 1 new TGA atlas, or: - 1 new .dat file, 1 new TGA atlas and 1 new "legacy_sizes.dat" file. Both work. If compatibility was not a problem then I'd do a much cleaner solution without "legacy_sizes.dat" nor old .dat files. But it seems it's out of question. However - for any new fonts the compatibility layer will be bypassed. It'll be much easier for font makers and gui designers. BTW.: Is it possible to get the stone font in TTF or OTF format?
  9. I use old .dat files to read information about their size. Then I save it on the side in a helper file, and don't use old .dat files ever again, for anything.
  10. What I've done so far: - ported BFG font rendering code to D3, - ported "stone" font to D3 BFG format, - implemented compatibility functions to adjust font scale, - potrted BFG LangDict to D3 so all languages now support Unicode. Here's a link to the picture (I don't have permission to insert an image): https://docs.google....dit?usp=sharing There a two problems that I can see: - in main menu and on lists of missions some letters have descenders cut (problem with font scale?), - in main menu the character "o with accent" is weirdly positioned. I haven't yet compared it with the unmodified TDM.
  11. Such one-pixel-here-and-there inaccuracies are bound to happen. idFont and BMFont render the fonts slightly differently. id uses it's own font rendering and BMFont uses standard Windows rendering. Things like antialiasing type, hints, clear type etc. will produce slightly different results. There's no way to copy idFont's output with bit-to-bit precision. What we have is probably as close as we can get. And it's close enough IMHO. Edit: "to" word in the next line is a result of such one-pixel inaccuracies.
  12. Not exact yet. Close enough though. (We should probably generate fonts from outline and turn off true type hinting.) As for your error: FileNotFoundException. Maybe "48.ftn" should be "48.fnt"? Also you could try giving absolute paths to make sure. I'm satisfied with the outcome so far. I'll try to do some TDM coding to try and make new fonts visually compatible with the old ones.
  13. I've uploaded your font's .dat file here: https://drive.google.com/folderview?id=0B0pkDNTfAmoeOUZRWkYxMzBOSVU&usp=sharing It does not match the parameters in original font from BFG exactly: descender is -10, in original it's -11. But descender is not used in font rendering. So the output, hopefuly, will be the same. I've also created my own, alternative, parameters. My font is here: https://drive.google.com/folderview?id=0B0pkDNTfAmoeRktUOElCRHlRZ00&usp=sharing I think it's slightly worse (ascender is 46 instead of 45 - but ascender is actually used during rendering), but you can check it out too. It has bigger spacing (4 pixels) so there should be no "boxing" artifacts. I don't think we can get any better results with BMFont (it supports only integer font sizes). But I don't think it's needed. I'm pretty sure you can compile my tool using VS2010 Express, or using gcc under Linux (should work on Mono without problems... except for the optional ImageMagick stuff). I've also uploaded my tool under the first link. It's not overly useful, though.
  14. Yes. My font has different ascender, descender and scale. But how to compute those values exactly as idFont does - I'll have to dig some more.
  15. The reason why my font display incorrectly in PDA is this code in BFG's SWF text renderer: float linespacing = fontInfo->GetAscender( 1.15f * glyphScale ); My ascenders are 0 now, since they are not used anywhere in text renderer. (This code is used only in the SWF renderer of the new Doom GUI).
  16. Thanks motorsep. I've uploaded source code of my tool here https://github.com/Zbyl/BFGFontTool
  17. Thanks for this test motorsep. The white boxes appear because I apparently gave too small spacing in BMFont's generation options. I should have bumped the output resolution too. I need to figure of what settings to use for scaling fonts properly. In D3 standard fonts are of size 48pt, but with what DPI? Maybe 120? And why the PDA is messed up I have no idea... yet.
  18. I've created an ArialNarrow font that should work. I'm not sure if the scale will be ok though. https://drive.google.com/folderview?id=0B0pkDNTfAmoeQm9zZG5TeVFqejg&usp=sharing I've attached BMFont's config and .fnt that I used to create this font too.
  19. Yep. I convert the text version of the descriptor into a BFG .dat. Probably converting XML descriptor would be easier, but I just didn't thought of it. Sure I'll share the code - but at the moment it's rather messy. And in C#. I'll clean it up a tiny bit first. As for testing my font in BFG - sadly I can't do that, since I don't own BFG... I only have the code to play with.
  20. My test Gothic font is here: https://drive.google...N1U&usp=sharing BFG .dat is of course in a different format than D3 .dat. The TGA is generated by BMFont - I didn't make any chages to it. BFG fonts are different for example in that they use only one big texture per font, not many like in D3. This is not a problem these days when big textures are universaly supported. As for the performace improvements: I don't know a lot about this. Only stuff I've read in BFG code review and some articles by Jean Paul van Waveren and Carmack. But I'll take a look if I'll find the time.
  21. I think the benefits of this code are impressive, even if not evident at first, so I'll keep working on this. It would definitely help me with compatibility to know what tools you use for generating fonts. Is it ExportFontToDoom3 exclusively? I also think I misunderstood the "manual painting Tels put in editing the existing raster fonts". I thought he wrote some tool to support adding new glyphs to existing fonts, but now I re-read it it sounds like you were talking about actual editing of font textures. It definitely would not be a wasted work. The only thing that is needed is: some tool to support adding new glyphs to existing fonts... I'll look into this too.
  22. But you ignore all the other issues I mentioned.
  23. Like I said: I use BMFont and my custom converter from BMFont to BFG fonts. They do replace the original font system (they need original fonts only to know what their maxCharWidth/maxCharHeight is to know how to scale new fonts into old GUI). This is in the code - no guesses here. There are many code pages to support now - language files need to be converted into custom encodings. Russian language is hacked in quite ugly. There is no way to display i.e. language list in the GUI properly: i.e. russian in russian, polish in polish, spanish in spanish - no one font supports all the necessary characters. Separate font files - inconvenient. Need to reload fonts after language change - inconvenient. Adding new languages is tricky. There's no way TDM can support Japaneese, Chineese, Korean etc. right now. It would be a breeze with BFG's fonts. Basically the I18N support is a big hack right now. I'd like to get a look at this. Is this code somewhere in the public SVN? The BMFont I used doesn't support this - but I used BMFont just because it was the easiest way I could generate a font for my testing. It would probably take little effort to generate BFG fonts using the content pipeline you already use. Even better: if breaking backwards compatibility in any way is not an option then BFG code can be modified to work just like the old system, but without the old D3 problems and with unicode support. But breaking backwards compatibility is ok sometimes. I just wonder what course of action would be best. It would, but there are ways to solve it. It could be done the hacky way (just porting current behaviour). But since the full D3 code is open now - it could be done the proper way: i.e. support changing font to a custom one mid-text, like the support for changing colors is done. About the broken toUpper()/toLower(): any thoughts on that? (I've described some of the problems here in http://bugs.thedarkmod.com/view.php?id=3321)
  24. Hi guys, I haven't seen anyone working on this, so I've ported font code from Doom 3 BFG edition to The Dark Mod. This allows to create fonts that support full unicode range. I'm porting LangDict now, so all texts will be in unicode and no hacks will be necessary - no code pages, conversions, replacements, separate font files, problems after language change etc. There's one issue: the BFG fonts don't have three sizes (small, medium, large). There is only one font size, and this font is scaled if necessary. This creates an unfortunate side effect: font scales in GUI that were tuned for old fonts will be wrong now. In the Doom3 BFG they do a little hack: they load old fonts too, but use them only to emulate old font measuring code. This is not only ugly, but also a maintenance nightmare. For TDM I would propose to drop it and just fix the GUI to use proper font scales. I'd like to know what you guys think about this. (To make it clear: using old and new fonts together is not possible.) Some technical stuff: I've used some new helper files from BFG. They are not strictly necessary, but I didn't see any reason not to use them if it made my work easier. Those are for example: sys_assert.h, sys_types.h, new collections/List.h any maybe something else. The porting itself was really straightforward - copy/paste mostly. I've also made a little utility program that converts fonts created by a freeware BMFont (http://www.angelcode.com/products/bmfont/‎) into BFG fonts. Another thing connected to fonts and localization that I'd like to discuss are the toUpper, toLower etc. functions. Those cannot be reliably used for GUI. Think about toLower() for german language: sometimes "SS" have to become "ss", and sometimes "scharf ss". It should be translators job to prepare text in proper case and form. I strongly advise against any conversions like that in GUI output. The toUpper() and toLower() functions in TDM right now don't work properly for diacritics (like ąęćżźńł, scharf ss) - and it makes GUI look super ugly. However: providing implementation that will work decently is quite simple and I've written most of the code for it. The question is: should I finish it, or should TDM just drop toUpper from GUI code? (BTW.: I know that you won't even consider integrating any of this stuff before 2.0 is out.)
×
×
  • Create New...