Many engine improvements on the road to next release: TCastleShape outlines, VS Code integration improvements, decide which viewport controls listener, packing to zip easier…

Posted on

Flying Cthulhu from Sketchfab by TooManyDemons

As you can see from our increased frequency of news posts, we’re busy busy doing lots of things around the engine πŸ™‚ The primary goal is to push engine 7.0-alpha.3 release out, with the bigger goal on the horizon to finally reach the mythical engine 7.0 release. And then of course do more things, planned after 7.0, like the web platform. As much as I like talking about our roadmap, I like doing it even more!

Remember that we’re listening for your feedback on our forum, Discord, GitHub issues, Reddit, Patreon and everywhere else we can.

And we appreciate if you can support us on Patreon — this is what ultimately allows us to commit more resources toward the engine!

So below, another bag of engine improvements “all across the board” — everyone may find something to enjoy below πŸ™‚ They are all already available in latest engine downloads which are now snapshots, built from latest GitHub code.

  1. TCastleShape more functional: Outline, Filled and related properties undeprecated and implemented for triangles too.

  2. Our LSP server improvements (no more spamming with errors in case of include file without {%MainUnit xxx.pas}.

  3. VS Code extension improvements, in particular fixed behavior with bundled FPC on Linux.

  4. TCastleThirdPersonNavigation fixes and API documentation improvements to work better in case your avatar has non-standard orientation.

    Note that new navigation components are coming, as part of PR 533. But we are committed to maintaining TCastleThirdPersonNavigation for a few releases too — as migrating to new navigation components will not be an automated process, they present quite a bit different API.

  5. TCastleViewport.UpdateSoundListener added, to indicate which viewport controls sound listener. Esp. useful when you have multiple viewports.

  6. Tiled improvements — when when we have a tileset without image atlas (not yet supported, but at least gracefully ignored now).

  7. projector example important fix (do not stretch the texture where it shouldn’t be).

  8. ApplicationData deprecated, and simplified (returns castle-data:... now). This also means that now

    FindFiles(ApplicationData('something'), false, @FoundIndex, nil, [ffRecursive]);

    will work, also on Android. But also, compiling it will clearly encourage you to use castle-data:/something instead.

  9. Removed old deprecated physics components (TRigidBody, TCollider) as they could confuse new engine users, and there was now plenty of time to upgrade πŸ™‚ See physics for description of our physics components.

  10. Packaging to zip is now more reliable: we no longer depend on external zip executable, on most platforms we will use built-in code that packages to zip.

  11. We now specify program name in DPR, to avoid Delphi IDE from breaking code when adding new units.

Comments on the forum ➀

New example demonstrating a few possible animations optimizations

Posted on

Optimize animations

I added a new example showcasing various engine features you can enable to optimize how animations are processed. It is present in examples/animations/optimize_animations_test subdirectory of the engine. Enjoy!

Make sure to make a release (not debug) build to experiment with performance. On my system, I can make FPS between 15 and 60 (which is maximum with vsync=on for my system), depending on the configuration of the switches. So there’s a nice spectrum to show how various options improve the speed.

Read the API reference of the linked options for details — what these things do, when do you want to enable them (and when not):

  • OptimizeExtensiveTransformations and InternalFastTransformUpdate — both especially useful in case of nested transformation hierarchies when many transformations change every frame. Like typical animations done using skeleton, in Spine or glTF. In the future, I hope to be able to actually remove both these flags, and have their respective optimizations always “on” and universal (always beneficial, never losing any functionality)

    I have also fixed OptimizeExtensiveTransformations along the way of preparing this — it had a long-standing bug that prevented from using it. Now it’s all good.

  • TCastleViewport.DynamicBatching also helps, though it is really a rendering optimization (doesn’t affect how animations are processed).

  • TCastleSceneCore.AnimateOnlyWhenVisible does pretty much does what it says :), it only optimizes animations if you look away from them. The invisible animations are not updated, saving time. You can experiment with this by looking away (press right mouse button to activate mouse look in the example).

  • TCastleSceneCore.AnimateSkipTicks is a “brutal” optimization — if you set it to something > 0 then animation just doesn’t update every frame. In this example you can toggle it between 0 (don’t skip) and 1 (skip every other frame). You can experiment with setting it to something even larger, like 2, for even more performance but sacrificing quality.

Comments on the forum ➀

Castle Image Viewer 2.2.0 release, new documentation about KTX and DDS texture formats

Posted on

Castle Image Viewer - leaf with alpha

We have recently updated our Castle Image Viewer to version 2.2.0. Castle Image Viewer is an image viewer developed using Castle Game Engine. It supports many image formats, including common formats (PNG, JPG…) but also some exotic formats useful in game development or just general 3D visualization (KTX, DDS, RGBE). It exposes even limited image editing features, again quite tailored to our gamedev needs — it can in particular perform alpha bleeding.

Depending on your needs, you can download and use it as a standalone image viewer, or you can just consider it part of the Castle Game Engine. When you double-click an image in Castle Game Engine editor, it opens the Castle Image Viewer automatically. The viewer is bundled included in engine downloads already.

Notable improvements:

  1. New name Castle Image Viewer instead of previous castle-view-image. Consistent with Castle Model Viewer rename.

  2. Features all recent CGE improvements and new platforms, in particular it is now built also for Raspberry Pi 64-bit.

  3. We have now dedicated documentation pages about KTX (Khronos Texture Format) and DDS (DirectDraw Surface) Image Format.

Comments on the forum ➀

Android tab in editor preferences, important deserialization fix, Cocos2d rotated frames in sprite sheets, doc outlining ObjFpc and Delphi differences, creating new projects on command-line

Posted on

Viewports with cameras copied in Castle Game Engine editor
Android page in Castle Game Engine editor preferences

As we work towards releasing Castle Game Engine 7.0-alpha.3, we have a bunch of unrelated but important improvements around various engine pieces. Hopefully everyone will find in this list something to enjoy πŸ™‚

  1. Our editor has a new page in preferences to configure “Android SDK location” and “Java location”. You can configure these common settings for Android using simple GUI, instead of messing with environment variables. The change is reflected in latest Android documentation.

  2. We fixed an important issue when deserializing components into an existing owner that already has some children, possibly with conflicting names. This in particular occurs when you Duplicate (Ctrl + D) or copy-paste inter-connected component hierarchies, like a viewport with camera, in the editor. Previously, the links (e.g. assignment of Viewport.Camera) could be wrong in newly added hierarchy. Now they are always correct.

  3. We improved our support for sprite sheets in Cocos2d format. We support now rotated frames.

  4. Our command-line build tool allows now to create a new project, from the specified template. Just execute castle-engine create new-project-name, see the “create” option documentation. Inspired by Flutter tool.

  5. As we work with both FPC and Delphi, on our forum and Discord we sometimes talk about unavoidable (or maybe sometimes avoidable) differences between FPC (and FPC ObjFpc syntax) and Delphi (and FPC Delphi syntax). I collected some of my older notes — this document is not finished, nor is it complete, but I hope it is helpful: Some differences betwen FPC ObjFpc mode and Delphi (and FPC Delphi mode).

Have fun!

Comments on the forum ➀

Example talking with OpenAI (ChatGPT) assistant using Castle Game Engine (from desktop or Android)

Posted on

Castle Game Engine - Talking with OpenAI assistant

I was playing with OpenAI “assistants” lately. Assistant acts like a ChatGPT with which you can talk, but adjusted personally to you — you can instruct the assistant to answer your questions using your guidelines, possibly using a database of your uploaded files and other information. For example, I can instruct assistant to “Call the person asking the question “Gary” and add a cat joke to every answer.”. I can also upload Castle Game Engine documentation in AsciiDoctor format.

Naturally, I thought “How hard it is to actually use the OpenAI API to do this? Can I do this from Castle Game Engine application?”. Turns out it was super-trivial πŸ™‚ Took me 1.5h to have a basic version working. Later I extended it to support mobile and have better UX.

Here’s the result: Use this code as you please. As an example of talking with OpenAI, or just as an example of using TCastleDownload to communicate with any HTTP REST service. See the screenshot to get inspired πŸ™‚

In related news, I have merged a pull request to support custom HTTP headers and request body on Android by Vlad (phomm). This extends the capabilities of our TCastleDownload on Android — which was critical to also make this example run smoothly on Android. Thank you!

Note that I don’t provide binaries for this application. You have to follow the README — get your own API key, create your own assistant, fill their ids as shown in the README. Then compile your own version of this application. Note that using OpenAI API this way is a paid feature — you will need to put some credits, and each query will use it.

Have fun! Like it? Please support us on Patreon!

Comments on the forum ➀

Castle Model Viewer (formerly view3dscene) 5.0.0 release — ton of improvements coming from latest Castle Game Engine, support to validate models, MD3 animations, saving to STL, more X3D 4.0 features

Posted on

Artstation Challenge - Untamed - Cat Duelist - from Sketchfab by Marc_A_D
Artstation Challenge - Untamed - Cat Duelist - from Sketchfab by Marc_A_D
Flying Cthulhu from Sketchfab by TooManyDemons
House Cat from Sketchfab by Alexa Kruckenberg
MD3 Tyrant model from Tremulous

We’re proud to announce a new version 5.0.0 of Castle Model Viewer, previously known as “view3dscene”. This is our tool to view 3D and 2D models in many formats (glTF, X3D, VRML, Spine JSON, MD3, …), and it is powered by the Castle Game Engine.

Along with the viewer, we also release new version of Castle Model Converter (formerly tovrmlx3d), a command-line tool to convert models between various formats.

Underneath, all the released tools use the latest Castle Game Engine version which will soon be released too as 7.0-alpha.3.

New Castle Model Viewer features:

  1. A ton of fixes and optimizations coming from using new Castle Game Engine 7.0-alpha.3. Some highlights (engine features that improve the viewer):

    1. Default fonts include a lot of common Unicode characters, so rendering text in local language in most cases will now just work “out of the box”.

      Almost all common glyphs are included, except the languages that have a lot of specific characters or require specific fonts: Chinese, Japanese, Arabic or similar. If you find your language characters missing, let us know, and we will likely β€œjust add a few more characters” to the default font. Unless your language has really a lot of specific glyphs. If in doubt, really let us know, we will talk and see πŸ™‚

    2. MD3 support improvements: multiple animations supported (we load animation.cfg). Choosing skins. Support for tags. Optimized loading.

    3. X3D 4.0 support improvements, e.g. proper metadata containerField handling for both X3D 4 and 3, and added new X3D 4.0 fields to various nodes.

    4. We changed how we deal with duplicate names in the input (like non-unique names in glTF content). We now rename non-unique node names on input (like glTF) to be unique on output (to guarantee to make valid X3D from valid input glTF).

      See docs: glTF files may have non-unique names, but we advise to generate them to be unique; eventually we’ll force them unique at loading. See also more details in the What to do with node names when importing e.g. glTF? document.

      And see demo of glTF including in X3D: avocado_and_exports. Here the Castle Model Viewer allows to work with the glTF file, despite glTF having duplicate names.

    5. Faster on modern systems, due to using only modern rendering features.

    6. Reliable on older systems, due to better tested “fallback mode” for old OpenGL workings.

    7. Fixes for shaders on older ATI GPUs.

  2. Prettier panel icons and buttons.

  3. Improved menu items to edit materials – you can now reset material, and create any material type (physical, unlit, Phong).

  4. New conversion options of Castle Model Converter:

    1. Option to only validate (--validate)

    2. Read from stdin (with optionally providing the base URL to resolve relative URLs using --stdin-url=URL)

    3. Configure output float precision using --float-precision=DIGITS

    4. 2nd parameter to specify output file name (optional; if you still want to save to stdout, you can influence output type using --stdout-url)

    5. Option to save to STL (binary). Also available in our online converter and “File -> Save As…” in Castle Model Viewer.

    6. We plan to add glTF output to the converter soon.

    7. Converter is also packaged in big engine download, just like the viewer already was. So if you download complete engine, then you already have all our tools, no need to download the viewer and converter separately.

  5. The viewer is packaged with a few example models, find them in the example_models subdirectory of the package. This is a small representative subset of our demo models.

New names – what, why?

As you see, we also renamed our tools. Summary:

The new names should better reflect the features (current and planned) of our tools. In particular:

  • Rename of “tovrmlx3d” to Castle Model Converter allows us to naturally add more output formats. We added STL, we plan to add glTF output soon. This means that Castle Model Converter will be useful to convert both ways, glTF -> X3D (right now) but also X3D -> glTF (soon!).

  • New names make the association with our engine obvious. They communicate “we support all formats supported by Castle Game Engine” which is the point of the tools, they are the “core” CGE tools and will always support everything that CGE supports.

  • New names avoid strict “3D” association. While we support many formats that are usually used for 3D, but the viewer (just like the engine) stays universal and supports also 2D formats. For example, 2D spite sheets, Spine JSON, Tiled maps and even simple images. You can also design and view 2D models in traditional “3D formats” like glTF or X3D.

Please support us on Patreon if you find our tools useful. Thank you!

If you find any issues with our tools, please report them using GitHub issues, or just talk to us on forum, Discord or other places.

Comments on the forum ➀

Models can be saved to X3D or STL now (soon to glTF too), new engine API to register custom model formats that can be loaded/saved, proper handling of duplicate node names in glTF on conversion to X3D

Posted on

Cathedral minecraft model, by Patrix, from

We’re working on a big release of our tools soon! For this week, we have some new inter-connected developments:

  1. First of all, I want our tools to be able to output various model formats, not only X3D. My goal is to be able to write glTF files, with as much features as possible. Thus utilizing glTF as both excellent input (right now!) but also output format (soon!) across our tooling.

    While the glTF output is not ready yet, this week I’ve done a big first step. I added a new trivial output format STL (common file format used in 3D printing) and made our tools capable of this alternative output format.

    This means:

    • The implementation of SaveNode procedure in the engine is now nice and flexible, supporting multiple possible model output formats.

    • Castle Model Viewer has a simpler “Save As” dialog that allows to choose any output format, in particular STL.

    • Castle Model Converter allows and recommends to specify a 2nd parameter, the output filename. The extension of the output determines it’s type. This is usually simpler than outputting to stdout. (But if you still want to output to stdout, you can influence output format using new --stdout-url).

    • Our online model converter can also output STL now.

    • Some old and no longer useful things were removed or deprecated. We removed --force-x3d option from Castle Model Converter (it’s no longer necessary, the output type already indicates when VRML->X3D upgrade is necessary). We deprecated --write-* options of Castle Model Viewer (better use now Castle Model Converter for command-line tasks). We deprecated --encoding, as output type (extension) determines already if it’s X3D classic or XML encoding.

  2. Connected to above: we have great new engine API to register custom model formats. Use RegisterModelFormat and TModelFormat to register format that can be saved/loaded to X3D node. 100% of existing formats were remade to use the new system, resulting in simpler code of the engine too.

    The formats you register this way, can be loaded using LoadNode or TCastleSceneCore.Load and saved using SaveNode.

    Here’s an example how to register Wavefront OBJ reader. Use it as a template — but don’t register exactly this format, as we already handle Wavefront OBJ in the engine πŸ™‚ Remember to associate also extensions with MIME type by extending global UriMimeExtensions dictionary.

    function LoadWavefrontOBJ(const Stream: TStream; const BaseUrl: String): TX3DRootNode;
      ModelFormat: TModelFormat;
      ModelFormat := TModelFormat.Create;
      ModelFormat.OnLoad := {$ifdef FPC}@{$endif} LoadWavefrontOBJ;
      ModelFormat.FileFilterName := 'Wavefront (*.obj)';
  3. Finally, we also changed our strategy to deal with name duplicates on input (like non-unique names in glTF content). We now rename non-unique node names on input (like glTF) to be unique on output (to guarantee to make valid X3D from valid input glTF).

    The result is that valid glTF on input (which means: with possible non-unique names for glTF stuff) should always result in valid X3D on output (which means: X3D node names have to be unique).

    See docs: glTF files may have non-unique names, but we advise to generate them to be unique; eventually we’ll force them unique at loading. See also more details in the What to do with node names when importing e.g. glTF? document.

    And see demo of glTF including in X3D: avocado_and_exports. Here the Castle Model Viewer allows to work with the glTF file, despite glTF having duplicate names.

Comments on the forum ➀

Using GitLab CI with our recommended setup for Castle Game Engine projects: note that GitLab-hosted runners changed tags

Posted on

GitLab CI

A small note (bigger news will come this weekend πŸ™‚ ): If you use GitLab CI, following our recommended setup, and rely on GitLab-hosted runners (available for free for all projects), be sure to update your tags to use new runners:

  • For Linux runner, use saas-linux-small-amd64 instead of just linux. More possibilities and info in Hosted runners on Linux GitLab docs.

  • For Windows runner, use saas-windows-medium-amd64 instead of just windows. More info in Hosted runners on Windows GitLab docs.

Our Test GitLab CI and Castle Game Engine project has been updated with this change, see latest .gitlab-ci.yml.

Comments on the forum ➀

Find (Ctrl+ F) / Find Next (F3) to easily find components by name (useful in large designs)

Posted on

Find in editor

A new feature, small but invaluable, for navigating large designs in our editor: easily find component by name.

  1. Use editor menu item “Edit -> Find” (Ctrl + F) to see a text box where you can type component name.

  2. Typing anything there, like camera, will search and select the first component matching given name (as a substring, ignoring case, so e.g. it will find MyCamera1).

  3. Pressing F3 (or using menu item “Edit -> Find Next”) searches for next occurrence.

  4. Just press Ctrl + F again to hide the search bar. Or leave it be — you can just ignore it and keep working, it will not change your selection unless you explicitly type something into the search bar or press F3.

This allows to move around in a larger designs much easier. An example is the platformer example – see “play” game design.

We have another feature planned to streamline working in large designs: easily hide behaviors or non-visual components (like fonts). By default, our component hierarchy may seem “deeper” than in other game engines because our hierarchy by default contains also behaviors (which in e.g. Unity are delegated to the object inspector). This has some benefits (for both code, and editor copy-pasting, our “behaviors” are just regular components, you can create/copy-paste/drag then just like e.g. TCastleTransform components; they also have names). But the downside is that our hierarchy tree looks “deeper”. We plan to have checkboxes to just easily hide this complication and/or move it to the right sidebar.

Do you like what we do? Please support us on Patreon!

Comments on the forum ➀

Documentation improvements: Android, Indy, ExposeTransforms, Pascal notes

Posted on

Android Studio - SDK location

My presentation of engine mobile features at PascalCafe 2024 has inspired me to polish more our mobile features. There’s something cool coming soon (ups, did I just leak a link to early release only for the bravest testers? yes!).

For today, let me announce a few significant documentation updates around our engine:

  1. Our Android documentation has been improved. I also added some screenshots from Android Studio, and this documentation now more explicitly recommends to just install Android Studio (not only Android command-line tools).

    Whole Android Studio is a larger download, but it is just worth it, in our latest tests. Even if you want to develop only CGE / Pascal applications for Android (not using Java or Kotlin), and you have already a favorite IDE (like VS Code, Lazarus, Delphi)… Android Studio is still very useful. It allows to easily install Android SDK (along with accepting Google licenses), allows to use Android virtual machines or mirror real Android device plugged over USB on your PC (very useful!), also contains already the proper Java version.

  2. There’s a new documentation page Expose scene elements, like children transformations as TCastleScene children. It documents features, current and planned, of TCastleSceneCore.ExposeTransforms. It is a bit different from most of CGE manual, in the sense that in most of CGE manual, I generally document what engine features already exist and rock. In case of this page, while TCastleSceneCore.ExposeTransforms already exists (and rocks πŸ™‚ ), this manual page also describes some plans about how it will rock even more in the future! I consider TCastleSceneCore.ExposeTransforms an important mechanism to enable a few use-cases in CGE.

  3. I improved a bit networking manual chapter, in particular emphasized clearly that TCastleDownload can be used to communicate with backends over HTTP REST and documented the case of known memory leaks with Indy.

  4. Our detecting memory leaks documentation is now more compiler-agnostic, spelling out available solutions in both FPC and Delphi.

  5. I consolidated various slide shows about Castle Game Engine on These come from various conferences where I spoke about CGE.

That’s not the end πŸ™‚ I also wanted to point your attention to some wiki resources about Pascal I wrote in 2023. You can treat them as somewhat “companion” information to our Modern Object Pascal Introduction for Programmers book — maybe not good enough / not precise enough to be included in the book, but may be useful information / advise for all developers using modern Pascal:

  1. Always use FreeAndNil

  2. How to solve EAccessViolation error in Pascal

  3. What are range and overflow checks (and errors) in Pascal

Happy reading everyone! πŸ™‚ Do you like to read? Or maybe you prefer to make games? πŸ™‚ Or both? Please support us on Patreon!

Comments on the forum ➀