Our downloads for Windows include now all the executables code-signed, which means that they are trusted and running the engine will raise fewer alarms from various Windows protection tools. In particular, “Smart App Control” (mentioned also in past news) will no longer block us, randomly preventing you from running compilers or your applications. This applies to all our downloads, including the automatic snapshots made after every commit+push.

We have also decreased a bit the size of our downloads, thanks to a small de-duplication fix and using more compressed formats for some systems (tar.xz for Linux, 7z for Windows).

Let this also be an occasion to ask for your support on Patreon. Your support really matters, enabling me to spend more time working on the engine. Our “infrastructure costs” are rising — the signing, employed now, will cost us an extra 120 USD / year (this comes on top of Apple membership costs, servers costs, domains etc., and on top of my cost of living 🙂 ).

That was the short version of the news 🙂

What follows is a detailed description of how / why we did the signing. I hope it is interesting, in particular if you wonder how to code-sign on Windows yourself, but admittedly there’s a lot of “gory” details below. Read on if you’re brave!

Various solutions to sign on Windows

We have done a lot of research about how / which signing solution to use:

1. I rejected usage of Certum certificates. They are cheap, but using them with CI requires quite some hack with Docker executing GUI application inside. I don’t believe this will be maintainable for a long-run, as we try to use it also for CI builds.

2. I had high hopes but in the end resigned from using SignPath Foundation for OSS projects. It’s a great initiative for open-source projects, “SignPath Foundation” can provide you with tools and sign your executables for free. However, it wasn’t a fit for us:

   • The process puts some constraints how we can use signing, in particular it is not allowed to sign 3rd-party tools (this means bundled FPC in our case) we ship with our engine. See their terms.

   • It also has additional constraints: “Every release needs manual approval for signing.”, signing 48 GB / year. So it’s not really for CI snapshots, only for “real” stable releases (which we should do more often, but that’s another story 🙂 ).

   • It would also practically tie us to GitHub, since their Trusted Build Systems for OSS support only GitHub Actions or AppVeyor, you cannot build anywhere else. And I want to avoid being limited to only these 2 CI systems — I like Codeberg more and more, and GitHub less and less and I want to keep our migration options open 🙂

3. I eventually settled on Azure Artifact Signing (formerly known as Azure Trusted Signing), a signing service straight from Microsoft.

   • It costs (10 USD / m) but it gives us the flexibility we need.

   • Tooling is really good and cross-platform. One can build any script on top of Windows signtool or cross-platform jsign.

   • We can sign everything — engine tools, and compiler we use.

   • It’s really well made to work in CI. The way Azure Login works with OIDC (OpenID Connect) was new to me, and really cool. It took some time to understand and set up… but the end result is really nice. It means that CI system (which can be GitHub, but also Forgejo implements OIDC workload identity federation) creates a token, authenticating that this is a particular project on a particular branch. There’s no need to establish/exchange any secret (that would be an attack possibility on our Azure account) to make signing work from CI.

   • Note: this is not available for individuals outside US/Canada, but luckily I’m a company in Poland so we are eligible for it.

All in all, we have a reliable system, and you shall see all our executables on Windows signed by “Castle Game Engine – Michalis Kamburelis”.

Our scripts to sign in castle-build-ci

Our castle-build-ci repository has now bash scripts to perform signing using Azure Artifact Signing. You’re welcome to use them too, they are generic and documented in castle-build-ci/windows.

As with Apple signing scripts (already done in the past), I decided to design this as bash scripts (portable to all systems, including Windows, and of course all Unix like Linux, FreeBSD, macOS). This is in contrast to using ready GitHub Actions for signing, like this one. Why bash scripts? I explained the reasons in detail here, in short:

• Having this as bash script is more powerful: can be used in the middle of another bash script. And can be passed as InnoSetup command to sign uninstaller too.

• bash script can be tested on a local system, i.e. I can just use the same scripts to sign locally, not in CI. I found this to be a great help when debugging — I don’t need to wait for GitHub Actions to perform first test of the scripts.

• It keeps us more independent from GitHub Actions, which is desirable for me, as I’m really looking forward to jump to Codeberg, and we already test their Woodpecker CI. Forgejo Actions may also be a viable option at some point. I do not want to depend on GitHub for our engine existence.

Signing everything!

FPC builds from castle-fpc are now signed, on both macOS and Windows.

Lazarus builds from castle-lazarus are now signed too, on both macOS and Windows. We don’t bundle it with CGE for now, but it’s ready.

Our Castle Game Engine releases are now signed, by our pack_release.sh script (controlled by GitHub Action workflows). Everything is signed:

• All our tools are signed (castle-engine, castle-editor, castle-model-viewer…).
• Installer and uninstaller are signed.
• pasls (LSP for VS Code and other editors) is signed.
• And bundled FPC is signed, as mentioned above.

Finally, standalone snapshot releases of our viewers are also signed:

• Castle Model Viewer (and converter)
• Castle Image Viewer

The tests confirm this is now good and makes Windows happy. I can install our engine, run editor, see detected (bundled) FPC version, create new project, build it and run — and everything works even with the dreaded “Smart App Control” turned “On”.

Our Pascal Language Server, used by VS Code / VS Codium extension also works without any fuss, as it is also signed.

Size optimizations

We also did some size optimizations, since we’re aware the engine downloads are big, and we’re looking for ways to trim them down (ideally: still keeping examples as part of default downloads).

• We found and removed duplicated binaries of our tools. These needlessly inflated download size by 40-70 MB (depending on system) — fixed now.

• We added alternative archives compressed by 7z (for Windows) and tar.xz (for Linux). These have much smaller sizes than simple zip, lowering download size by ~250 MB (for tar.xz) and even 300+ MB (for 7z). No loss of functionality, just better compression!

  • So, we will continue to provide zip versions, for maximum compatibility…
  • but our default downloads now lead to smaller tar.xz on Linux.
  • (On Windows, we still lead to InnoSetup installer, which is already a better compression than plain zip.)
• We also removed “non bundled” download archives, because maintaining them was becoming too much work, our GHA scripts were getting quite complicated. They were only available for 2 platforms (win64/x86_64 and linux/x86_64) and the size gain from not bundling FPC was < 100 MB after above optimizations.

Thank you!

Woah. This was a big infrastructure change, to make all our Windows stuff signed. Enjoy!

And if you like what we do, and like our long news posts :), please support us on Patreon.

We improved how our engine tools (build tool and editor) call Delphi. These improvements take us closer to making our engine compatible with Delphi for Android, iOS and macOS and improve how you can build with Delphi from shell (e.g. from Continuous Integration workflows) for all platforms.

1. First of all, our build tool, when using Delphi (pass --compiler=delphi), now calls msbuild when you build for non-Windows. We do not directly call dcc* compilers.

   This makes building non-Windows applications with Delphi, using command-line, much easier. Notably, the command castle-engine compile --compiler=delphi --os=linux just works. See using Delphi to build Linux applications.

   Note: pass --verbose to our build tool to see more details about what is executed. In effect, we pass options to msbuild to make it more verbose too. By default, msbuild output will be silent, unless Delphi will report some warnings/hints.

   See our dcc vs msbuild comparison for more explanation.

   We still fallback to using dcc*

   • if we cannot find DPROJ,
   • or if you pass --use-delphi-dcc option to the build tool,
   • or you build for Windows (because using dcc directly avoids the 32k command-line length problem, see dcc vs msbuild comparison).

   Note that this section of the post has been edited 1 day after publishing. We had to change our course. Initially, we tried to use msbuild also for Windows with Delphi > 10, but this was not good, we’ve been hit by the 32k command-line length problem also with Delphi 13.

2. Build tool allows to request specific Delphi version (instead of always calling the latest) using --delphi-version parameter. For example, to compile using Delphi 13, call

   castle-engine compile --delphi-version=37.0 --compiler=delphi

   1	castle-engine compile --delphi-version=37.0 --compiler=delphi

3. When generating DPROJ for your project, we no longer add absolute paths to engine units in DPROJ.

   We used to do this for a long time, knowing it’s not a good solution… time to remove this hack.

   • The hack made DPROJ files, generated in the past, specific to given user on a given machine, since your DPROJ contained something like C:\Users\Michalis\castle-engine\src\... in search paths. This was not nice to put in a version control system or otherwise share with other developers/machines.

   • It also made DPROJ specific to a given CGE version, as we change engine paths between versions.

   New approach: We rely on:

   • If you build from Delphi IDE: you must do “Configure Delphi to Use Engine”, following Installing Delphi Packages instructions.

   • If you build from our build tool or editor: we provide search paths to find the engine (in both dcc and msbuild approaches) automatically, on the command-line, in all cases. You don’t need to do anything.

4. If you have issues with Delphi+Linux and PAServer due to “too new Python on Linux”, see here for solution.

   In short, you have to install older Python (<= 3.12). On Ubuntu it’s easiest to do using Python packages in PPA by “deadsnakes”. Then make sure you symlink PAServer libraries to use that older Python.

5. Maybe you have problems building from Delphi 13 for macOS/Aarch64 (Silicon)? Then we have another tip:

   • you must install the patch from Embarcadero with the fix,

   • then hunt down the new PAServer version for macOS inside the folder like C:\Users\<username>\Documents\Embarcadero\Studio\37.0\CatalogRepository\13.1Patch-May\1.0\PAServer . It is not applied to your Delphi installation, C:\Program Files (x86)\Embarcadero\Studio\37.0\PAServer will still contain the broken version! It’s not obvious as the patch docs merely say “This is copied to the patch download folder.”.

   • Install the PAServer from C:\Users\<username>\Documents\Embarcadero\Studio\37.0\CatalogRepository\13.1Patch-May\1.0\ on your macOS machine, and reimport macOS libraries (“Options -> Deployment -> SDK Manager”).

Thanks for reading and stay tuned for more Delphi news — we are working on something exciting 🙂 As always, we appreciate your support on Patreon.

I gave Claude a long-running task: Review every file of Castle Game Engine.

The process found 11 “real” bugs (something was indeed a bug in the engine, and it could be a bug in real-life applications using the engine) which we promptly fixed. So I’m happy:) See the “Detailed Stats” section at the end for all the numbers.

I will describe the process below, to give some pointers how to do it on your own codebases. In short: fine-tune the instructions to get quality reviews, watch for agent trying to avoid doing real reviews, use Docker SBX to run securely unattended.

Note: If you want to know my general thoughts/experience about using AI with Castle Game Engine, see AI guidelines for Castle Game Engine. A short version: let’s work to gain understanding / be smarter thanks to AI, and not to lose understanding / be dumber. AI can do impressive stuff, but can also be terribly unreliable — in fact the post below is another good example of both of those facts being true at the same time.

For some independent AI opinion that I agree with, see links at the bottom of our guidelines, and also I recently read from a creator of open-source AI harness Pi “Thoughts on slowing the fuck down”.

Motivation: AI reviews (subset of them) are useful

1. AI reviews of commits/PRs by Claude are useful in my experience. Using commands like review staged, review unstaged, review unmerged is consistently giving me useful suggestions how to improve the code before I push it.

   I have to emphasize that by useful I mean that they contain useful bits. Of course they are also filled with nonsense — AI misunderstanding what the application/engine around it does, misunderstanding differences between FPC/Delphi or particular platforms, suggesting bad approaches (always with confidence), suggesting “defensive” coding techniques that would actually hide problems instead of keeping the flow validated…

   But if you’re prepared + capable of filtering out the nonsense, you’re left with useful observations how to improve the code. AI reviews do sometimes note a real improvement or even real bug-fix that my own eyes didn’t catch — that’s why I use it. It’s a special case of “many eyeballs make all the bugs shallow” rule, here AI is another set of eyeballs.

   ( This of course also deserves a disclaimer: Don’t write bad quality code just because you can rely that “AI review” will smooth it out. It will not, it will not capture all the wrong edge-cases if your design is flawed, it will not do the thinking for you. Use AI as a helper, not as replacement for your own thinking/understanding. )

2. So, why am I using AI reviews only for new code that I commit? Let’s review all the past code!

3. A bonus note about security, especially if you develop an application where security is a concern (you consume untrusted input, from network or game MODs — see how this applies to games / game engines too): this approach could be focused to perform a “security audit”.

   You don’t need Mythos to do it:) And, to be serious, the bad actors will do such review of your code, esp. if you’re open-source and your code is just public. So you better do the audit yourself, and fix the issues before they are exploited.

How I did this: on tuning the reviews quality/verbosity and Docker sbx

The details how I set this up (so that you can consider doing this for your own codebase too):

1. Initial prompt. At the start, I asked to review the engine, file by file, starting from src/ and provide a review for each file.

   Note: Our engine already includes CLAUDE.md to help Claude follow our rules better. If you don’t have such file, I would recommend to create and maintain it — it really helps to “steer” Claude in a good direction. To make it available to non-Claude agents, use AGENTS.md and point to it from CLAUDE.md.

2. Fine-tune to get useful reviews. It took some fine-tuning to make the initial prompt really useful.

   At the beginning, it tended to produce overly-verbose and useless reviews — often discussing with itself (like “Bug! X does Y. Oh, no wait, it is actually OK. Not a bug”.) or pointing to not important details (to give it credit, it sometimes flagged such notes as nit-picking indeed).

   Instructing it to give more concise reports… resulted in getting simple review “No definite bugs found.” for all engine files:) Well that’s also useless, of course.

   In the end, we found a middle ground, although effectively I cannot share with you “just a single prompt to do this”, because the end result is a conversation and pointing into examples what to do / what not to do. For some files, I got “No bugs.”, for some others I got txt files with 1-2 issues to correct.

   The point is: you need to look at initial reviews, and consider if they are too verbose/succinct, and give feedback to steer it in the useful direction. Otherwise browsing a 4000 sloppy reviews will be a huge pointless job for you.

3. It was worth it! The issues detected (after the fine-tuning above) are genuinely useful reports. Real, meaty bugs that I missed over the years. E.g.

   • Our fallback from OpenGLES 3 to OpenGLES 2 (important to support older mobile devices) was broken.

   • Loading non-mono sounds on the web was broken.

   • FMOD priority was passed inverted (we marked the most important sounds -> as the least important)

   • Genuine bugs, that could affect real applications! So I’m really happy I did this. Later section of this post “Detailed Stats” contains all the links.

   • It also reported a few minors – typos in documentation, and things “potentially buggy, but not really possible in real-life usage”. But after the above fine-tuning, this wasn’t a terrible flood of noise, and I’m happy to fix the genuine typos too.

4. Fixing them manually or not? Initially I considered letting Claude also fix the issues by itself.

   • But in the end, I fixed most of them manually (i.e. I’m still using AI code completion through GitHub Copilot, but not AI agent) since the AI agent “fixes” mostly required fixes on top of them. It didn’t add automated tests, it didn’t make code clean (centralizing logic). Reviewing + fixing agent work was taking me longer than “just doing” them in the way I want from start.

   • And some reviews were plain wrong. E.g. it wanted to break TCastleTouchControl by limiting speed, because it wanted to adapt visual clamping to speed clamping — without understanding that the current version is actually what we want, more functional to use.

5. Place reviews in .ai-review subdirs. I started by instructing Claude to show me the review, and only continue once I acknowledge. This was of course not good in the long-run, it needlessly blocked the work, so I switched to “put each review in a txt file alongside the source, and don’t wait for my confirmation to move on”.

   In the end I switched to “put each review in a .ai-review subdirectory, e.g. review for src/foo.pas goes to src/.ai-review/foo.txt“.

   This allowed me to easily ignore these reviews in version control, by adding .ai-review/ to GIT exclusions (e.g. in .git/info/exclude, so the exclusions themselves remain private to me).

6. Exclude auto-generated and 3rd party stuff. I fine-tuned which files to include / exclude. I did want to go through entire engine (sources, examples, tools etc.). But I excluded auto-generated files (like LPK, DPROJ, auto-generated per-node includes in src/scene/x3d/auto_generated_node_helpers/) and 3rd-party units code (like Vampyre Imaging).

7. Watch it, as it tries to abort / avoid doing the work! I needed to push Claude to actually do all the reviews, unattended. I used /goal to enforce it, and it worked… only to some extent.

   Claude started to avoid work by doing “shallow” reviews of most files — and happily reported “No bugs found” for ~1000 files while admitting it only scanned them. (grepped for potential issues, not read). I instructed to use “deep review”, and again enforced it using /goal.

   Then Claude lied to me that it “finished the work” while it turned out it only processed 3 sub-directories in src and the rest was quickly scanned. Not surprisingly, the “scanned sub-directories” did not contain any issues according to the review. This is hilariously unreliable:) I just kept looking what it’s doing and asking for the “deep review” when I saw it tries to mass-qualify a bunch of files as “No bugs found”.

8. This used multiple 4h sessions. This was a very long-running task. Multiple times I exhausted my “tokens in 4h window” limit from Claude Code. I was ready and OK for this, I just waited, and later/next day said “continue”.

9. Docker SBX rocks for unattended agent usage. I wanted it to run without interaction, since otherwise I’m a human bottleneck and I mostly just accept the commands executed. (some of the commands could not be auto-accepted by a useful pattern.)

   So I wanted to run with --dangerously-skip-permissions, but that’s something you should never do without being in a secure container. ( Really, don’t ignore this warning. Esp. for longer-running tasks where you don’t observe everything the AI is doing. Letting it run with --dangerously-skip-permissions will lead to a disaster!, weird things will happen at least in your repo (and maybe beyond) and you will not even know what/why happened. )

   Solution: I run the session of Claude inside Docker’s sbx which is a fantastic tool to run AI agents in a sandbox. Docker containers are obvious solution for isolation of agents, and sbx makes using them for this specific purpose a breeze. It creates containers with read-write mount on your disk, so you can inspect the work (and even commit+push) comfortably on your host system, while AI runs in a really isolated environment.

   I highly recommend this approach for any longer-running AI tasks. It’s really a relief to just run inside sbx with --dangerously-skip-permissions, so you’re no longer a dummy clicking “yes I allow” (and constantly break your work to look at Claude state) and you can just let it run. You don’t specifically need sbx for this, since any virtualization Docker-like solution could achieve this — but I found sbx to just fit me right out-of-the-box, and I already use Docker for other stuff so this felt “I’m at home” for me.

10. Moving conversations from outside to inside SBX. As I didn’t start with the sbx approach, I started with a normal session outside sbx -> so then resumed work in a session inside sbx. I wondered about copying around ~/.claude to make this resume smooth, but in the end it was enough to carry the “current review state” in a collection of Markdown files, and just point the new session to them, and also copy a bunch of “memory files”.

All in all, I do recommend this process, I guess, to everyone if you have some “tokens to spare”. As pointed above — the process had flaws, you need to fine-tune the verbosity/quality of the reviews, you need to make sure it’s really doing it (and not lying to you). But it also had real gains — real, user-affecting bugs have been found and fixed in the engine thanks to this.

Detailed stats

If you’re curious, detailed stats and links to what was fixed:

• 11 bugs I would classify as important (real bugs, affecting potential real use-cases):
  1. GLES 3->2 fallback

  2. stereo WAV files for WebAudio backen

  3. FMOD priority inverted

  4. S3TC vertical flip for some heights

  5. SaveScreen on TCastleControl ignored SaveRect

  6. 3D images with TransformRGB, ModulateRGB

  7. secure shell quoting for Delphi+Linux OpenUrl / OpenDocument; note that we later removed this in favor of new ExecuteCommand logic

  8. TCastleFontFamily with Size=0 but Outline<>0 was buggy

  9. mismatched parameter types, float vs double, in C header files vs Pascal implementation

  10. slightly wrong, washed out, PLY colors

  11. wrong opacity interpretation in PLY files

• 8 very minor bugs (unlikely this affected any real use-case, but yeah, the bug is real):

  1. FitWithin, TSprite

  2. more

  3. more

  4. more

  5. more

  6. more

  7. more

  8. CastleScript’s image_load never returned TGrayscale[Alpha]Image

• 2 very minor memory leaks (unlikely to affect any real usage):

  • this is a subset of this commit
• Few minors – error messages improvements, obvious comments/typo fixes:
  • here

  • here

  • and here.

And that’s it 🙂 Thank you for reading.

If you like what we’re doing, please support the engine development. Thank you!

We refactored our process running code (when one application wants to run another). This is used throughout our tools (build tool, editor) but we also have uses for it in the engine itself. Refactoring this into a nice unit gives us more possibilities, for now and for the future:)

1. The code is now in a nice unit CastleInternalProcess available throughout the engine, with TCastleProcess class and our routines like ExecuteCommand, ExecuteCommandCapture.
   • As the name suggests, we still consider this an internal unit, so if you decide to use it in your own applications -> you risk that we break API.

   • That said, there’s no hiding that the unit is useful right now, with FPC+Delphi capability to run processes. Let us know how do you use it, and maybe we’ll just rename it to CastleProcess at some point.

   • Since this is internal now, the API docs are not generated by PasDoc, but you can just read the source code for the docs in comments.

2. The code is simpler and better organized than previous code in build tool / editor. Some of the old internal code had “historical baggage” (e.g. how is environment overridden for the child process) which was cleaned up now.

3. Since all usage now goes through TCastleProcess, we can reliably make a better error message when execution on Windows is blocked by “Smart App Control”. FPC Process was showing cryptic “Failed to execute  : 4551” message in this case. This is quite important — as this message is killing our usage on Windows now!

   • Note that this Reddit comment with cited Microsoft documentation tells the simple version of what happens: “Smart App Control” checks if the application is “known”, and if not -> checks does it have a valid signature. As that comment says: “it effectively just prevents you running any programs that don’t have a digital signature”.

   • Proper codesigning is coming ASAP too. I see that with “Smart App Control”, right now our experience on Windows is really bad. We have started our SignPath process, I need to finish it.

4. TCastleProcess and helpers are now implemented also for Delphi (for Windows, Linux, macOS/Intel, macOS/Aarch64).

   • This also opens the door to have e.g. our build tool compile-able with Delphi in the future. It’s not a high-priority goal (it is an engine tool, you should not need to recompile it yourself), but it aligns with our goal “support Delphi as good as FPC”. On more practical grounds, compiling code with Delphi is always a useful “extra check” of the code correctness.
5. We feature helpers like:

   • ExecuteCommand – wait for the executed process to finish, don’t capture anything, return status.

   • ExecuteCommandCheckStatus – wait for the executed process to finish, don’t capture anything, raise exception if non-zero status.

   • ExecuteCommandCapture – wait for the executed process to finish, capture stdout/stderr to string. This one is for now still FPC-only.

6. OpenDocument, OpenUrl on Unix are simpler now — they just use TCastleProcess through a simple ExecuteCommandNoWait, with both compilers.

1. We have a new example: Music Player, a simple application that allows to play a chosen audio track with UI similar to typical mobile music/audiobook players.

   This example has a nice backstory: For Mother’s Day (which is 26th May in Poland) my daughter and I made a gift for The Wife: a private application (Android apk) with a few audio tracks just for her. There’s an audio track with my daughter signing, with our cat meowing and other gems:)

   Don’t worry, the version I committed as our Castle Game Engine demo has more mainstream sounds :), using open-source audio tracks from OpenGameArt.org. Big thanks go to The Cynic Project (see also Pixelsphere project) for the cool public domain music tracks! See the credits for details about audio and art authors.

   Have fun extending this into your own ideas and I hope this inspires you to have fun with our engine:)

   Try out the example playing on the web right now! Though it looks best in portrait aspect, like on mobile.

   In a bit related news, please sign and spread the word about the need to keep Android open. Sadly, Google plans to practically break this important aspect of Android, which will prohibit making such fun experiments like “family Android app” and endanger more important use-cases (like distributing VPN apps in countries with totalitarian regimes).

2. We have a few important audio fixes in the engine (thanks to experience with above example, but also a review done by Claude — more on this in a future news post):

   • TCastlePlayingSound.Offset for streaming sounds is now correctly read, and when trying to set it we make a clear warning that this is not supported. Please uncheck TCastleSound.Stream if you want to change audio track offset at runtime. (Before this fix, both getting and setting offset was broken, without any warning.) This applies only to the OpenAL sound backend, which is default on most platforms.

   • Loading stereo (or other non-mono) WAV sounds on the web has been fixed.

   • Priority of sounds was mistakenly inverted when using FMOD (we marked “most important sounds” as “least important” by accident), fixed now.

3. We have fixed loading float textures on OpenGLES (Android, iOS). This makes our optimized skinned animation work in an optimal way on your phones.

4. We made important glTF skinned animation fix (affecting all platforms): multiple skins that affect the same skeleton are now supported (if equivalent) or at least cleanly tolerated (we make a clear warning, and render part of the model as static).

   E.g. these Mini Characters from Kenney were broken, now they are fixed. See the forum thread for gory details what was broken and how it was fixed.

As always, we hope you have fun developing games and we appreciate your support on Patreon. Thank you!

Shaders on web fixes:

Our shaders on the web platform can render now all our effects:

1. Bump mapping (normal maps). As shown by demos:
   • bump_mapping (source code).

   • creature_behaviors (source code).

   • third_person_navigation (source code).

   • game_3d_sound (source code).

2. ClipPlane X3D node, useful to clip part of 3D/2D content when rendering. The node can be instantiated using Pascal class TClipPlaneNode or by writing X3D file like this:

   #X3D V3.2 utf8 PROFILE Interchange ClipPlane { plane 1 0 0 -100 } Inline { url "my_model.gltf" }

   1 2 3 4 5 6 7 8

   #X3D V3.2 utf8 PROFILE Interchange   ClipPlane {   plane 1 0 0 -100 }   Inline { url "my_model.gltf" }

   Save this as my_cut_model.x3dv and open (using our Castle Model Viewer, or from Pascal load it using our TCastleScene). In effect, you will see my_model.gltf but cut by a 3D plane. To be precise, the plane equation is Ax+By+Cz+D=0 with the (A,B,C,D) values given by the ClipPlane.plane vector above. The points we render are ones that satisfy Ax+By+Cz+D>=0, so they are in half-space determined by the plane.

3. Fog.

   • Example in eye_of_beholder (source code).
4. TCastleTerrain shader.
   • Used by terrain example (source code).
   • Note: Water used in this demo doesn’t work on web yet — we need to fix our FBO on web.
5. Shader effects using varying, like “time to shader” in Castle Model Viewer (Mobile) on web.

The above features failed to work in the past due to a bug in ANGLE, library used to processes shaders (and optionally render) in both Firefox and Chromium-based browsers (I test with Vivaldi).

• There’s a real bug in the latest Firefox that was affecting us — and it is workarounded now in our engine, so our games rock in Firefox. See my Firefox bugreport and reproduction of the bug, with details why/how ANGLE processes some shaders incorrectly.

• The ANGLE version in the latest Vivaldi is already OK (there was a period when it also exhibited issues).

Occlusion culling on web:

We have fixed how occlusion culling works on the web. We needed to account for the fact that occlusion queries on the web can run for multiple frames.

See the running demo here: occlusion_culling (source code).

Unholy Society demo on web:

We have updated The Unholy Society web demo. We fixed audio, comic bubbles size, “pope call” animation (using ClipPlane, see above). Overall, at this point the complete game works on the web and yes, you can just play it for free here 🙂

Note that the web version doesn’t support persistent savegames (reloading the page will reset the game state), which is of course something we plan to fix soon.

Enjoy and please support us on Patreon to make it possible to continue improving the engine!

We have implemented audio playback on the web. Underneath we use WebAudio API but you don’t really need to know anything about it — just use Castle Game Engine sound API and components and everything will work on the web.

Try these examples (links below lead to ready builds — they should work out-of-the-box in your browser):

• Platformer game (Source code)

• Play Sounds (Source code)

  Be sure to test edge-cases, like tweaking pitch/volume at runtime and stopping sound prematurely:)

• 3D Sound Demo (Source code)

  Note to the last example: “mouse look” is not correct yet, the mouse cursor is visible and it can be offscreen. That’s a TODO I plan to address next.

We have documented some important notes about WebAudio here, a short recap:

• Audio playback will be in a suspended state when loading the page in modern web browsers. Audio starts in response to user interaction with a page, like clicking any button. You can solve it also by putting your web application inside an iframe with allow="autoplay", which is done e.g. by wrapper generated for HTML games on itch.io.

• OggVorbis and other formats support relies on the sound decoding support on the browser side. The exception is WAV format support, which we decode on the engine side.

We also did a few improvements around the sound formats API, which benefits all platforms by improving our cross-platform API.

• The old TSoundDataFormat enum (with 4 values: mono 8-bit, stereo 8-bit, mono 16-bit, stereo 16-bit) is now gone. It was needlessly limiting us to 4 arbitrary combinations of channels/format.

• We expose new property TCastleSound.Channels, as Cardinal. This can express sound files with more than 2 channels, like Quadraphonic. Already playable by some backends, like FMOD and new WebAudio. Our OpenAL could also play them in the future, see extensions to provide surround sound buffer formats.

• We have an internal sound sample format (not exposed by public API), which describes just formats we decode on the engine side right now. It’s right now just pcm 8-bit (unsigned) or pcm 16-bit (signed) but can be easily extended. Moreover, it is now only used when we decode on the engine side — because some backends (FMOD and WebAudio) are capable of decompressing + playing without passing through our engine, so are not limited to these formats. E.g. FMOD can also use float sound data.

• Sound frequency in TCastleSound.Frequency type changed from Cardinal to Single. This again matches better full FMOD and WebAudio backends capabilities. Prefer to express it as TSoundFrequency type, in case in the future we need to upgrade this to Double.

• We tested and documented that some backends (again FMOD and WebAudio) support more sound formats (like mp3 and flac).

We hope you like our work and we appreciate your support on Patreon!

We already announced some new features in April (PLY, InlineGeometry, web: URL parameters and TCastleDownload). Below we report more goodies 🙂 Enjoy!

1. Check out Training Timer 2: Zero Time project by Serufu Yua, available for Windows and Android. Downloads on itch.io and source code on GitHub (thank you!).

   See also ready UI list box components also from Serufu Yua. Thank you!

2. View changes (setting Container.View:=.., calling Container.PushView, Container.PopView) may be now performed with a delay. We have extensive documentation what it means, and why we do it, here. The forum thread, with even more information and reasons, is here. Thanks to Vlad (Phomm) for reporting this — this was a critical design problem we had, now “defused”.

   Please note that this change may require to adjust your code in some cases. We tried to make it backward-compatible, and in many cases it is, but it cannot be 100% — inherently, some things are now done later -> so some assumptions break.

   For example, you can no longer assume that new view is started right after PushView:

   procedure TViewMainMenu.ButtonClick; begin Container.PushView(ViewInventory); // THIS IS LIKELY INVALID NOW, // published ViewInventory.Label1 is not initialized // because ViewInventory.Start is not yet done. ViewInventory.Label1.Caption := 'Something'; // Solution is to pass information using a public field, // which will be applied in TViewInventory.Start: ViewInventory.DesiredLabel1Caption := 'Something'; end;

   1 2 3 4 5 6 7 8 9 10 11 12 13

   procedure TViewMainMenu.ButtonClick; begin   Container.PushView(ViewInventory);     // THIS IS LIKELY INVALID NOW,   // published ViewInventory.Label1 is not initialized   // because ViewInventory.Start is not yet done.   ViewInventory.Label1.Caption := 'Something';     // Solution is to pass information using a public field,   // which will be applied in TViewInventory.Start:   ViewInventory.DesiredLabel1Caption := 'Something'; end;

   Another example (of logic that will no longer work) is if you assumed that old view is stopped right away:

   procedure TViewMainMenu.ButtonClick; begin Container.View := nil; // THIS IS INVALID NOW, // if you assumed that ViewPlay.Stop is already executed // and did something with LastSavedSaveGame. LastSavedSaveGame.Done := true; end;

   1 2 3 4 5 6 7 8 9

   procedure TViewMainMenu.ButtonClick; begin   Container.View := nil;     // THIS IS INVALID NOW,   // if you assumed that ViewPlay.Stop is already executed   // and did something with LastSavedSaveGame.   LastSavedSaveGame.Done := true; end;

3. We have a new utility to process URLs of the model (useful before saving it) to e.g. force URLs to be relative or embedded. See ProcessUrls and TUrlProcessing API for the possibilities. See also pull request for all details. Thank you to Jan Adamec for implementing this!

4. We have added documentation how to install web prerequisites using “WA” button in FpcUpDeluxe. Thanks to Vlad (Phomm)!

5. I (Michalis) attended FOSS Backstage 2026 conference recently and enjoyed a lot of talks with fellow open-source devs (and walking in Berlin!). The talk “AI generated violations of FOSS Licences” was in particular informative, and fun, and sad -> because AIs indeed ignore copyrights and licenses. To put it bluntly, all the open-source code in the wild has been abused — it is now reproduced, ignoring copyrights. Watch it and maybe you can spot the back of my bald(ing) head in the front :).

   There’s a lot of related discussion and opinions, see e.g. here at Gitea and this article.

   I have added a suitable section about it to our AI guidelines.

6. Finally, something in progress: we work on audio playback on the web using WebAudio. Current progress is on branch webaudio. Details what works / what needs to be completed before merge in forum post here.

Enjoy using our engine? Please support us on Patreon. And have fun making games:)

We add 2 new features to our web target:

1. New methods to read URL through which your page was accessed, and get query parameters of this URL. The use-case is creating webpages that react to URL parameters, e.g. expose a model viewer on URL like https://viewer.castle-engine.io/?url=http://example.org/model.gltf (working version of this coming soon!). Use these methods:
   • Application.PageUrl – get entire URL as a string,

   • Application.PageUrlQuery – get query part of the URL (the part from ?), as a string,

   • Application.PageUrlParameter – get value of a specific query parameter,

   • Application.PageUrlParameters – get all query parameters as a dictionary

   This API exists on all platforms, just returns nothing on non-web platforms. So you don’t need to use any $ifdef WASI when accessing this.

2. TCastleDownload class works on the web now. It allows to make HTTP requests, e.g. download files or communicate with REST APIs. See URLs, loading resources and Multi-player (network communication) for general usage description.

   Underneath, it uses XMLHttpRequest which is the standard way to make HTTP requests on the web. It supports all HTTP methods, custom headers, progress monitoring and generally all features of our TCastleDownload.

   Examples:

   • examples/network/asynchronous_download/ – simply download real data from various real servers. Downloads asynchronously (without blocking the UI, animations etc.) I added to this example showing (in log) MD5 and SHA-256 checksums of the downloaded contents, so we can easily confirm that indeed it downloads 100% correct data.

   • examples/network/random_image_from_unsplash/ – communicate using REST with Unsplash API. Shows that, beyond simple downloading, also TCastleDownload.HttpHeader works.

   • examples/network/remote_logging/ – send using POST (Request.HttpMethod := hmPost, Request.HttpPostData.Values[ParameterKey] := ParameterValue). I verified on the server (that receives data using simplest PHP script that logs POST parameter) that it received correct data.

   Note that CORS (Cross-Origin Resource Sharing) security will prevent our application on the web from downloading things from other domains.

   This is a standard security feature of web browsers. It is unavoidable from our side (application living inside a web page). All web application (using JS or WebAssembly) have to deal with it.

   • For development, you can disable CORS in your browser. E.g. on Firefox with CORS Everywhere extension does the job. Chrome supports --disable-web-security command-line option. Search the web for details specific to your browser.

   • For real usage, the server has to be configured to allow downloading from it. It generally involves configuring the server to return appropriate header, like Access-Control-Allow-Origin: *. See CORS documentation at MDN and example configuration for Apache.

1. We support now loading models in PLY format, commonly used for 3D scanning and printing.
   • We support all common variants, which means ASCII and binary with any endianness.

   • We support both models with faces (loaded to TIndexedFaceSetNode) and without (loaded to TPointSetNode).

   • As usual, “support” means we support them everywhere in our engine and tools. In particular Castle Model Viewer can load them, Castle Model Converter can convert them (to X3D, IFC, STL and soon to glTF), and in our engine editor you can load them inside TCastleScene.

   • They can also be used with X3D TInlineNode and TInlineGeometryNode nodes.

   • For more information about the format follow our docs.

   • Some testcases: Kaktus from Sketchfab (can be downloaded as PLY source) and our demo-models ply subdirectory.

2. We support X3D InlineGeometry node.

   • It allows to get geometry (polygons, vertexes) from an external 3D model and reuse it with a different appearance (material, textures, shader effects).

   • Our testcase is here.

   • More testcases in X3D archives: here and here.

Have fun with Castle Game Engine and 3D standards!