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.

1. We’ve made a big optimization to processing of large worlds (which means: many TCastleTransform in a viewport), that in particular benefits cases when you use shadow volumes.

   This changes how an important rendering code works. We now make 1 pass to collect all the shapes, and reuse results of this pass a few times — 2x without shadow volumes (because we render opaque and then transparent objects), 4x for shadow volumes (was 5x before the optimization, but I managed to completely remove one). This means that “traversing transformations” (which matters for large worlds) is 2x-5x faster now.

   This matters for a number of applications, in particular it is impactful for applications using shadow volumes and non-trivial amount of scenes: pirates demo for Dev Days of Summery 2024 or games like DSRally from DiDi.

   For some technical details, see notes in the GitHub issue and notes about AddRenderEvent (how to make custom rendering code now).

   (This was done over a month ago, but I finally got to announcing it: ) ).

2. We made a big refactor to the shadow maps processing.

   The immediate benefits are: much simpler code (using shadow maps is no longer entangled with texture coordinate generation in ProjectedTextureCoordinate) and fixes for some cases, like using shadow maps and occlusion texture.

   The more long-term benefits: This opens the door to finally improve shadow maps to work cross-scene and be trivial to activate from editor. The way forward is now clear: remove the TShape.InternalShadowMaps, pass the shadow maps when rendering, thus enabling the shadow maps from one scene to another.

3. Small inspector rendering optimizations, and FrameProfiler shows now also rendering time spent in DrawPrimitive2D and TDrawableImage.

4. Nintendo Switch version updated.

   While we cannot publicly share much details, the overview is simple: the very latest version of the engine is available and tested for Nintendo Switch, using the latest software stack for developing games from Nintendo). We also added “Run -> Platform -> Nintendo Switch” to the editor menu, so building can be done from GUI.

5. Improvement: In the design mode (that is, in editor), we always have precise collisions. You no longer need to worry to toggle TCastleSceneCore.PreciseCollisions just to select things in the editor.

6. Fix: Important fix has been pushed for physics. If you modify a transformation of TCastleTransform that has children TCastleTransform, and these children have physics behaviors (colliders, rigid body) then it’s automatically OK now.

7. Fix: Saved JSONs are a bit shorter. No need to write JSON object for a vector / color with default value.

8. Fix: Container.MousePosition during Motion events could be wrong due to recent Motion events collecting. It’s OK now. This also fixes mdRotate option of the TCastleWalkNavigation.

9. Fix: Billboards in multiple viewports are now rendered OK. This also fixes lights gizmos in editor, when using camera preview. This also fixes lights gizmos in editor in terrain demo blinking.

10. Improvements: examples/lazarus/model_3d_viewer for various UI improvements.

11. Improvements: default .gitignore for new projects is improved to ignore some files produced by Delphi.