1. Phomm posted about a cool new game he made in our forum: Tower Fight – Samurai Arcade for testing math skills. Available for various platforms including web.

   I recommend also his accompanying post about deploying web builds on itch.io for great instructions how to release your web games on itch.io. There’s a lot of more in that thread, including our immediate plans for more work on the web — stay tuned:)

2. Thanks to above, I updated our “Known Limitations” on the web, to keep knowledge about some necessary limitations (e.g. lack of Application.ProcessMessage) clearly documented.

3. We converted a lot of website pages to the AsciiDoctor, where it’s easier to maintain them. This also resulted in some meaningful updates to some pages:

   1. Screen effects has a new section For Pascal developers: use TCastleScreenEffects with a clear Pascal sample how to use this feature.

   2. Supported compilers info has been updated to mention new Lazarus versions.

   3. Transformation hierarchy has been updated with section titles and more details.

   4. Standard command-line options for GUI programs has been updated to be more complete (it missed a few options) and to make it clear that --fullscreen-custom is deprecated, as changing physical screen resolution is not recommended.

4. We made fixes around skinned animation usage, to account that TSkinNode may be created before rendering context is initialized. Fixes editor crashes when opening files with skinned animation.

5. We improved our check whether float textures are supported. TGLFeatures.TextureFloat is now correct also on mobile and web. This also fixes skinned animation on the web target.

6. We made a small fix to our editor on macOS, to not draw class name when editing component name in the “Hierarchy” view (on the left).

7. We fixed key down/up reporting for letter keys (A, B, …) when using new GTK 3 backend of TCastleWindow.

8. We fixed how our GTK 3 backend of TCastleWindow works in a Wayland session. Since we need to use X-specific API (to initialize OpenGL context using either glX or EGL), we cannot let GTK use “pure Wayland” backend now.

9. … But we also experimented with implementing a “pure Wayland” path (again for our GTK 3 backend of TCastleWindow).

   For this, we have to use EGL, and pass around Wayland surface (not touching any X or glX API).

   This is done… but has problems (flickering, obscuring menu bar) documented as TODO in code. We tried a few solutions, nothing reliable so far. You can define CASTLE_WINDOW_GTK_WAYLAND to test it. Note: Once we get it working, we would have to make it switchable at run-time anyway, to use only when GTK decided to use Wayland instead of x11 display. In the end, we need to continue working in X session too.

   Practically speaking, this isn’t a critical thing for now — the existing solution works perfectly within a Wayland session for users.

10. We fixed our example GitHub Actions workflow by explicitly setting permissions for the GITHUB_TOKEN, as required by GitHub for new repos (and recommended by CodeQL for existing repos too). See Use GITHUB_TOKEN for authentication in workflows – GitHub Docs. This is in practice just permissions: contents: read clause in the .yml file plus permissions: write when you want to upload release / move snapshot tag.

11. Our Docker image has been upgraded to have Lazarus 4.4. And to have FPC unstable at the same commit as castle-fpc.

Have fun developing games using Castle Game Engine and reading our long news posts! 🙂 If you like what we do, we appreciate your support.