The most comfortable way to show text is to use TCastleLabel
. You can customize it's font using TCastleUserInterfaceFont.CustomFont
and TCastleUserInterfaceFont.FontSize
properties.
Many UI controls (see for example unit CastleControls
) descend from TCastleUserInterfaceFont
, and thus can render text and have their font customized, for example TCastleButton
.
You can add and configure UI controls (like TCastleLabel
, TCastleButton
and many more) by code, or using the CGE editor.
Another way to render text is to use TCastleText
. You can place such component in a viewport and it can be transformed just like any other 3D object.
This is a great way to display text in 3D and/or attach the text to some 3D or 2D game object, e.g. as a debug text over some character.
The properties of TCastleText
and TCastleLabel
are deliberately very similar. They also use the same font classes underneath.
You can add and configure fonts. To customize font in the CGE editor:
Use the "Design -> Add Non-Visual Component" menu item, or the context menu (when you right-click in the hierarchy on the left). Font is added as "Non-Visual Component" to whatever parent you selected.
The parent that keeps reference to the font node can be anything -- TCastleComponent
, TCastleTransform
, TCastleUserInterace
etc. It is similar to VCL/LCL non-visual components: it doesn't really matter where you drop them on the form.
Then assign this font to TCastleLabel.CustomFont
. Or any other UI control descending from TCastleUserInterfaceFont
, like TCastleButton
or TCastleEdit
.
You can also assign font to TCastleText.CustomFont
to customize font used by the (potentially 3D) TCastleText
in the viewport.
Our most important font classes:
TCastleFont
- the most often used font class, loads font from TTF, OTF and other file formats.
Most important properties:
URL
(font file URL, e.g. TTF or OTF),
LoadBasicCharacters
to control the loaded font.
TCastleBitmapFont
- define letters using an image.
Most important properties:
TCastleFontFamily
- a collection of other fonts to provide bold/italic variants, useful with rich text in TCastleLabel.Html
.
See examples, e.g. examples/fonts/text_tests for demos of it.
You can define a default_font
inside the CastleSettings.xml file to change the default font. This way CGE editor will also use the new font as default.
(A complete program using the concepts discussed below is in the engine examples, in the examples/fonts/test_local_characters/. The main code is in gameinitialize.pas unit there. Check it out!)
All font routines (printing, measuring) expect the international characters to be encoded using UTF-8. To draw the international characters (anything beyond basic English ASCII set) you also need to create a font with these characters.
To TCastleFont
provide a list
of the characters (including all the possible international characters)
that you want to display. Like this:
uses ..., CastleFonts, CastleStringUtils; function CreateMyFont: TCastleFont; begin Result := TCastleFont.Create(nil); { Below is a string containing all my international chars, in UTF-8. Note that basic ASCII characters are also always loaded, because Result.LoadBasicCharacters = true by default. } Result.LoadCharacters := '你好世界ΓειασουκόσμεЗдравствуймир'; Result.OptimalSize := 20; Result.Url := 'castle-data:/MyFontFile.ttf'; end;
Make sure to provide the sample characters encoded in UTF-8.
In the example above, they are simply hardcoded in the Pascal source file,
so make sure that compiler understands it as UTF-8 data.
Make sure your source code is in UTF-8 (edit it using an UTF-8
capable editor, consider adding an UTF-8 BOM,
consider using {$CODEPAGE UTF8}
,
see FPC source codepage option).
If you use the texture-font-to-pascal
utility to embed fonts in
Pascal sources (see above) then use it's parameter --sample-text
to provide the additional (beyond simple ASCII) chars. Like this:
texture-font-to-pascal --size 20 MyFontFile.ttf --sample-text '你好世界ΓειασουκόσμεЗдравствуймир'
And make sure that your command-line, and/or your script interpreter, correcly handles UTF-8 (on Linux, this should be a breeze, since everything works with UTF-8 out of the box; on modern Windows it should also work).
You can use the CastleLocalizationGetText
for a localization approach based on GetText.
You use standard GetText formats for translating (PO, MO) and utilizing GetText tools like PoEdit. You can automatically translate strings in Pascal code, declared as resourcestring
(use CastleTranslateResourceStrings
). You can automatically translate user interface (use TranslateAllDesigns
). You can generate starting file to translate user interface (use GenerateGetTextPo
).
A typical workflow for translating an application looks like this:
Generate POT (PO Template) files containing everything to translate:
Generate POT file to translate the user interface
by calling GenerateGetTextPo('castle-data:/gui/*.castle-user-interface');
.
Place the resulting contents in user_interface.pot
.
Generate POT file to translate all resourcestrings
using the rstconv
tool from FPC.
Place the resulting contents in game.pot
.
Create and translate the PO files for each language you support.
For each xxx.pot
,
create a file xxx.<language-code>.po
.
For example for Polish translation you would create files like
game.pl.po
and
user_interface.pl.po
.
For Japanese translation you would create files
game.ja.po
and
user_interface.ja.po
.
Note that game.xx.po
should contain
a map from English text -> localized (Polish, Japanese etc.) text.
In contrast, user_interface.xx.po
should contain
a map from internal identifier (qualified component names) -> localized (Polish, Japanese etc.) text.
Both approaches are possible with GetText.
You can create and edit PO files using any GetText PO editor, like PoEdit. The PO is a text file format, so you can use any regular text editor (like Atom or Emacs) as well.
Generate MO files from PO using the GetText msgfmt
tool.
Some editors like PoEdit may also do this automatically.
In effect you will get
game.pl.mo
,
user_interface.pl.mo
(Polish translation) and
game.ja.mo
,
user_interface.ja.mo
(Japanese translation).
Place these MO files inside the data directory of your application.
In game, determine user preferred language, e.g. using
CastleSystemLanguage
.
Then translate things by loading appropriate MO file.
To translate all user interface that will be loaded,
call TranslateAllDesigns('castle-data:/translations/user_interface.ja.mo');
(where "ja" stands for Japanese localization, just an example).
To translate resourcestrings, call
CastleTranslateResourceStrings('castle-data:/translations/game.ja.mo');
.
For more details and example how to do it all see the README and source code of our example application using CastleLocalizationGetText (examples/localization/gettext/).
You can tweak this workflow to your needs by using various other routines from
CastleLocalizationGetText
unit and overriding TCastleComponent.TranslateProperties
.
You can use more POT / PO files for your own needs.
You can translate strings explicitly at any moment, using
TMOFile.Translate('my_id').
The engine uses resourcestrings for some internally-generated messages, so these can be translated too.
NOTE: While this functionality is still available, we advise to rather render all text using TCastleLabel
(in UI) or TCastleText
(in viewport, maybe in 3D).
Instead of using TCastleLabel
, you can explicitly draw the text. For this you need an instance of the TCastleAbstractFont
class. To make it easy, one global instance of this class is already created for you: UIFont
(part of CastleControls
unit). So you can simply draw text like this:
UIFont.Print(10, 10, Yellow, 'Some text to print');
You should place such drawing code inside a render method, for example inside the TCastleWindow.OnRender
or TCastleControl.OnRender
or inside the overridden TCastleUserInterface.Render
implementation. See the manual about 2D drawing for a general info about 2D rendering.
TCastleAbstractFont
class has a lot of methods and properties.
TCastleAbstractFont.Print
).
TCastleAbstractFont.Size
).
TCastleAbstractFont.Outline
,
TCastleAbstractFont.OutlineColor
).
TCastleAbstractFont.TextWidth
,
TCastleAbstractFont.TextHeight
,
TCastleAbstractFont.TextSize
,
TCastleAbstractFont.RowHeight
...).
TCastleAbstractFont.PrintRect
,
TCastleAbstractFont.PrintRectMultiline
,
TCastleAbstractFont.PrintStrings
,
TCastleAbstractFont.PrintBrokenString
and other methods).
NOTE: While this functionality is still available, we advise to rather load fonts from TTF / OTF. It is more flexible.
Instead of loading the font data from a file, you can also provide
a TTextureFontData
instance to the TCastleFont
constructor. This allows to create the font data at runtime
or to use the font data embedded in a Pascal source code.
You can use the texture-font-to-pascal
program (compile it from
castle_game_engine/tools/texture-font-to-pascal/texture-font-to-pascal.lpr
)
to convert a font file into a Pascal unit:
texture-font-to-pascal --size 20 MyFontFile.ttf
In response, it will create a unit called
CastleTextureFont_MyFontFile_20
with a public function:
function TextureFont_MyFontFile_20: TTextureFontData;
You can use this unit in your program, and create a font instance like this:
MyNewFont := TCastleFont.Create(Application { any TComponent to act as owner }); MyNewFont.Load(TextureFont_MyFontFile_20);
The advantages of embedding a font inside a Pascal unit are:
The disadvantages are of course that you cannot simply change the font file anymore,
you need to rerun the texture-font-to-pascal
command
and recompile your program to see the new font.
NOTE: This localization approach is deprecated, as it has less features than the GetText approach.
You can use our own localization approach from the
CastleLocalization
unit. It can read from a number of translation formats (XML, JSON, CSV, GetText MO). It can translate user-interface controls, like TCastleLabel
. The demo is inside examples/localization/custom/.
For advanced users, the system allows to aid in localizing your custom classes too (see
OnUpdateLocalization
)
and to add your own translation formats (see
FileLoader
).
As with GetText approach, you can use a cross-platform CastleSystemLanguage
unit that tells you the preferred user language. You can also translate strings "explicitly" using the
Localization.Items['my_id']
in CastleLocalization.
Thousand thanks go to Benedikt Magnus for developing this approach!
This localization approach is deprecated.
CastleLocalizationGetText
offers more features:
resourcestrings
(so the constant strings in code are "magically" translated),
GenerateGetTextPo
(generating translation template),
TranslateAllDesigns
(automatic translation of all deserialized components),
TCastleComponent.TranslateProperties
(mutiple translatable properties on a component are possible).