We present a number of improvements to our URL system, which is the basis for all engine resource loading and saving:

1. We introduced castle-config:/ URL protocol, to save files in a system-specific place (directory) that is “persistent” for given user.
   • It points to a specific directory that is by convention writeable and should be used to save user data. For example, something like C:/Users/<username>/AppData/Local/<application_name>/ on Windows or /home/<username>/.config/<application_name>/ on Linux and FreeBSD. We follow system-specific conventions and APIs.
   • This replaces previous ApplicationConfig routine.
   • It is consistent with castle-data:/ which is read-only location with your application data.
2. We added TCastleMemoryFileSystem – useful to create a temporary filesystem, living only in memory, registered at given URL.

   It is, for now, our implementation of castle-config:/ on the web — so the data is not persistent if you reload the page, but at least it makes sense within a single session. This made our portable editor possible. Of course it is a TODO to actually persist the data using WWW browser mechanisms.

   That said, TCastleMemoryFileSystem may be useful for your own purposes too, if you want a temporary virtual filesystem in your application.

3. RegisterUrlProtocol exposes now a class that allows to configure URL behavior. (So we can extend the functionality offered by custom URLs, aka virtual file systems, without adding more and more parameters to RegisterUrlProtocol.)

   • One can register an TRegisteredProtocol.ExistsEvent handler for custom URLs, to configure how UriExists behaves for them.
   • And TRegisteredProtocol.FindFilesEvent , to configure how FindFiles behaves.
4. Many built-in URLs, and URLs pointing to ZIP (using TCastleZip), and URLs pointing to TCastleMemoryFileSystem, use above, so their resources can be tested using UriExists and searched using FindFiles.

5. Queries like UriExists('castle-data:/my_texture.png') on the web are also useful now, as we use castle-data:/auto_generated/CastleDataInformation.xml to test data files existence.

What’s the image shown at this news post? Chibi Gear Solid by glenatron on Sketchfab, cool 3D scene rendered using our Castle Model Viewer. It has no relation to this news post (except that’s it’s rendered using our engine and you can download it too and turn into a game right now!), just something pretty I wanted to show 🙂

I’m traveling back home after enjoying Delphi Day 2025 in Piacenza.

1. I think I’ve made a nice presentation about the engine features.

   Slides are available here and one new (simple and fun 🙂 ) example is part of the engine now: examples/physics/physics_throw_chickens.

   During the talk, I also showed a number of existing projects, including platformer, fps_game, complete FPS game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack (shown first at Zlot 2024).

2. I also watched a number of inspiring presentations from fellow Delphi users. It was really good to see so much activity around Delphi and Pascal!

3. One talk that in particular remains in my memory was about the Afterwarp Framework by Yuriy Kotsarenko. I was truly amazed by some features he shown, in particular the deferred shading implementation combined with shadow maps that allows to have 65k dynamic light sources casting shadows (and he showed demos really proving it — one demo with really ridiculous 65k dynamic lights, one demo with over a thousand lights casting shadows and car with headlights moving through them). Really impressive, and it makes me jealous, and I told him about it 🙂

   To make it happen, deferred rendering is the key (in contrast to the current CGE forward rendering). I was looking into this in the past… but there was never enough time to “attack” it, as it’s a bigger task.

   Edit 1: My intention here is not “let’s just switch to deferred rendering”. The cited Wikipedia page about deferred rendering already mentions disadvantages of this approach, and Afterwarp that inspired me is actually using a hybrid approach (“uses a hybrid forward, deferred rendering using clustered shading”). My intention here is to explore our options for lots of dynamic lights and shadows in the engine, and I note 2 things: 1. it’s high time to focus on shadow maps, as I already wrote in roadmap (see more below) and 2. I want to experiment with deferred rendering.

   Edit 2:: Originally I wrote here that our optimal path to deferred rendering may be to speedup BGFX renderer integration, as BGFX will give us deferred rendering, and we want to have BGFX as alternative renderer anyway. However, while BGFX indeed allows for deferred rendering, it’s a manual approach (not a simple toggle “forward / deferred rendering”). So: 1. we still want to have BGFX!, 2. but it’s independent from deferred rendering, as we can introduce deferred rendering either on top of BGFX or CGE current renderer, with ~similar work.

4. I had a few “nudges” recently to focus more on our shadow maps as a preferred shadows algorithm, and maybe leave the shadow volumes as… maintained, but not default.

   To explain more:

   • In the current engine version, shadow volumes are more comfortable to setup (just click 1 checkbox, if only your models are 2-manifold), while we have a few TODOs to make shadow maps comfortable.

   • But the shadow maps have likely a brighter future: more performance, because you can control the shadow map resolution and frequency of updates, which was pointed both by Afterwarp presentation and recent forum thread where Erik Johnson managed to use our shadow maps with great performance gain. Also, shadow maps work out-of-the-box with our upcoming (not yet merged to master) skinned animation on GPU, while shadow volumes… in short, require fallback to animate skin on CPU (see TODO there for more details). So, again, shadow maps seem to give “more performance, easily”.

   • And of course shadow maps “just work” with any geometry, 2-manifold or not, and even account for alpha testing (e.g. precise shadows cast by typical leaf textures). So there’s no need to worry about whether your 3D model is 2-manifold, and no need to tweak RenderOptions.WholeSceneManifold either.

5. So, thoughts coming from the above:

   • shadow maps improvements are important (and don’t be afraid to make shadow maps, not shadow volumes, default),

   • deferred rendering is important (to experiment with, and maybe come up with a hybrid approach),

   • BGFX renderer is important, albeit independent from us “getting deferred rendering option”.

   OK, this mostly validates our roadmap, with shadow maps before 7.0, and BGFX after 🙂

Have fun everyone! Stay tuned for more technical announcements next week. And if you like what we do please support us e.g. by subscribing on Patreon.

We’ve done a number of improvements to our shaders support, and it starts with one big thing:

We have a new documentation how to use shaders with Castle Game Engine. Recommended reading! This documentation shows the most recommended way to use shaders in Castle Game Engine, combining simplicity with power:

• It starts with up-to-date explanation of why we recommend to use “shader effects” (TEffectNode) to express your shaders.

• It goes through simple practical examples: the most trivial shader, passing time to shader, passing texture to shader, converting eye<->world space (and what does it even mean).

• Points interested readers to all the “advanced” topics and alternative ways to use shaders (sometimes more complicated).

We’ve also improvements to our engine API around shaders, to actually enable everything documented above:

1. We added new SetEffects methods to easily connect TEffectNode with higher-level components that are core of our engine (like TCastleScene) in the simplest possible way. These are:
   • TCastleScene.SetEffects
   • TCastleAbstractPrimitive.SetEffects
   • TCastleImageTransform.SetEffects
   • TCastleBackground.SetEffects
2. We have improved our examples:
   • grouped shader-related examples in examples/shaders/ subdirectory
   • Added shader_effects_simple example (corresponds to the code we create in a tutorial-like sections of the docs).
   • Added shader_effects_on_primitives example (simple test of SetEffects on primitives and TCastleImageTransform).
   • Added shader_effects_on_background example (effects on TCastleBackground).
3. We added property shaderLibraries (string list) to our TEffectNode. In Pascal you set it like this:
   MyEffectNode.SetShaderLibraries(['castle-shader:/EyeWorldSpace.glsl']);

   1	MyEffectNode.SetShaderLibraries(['castle-shader:/EyeWorldSpace.glsl']);

   Right now, the castle-shader:/EyeWorldSpace.glsl is the only possible value you can put there. But the system may be more flexible in the future, allowing us to expose more GLSL libraries (from the engine, using castle-shader:/; other ideas may appear; note that you don’t need this to reuse shader setup in your own application, since you can just reuse own TEffectPartNode multiple times).

   Each “shader library” may define additional GLSL functions. It can also use PLUG_xxx of the shader, thus augmenting the rendering or computation. The uniform values necessary for the library are automatically passed by the engine, so you don’t need to know/do anything more to use it.

   The castle-shader:/EyeWorldSpace.glsl, in particular, defines 4 new GLSL functions, available in both fragment and vertex stages:

   vec4 position_world_to_eye_space(vec4 position_world); vec4 position_eye_to_world_space(vec4 position_eye); vec3 direction_world_to_eye_space(vec3 direction_world); vec3 direction_eye_to_world_space(vec3 direction_eye);

   1 2 3 4 5

   vec4 position_world_to_eye_space(vec4 position_world); vec4 position_eye_to_world_space(vec4 position_eye);   vec3 direction_world_to_eye_space(vec3 direction_world); vec3 direction_eye_to_world_space(vec3 direction_eye);

   Use them in your own shader code. Just make “forward declaration” for them first, like this (effect makes fog depending on point height in world space):

   vec4 position_eye_to_world_space(vec4 position_eye); // Save value obtained in PLUG_fragment_eye_space to use in PLUG_fragment_modify. vec4 vertex_world; // Get the vertex position in world space. void PLUG_fragment_eye_space( const vec4 vertex_eye, inout vec3 normal_eye) { vertex_world = position_eye_to_world_space(vertex_eye); } // Make lower things enveloped in fog (turn into gray). void PLUG_fragment_modify( inout vec4 fragment_color) { const float fog_y_start = 0.5; const float fog_y_max = -5.0; if (vertex_world.y &lt; fog_y_start) { const vec4 bottom_fog_color = vec4(0.1, 0.1, 0.5, 1); float factor = max(0.0, (vertex_world.y - fog_y_max) / (fog_y_start - fog_y_max)); fragment_color = mix(bottom_fog_color, fragment_color, factor); } }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

   vec4 position_eye_to_world_space(vec4 position_eye);   // Save value obtained in PLUG_fragment_eye_space to use in PLUG_fragment_modify. vec4 vertex_world;   // Get the vertex position in world space. void PLUG_fragment_eye_space(   const vec4 vertex_eye,   inout vec3 normal_eye) {   vertex_world = position_eye_to_world_space(vertex_eye); }   // Make lower things enveloped in fog (turn into gray). void PLUG_fragment_modify(   inout vec4 fragment_color) {   const float fog_y_start = 0.5;   const float fog_y_max = -5.0;     if (vertex_world.y < fog_y_start) {     const vec4 bottom_fog_color = vec4(0.1, 0.1, 0.5, 1);     float factor = max(0.0,       (vertex_world.y - fog_y_max) /       (fog_y_start - fog_y_max));     fragment_color = mix(bottom_fog_color, fragment_color, factor);   } }

   The X3D file demonstrating this feature is here.

   The Pascal example demonstrating this feature is here. The “Effect: cube map” is using this to get 3D direction from camera to rendered point, in world space, and then use this direction to query a cubemap (loaded from DDS).

   This deprecates: our Viewpoint.camera*Matrix events. Their usage in practice was only to pass new uniforms to the shaders, but they were complicated to use, needed X3D Viewpoint node, routes, passing events… The new thing is trivial to setup if you already have code dealing with shaders using TEffectPartNode, in Pascal or in X3D. And it is trivial to implement too, it just does literally what you expect, i.e. adds extra GLSL code and makes sure it receives proper input (uniforms).

Have fun using shaders! And if you like it, please consider donating to support the engine development.

We’re proud to present a completely new comfortable API to handle game controllers (which includes gamepads, joysticks and similar devices). Everything is documented, with links to examples, in the dedicated manual page about game controllers.

Highlights of the new support:

1. You receive information about pressing / releasing gamepad buttons by overriding TCastleUserInterface.Press and TCastleUserInterface.Release methods. Usually you define these overridden methods in your view and handling the gamepad buttons is similar to handling key and mouse button presses.

   The simplest example looks like this:

   function TViewMain.Press(const Event: TInputPressRelease): Boolean; begin Result := inherited; if Result then Exit; // allow the ancestor to handle keys // handle key F1 or north button on gamepad if Event.IsKey(keyF1) or Event.IsController(gbNorth) then begin // .. do something Exit(true); // input was handled end; end;

   1 2 3 4 5 6 7 8 9 10 11 12

   function TViewMain.Press(const Event: TInputPressRelease): Boolean; begin   Result := inherited;   if Result then Exit; // allow the ancestor to handle keys     // handle key F1 or north button on gamepad     if Event.IsKey(keyF1) or Event.IsController(gbNorth) then   begin     // .. do something     Exit(true); // input was handled   end; end;

   Follow the documentation for examples.

2. Buttons are expressed using controller-agnostic enumerated values. In particular, the 4 face buttons (sometimes labeled A B X Y, sometimes square triangle circle cross, and occurring in various order on different pads) are called gbNorth, gbEast, gbSouth, gbWest. You can also access buttons’ caption (which is a name to display to user, like A or B) and meaning (which corresponds to the typical meaning of the button, like gmConfirm, gmCancel).

   Note: While the API is ready to support any gamepad in the future, the current mapping on PC (Windows, Linux) just assumes Xbox Controller. Because it seems to be the most common controller. Support to properly detect e.g. PlayStation gamepads connected to PC is coming. This week, we focused on having a simple and future-proof API to make it possible.

3. The axes of controllers are available as simple TGameController functions:

   • TGameController.AxisLeft (left stick, 2D)
   • TGameController.AxisRight (left stick, 2D)
   • TGameController.AxisLeftTrigger (left trigger, 1D)
   • TGameController.AxisRightTrigger (right trigger, 1D)

   Observe them using e.g. Update method of your view. Again, follow the documentation for many examples 🙂

4. The example examples/game_controllers allows to test all this. Shows detected game controllers, reports pressed / released buttons, visualized axes of the selected controller.

   It is a “resurrected” version of the old example examples/deprecated_to_upgrade/joysticsks. But practically almost whole code of that example changed 🙂

5. On top of that, we have expanded our TInputShortcut to accept game controller button press or axis move (and report “how much” it was moved above the dead zone).

6. And on top on the new TInputShortcut capabilities, we give you TCastleWalkNavigation.UseGameController method: a 1-liner to make your TCastleWalkNavigation follow the typical 3D FPS games behaviors. So left stick moves, right stick rotates, you can jump / crouch / run using the typical button layout.

7. New example walk_3d_game_controllers, that Michalis showed at the Delphi Summit 2025 this week, shows a simple demo of a game where you can walk with gamepad and have simple interactions with horses and other weird NPCs 🙂

8. Also our examples/fps_game/ was adjusted to use controllers. We just added the 2 lines below to adjust the game to use the game controller:

   Controllers.Initialize; MyWalkNavigation.UseGameController;

   1 2	Controllers.Initialize; MyWalkNavigation.UseGameController;

9. We started this feature as an upgrade of our old CastleJoysticks unit. We were changing and changing old API (which was somewhat over-complicated, exposing internal system/controller-specific numbers, and weirdly inconsistent with how you handle keys/mouse)… until practically nothing remained.

   So we decided to just break compatibility. Old API was really uncomfortable, and maintaining the backward-compatible “crutches” would risk that we confuse everyone what is the “proper non-deprecated way” of doing things. We also suspect not many people actually used the old API — since you needed to account for internal button and axis numbers that were both system-specific and controller-specific, it was very difficult to make cross-platform applications using the old API.

   Of course, report if you have used old CastleJoysticks and have trouble upgrading. Tell us which exactly things you miss.

10. We also did some important fixes uncovered during code refactors. Disconnecting / reconnecting no longer crashes. It was crashing in at least 2 ways on Windows (free in the middle of iteration, mixed ids on the list vs Windows ids).

11. As you see, our naming changed from “joysticks” to “game controllers”. This follows most of modern naming and APIs.

    • We looked at Steam, Godot, Android and web APIs for gamepads and tries to take the best.
    • We considered using
      • “Joystick”
      • “Gamepad”
      • “Game controller”
    • None of above are really perfect.
      • “Joystick” and “gamepad” are both too narrow, as APIs support both things, because for software they are generally the same thing, just with different physical shape.
      • “Game controller” sounds a bit too wide, as Wikipedia says that even mouse+keyboard is in principle “a kind of a game controller”.
      • In the end, we choose “game controller”, because that’s what Steam and Android call them. Though on web they are gamepads.
      • We know, it’s the longest name possible. If Steam and Android APIs can handle it, so can we 🙂
      • In many places, we shorten “game controller” to just “controller”.
12. Note that this is not the end. We list a number of TODOs at the end of the doc page. They include new TCastleInputAxis and actual support for more gamepad types. But the current work provides a solid foundation for it: we have API that is comfortable to use (simple press/receive, axes) and future-proof (makes sense on various platforms and with various devices).

Enjoy! And as always, if you like the new development, please donate. Your support keep us going.

As many of you know, I looove talking about Castle Game Engine and our many features. But my wife, though she loves me dearly, eventually says “enough” 🙂 So I learned to travel around the world and speak at various conferences. Catch me at these upcoming events:

1. I will be at the Delphi Summit, in Amsterdam (Netherlands), 5-6 June 2025 (next week!). With big thanks to Blaise Pascal Magazine and Detlef Overbeek, we should have a demo of the engine running and available to interact with.

2. I will speak at Delphi Day in Piacenza, Italy, on June 20. I will show our engine for Delphi developers, introducing the engine and showcasing latest developments like IFC, mORMot demos, improved comfortable shader effects (stay tuned for upcoming news post about the details of this!).

3. I will speak at Pascal Conference organized by Sorpetaler, in Sundern (Sauerland, Germany) on 18-21 September 2025.

   • We plan a larger demo of our IFC support to design windows. This will use our engine combined with the Sorpetaler software to achieve something very cool 🙂
   • I will also present other features of the engine, including the web platform.

Please catch me at these events if you’re there! I was serious when I said that I love talking about Castle Game Engine 🙂 Whatever you do with the engine, whatever questions you have, I will be happy to look and talk.

If you cannot attend these events, but live nearby and want to connect — I’m also open to this. Just drop me a mail ([email protected]) and we’ll coordinate it.

Be seeing you!

We’ve been busy in the last months developing our web target! If you haven’t already, check out our video about web support and also a free web game linked in this post 🙂

The new web developments:

1. Let’s start with something big: We have developed proof-of-concept portable version of Castle Game Engine editor that has some of our real editor’s functionality, but is fully developed usign our own UI and runs on the web.

   You can try how it works here.

   Please heed the warnings — this is only a “proof of concept”, it misses many features critical for real usage, including building or even saving your project when you reload the page. Use the “real” editor (developed using LCL, available only on desktops) for the time being. It will be a long time (definitely not in 2025, and not for 7.0 release) before this “portable editor” will become useful for real work.

   That said, this “portable editor” shows that it is possible in the future 🙂 We will be able to just create games, fully in a browser, using Castle Game Engine and FPC. For now, you can create projects, edit views, with our own hierarchy view, object inspector and 3D manipulation. Some developments of it benefit also our inspector invoked by F8 that allows to investigate your view at run-time.

2. OpenUrl is now implemented on the web. it just opens the page using JS window.open.

3. We disable the “context menu” of browser over the HTML <canvas>, which means that using the right mouse button in web applicaitons is now possible.

   We still discourage from relying on the right mouse button in web applications (as it is not available on mobile), but at least it makes sense now on desktops. Note: that on Firefox, users can still use Shift+Right click to open the context menu.

4. We added castle-model-viewer-mobile to web-demos.

   You can view:

   • various pre-packaged 3D files (various formats — glTF, X3D, IFC…)
   • in various models (walk, examine)
   • switch animations, viewports
   • also you can view detailed WebGL information.
   • Cannot open arbitrary files yet — it will come!
5. More 3D demos now run thanks to shader fixes (and some temporary workarounds) on web:
   • Creature behaviors (our simple creature AI, fight with skeletons) (mouse look still TODO!),

   • Eye of Beholder

   • Third-person navigation

   Also we made progress of running more examples, like fps_game, terrain, test_rendering_opengl_capabilities.

6. Shader errors make warnings, not crash, on web. This matches behavior on other platforms (we need extra code to handle this, because on web we cannot rely on catching exceptions).

7. We added ApplicationProperties.CanCatchExceptions to easier handle platforms where this is false (web now).

8. We added Application.MultipleWindowsPossible, to help develop cross-platform apps with a single code. The applications can detect at run-time and change behavior on platforms where only a single window is possible (mobile, console, web).

9. Vampyre Imaging library is now used on web, just like on other platforms, to read some image formats. This adds some formats and has more optimized PNG loading (sometimes 2x over FpImage). Test with image_display example application.

10. New Kraft version was adjusted to work on web too, demo in physics_3d_shooter.

11. We no longer show logs in the page content. (This was using pas2js unit BrowserConsole).

    Now logs are only send to the browser’s console using JS console.log, standard facility how to report logs in web applications. This is better, because

    • browser’s console is not visible by default (user doesn’t see debug things),
    • browser’s console is toggable by developer and most web developers likely know about F12 already,
    • browser’s console has filtering, nice scrolling etc.

    It is still possible to restore BrowserConsole, by

    • uncommenting a symbol in tools/build-tool/data/web/program_js.lpr
    • uncommenting additional HTML things in tools/build-tool/data/web/dist/index.html
12. CastleEngineManifest.xml supports new option for the web HTML generation, <web html_contents="...">. Allows to easily add more HTML content to describe your application. Used by our “The Unholy Society” on web.

13. You can use castle-engine cache --target=web to speedup future compilation. See cache option docs.

14. We use auto_generated/CastleDataInformation.xml on the web, which allows to quickly enumerate and check for existence of data files. (Although our ZIP handling, responsible for our data on web now, can also provide this functionality now.)

15. Our automatic tests can run on the web!

    • We abort some tests on the web – that require platform to be able to catch exceptions.
    • We count all aborted tests.
    • We hide the checkbox “stop at fail” on the web (cannot work since web cannot catch exceptions).
    • The automatic tests is available to run if you want to test it yourself.

      Heed the warning from web page: Don’t be alarmed if a test seems to hang in the middle. The test TTestX3DNodes.TestGltfConversion indeed takes time, around 30 seconds, it knowingly does something quite unoptimal (converting large binary data in glTF to a textual representation in X3D).

16. Lots of updates to the web page documentation and docs linked there. The wasmtime usage docs updated.

17. We optimize now binary size using wasm-opt, which achieves 1/3 size optimization and very noticeable loading speed improvement and very noticeable run-time execution improvement!

    We perform this optimization completely automatically for “release” builds done using CGE build tool / editor. I.e. we just run wasm-opt, if found on $PATH, after FPC made the WASM binary. See section Optional, for extra size/speed optimization: Binaryen (for wasm-opt tool) in docs. We show a simple log what was done:

    wasm-opt found, using it to optimize the release build. ... Optimized .wasm file in 84.64sec, size decrease 34% (from 43.04 MB to 14.61 MB).

    1 2 3

    wasm-opt found, using it to optimize the release build. ... Optimized .wasm file in 84.64sec, size decrease 34% (from 43.04 MB to 14.61 MB).

    All the demos on web docs have been optimized with wasm-opt now.

18. castle-engine package --target=web makes sense now, packages to zip the dist/ contents.

19. We updated everything to follow FPC rename wasi -> wasip1.

20. We also submitted to fpcupdeluxe a fix for the rename wasi -> wasip1, and it’s already applied to the fpcupdeluxe master branch on GitHub.

    However, be aware that (as of now, 2025-05-24) the fpcupdeluxe release (precompiled binaries) with this fix is not available yet. Which means that we recommend you to take fpcupdeluxe master sources and just build it yoursef. FpcUpDeluxe is straightforward to compile with Lazarus.

21. We also submitted Pas2js fix for TJSProgressEvent.Total, already merged.

22. Fixes using WebGL extensions, enabling extensions like anisotropic filtering on WebGL.

23. This is something we made already in ~February, but didn’t announce it properly yet. Here it goes: Web platform automatically embeds custom fonts, to allow you use font files (TTF / OTF / WOFF) in web applications.

    This is our initial attempt at solving the need “allow to use custom fonts (from TTF / OTF / WOFF) without the need for FreeType”.

    Why do we need to solve it?

    • One reason is that getting FreeType to work on all platforms, including mobile (Android and iOS), consoles (Nintendo Switch right now), web (WebAssembly) is a maintenance burden. It is possible!, the FreeType C code is very portable, and for web there are JS alternatives like https://github.com/opentypejs/opentype.js/ . But it is still additional work.

    • Note: We explored one additional avenue, using “EasyFreeType” bundled with LCL (we could extract the code from LCL). This is using pure Pascal solution, based on a very old FreeType source (they originally wrote FreeType in Pascal) from ~1997. Why did we reject this solution? Well, “very old … from 1997” does not sound good from a security perspective or from feature-set perspective 🙂 We need support for at least TTF / OTF / WOFF. We need a solution that accounts for more font formats that may appear.

    • We note one more reason: even if we got FreeType working everywhere at zero maintenance cost, this is still not optimal. Loading font from a FreeType requires to do some job (processing the font file to generate a texture). This takes time, and for distance field fonts it takes even longer. It would be better to just distribute the result of the processing (font texture), IOW: move part of the work from runtime to pre-processing.

    Our current solution to this on web relies on the “embed font by generating Pascal code”. For all the TTF / OTF / WOFF files we find in your data, we generate Pascal unit, which is compiled-in into the application (this is invisible to you, we use this unit from auto-generated web library).

    This works… but we identified a number of issues with it.

    • From a high-level view, this goes contrary to our idea to discourage “embedding by converting to Pascal code”. Maintaininig conversion like texture-font-to-pascal is a burden. And we don’t really need to convert font to Pascal code, we only need to convert it to another data file, jus a file in a more friendly format (something we can read without FreeType). IOW, “embedding to Pascal” needlessly tries to solve 2 things (how to distribute, and how to read) when we only need to solve one (how to read).

    • Practical problem: this generation is not influenced by application needs now. The information about the desired optimal font size, character set — is inside the design, in TCastleFont. Not inside the TTF / OTF / WOFF that we process. So we process with some hardcoded size and “common Unicode” character set, for now — but this is not flexible for all uses.

    • Another practical problem: this generation doesn’t work on Windows now. Because build tool on Windows cannot use shared libraries, which is our easy solution to avoid locking project DLLs by accident. We can invent a better solution to this (build tool should not use project DLLs).

    More information about how we plan to solve it: see web docs, find the section about fonts in “Plans (TODOs)” there.

And that’s… not everything. But we will announce some URL handling improvements, which were also done to benefit the web platform, in a separate news post.

Do you like reading super-long news posts with lots of new engine features? 🙂 If yes, we appreciate your support on Patreon or other ways to donate. Thank you!

We have a number of improvements to announce, so welcome to another “bag of improvements all around the engine” news post! Take a look around, see if you find something you like 🙂 As usual, all the announced improvements are already part of the latest downloads.

1. TCastleComponentFactory is now a non-visual component registered in the editor, so it’s easier to use it. You can just add the factory instance to your view, point it using TCastleComponentFactory.Url to the design that you want to spawn multiple times, and then from code use TCastleComponentFactory.ComponentLoad to spawn multiple instances of the same thing.

   For examples using TCastleComponentFactory like this, see examples/audio/game_3d_sound (the TntFactory: TCastleComponentFactory) or simple_3d_scanning_fun from conference-pascal-cafe-2025 (the FactoryGamepads: TCastleComponentFactory).

   There are more examples in the engine using TCastleComponentFactory, though some create TCastleComponentFactory by code. Like examples/space_shooter. This approach is also of course fine (it is always OK to create in code what can be done in the editor), it depends on what is more comfortable in given case.

2. We have upgraded Kraft, our physics engine to follow the latest developments done by Benjamin “BeRo” Rosseaux. This brings new optimizations and features (see below).

   The upgrade is quite substantial, from version last synchronized on 2019-08-26 to 2025-03-10. We hope to keep in-sync more often in the future, which should be easier because we isolated most of our customizations to separate files like castlekraft.inc and castleinternalkraftoverrides.pas. Our changes revolve around adjustments to platforms and compilers not supported by Kraft, like web, Delphi on Linux or Nintendo Switch. Some of those rely on linking Kraft with some CGE utilities, e.g. for time.

3. Following the Kraft upgrade, we expose a new method in Castle Game Engine: casting a sphere using physics. See TCastleAbstractRootTransform.PhysicsSphereCast, TCastleRigidBody.PhysicsSphereCast. This is similar to casting a ray, but now you move an imagined sphere in a certain direction.

   This is great for implementing navigation using physics. And it synchronizes our “master” branch with the new physics-based navigation components developed by Andrzej Kilijański. Effectively, we have merged part of this PR into master, with some changes and newer Kraft.

   And yes, this means that eventually merging these new physics-based navigation components is closer now. We still want to do some work first (I outlined next TODOs in this comment), but we are getting there. Of course tests are welcome, and if you’re impatient you can also just try to use the components from the PR 🙂

   Aside from this PR, a simple example using PhysicsSphereCast is already available in the engine as part of examples/viewport_and_scenes/collisions.

4. More physics improvements? Sure 🙂 Our TCastleAbstractRootTransform.PhysicsRayCast, TCastleRigidBody.PhysicsRayCast methods have been extended to support layers. They just get an additional parameter CollisionLayers: TPhysicsLayers, by default AllLayers. Customize it to test for collisions only with a subset of your bodies.

   This also synchronizes our work from 2 branches, the new navigation components and hit-api-upgrade. Our master branch gets new features, and other branches get closer to master 🙂

5. Thanks to Vlad (phomm) you can now disable compiling-in support for some formats that you don’t need, to reduce the exe size of your applications. See how to use the CASTLE_xxx_SUPPORT_DISABLE symbols.

   See also PR for more details how much you can gain and why. And also for some thoughts from Michalis “decision paralysis” where I wondered should be do it this or that way 🙂

6. We fixed iOS building and TestFairy integration. Ups! Without oversight of the CI/CD such mistakes can happen. I added to TODO to make automatic test of iOS building through GitHub Actions soon.

   This has been done as we work on Mobile Castle Model Viewer version for iOS! Stay tuned for more details.

7. Our build tool unused-data analysis can now optionally remove some unused files.

   Please heed the warnings there before using it! In short, keep your stuff in a version control 🙂 Which is in general a good idea anyway.

8. We have improved some functionality around images:

   • You can now load image created in code to TCastleImageTransform using TCastleImageTransform.LoadFromImage.

   • We have TDrawableImage.Create overload to create a drawable image with undefined initial state. Just provide the size and format, no need to provide initial contents as TCastleImage instance. Great if you want to fill TDrawableImage with something later.

   • We added new example showing how to draw on an image efficiently and use the result as a texture: examples/images_videos/image_generate_and_use. This demonstrates the 2 above new features, and also presents our recommended way to draw on images using TDrawableImage, with GPU acceleration, with complete rendering features.

9. Finally, we have made UrlEncode and UrlDecode public. Useful to construct URLs to arbitrary files, see TCastleZip.Files for example.

10. BTW, Delphi users, Delphi 12.3 is available and of course our engine was tested and works flawlessly with it. Don’t hesitate to upgrade 🙂

OK, and this is not everything. We still have a number of web and IFC improvements to announce in upcoming dedicated posts. And a new release of our Android apps are in-review. Stay tuned for more!

And if you like what we do, please consider supporting us on Patreon. We count on your support to keep the engine development active. Thank you!

P.S. As I didn’t have a perfect image for this news post, I typed “improvements” into Sketchfab and run with it 🙂 The screenshot shows “Mars One” Mission 3D environment modeled by Admone and displayed using our Castle Model Viewer.

There’s a gift at the end of this news post 🙂

Almost a month ago (time flies fast!), I did a presentation at Pascal Cafe 2025, an annual FPC / Lazarus conference organized by Blaise Pascal Magazine. This time, I didn’t pick one topic for my talk, I decided to showcase a number of cool engine features. The common theme is “you can use the engine to make games for any platform, from any data, using any authoring software and workflow”.

Here are the the presentation slides: https://castle-engine.io/pascalcafe2025

After an introduction to the engine, I talked about:

• New web target development. (More information about progress on this in next news.)

• New IFC format support. (Again, we have more to say here, and it deserves a separate news post coming soon.)

• 3D scanning workflow, using your phone and Scaniverse, Polycam, glTF support, some cleanup in Blender and in the end naturally we load the environment into a Pascal application developed using our Castle Game Engine. Room interior, building exterior, asset like a cup or furniture… lots of 3D things with various sizes can be scanned, even with the simple Android / iPhone in your pocket. A very simple result is in this demo application.

• Our mORMot 2 integration example, which we already announced on this blog: Collaborative online editing of 3D world using Castle Game Engine and mORMot2.

Aaaaand…. One thing that I shown, and now I want to share it publicly, is I believe very cool: you can now play “The Unholy Society” online, in your web browser, for free. This is a game originally developer for Steam, Nintendo Switch, iOS and Android. Thanks to our web support, we could just recompile it and it works on the web!

So just play “The Unholy Society” now by clicking here.

Please enjoy it all and we appreciate if you can support us on Patreon. Thank you!

1. Last week I made a course teaching modern Pascal, organized by BSC (Embarcadero branch in Poland). We started from basics (structural and imperative programming, classes) and went on to advanced things (TComponent, various ways to deal with memory management, class references, generics, and more). It total, it was 2 days * 6 hours. Mostly lectures, i.e. “Michalis talking and showing”, but also with some time to do exercises in Delphi.

   I was happy to got very positive feedback from the participants! To let everyone benefit, I’m publishing materials from it:

   • Repository with all (38, as of now) examples: https://github.com/modern-pascal/modern-pascal-course

   • Slides (in Polish): Day 1, Day 2.

   We used Delphi during the course, but I made sure all information and examples is compatible also with the open-source FPC compiler. For this, we used FPC Delphi mode syntax.

   We use GitHub Actions to make sure this is true: all the examples compile with FPC and Delphi. I created a new GitHub organization for this, https://github.com/modern-pascal/, useful to use my self-hosted runners with Delphi across non-CGE projects.

2. To not stop above, I pushed an upgrade to our Modern Object Pascal Introduction for Programmers.

   This updates a few things, most notably adds a section Compilers and FPC “syntax modes” and adjusts all the text and examples to be relevant for Delphi too. Where the feature is FPC-specific (like CORBA interfaces or global operator overloads), we mention it clearly. Just like with Castle Game Engine, we want to support both compilers in all teaching materials.

   The examples in the book still use the FPC ObjFpc mode, with some differences between ObjFpc and Delphi modes. When using FPC, this is the recommended mode (default in Lazarus and CGE projects), so we want to show it, even though it’s a bit more work.

Have fun with modern Pascal! If you like this work, please support us on Patreon.

We’ve a made a new demo project using Castle Game Engine:

Throw a 6-sided dice, using physics, and cheat to make the outcome predictable. Before throwing the dice, you select the desired outcome, and we guarantee the dice will land the desired face “up”.

Full source code and data are available at https://github.com/castle-engine/castle-dice-throwing.

• You can run the demo in a web browser, done thanks to our web target support.

• You can also download a precompiled version for Windows and Linux.

The dice trajectory is truly random, following physics and some initial (random) parameters. So, how is it possible we can guarantee the outcome?

• First we run the physics simulation without rendering it. It’s a very fast process, takes about 1/50 of the second (so you don’t even notice that we do this whole simulation when you press the button “Throw Dice”).

• Then we apply a local rotation to the dice, to change the simulated outcome (face that is up after simulation) into the desired outcome. Since a dice has the same shape (at least for our physics approximation, and for our human feelings; in reality of course the shape is a bit different from each side), no matter how you rotate it by 90 or 180 degrees around one the primary axis, the rotated dice will look equally good during the same trajectory.

• Only then we actually render the simulation. We simply play the previously-recorded physics simulation.

You can look at the source code, naturally, to see how this is done. The ClickThrow method with the nested procedures StartSimulation and RecordSimulation does the core job. If you build the example yourself, in debug mode (toggle it using the editor “Run -> Debug Mode” menu item, or command-line --mode=debug for the build tool), then additional “debug UI” will be visible, allowing you to tweak the physics parameters and also to perform the simulation without prerecording (so the outcome is unknown).

We hope that you enjoy this demo 🙂 Recording the physics simulation (to later replay it) may have a number of use-cases, we hope that our demo makes it clear how to do it.

If you like this, please consider donating, for example by supporting us on Patreon.