Our support for the KTX image format was greatly improved, to make it the best format for images (in some cases — when you don’t care about image size on disk, but care about loading time).

Note that the post below discusses various details, but you don’t really to do anything special to benefit from these improvements. Just use KTX, as any other image, for your textures / images. The snapshot Castle Image Viewer can be also used to view KTX files.

Improvements:

1. KTX loading has been optimized for (very often) cases when the entire image contents can be loaded from disk to memory in one Stream.ReadBuffer call. This makes reading KTX lighting-fast in many cases.
   • To get some logs about it, you can use CastleInternalCompositeImage and set global LogVerboseKtx to true. We will then send to log additional messages when the optimal loading / saving path was used. As the name implies, this is internal functionality, if you use it: be prepared we may break it in the future (but then, this is just additional logging).
2. The support for 16-bit KTX images, which previously resulted in 8-bit data (we lost precision) and only worked for grayscale data, has been extended: they now result in float-based (32-bit) data, and support all channel variants (G, GA, RGB, RGBA).
   • Note that I didn’t have testcases for all possibilities. You’re welcome to test the code on your KTX files, and report a bug if it fails!

   • Note that we also support KTX images with 32-bit float data, which load/save fast to our float-based image classes like TGrayscaleFloatImage. This didn’t change. We just changed 16-bit support now to also result in TGrayscaleFloatImage, not in TGrayscaleImage.

3. We can now save KTX files (without any extra libraries necessary, just pure Pascal code).

   • This also means we can auto-generate trivial/downscaled KTX files from your files, which is great to speedup loading time (at the cost of extra disk space), see description here.

Having fun with KTX? Please support us on Patreon.

We present a demo showing how you can keep your web application data encrypted (with decryption key embedded in your application code).

By default, when you build a web application, the data is packed into a ZIP file, and a person that wants to access your data can download this ZIP and unpack the data on their own system (and e.g. extract your 3D models or textures).

The demo on demo_encrypt_decrypt_data shows how to prevent this. The data gets encrypted using BlowFish with your password, and then it is decrypted as you access it from your WebAssembly application. Read the README.md instructions in the demo for

• how to build it,
• how it works,
• how to adopt it to your own applications,
• and, to be clear and explicit, what are the limitations of this approach. It’s not a fool-proof solution to keep your data secret from a dedicated attacker, and there’s no such solution (in any game engine).

The README in the demo_encrypt_decrypt_data project already explains all the details, so if this sounds interesting, please read it 🙂

Big thank you go to UND DREAM Lab for sponsoring this demo through Patreon! Your donations to Castle Game Engine make our engine sustainable.

We’ve been extending in recent months our IFC support.

I talked about it at conference in Germany and I will talk about it at conference in Poland next week 🙂

General overview of what IFC is about:

• You can open, save and manipulate 3D models in the IFC format. This is the standard 3D format used by the BIM (Building Information Modeling) industry and supported by tools like Revit, ArchiCAD, FreeCAD, BonsaiBIM (in Blender). It describes how real-world 3D objects are constructed, from cities and buildings to the individual furniture and appliances.

• Using our engine you can open IFC files, manipulate their contents using “native IFC classes” (which means that your software works using the same concepts as the IFC specification), and save them back to IFC files.

• You can develop browsers and editing tools for IFC files, and deploy them on all the platforms supported by our engine.

• All the details, along with sample code, are documented on our IFC page.

New things we’ve done in recent months:

1. Our IFC test files are published in demo-models.

2. Our online converter supports IFC.

3. Our command-line converter supports IFC, so you can do things like castle-model-converter simple_house.ifcjson output.stl

4. We have basic knowledge of all IFC classes (thanks to reading their information from XSD) and for many of them (178 now) we have knowledge of all properties.

5. IfcGridAxis, IfcGrid are handled and displayed now.

6. New engine utility method:TCastleIfcMapping.ProductToNodes, used by ProductBoundingBox method in example.

7. New algorithm for extrusions in IFC, simpler, more efficient, more correct in some cases.

   • Just use quads for sides + concave top/bottom caps, do not use X3D that tries to be “too smart” and e.g. rotates the spine.

   • Also optimized convex/concave extrusion top/bottom caps.

   • Also adjust circle slices based on radius, to make it more efficient.

8. New efficient wireframe generation (e.g. for IfcBoundingBox, but also every other shape in CGE).

9. IFC transformation handling fix.

10. Much more optimized changing of IFC Translation by TIfcProduct.Translation.

11. Better saving to X3D:

    • Fixed rotation defaults.

    • Reuse Coordinate node for IFC extrusions (across 2 X3D geometry nodes).

12. Improvements to examples/ifc:

    • Button to view entire model.

    • Checkbox to toggle debug IfcBoundingBox display.

Have fun with IFC and 3D standards, and support our work on Patreon!

This was a busy month, with lots of engine work and also a great conference in Germany organized by Sorpetaler. Let me then announce a bag of engine improvements and news all across the board from last month (and more):

1. We’ve been working a lot in recent months on our IFC support.
   • More details about the IFC improvements will be announced later this week. Otherwise they would “dominate” this news post 🙂

   • For now, let me just say I talked about our IFC support at the conference in Germany and I will talk about it again at the conference in Poland next week. Catch me if you can!

2. Web target improvements:

   • Building for web from Windows no longer has problems with opening fonts. Previously building e.g. platformer for web failed on Windows with error “FreeType DLL could not be loaded”.

   • OpenUrl works on web now, e.g. clicking on “Credits” in platformer works.

   • As more features work, we have added and updates some demos. In particular check out:

     • dungeons_and_skeletons_fight

     • walking_adventure

     • Note: mouse look does not work on web, so playing 2 examples above is still not comfortable. Stay tuned for more work 🙂

     • Castle Model Viewer mobile (good on web too)

3. We have a new unit CastleHttps to easily activate HTTPS support in TCastleDownload.

   • Easy to use, no need for any $ifdefs on your side.

   • Fixes HTTPS + FPC 3.2.x + Linux with newest SSL (because our CastleHttps pulls a fork of SSL for FPC 32x in this case).

   • Fixes CGE editor SketchFab auto-download functionality.

   • See URLs and networking docs for various pointers and examples using TCastleDownload.

4. Our VS Code extension brings a major upgrade with version 1.4.

   • Your VS Code should update it to version 1.4 already.

   • New version has improved debugging support. See the Debugging section in the README for ways to activate it.

   • New version has been upgraded from plain JavaScript to TypeScript, which makes the code much easier to read and maintain.

5. New “Maximize Preview” feature (“zen mode”) is available in our editor.

   • Use menu item “Edit -> Maximize Preview” or key shortcut Shift + Space.

   • It toggles the visibility of most things except the main preview of your application. So it hides / shows the hierarchy (left sidebar), object inspector (right sidebar), files / console (bottom panel). It allows to focus on the main thing: the preview of your game.

   • The key shortcut, Shift + Space, is somewhat consistent with similar Unity and Blender‘s features that maximize the panel under mouse. In our case, it always maximizes the preview window. In Blender, the shortcut is actually Ctrl + Space, but we didn’t want to take that, as Ctrl + Space is commonly used for completion in text editors, so (even though the CGE editor is not a text editor) we don’t want to conflict with that meaning.

   • We unofficially call it “zen mode”, as the spirit is similar to “zen mode” found in VS Code and recent Delphi versions: no distractions, maximize the one most important view.

   • This is based on similar idea by Andrzej Kilijański he implemented for the terrain PR.

6. “Open Engine Location in File Manager” button is now available in the editor “Preferences” dialog. It’s sometimes useful to explore engine easily, esp. since on Windows engine is installed to AppData which is by default hidden.

7. Various X3D 4.0 and 4.1 support improvements:

   • Viewpoint nearDistance / farDistance support.

   • Validation of audio and volume rendering X3D 4.1 nodes.

   • With thanks to Don Brutzman and John Carlson for submitting lots of feedback in these areas, causing us to improve!

8. We maintain a mirror of our releases at SourceForge (files of castle-engine project). You can download from there the same files as from GitHub releases.

   • Why? We found cases of networks where downloads from GitHub releases don’t work reliably (are often interrupted in the middle) while downloads from SourceForge behave reliably. Your mileage may vary — you have an option.

If you like what we’re doing, please support us on Patreon. Have fun making games!

We have released Castle Model Viewer Mobile on iOS (iPhone, iPad) and you can get it right now from the App Store!

Open this link to the AppStore on your iPhone/iPad, or just search for “Castle Model Viewer” in the AppStore. We’re available in all AppStore regions (including US and EU).

You can open a number of built-in models (in X3D, glTF, IFC JSON and other formats we support). You can also open your own models, provided they are “self-contained”. More information about our features, and in particular about “Opening your own models” and what it means that “Models must be self-contained” is on Castle Model Viewer Mobile webpage.

The application is completely free, also no ads and no tracking, and it is naturally open-source and using our free and open-source Castle Game Engine.

In return, we ask that you consider donating to us and/or giving us a good rating on the AppStore 🙂

Of course, if you have any problems or questions, go ahead and ask. Various ways of contacting us are here, in particular you’re welcome to our forum or submit GitHub issue.

I’d like to thank Jan Adamec for working on this application, as well as on a lot of related iOS-specific improvements in Castle Game Engine. I’d also like to thank a sponsor (who wished to remain anonymous) for covering our Apple membership fee for 1 year. Much appreciated.

The Android version of the viewer was also updated, with:

• Various mobile improvements in the engine announced last time.
• New built-in demos: shadow maps, shadow volumes, screen effects. Some of these demos have also been upgraded in demo-models.
• Fixed handling of TouchSensor (for clicks in X3D/VRML models).

We also added unit GameScreenShotArbitrarySize that shows how to take screenshots using FBO, in arbitrary resolutions (maybe larger than your monitor), maybe in multiple resolutions at once. Useful when some app store requires screenshots in a few particular resolutions.

As we’re preparing to release Castle Model Viewer on iOS, we’ve done a number of improvements to our mobile support for both iOS and Android:

1. With big thanks to Jan Adamec, we have:
   • Upgraded our OpenGLES usage on iOS to OpenGES 3 (if only your system supports it; otherwise we still fallback to OpenGLES 2). This brings features like shadow maps to iOS rendering.

   • Fixed shadow maps precision on both Android and iOS.

   • Fixed screen effects using depth on iOS. (Though heed we still want to fix SSAO shader.)

   • Using this occasion, we want to mention that our Castle Game Engine iOS rendering is used in Jan Adamec‘s Room Arranger, a cross-platform application for designing your apartments and previewing them in 3D. Check it out, as a real application of our engine (through the library approach)!

2. More iOS stuff:

   • Fixed opening associated documents on iOS when it causes launching the application.

   • Solve 2 AppStore validation issues if you used associated documents on iOS. So that your iOS application uploads smoothly to AppStore.

   • Added <ios override_icon=...> option to the manifest to enable specifying iOS-specific icon. This makes sense if you need to use a different icon for iOS than the other platforms (Android, desktop etc.), e.g. because your default icon has transparency (which is not allowed on AppStore).

   • Our iOS code migrated to use UISceneDelegate instead of deprecated AppDelegate. This makes our integration code follow latest Apple recommendations. Again with big thanks to Jan Adamec!

3. More Android stuff:

   • We have upgraded Google Play Billing API to use version 8. This makes in-app purchases on Android follow latest Google recommendations and will pass validation when uploading application to the Google Play.
4. More miscellaneous stuff, for both Android and iOS:
   • We have fixed our mobile Facebook integration, improving docs, tested on iOS and Android, and adding example examples/mobile/facebook_integration. It’s still admittedly a very simple integration, it’s main use-case is just to report application opening to Facebook Analytics. See it’s docs from Android services and iOS services.

Have fun with Castle Game Engine on your phone(s) 🙂 And if you like this, please support our work on Patreon. Thank you!

We did some rearrangement of our examples, to showcase better engine features and some good demos.

• First of all, we now have 3d_games and 2d_games subdirectories in our engine examples.

  The names 2d_games, 3d_games are alphabetically first — which is a nice bonus, we want them to be noticeable.

• Example 3d_games/walking_adventure has been added to the engine repository.

  It’s a simple walking simulator where you can talk with NPCs (horses), interact with objects, spawn and push physical objects. Full game controller support.

  This is not really new. This was done from Delphi Summit 2025 presentation, it is now just repurposed as a regular engine example that we want to maintain and recommend to check out.

• Example 3d_games/dungeons_and_skeletons_fight has been added to the engine repository.

  This is FPS game where you shoot at skeletons and try to find dungeon exit. Using 3D assets from OpenGameArt, Sketchfab, Quaternius, modified by Blender. Enemy logic using TCastleMoveAttack.

  This is also not really new demo. This was done for “Zlot Programistów Delphi” at 2024 presentation. As it is useful, we decided to put it in engine “core” repository.

• We have added an example ask_openai_assistant to the examples/network/. Shows how to use our TCastleDownload for REST communication, with OpenAL in particular. This is, again, not really new — it was presented already last year, but was in a separate repo. Given the popularity of AI, and the usefulness of the TCastleDownload for REST, we want to showcase this demo better, by having it part of the engine.

  And if you haven’t, check out also the new random_image_from_unsplash demo, announced just yesterday.

• We have also renamed previous examples/fps_game demo into examples/3d_games/explore_impressive_castle.

  The previous name was causing (understandable) confusion — because it wasn’t really a functional FPS game, it was “in the middle of rework” for a long long time. And in practice, our 3d_games/dungeons_and_skeletons_fight is already better as “FPS game” demo.

  The new name and new README better describe what it actually is, right now. The README also documents why this example demands better GPU to work fast, and what do we plan to do about it, which was somewhat a FAQ.

• We also moved eye_of_beholder demo to 3d_games.

• We also moved platformer and space_shooter to 2d_games.

Note about engine size: Engine download size grew because of new demos.

• We fought to keep this growth limited. We removed some old deprecated demos, to keep size lower. We removed all unused data and even decreased some textures from new demos and/or converted them to jpg. We also took care to not commit to GIT history large files, since GIT repo size grows even after things are removed.

• But in total, some growth could not be avoided. Downloads are now about +80 MB bigger.

• We hope that the increased engine size is worth it. The new demos are cool, and hopefully demonstrate nicely what you can do with our engine.

• But we’re aware this is a problem in the long run. It would be nice to have a small engine download size. Some other game engines are also large (much larger than us!), but some others are small… it would be nice to get back to “small size” category. But at the same time we have a priority to provide you great examples, out-of-the-box, with the engine. We think (hope!) our existing examples are valuable.

• Possibly, in the future our examples library could be auto-downloaded as you open each example, this would reconcile our 2 desires (to have “lots and useful and discoverable examples” with “have smaller engine download size”).

Like this? As always, we appreciate your support.

We have a new example in our repository: examples/network/random_image_from_unsplash. This shows using our TCastleDownload to access Unsplash API and ask for a random image matching a given search term (like a “cute fox”).

The main part of the example is the unit gameunsplash.pas with a reusable class to download images from Unsplash.

There are 2 ways how this can be useful:

1. You can learn how to use TCastleDownload with some REST API, to access the resources in an asynchronous manner (without blocking your application).

2. And/or you can just use gameunsplash.pas unit in your own applications (feel free to just copy it, it’s on permissive BSD license) to get images from Unsplash.

   For example, you can use the images as randomized pretty background, or an image for a puzzle (to arrange puzzle pieces etc.)

   The images are generally free to use (see Unsplash license) for various, though not all, purposes. And there’s a ton of high-quality images.

To use this example, you need an API key (“access key”) from Unsplash. Don’t worry, it’s rather trivial (and free) to obtain it 🙂 Please follow the instructions in the README for details.

This is based on an actual fun application I (Michalis) did this week for our family! We have a monitor playing a role of a “wall clock” powered by the Raspberry Pi, showing clock with a nice background using TablissNG extension (a fork of it, that refreshes image from custom URL every 15 mins). I wrote a simple Pascal application to randomize the image, choosing randomly from a collection of our private photos and pretty images from Unsplash matching terms like “cute fox”. My daughter loves this 🙂 Note that Pascal application just exposes the image on local server, I deliberately made the separation between “display of image” (using TablissNG) and “choosing the image” (using my small Pascal program) to enable more future experiments with various fun ways to use these images.

I hope you enjoy it 🙂 And if you do, we appreciate your support on Patreon!

1. Castle Model Viewer for Android version 2.8 has been released! This brings:
   • Support for IFC format right in our mobile viewer.

   • Small UI improvements: better button order (left-most changes model), show more built-in files.

   • Opening ZIP files underneath doesn’t create temp directory on your device. Internally, this is achieved by using TCastleZip to open ZIP files. The TCastleZip class also makes code simpler, and compatible with both FPC and Delphi.

   • Fix: No more crashes on Android 15 (on some devices, like Google Pixel 6a, argv is broken after Android upgrade).

   • Fix: Take into account safe borders on left/right.

   • And all improvements and optimizations from the Castle Game Engine done recently. Including target Android version bump, mentioned below.

2. All other Castle Game Engine applications on Google Play have been upgraded as well, to include all the latest improvements from the engine, including the target Android version bump.

3. On the engine side, we have migrated google_play_games service to use version 2 of the Google API. New applications uploaded to Google Play are required to use this version.

   Please note that v2 is somewhat less functional than v1. E.g. there’s no way to explicitly request sign-out. It’s just how Google made it, and we have to adjust, see migrating to Play Games Services v2 about all changes.

4. We also bump the “target” Android version to 35, as required by Google Play. This will be required by Google Play since 31 August 2025, see Target API level requirements for Google Play apps. Nothing in practice changes for you because of this (it doesn’t affect minimal version supported).

If you like it, we appreciate your support on Patreon. We also appreciate a good review for Castle Model Viewer on Google Play and our other apps!

We did a few moves and renames to our Lazarus packages.

After upgrading to the latest engine version, be sure to run again “Register Lazarus Packages” button (from the “Preferences -> FPC and Lazarus” in our editor, as documented in our Lazarus docs).

Note that the existing applications will continue to work even without you doing the above, because new packages provide the old names too. But we advise to just use new names from now on.

The short version of the changes: Lazarus packages are now in the packages/lazarus/ subdirectory of the repository, with some better names.

Full list of changes and their reasons:

1. We moved Lazarus packages to subdirectory packages/lazarus.

   Reason: This is consistent (sibling) to Delphi packages in packages/delphi, and good for TMS Smart Setup, and likely just more obvious to both Lazarus and Delphi users.

2. We rename packages to add _engine. So we have

   • castle_base.lpk -> castle_engine_base.lpk
   • castle_window.lpk -> castle_engine_window.lpk
   • and so on.

   Reason:

   • Avoids having castlewindow.pas and castle_window.pas (the latter just auto-generated package unit) being too close to each other. They are completely unrelated units.
   • New names are consistent with Delphi packages (which always had the _engine part).
3. We rename castle_components to castle_engine_lcl. So in addition to adding _engine, we change components -> lcl.

   Reason:

   • The components word there was confusing for a long time. Because this is not the only package with “components”, other packages (including base) also provide components (though they don’t register them now in Lazarus component palette, but they did in the past). However, this is the only package that depends on LCL and thus provides TCastleControl that uses LCL. This package may provide more LCL components in the future.
   • It also makes name of alternative_castle_engine_window_based_on_lcl.lpk more obvious. Now alternative_castle_engine_window_based_on_lcl.lpk depends on castle_engine_lcl.lpk — which looks obvious and natural.
   • We have planned to do this rename for quite a while now. We mentioned it in TCastleControl docs and packages README that “this should probably be renamed to castle_lcl” already.
   • This seemed to be a good moment to do this, as we go with rename/move anyway.

Note that the packages/lazarus/README.md has been updated to reflect it all. We also updated Lazarus docs, TCastleControl docs and everything else we found.