We work intensively on the engine! Here’s a list of smaller engine improvements / fixes done recently. (For bigger improvements, see all the recent news — we have a lot of new stuff.)

1. New simple API in our CastleUnicode unit: TCastleStringIterator, UnicodeCharToString, UnicodeCharToReadableString, StringWithHtmlEntities. All with auto-tests. All following our general rule that when used with FPC, we follow default Lazarus conventions: String is AnsiString and it holds UTF-8; when used with Delphi, we follow default Delphi conventions: String is UnicodeString and it holds UTF-16.

2. We’ve made important fix to our VS Code extension last month: we now pass engine path properly to the LSP when the engine path has been configured as VS Code extension setting.

   Previously, our VS Code extension only worked if you had set CASTLE_ENGINE_PATH environment variable… which was not our intention, this was just a bug. To be clear, we work a lot to not require regular users from ever setting CASTLE_ENGINE_PATH environment variable (or any other environment variable, for that matter, like PATH). Because setting environment variables, in a way that is applied to all applications run in any way (also e.g. GUI applications not run from a shell), and on all operating systems (Windows, Linux/FreeBSD, macOS)… is not that trivial, as experience shows.

3. I wrote a small page documenting how overloading Pascal works, with or without the oveload keyword.

4. Optimized DPROJ size when your project has huge number of data files (we still need to list them all, for Delphi non-Windows targets, see Data files deployment (applies to all non-Windows platforms with Delphi), but the DPROJ shouldn’t be that big anymore).

5. New example examples/user_interface/screen_resolution_change showing how to use Application.TryVideoChange to change the monitor physical resolution. Along with a README that warns when it may not be the best idea 🙂 Using UI scaling is our first recommendation to make a game that adjusts to arbitrary user screen size.

6. You can now drag and drop Tiled maps on the viewport.

7. Docker image upgrades:

   • Updated Compressonator version in the image.

   • Updated FPC and Lazarus “latest” versions, see here for latest GIT hashes from FPC / Lazarus GitLab repos.

   • Updated GitHub CLI version.

   • Added git-lfs to checkout large repos (in case of GitHub Actions, they are checked out inside Docker image, unlike in case of Jenkins).

   • Fixed updating all Docker images hosted on GitHub in addition to Docker Hub

   • Repo is now castle-engine/castle-engine-docker (less sexy but more obvious name for previous “castle-engine/castle-engine-cloud-builds-tools”) 🙂

8. We now warn if it seems you mix 2 engine versions.

   The mix means that it seems the tools you call (in particular build tool, also called by editor) are accompanied by one engine version, but you use CASTLE_ENGINE_PATH environment variable to force a different engine location. This is a strong indicator that you have a mistake in your setup (maybe you forgot you have a CASTLE_ENGINE_PATH pointing to some old engine version) and can lead to various weird problems (since given build tool expects a given engine layout). Now you will get a clear message about it, like

   “$CASTLE_ENGINE_PATH environment variable points to a different directory than the one detected from the executable path: “…” vs “…”. This may be a mistake, possibly you have two (different) engine versions installed. Please check your environment, likely remove one of the engine versions or undefine CASTLE_ENGINE_PATH to not point to the engine that shall be unused.

   To be clear. you can have multiple engine versions on your machine. Just be sure to always use the tools (like build tool) from the same engine version from which you use sources (and build tool data).

   To avoid confusion, if you are unsure, we generally advise to not use CASTLE_ENGINE_PATH (as a central variable pointing to “current” engine) and do not put CGE tools on PATH. The less “central” settings you have -> the less things you have to maintain 🙂 If you don’t have any environment variable like CASTLE_ENGINE_PATH, but just run “bin/castle-editor”, it will correctly pick up the tools (including build tool) from the same engine directory. There are exceptions when CASTLE_ENGINE_PATH is useful, but you need to know what you’re doing :), in particular you need to remember that it’s another place where you indicated “where is the engine” and you will have to update it, if you decide to juggle engine versions.

9. Nothing done: We have been testing switching FPC optimization in release builds from -O2 or -O3. Sadly, it creates bugs in Aarch64, so we reverted back to -O2.

I don’t have a perfect image to illustrate this post. Attaching a screenshot showing how to display a cat with a jetpack instead :), because we can.

Do you like what we do? We appreciate your support on Patreon!