Castle Game Engine: April improvements: physics upgrade, sphere casting, layers filtering, easy factory, iOS fixes, image improvements, and more

From Castle Game Engine: link to original post

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.