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.

This post contains a relatively unimpressive screenshot that actually shows a very important achievement 🙂

Things we are working on right now in Castle Game Engine:

1. Web target.

   Yes, it means what you think 🙂 Just recompile any Castle Game Engine project to run in a modern WWW browser! No plugins of course, it’s using JS + WebAssembly, it just works.

   What we have: We have a CGE branch with build tool that can execute castle-engine compile --target=web and then castle-engine run --target=web to:

   • build a wrapper using Pas2js,

   • then build your game using FPC for WebAssembly,

   • generate skeleton HTML file with <canvas> element,

   • run a HTTP server (just compileserver from pas2js, on port 3000),

   • run a WWW browser to open http://localhost:3000/ and execute Pas2js-generated JavaScript that in turn runs the WebAssembly code.

   • The WebAssembly code initializes log (you will see typical CGE log messages in both the browser console and in HTML content), and then opens TCastleWindow with a special WebAssembly backend…

   • …and, nothing more yet 🙂 TODO: We fail at the moment we want to use glGetString. Next steps are known, we need to use WebGL from WebAssembly, and the way to do this seems to use TJSWebGL2RenderingContext from job_web. Stay tuned!

   More information (what we have, what we plan) on the dedicated web target docs.

2. IFC (Industry Foundation Classes) format support.

   It’s “another 3D model format”, ISO standard, that we support. It defines useful concepts for architecture, construction and engineering use-cases. It cooperates with some known applications in the domain, like Revit, ArchiCAD, BonsaiBIM in Blender, FreeCAD and many others. It defines concepts useful for building real-world stuff — the things defined are not only displayed in 3D, they may also have plans, they may have costs, scheduling and other metadata useful for real people making it.

   It’s also quite special — we provide dedicated API for it, using IFC classes, to load (or build from scratch), save and modify IFC models.

   A lot of basics work already. The IFC models can be loaded, modified and saved. We have examples/ifc that shows this.

   TODO: We work on making it now “as complete as possible (though without CSG and NURBS)”.

3. Collaborative editing of 3D world using Castle Game Engine and mORMot2.

   This is a new example using our engine and mORMot 2.

   It shows already how you can modify and render a 3D world using our engine, and send the world information to a server made usign mORMot 2. The server synchronizes world state to a database on disk.

   TODO: The missing feature is “collaborative editing” promised there. Right now actually changes from other users are not synchronized as I envisioned.

Have fun with Castle Game Engine! And if you like what we do — please support us!

This is a small infrastructure change for us, but you can also follow this for your own projects, if you already use GitHub Actions to build your applications.

For some time, we have been using self-hosted real Raspberry Pi machines to build our releases (of Castle Game Engine, Castle Model Viewer and PasDoc) for Raspberry Pi. This includes 32-bit Raspberry Pi (with support also for older OS version, based on Debian bullseye) and 64-bit Raspberry Pi (with support for OS versions >= based on Debian bookworm).

However I was doing tests to see can we use GitHub-hosted Linux runners (thus, available for free, and maintained for us) to build our releases for Raspberry Pi. The idea is to run Raspberry Pi in a virtual machine (not only do cross-compilation to it) to be able to also run tests on it.

Turns out there’s a ready ARM runner GitHub Action that does exactly this. Examples of using this for Pascal applications:

• I’ve done testing can we use it reliably to build FPC + Castle Game Engine applications, which you can see in the repository michaliskambi/test-arm-runner-for-cge. The workflow file inside shows how to build CGE application for Raspberry Pi using this runner.

• I adjusted PasDoc snapshots building to use it. See PasDoc workflow here.

• See also Castle Game Engine workflow.

• See also Castle Model Viewer workflow.

We have switched all our projects to building Raspberry Pi releases using this approach now.

Recently we did some updates to our VS Code extension for Castle Game Engine and the Pascal LSP.

1. VS Code extension now uses the FPC path you set for more things. Namely, the build tool (which is executed when you press “Compile” from VS Code) will reliably use this FPC. This means that there’s no need to have FPC on $PATH anymore to use CGE from VS Code. Just configure FPC location in VS Code and everything should “just work”.

   Further notes:

   • Direct link to the extension in the marketplace.

   • We actively develop our VS Code extension, see the changelog for all details. I (Michalis) use it during all my work on the engine nowadays, so I really need it to be good and handle code in various stages of “in progress” 🙂

   • Reminder: The extension is useful for development of any Pascal projects, whether using Castle Game Engine or not. Pascal syntax highlighting and code completion (provided by LSP) work regardless of the Castle Game Engine. Only the “Compile”, “Run” features rely on CGE project (CastleEngineManifest.xml).

2. Our Pascal LSP (pasls binary present in engine downloads) also got updates. It now better reports errors, capturing all possible Pascal parsing errors and returning useful error messages for them — with filename, line and column number. The idea is that, when working, you naturally sometimes have a code that isn’t (yet!) correct, so the code tools sometimes cannot provide their services (completing, jumping to definition etc.). In such case it’s important that you get useful errors, why is your current code wrong.

   • Reminder: While nowadays we test our LSP mostly with our VS Code extension for Castle Game Engine, but it’s not limited to VS Code. Every editor that supports LSP, including Emacs and NeoVim should be capable of using this LSP for code completion in Pascal projects.

Our website looks a bit different all around since last week 🙂

• We have upgraded the underlying Bootstrap (which serves as the base for our look) from version 3 (rather ancient at this point) to the latest 5.3.

• We took this opportunity to make some small improvements:

  • dark-themed navigational bar,

  • navigational bar properly collapsing on mobile (or just narrow window sizes),

  • search box in the navigation bar,

  • simpler “Donate” button leading to streamlined Donate page,

  • from the main page we have a link “Video Tutorial” to our presentation from Dev Days of Summer 2024.

• In some cases (like link colors and font), we decided to follow the new Bootstrap defaults.

This is a preparation for a bigger website redesign. What we have now, thanks to using the latest Bootstrap 5.3 and thanks to being simple (generally following Bootstrap conventions, with only minor customizations) should lend itself nicely to bigger redesign.

What bigger redesign, you ask? 🙂 Well, we’ve been planning a website redesign for some time now, to make it both more impressive and communicate our intentions better. Attaching to this post a cool main page redesign from Adrianna Matejek. This is something which we want to eventually reach!

We’re proud to present ready Steam integration in Castle Game Engine!

Features:

• Use Steam API to
  • Control achievements (list, get, set state).
  • Get some information (country, language, VR mode, Steam Deck, whether some DLC is installed).
• Works on all supported platforms: Windows, Linux, macOS.
• Works with all supported compilers: FPC, Delphi.
• Ready Pascal unit CastleSteam.
• Ready example in the engine sources: examples/steam.
• We have put deliberate effort into solving some technical things in a clean way: the integration doesn’t need any “wrapper” Steam library (you only need Steam DLL/SO from Valve, not anything additional), the integration code is clean and cross-platform (in particular, we use SteamAPI_ManualDispatch_GetNextCallback and friends – no assembler, no hacks to simulate C++ VMT in order to receive callbacks). This implies that our integration should “just work” on any platform supported by Steam, forever, reliably.
• We have further plans related to this. The most immediate: release Castle Game Engine on Steam! We are finishing setting up our Steam page. Next: add more features from Steam API, like support joysticks using Steam (allows to handle any joystick type, and user can customize the handling in Steam) and Steam Deck-specific API (e.g. activate on-screen keyboard on Steam Deck).

Everything is documented on our Steam documentation page. It has also been mentioned on slides in 2 recent conferences — see Cologne FPC/Lazarus Meeting 2024 slides, Delphi Programmer’s Meeting (Polish) 2024 slides.

This big work has been largely done by the late Eugene Loza.

If you like what we do, we appreciate your donations.