We’re happy to announce a new demo project, showcasing our Castle Game Engine and mORMot 2 working together!

mORMot (1 and 2) is an open-source Pascal framework (just like our engine!) providing networking and database solutions, at a few layers. You can use it for ORM (easily synchronize and persist objects), classic client-server (HTTP REST communication), peer-to-peer communication (like WebSockets), database access and many other things.

We present a demo showcasing that Castle Game Engine and mORMot 2 can cooperate seamlessly, and together achieve something really cool:

https://github.com/castle-engine/castle-and-mormot-collaborative-editing/

The demo presents a collaborative editing of 3D world. Features:

• Multiple clients can edit a 3D world online.
• It’s synchronized using ORM with a server.
• The server in turn stores the world contents in a database (so it survives server restarts).
• Each client can add, remove, modify (move, rotate, scale) 3D objects in the world.
• The changes are immediately visible to all other clients.
• mORMot 2 takes care of all the network communication and database persistence.
• Castle Game Engine takes care of displaying: showing and updating the 3D world, allowing user to move/rotate/scale by nice gizmos (using CastleTransformManipulate), allowing camera movement in 3D.

Instructions to build and run the demo are in the README file. You will need the latest Castle Game Engine and mORMot 2. Latest versions, from GIT master branches of both projects, have been tested today.

In related news, we have recently updated our URL and networking documentation, and this was a great moment to mention mORMot at the latter. Check out new:

• URLs, loading (downloading) and saving
• Multi-player (networking) options

Enjoy, and as always — any feedback is welcome!

We implemented multiple improvements around TCastleTransformReference, making it easier to use, have more options, be more optimal and correct in certain cases. Overall, we think that after these improvements, you will use TCastleTransformReference much more often 🙂

The TCastleTransformReference is a component that allows to use the same TCastleTransform multiple times in the viewport. This can imply using the same TCastleScene many times or using a whole hierarchy of TCastleTransform multiple times in one viewport. The technique implies we point to the same TCastleTransform from multiple parents, so the same pointer is present multiple times in the TCastleTransform graph. This is sometimes a very powerful optimization: having a million TCastleTransformReference means you display a million trees, but we still have only one tree in the memory, with one set of GPU resources (VBO etc.). Rendering it will be fast and memory-efficient. On the other hand, this technique also imposes some limits: as all instances are really one object, it must have the same state, e.g. play the same moment of the same animation.

Our engine has other features to cache things between models (even when not using TCastleTransformReference, we cache textures, shaders, we make an effort to cache VBOs too). But using TCastleTransformReference triumphs (in terms of efficiency) everything: everything has to be shared across all references, because they are really just one object underneath.

What we effectively want to achieve by improvements below: encourage you to use TCastleTransformReference more often!

• It’s available with an easy menu item (“Duplicate Linked”) and key shortcut (Ctrl + Shift + D),

• it behaves in a more intuitive way (thanks to ignoring target transformation by default),

• and if you change your mind — you can always “escape” from sharing by using “Edit (Make Independent Copy) Referenced Transform”.

The choice between “Duplicate” and “Duplicate Linked” comes down to answering “will I want to modify this clone”, and if the answer is “probably not” -> then “Duplicate Linked (TCastleTransformReference)” is an excellent choice. So you can use TCastleTransformReference and reap the benefits (i.e. enjoy smaller resource usage) when it makes sense.

Thanks go to DiggiDoggi for providing a lot of useful feedback, testcases and analysis that ultimately resulted in these improvements!

The changes are:

1. First of all, the display of reference (TCastleTransformReference) is no longer affected by the transformation (translation, rotation, scale) of the target (in TCastleTransformReference.Reference). This makes the relation between reference and target more intuitive. You can move target independently of the reference.

   You can adjust this behavior using TCastleTransformReference.ReferenceTransformation: rtIgnoreTransform is now the default, while rtDoNotIgnore restores the old behavior. And sometimes the rtIgnoreTranslation is useful, to ignore only translation but still apply rotation and scale from the target.

2. New menu item “Duplicate Linked (TCastleTransformReference)” is available in both the main menu (in “Edit”) and in the context menu (right-click on source transformation in the hierarchy).

   It creates a TCastleTransformReference that points to the selected transformation object.

   The shortcut is Ctrl+Shift+D, similar to Ctrl+D for the regular “Duplicate”.

   The behavior tries to be natural and nice for duplicating multiple times:

   • The created TCastleTransformReference has nice name, Reference + target name (with target numeric suffix removed, and new numeric suffix added for uniqueness of the reference).

   • Doing it when TCastleTransformReference is selected creates another TCastleTransformReference to the same target, not a TCastleTransformReference to TCastleTransformReference (which is technically possible but often not what you need in this case).

   • New TCastleTransformReference starts with copied transformation (translation, rotation, scale) but it is independent from the target (using new default TCastleTransformReference.ReferenceTransformation = rtIgnoreTransform). So it starts in good place and you can move everything in an obvious way.

   • Overall, the idea is that “hitting Ctrl+Shift+D multiple times does what you expect” (creating multiple references to the same target).

   Moreover, this is deliberately similar to Blenders’s command “Duplicate Linked” (Alt+D). The use-case in Blender is similar: create another instance, but sharing all the properties with the original.

   NOTE: The underlying implementation and capabilities differ between Blender and our engine for this functionality. Blender does “Duplicate Linked” by utilizing it’s separation between “Blender Object” and “Blender Mesh”. “Duplicate Linked” in Blender makes new “Blender Object” that links to the same “Blender Mesh”. Our “Duplicate Linked”, doing TCastleTransformReference, is a more powerful beast: we link to the whole source TCastleTransform, which can be any composition of transformations, scenes, behaviors. Still, we think that despite these differences — the basic use-case is similar.

3. Our manual has been updated to mention the new option: TCastleTransformReference, 3D tutorial with car.

4. Examples using TCastleTransformReference have been adjusted too:

   • examples/fps_game
   • examples/terrain
   • examples/viewport_and_scenes/billboards_blending_in_3d
   • examples/viewport_and_scenes/shadows_distance_culling
5. We have additional options in the editor context menu, when you right-click on TCastleTransformReference instance in the hierarchy.
   • “Edit (Make Independent Copy) Referenced Transform”
   • “Revert To Referenced Transform”

   In effect, you can easily “make real copy” (making the TCastleTransformReference act like a basic TCastleTransform container for that copy, and nothing more) or remove that copy. They work in a consistent way with analogous commands for TCastleTransformDesign, which is good.

6. We fixed a bug (crash in debug mode, missing texture in release mode) when you use TCastleTransformReference in certain conditions. Namely, when some references are within a given light radius, the others are not, then the shaders were not setup correctly. This is now fixed. See issue 664 for details and 3 testcases, one testcase is also part of our automatic tests now.

7. We improved optimzation around the TCastleTransformReference, to better account that when you have multiple references, some of them may be affected by different lights than others. See also the same issue 664.

8. We exposed a new option to configure optimization: TCastleScene.TransformOptimization. It may be beneficial to use this for scenes where you change the translation often, and by a large amount: it will prevent recreating shaders needlessly. Much more details are in the TCastleScene.TransformOptimization and TTransformOptimization API documentation.

9. We fixed TCastleStickToSurface coordinate system (not really connected to TCastleTransformReference, although often used together, both TCastleStickToSurface and TCastleTransformReference make sense for planting trees on a terrain). Now moving the TCastleStickToSurface.Target (like a terrain) makes a proper effect, moving also trees.

10. Making the LOD work no longer requires TCastleSceneCore.ProcessEvents. The displayed LOD level is updated regardless of TCastleSceneCore.ProcessEvents.

11. LODs in scenes references by TCastleTransformReference work now perfectly. Each reference displays the correct LOD level. It’s not a problem that multiple TCastleTransformReference instances point to the same TCastleScene while displaying a different LOD level of this scene.

12. The example examples/viewport_and_scenes/level_of_detail_demo/ has been expanded with a demo of it, the README.md there was also updated.

Enjoy! And if you like what we do, please remember to support us on Patreon or in other ways. Have fun making games!

Enjoy a new video overview describing the latest development around web, ifc and zip support!

The video was supposed to be short, it turned out to be 44 minutes long, and it talks about many details. I hope you enjoy it! If you do, please support us on Patreon or in other ways and use our engine for your next game 🙂

Announcing a number of engine improvements from the last weeks:

1. We have a new class for ZIP handling: TCastleZip. Features:
   • Reading ZIP files from any TStream or URL (see networking about our URL support). Just open ZIP by TCastleZip.Open and read by TCastleZip.Read.

   • Create and write ZIP files. Again, with API consistent with our engine, supporting URLs and so on. Just open ZIP by TCastleZip.OpenEmpty and write by TCastleZip.Write.

   • Optionally register a URL handler, to read or write files inside a ZIP archive by just accesing URL with the given prefix. See TCastleZip.RegisterUrlProtocol for an example. Very comfortable to use ZIP throughout our engine. E.g. you can open TCastleScene using an URL that points to a ZIP file, and relative URLs in the scene (e.g. texture names from a 3D format like glTF or X3D) will be automatically resolved to files inside the ZIP archive. Everything else in our engine also in effect supports ZIP, e.g. you can use FileToString or StringToFile to access ZIP files as well.

     Examples are in the linked API docs and in improved examples/network/custom_url_handler.

   • Works with both FPC and Delphi.

   • Has been tested on really wild examples, to make sure it supports out-of-the-box also files with non-ASCII characters (spaces, Polish characters) with all compilers, for both reading and writing. You can see some of the testcases it passes in tests/code/testcases/testcastlezip.pas and tools/build-tool/tests/testtoolutils.pas.

   • Used also internally in our engine, so it’s really well-tested, we rely on the API being functional and implementation being correct. Our build tool uses it, for both packaging web data to zip, and for packing whole application release to zip. Web target also uses it at run-time to read data — castle-data:/ URLs are resolved to a ZIP file that holds your data on the web, by default.

2. Using TAbstractShapeNode.Shading with shWireframe value in Pascal (or shading=”WIREFRAME” in X3D) is now supported for all geometry node types.

   This is a new way for rendering things as wireframe. It looks pretty (quads and other polygons look good in wireframe, as we don’t display diagonals) and it works also on OpenGLES and WebGL (as it doesn’t depend on glPolygonMode).

   See roadmap about our wireframe plans. This a step towards uniform support for TCastleRenderOptions.WireframeEffect, also on mobile (OpenGLES) and web (WebGL).

3. We have added a new simple example examples/viewport_and_scenes/level_of_detail_demo showing how to setup LOD (level of detail) for your 3D models. This is a simple way to optimize rendering, by using simpler geometry for objects that are far away from the camera.

   If you are interested in details, we talk about LOD on the forum thread now too.

4. We support WOFF fonts throughout the engine. Our underlying FreeType already supported them, we just enhanced some filters (in dialog boxes) and improved our documentation to make it official.

   And by the way, our documentation about text and fonts has been improved in various small ways and documentation about localization (translation) is now on a separate page. Hopefully this makes things easier to find.

Do you like what we do? Please support us on Patreon or donate to keep the engine development going! Thank you!

1. You can now easily uninstall Android application or list available Android devices (connnected using USB, paired using Wi-Fi, or running emulated devices).

   Use the new editor menu items in “Run -> Android -> …”.

   Or use the command-line build tool like castle-engine uninstall or castle-engine devices. See the uninstall docs and devices docs.

   The castle-engine devices is a wrapper around adb devices, it also is consistent with flutter devices. The castle-engine uninstall is a wrapper around adb uninstall.

   Note: We recommend to use Android Studio to pair Android devices over Wi-Fi and to manage emulated devices.

2. Fix for Android 15 (on some devices).

   We uncovered a critical problem on Google Pixel 6a after upgrade to Android 15. It looks like Android 15 bug, namely: argv on this device just contains invalid pointers. This was causing applications made using our engine to crash, as we initialize Parameters.

   Workarounded now. Gory details in this commit and this comment with logs.

3. Updated Android applications, like Castle Model Viewer for Mobile, will be available soon.

   They will be released by our new Castle Game Engine account on Google Play.

   New Google verification process forced us to create a new Google Play account… otherwise Google decided it would publish exact Michalis’ private home address for the whole Internet. ( Why? Because the account had payments enabled, even though we never used them, all our apps are free, no in-app purchases, no ads. But Google things they “may earn money” and their decision is irreversible, so says their support and recommended us to make a new account. Thank you for not doxing me, Google. )

4. We introduced TAbstractTextureNode.Color to query texture contents from Pascal code. This is useful e.g. to perform ray-casts that go through transparent texture pixels, see this forum thread.

5. We are working intensively on IFC support in our engine. January improvements include:

   • adding “voids” and connecting windows to wall,

   • examples/ifc improvements,

   • displaying ellipses,

   • displaying bounding boxes,

   • displaying rectangular “profiles”,

   • saving X3D (or any other model format) to IFC (as TIfcBuildingElementProxy),

   • fixed rotations handling,

   • support for TIfcMappedItem,

   • TIfcPolygonalFaceSet.Closed support (toggle backface culling).

6. Work on the web target also continues.

   We have cleaned up various code and merged all the work into the engine master branch. So it’s all safely integrated with the rest of the engine work.

7. You can override the default project platform of the project. While the documentation is now part of the “web target”, it’s a general feature unrelated to web. You can make any target (like web, or Android, or anything else) the default for all the engine commands.

   The default platform set this way is recorded in a file CastleProjectLocalSettings.json, which is a serialized TCastleProjectLocalSettings class. It affects both the editor and command-line build tool usage.

   You can change the default platform by editing this JSON file, or using the menu item “”Run → Platforms → Save Chosen Platform As Default (in Project Local Settings)” in the editor.

8. FPC has solved an issue of unnecessary warnings/notes when using Generics.Collections. Not everything is perfect but it’s a great step forward, addressing the issue in most common cases.

   In response, We have adjusted the warnings/notes hidden by our engine config, to hide less things when being built by the latest FPC 3.3.1 version. This is great, it means you may get some new useful warnings from FPC 3.3.1, because we no longer have to hide the “flood” of unnecessary warnings/notes emitted previously for every Generics.Collections usage.

9. A small new feature is TCircle2DNode.RadiusY which allows to make ellipses (not necessarily proper circle) using the X3D node TCircle2DNode. Test X3D file is here.

10. We have just pushed an important fix to how our “bundled FPC” (distributed with CGE downloads, so that you don’t need to install FPC) cooperates with the build tool. We had a bug previously, that in particular affected usage from our VS Code extension – you could experience errors like Generics.Collections not found.

    Note: At the moment of posting this, this fix is still building. It will be available in downloads in a few hours, once the commit “Find fpc-cge first, because our “bundled FPC” may be on $PATH” disappears from this page.

Finally, we’d like to thank everyone who supports us! Your support on Patreon and other places matters and it allows us to develop all the features you see above. Thank you and have fun!

Let’s make a recap of 2024 and talk about plans for 2025! I included below some new information, so even if you follow our news and roadmap, you shall find something new here 🙂

Before we start, I want to sincerely say thank you to everyone in our community. Thank you for supporting the engine development, thank you for all the kind words, thank you for being with us in our desire for an open-source game engine using modern Pascal. We’ve made a lot of cool things in 2024 and I have big, big plans for 2025 that I think may excite you. So, let’s start!

What we did in 2024

1. First of all, we’ve made a big engine 7.0-alpha.3 release. This release packs a lot of big new features that we’ve been working on for last 2 years. Some of the most prominent ones:
   • Physics with new components, running also in the editor, with joints, layers, forces.

   • A lot of rendering improvements. Blending doing out-of-the-box what you need in many cases, occlusion culling, fully modern OpenGL rendering on new GPU (utilizing OpenGL 3.3 features without anything deprecated) while also reliable rendering for old GPUs (we can fallback even to ancient OpenGL 1.1 versions and work e.g. in Windows virtual machines), OpenGLES (mobile) rendering upgrades to support shadows, 3D textures and more.

   • Visual Studio Code integration. Our own VS Code “Castle Game Engine” extension with code completion, syntax highlighting (for all Pascal code) and integration with Castle Game Engine projects.

     This coincided with my (Michalis) big personal change, as I switched from using Emacs for ~20 years to VS Code as my main text editor.

   • Delphi integration improvements: TCastleControl available for VCL and FMX applications, Delphi packages with IDE support, Delphi Linux support and more.

   • And much more…

2. After the release, we’ve made more improvements:

   • Big optimizations of shadow volumes done.

     In progress: working towards more intuitive shadow maps usage, to make them viable alternative to shadow volumes in all applications.

   • Steam integration, see news.

     In progress: we work on making engine available on Steam as a game development tool, we already started adding integration to editor.

   • Initial version of TCastleMoveAttack and TCastleLiving which allow to have “drag and drop” creature intelligence in your games. See news.

     In progress: we work on making these components honor physics for movement.

   • Support for the IFC, 3D model format used in BIM to design construction of real things. Interoperability with BonsaiBIM, FreeCAD and other tools in the ecosystem. Working with native IFC classes.

     In progress: there’s more IFC features we want to support.

   • Example of integration with mORMot.

     In progress: extend this to really allow collaborative editing (right now the edited world is stored on server, and persisted in database, but multiple clients do not reflect each others’ updates).

3. Last but not least, we have a number of new training materials available:

   • We published a tutorial: 3D physics fun (aka “the bad way to play chess”) which is a great tutorial describing all important engine concepts from scratch. Recommended reading!

   • We published some videos and in particular we encourage you to watch Coding games using Castle Game Engine and Delphi (presented at Emcarcadero Dev Days of Summer).

   • I was quite active at conferences in 2024. Enjoy the slides and examples linked from the conferences page.

   • I made (also presented at conferences) a demo game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack. This is a great example of using the engine to easily make a working FPS game.

Plans for 2025

1. First of all, we work intenstively now on the web target. We’ve made cool progress documented at this page. We’re working right now on finalizing it, adjusting our rendering code to WebGL.

2. Some important things were already mentioned above as “in progress”: more intuitive shadow maps, engine as tool on Steam, TCastleMoveAttack and TCastleLiving following physics, more IFC, collaborative editing with mORMot.

3. I want to announce today our design plan for the package system in our engine. This is our way to build ecosystem of packages around the engine, this is our equivalent to “asset stores” on some other engines, suitable for both code and data and combined packages. I wrote a lot of details in the package system section of the roadmap.

4. Everything planned is collected at our roadmap page. It is updated regularly, so check it out to see what to look for.

Non-technical things

• We lost Eugene Loza, a fellow engine developer.

• For a few months now, Michalis Kamburelis is now working solely on the Castle Game Engine development. Yeah, I have no other job. I count on your donations to make this possible for a longer time! First of all, support us on Patreon. If you have a company, contact me ([email protected]) — we’re open to various forms of cooperation, including paid support and prioritizing features you need.

• Remember you can reach me. For questions that benefit everyone, I recommend asking on the forum where I always try to answer threads ASAP. We also have Discord chat though it’s no secret that lately I’ve been a little offline (no big reason, I just concentrate best on coding when I’m offline). For private questions, just send me an email ([email protected]).

See you all in 2025! Have fun developing games with Castle Game Engine 🙂

Recently I got a very nice question about comparing non-integer values in Pascal (thank you to Jacek Mulawka!).

The core of the question was: Does the condition below (if) evaluate to true or false, and why?

MyVar := 0.1;
if MyVar = 0.1 then
  Writeln('Yes, MyVar equals 0.1')
else
  Writeln('No, MyVar does not equal 0.1');

I created a testcase for this (compiles with both FPC and Delphi) and I provided a lengthy explanation what happens and why in this repository:

How does comparing “MyVar = 0.1” work for different types?

As you can read there, it’s actually quite complex what happens, and depends on both the type, and compiler, and “platform” (“platform” is a term I tend to use to mean “combination of operating system and the processor, OS / CPU”). The short version of the conclusion is: use Math.SameValue to compare non-integers, but I explain much more details (and justified exceptions to this simplified conclusion) in the linked repo, so please read it 🙂

I hope that this overview is helpful to everyone dealing with floats, in Pascal or otherwise 🙂

P.S. The screen attached to this post continues our tradition “if you don’t have anything relevant to show, post something pretty rendered using our engine”. This is a floating castle from Sketchfab created by Shahriar Shahrabi and rendered in our Castle Model Viewer.