1. Our demo examples/fonts/test_local_characters was improved a lot.

   It’s now both simpler and more powerful, shows the advised approaches: just set up TCastleFont to load fonts from TTF/OTF and assign it to TCastleUserInterfaceFont.CustomFont (like TCastleLabel.CustomFont) or TCastleText.CustomFont.

   See manual about text and fonts.

2. With big thanks to Freedomax, our TCastleEdit now works with Windows IME much better. The IME popup appears at a proper place, and is thus visibly associated with the input box. This is great for languages relying on IME for input, like Chinese. See PR 457 for movie how it looks.

3. The way we calculate font sizes is now easily customizable using published properties (available also in editor):

   • TCastleAbstractFont.MeasureHeight,
   • TCastleAbstractFont.MeasureCapHeight,
   • TCastleAbstractFont.MeasureDescenderHeight,

4. Font sizes have also better names, following standard conventions:

   • TCastleAbstractFont.Height (previous RowHeight)
   • TCastleAbstractFont.CapHeight (previous RowHeightBase)
   • TCastleAbstractFont.DescenderHeight (previous Descend)

   See terminology: Metric typographic units – Wikipedia, Glossary – Google Fonts.

I’m proud to announce I’ll be part of International Pascal Congress, an event taking place July 3-7 (this year, 2023) in the Salamanca city (Spain).

You can register now (see the registration page for prices)! Note that 1st early registration phase is only up to the 10th April, and registering early costs less.

The program is full of talks and presentations that should be appealing to every Pascal user, coming both from FPC (e.g. Michael Van Canneyt will give a talk “Free Pascal: Past, Present and Future”) and Delphi (e.g. Marco Cantù will give a talk “Delphi’s Object Pascal Evolution”). See the Plenary talks for details.

And of course from yours truly 🙂 I will be:

1. Making one of keynote lectures titled “Developing games and graphic visualizations in Pascal”.

   This will be an overview of the most important concepts of developing graphic applications, including in particular 3D visualizations and games, and how to do them in practical Pascal applications.

   We will start with an overview of APIs, like OpenGL(ES) and Vulkan, and their most important concepts like shaders.

   We will show how to use these graphic APIs from Pascal, from various Delphi (like Firemonkey 3D) and Lazarus (like TOpenGLControl) components.

   Then we will move to high-level libraries and game engines, like

   • Castle Game Engine (support us on Patreon),

   • Apus Game Engine (support Ivan Polyacov on Patreon),

   • and BeRo projects (RNL, Kraft, PasVulkan; support support Benjamin Rosseaux on Patreon).

   Finally I will talk about the important features you should consider when choosing a library (and creating your own): 3D model formats (how and why are formats like glTF and X3D developed), PBR (physically based rendering), mixing 2D and 3D, physics and more.

2. I will give a course Developing games using Castle Game Engine.

   The course consists of 4 sessions, throughout which I’ll present using CGE to make 3D and 2D games, with physics, user interface, spatial sounds, and even using GitHub Actions.

Read all the information on International Pascal Congress. See you in Salamanca! 🙂

As a fan of Tremulous, I’m happy to announce big improvements to our MD3 file format support.

Note that we still recommend glTF as the best 3D model format in general. MD3 is an older model format, with some known limitations (precalculated frames per second, no PBR, no runtime manipulation of rig…) but it is just so fun and easy to support that I couldn’t resist adding a few features 🙂

1. New example examples/animations/md3_animations_tags shows using MD3 animations, tags and skins.

2. Manual page dedicated to MD3 documents everything about our support.

3. Multiple animations from MD3 file are supported in natural way.

   We read animation.cfg automatically when you load MD3 into TCastleScene.

   You can play MD3 animations using TCastleSceneCore.PlayAnimation or TCastleSceneCore.AutoAnimation, list animations using TCastleSceneCore.AnimationsList and so on. See manual about running animations from code.

   This also means you can set animations in CGE editor (TCastleSceneCore.AutoAnimation property is a combo-box there to choose animation).

   You can also play MD3 animations in view3dscene (open “Animations” panel).

4. Optimized reading vertexes and triangles from MD3.

5. Tags from MD3 are supported. Tags in MD3 are places where you can attach additional things to the model, e.g. a weapon to a character’s hand. This way the weapon will be animated naturally along with the character’s hand movement.

   We support them now in CGE, and you can use ExposeTransforms mechanism to attach anything to an MD3 tag (you can attach another MD3 model or anything else, any CGE TCastleTransform and TCastleScene).

6. You can choose MD3 skin. While by default for xxx.md3 we load xxx_default.skin, but you can now change the skin, by adding an anchor like #skin:yyy to the URL. For example, loading head.md3#skin:light will load the skin from head_light.skin.

Have fun 🙂

New example split_long_md3_animation_into_logical_pieces shows how to play subanimations in MD3 files. In a broader context, it shows how to use TCastleSceneCore.ForceAnimationPose to manually “drive” the animation, picking the animation frames you want.

The MD3 format comes from Quake 3 and it’s used by various games sharing that game engine. In particular I’m a big fan of Tremulous so this example naturally shows Tremulous cool low-poly aliens rendered and animated using Castle Game Engine 🙂

The MD3 file itself doesn’t specify particular animations, it is essentially one long animation that in practice usually contains glued a number of “subanimations” in our terminology. The accompanying animation.cfg specifies the “subanimations”, where do they start and finish. The example code defined a ready class that loads animation.cfg, and allows to query and easily play “subanimations” specified there.

If you use MD3 files with accompanying animation.cfg files, you will find the class TSceneSubAnimations to be a ready-to-use component that allows you to deal with MD3 animations easily.

If you’re looking into more general “how can I manually control the animation” then look under the hood and see how is the TCastleSceneCore.ForceAnimationPose used there.

Here’s a quick demo:

Following the Tiled improvements and optimizations done in January, it was most natural to introduce a dedicated class TCastleTiledMap that represents a Tiled map in a viewport. It descends from TCastleTransform and thus can be moved, rotated, scaled (in 2D or 3D), just like anything else in the viewport.

The usage demo, along with many sample maps, is in examples/tiled/map_viewer_in_viewport.

Most important Tiled-specific API:

• TCastleTiledMap.URL – map to load

• TCastleTiledMap.SmoothScaling – controls texture filtering

• TCastleTiledMap.SmoothScalingSafeBorders or TCastleTiledMap.ForceTilesetSpacing – provide 2 alternative ways to deal with smooth scaling artifacts, when TCastleTiledMap.SmoothScaling is used with tilesets not perfectly prepared for it.

• TCastleTiledMap.Map – read-only map data (as TCastleTiledMapData), may be used e.g. to query what tile type lies at some map position.

• TCastleTiledMap.Layers – choose which layers to render; this can also be used to split map into 2 pieces, e.g. front and back, and place them at distinct Z values: simply use 2 instances of TCastleTiledMap with disjoint layers.

• TCastleTiledMap.PlayAnimations, TCastleTiledMap.StopAnimations – control animations. By default, Tiled animations automatically play when the map is loaded.

The full documentation is in Tiled map manual page.

Many thanks go to Freedomax for implementing animations on Tiled maps and providing a lot of Tiled fixes (seams fix, ForceTilesetSpacing, proper Z-order of tiles in all situations, relative URL fix…) and examples!

New TCastleSceneCore.Cache property allows to load the scene contents through a shared cache. If you have multiple TCastleScene loaded from the same URL, this is a sure way to speedup loading of them.

Testcase: examples/viewport_and_scenes/occlusion_culling, where I set up multiple buildings and creatures from the same glTF.

Alternative: You can actually achieve even more optimization (loading time, memory use) using TCastleTransformReference or (equivalent internally) just adding the same TCastleScene instance multiple times to the viewport. These techniques allow to really have one instance and just draw it multiple times — this is a much more powerful optimization, but also puts more constraints: all the referenced things must have the same animation, occlusion culling doesn’t work on them etc.

In contrast, using TCastleSceneCore.Cache is much safer, it doesn’t really change how things work at all from the developer perspective. Each scene may be in a different state, play different animation etc. We just internally load them faster. And it is simpler to use, just toggle the Cache checkbox and observe the speed boost.

Related: Do you want to measure the loading speed, e.g. to compare what do you gain by cache? See the advise about “profiling” in our manual. To cut the long story short, I advise to do Profiler.Enabled := true in your initialization, and observe the report about what takes time at initialization in the log. For more about TCastleProfiler, see the API docs.

How this cache works now, and what is the future: Right now, it works by internally storing the nodes graph in the cache, and instead of loading a file again — we can just do TX3DNode.DeepCopy to clone the graph. This is nice, but actually in the future it could be even better: if we change how our animations work to do not modify the graph, then actually all cached scenes could just use one and the same graph. This is a possible future optimization.

If you like this, please support us on Patreon!

You know the drill — our quarterly meeting on Discord, open to everyone, is this weekend! Join us and talk about Castle Game Engine 🙂

The meeting will happen at 15:00 (UTC timezone) this Saturday, March 18th, 2023.

Simply join our Discord chat and go to the #open_meeting channel.

You can just visit this link to land in the channel directly. Or use this link to see the event details (click on “…” to see options to add it to your calendar, mark it “I am interested” etc.).

Agenda:

1. Presentation of new CGE features. We have a lot of stuff from lately done features and I actually hope to add some more before Saturday 🙂

2. Our plans for the immediate future.

3. Your turn! Everyone is welcome to take the stage!

   Show what you are working on. Show your project, component, game, anything even loosely related to CGE is OK.

   Do you have any questions? We will be happy to answer them live.

Our OpenGL and OpenGLES code is now more streamlined, which allowed to “unlock” various rendering features on OpenGLES.

This means we will use some features from OpenGL ES 3.0, if it is available:

• Occlusion Culling, that is also showcased in a new demo examples/viewport_and_scenes/occlusion_culling.

• 3D textures (example data in demo-models, look in texturing_advanced subdirectory).

• Using glBlitFramebuffer to get FBO results to image.

• Modern way to query OpenGLES extensions by index.

• Fixed, and more efficient than ever on mobile, shadow maps using shadow samplers in OpenGLES 3. I already mentioned shadow volumes and shaow maps improvements on mobile in past news.

• Loading DDS and KTX with explicit mipmaps (using GL_TEXTURE_MAX_LEVEL).

Note that we still require only OpenGL ES 2.0. The OpenGL ES 3.0 features are optional for us.

Moreover:

• Anisotropic filtering is now supported on OpenGLES, through an almost universally-available extension, just like on the desktop. See e.g. anisotropic_filtering demo. (Yeah, we should have a more comfortable way to adjust anisotropic filtering visually — I have 2 ideas about this, will explore them.)

• We also fixed support for rendering shapes that require 32-bit indexes. While OpenGLES 2.0 guarantees only 16-bit indexes (OpenGLES 3.0 bumps it to 32-bit), we now automatically deal with it inside a renderer, if necessary doing additional processing to enable bigger meshes even for OpenGLES 2.0. This can be tested using fps_game on mobile.

Many laptops come now with 2 GPUs: a slower one that consumes less battery and a “dedicated” GPU consuming more battery but capable of much better speeds, esp. when used with non-trivial 3D data. The CGE editor and your applications automatically use the “dedicated” GPU now.

More information about this feature, the documentation how to disable it, and how to upgrade your existing projects to follow: Dedicated GPU.

1. New component TCastleMask allows to define a mask (using an arbitrary UI control) and use this mask to limit rendering the children.

   The mask may be any UI control (or a composition of it). The colors do not matter, only which pixels are drawn by the mask. E.g. you can define a mask using

   • An image (TCastleImageControl) with alpha channel. Be sure to set TCastleImageControl.AlphaChannel to acTest.

   • A viewport (TCastleViewport), maybe even with something animated and/or 3D. Be sure to set TCastleViewport.Transparent to true.

   • A shape (like TCastleRectangleControl, TCastleShape).

   The masked children, in turn, can also be any UI control. So you can filter rendering of anything, even if it’s interactive (like a button) or 3D (like a viewport).

   TCastleMask.MaskRendering determines if the children are rendered where the mask is visible or (on the contrary) where the mask is not visible.

   See the example examples/user_interface/mask for demonstration.

2. I improved the default look of our sliders (TCastleFloatSlider, TCastleIntegerSlider).

   These sliders are quite useful, esp. for various demos and tools (view3dscene uses them to test animations and lights). Well, they no longer look ugly 🙂 and their design allows an optional label inside (useful to communicate to user exact numerical value behind the slider).

3. I implemented a special way of treating protected sides for images. By default they do normal 9-slice scaling but a new option allows to scale corners horizontally to match the image height: TCastleImagePersistent.ProtectedSidesScaling, pssMatchHeight.

   Admittedly it’s a bit easier to see than to explain with words, so if you’re curious, just try it out with an image like SliderBackground that has exactly circular left and right endings. Thanks to the new option, they will stay circular, no matter how you resize the slider.