Recently I got my Raspberry Pi 4 device, and I am excited by the possibilities (small+cheap device with fully functional Linux). I was happy to see that Castle Game Engine runs perfectly on it 🙂 Here are some screenshots of The Unholy Society running on Raspberry Pi.

If you’re interested in using CGE on Raspberry Pi:

• Just install FPC using the package repository (apt-get install fpc)

• Get CGE source code

• Build CGE build tool running castle_game_engine/tools/build-tool/castle-engine_compile.sh

• Build your application as usual, running castle-engine compile.

• Raspberry Pi is just Linux OS + ARM CPU, rendering using OpenGLES. Everything just works, no surprises 🙂

• It should also be possible to run Lazarus and CGE editor, although I didn’t do it yet.

• Note that the default backend uses X. It is also possible to get CastleWindow backend using DispmanX (without X), although it is not yet merged into latest CGE.

Have fun with CGE on all your devices!

1. Our sound engine now supports streaming sounds.

   “Streaming” means that we decompress the sound (like OggVorbis) during playback, in parts (as needed). This technique allows much faster sound loading (loading sound as “streamed” is almost instant). It adds a small run-time overhead to playing given sound, although in practice it is not noticeable at all, even on mobile devices (where the benefits — much faster loading — will be very noticeable 🙂 ).

   In general case, I advise to use it for longer sounds (like music tracks).

   The default remains to load sounds “complete”, just like before.

   To use this feature, call LoadBuffer method with slStreaming or use <sound ... stream="true" /> in sounds XML file. See the manual about sound for general information how to play sounds, including LoadBuffer and sounds XML files. An example is in our play_sounds example, just uncomment proper lines in gamestatemain.pas and CastleEngineManifest.xml (search for “streaming”).

   This feature works with both OpenAL and FMOD sound backends.

   Thousand thanks for implementing this feature go to Andrzej Kilijański!

2. FMOD dynamic loading is now improved, which is particularly useful for Linux users.

   • The FMOD library no longed needs to be present at compile-time on Linux, it only needs to be present at run-time. You no longer need to pass -k-L... to FPC to link with FMOD.

   • If the FMOD library is not present at run-time, we make a warning (in log) and continue using existing backend. In effect, you can have the application use FMOD if possible, but fallback on OpenAL. This applies to all platforms using dynamic loading of FMOD, like Windows and Linux.

   • It fixes problems with linking with FMOD using GNU binutils 2.32 (like in Debian
     Testing). The linker was previously reporting errors bad value.

1. Castle Game Engine now supports ASTC, which is a great GPU compresion method available on most modern mobile devices (Android and iOS). You can easily compress your textures, and then use them at runtime, using the appropriate declaration in material_properties.xml file.

   The usage is described in details in ASTC compression support added to Castle Game Engine (also available in Polish) article by Andrzej Kilijański, who implemented this feature. Thousand thanks!

2. I pushed Delphi compatibility further. Many more units are supported, in particular our file reading/writing/searching system using URLs, including our XML support (used throughout the engine). To have uniform XML support, I introduced Delphi units DOM, XMLRead, XMLWrite that wrap Delphi XML implementation (using MSXML and COM interfaces) in an API compatible with analogous FPC units.

   It all can be tested by compiling Delphi example in CGE sources. I hope to make more progress very soon 🙂

P.S. More cool stuff from Andrzej is coming — streaming music 🙂

P.P.S. Blender 2.8 was released! Note that CGE supports various 3D model formats supported by Blender 2.8 out-of-the-box (Wavefront OBJ, glTF 2.0, X3D, Collada, STL). (Unfortunately, exporting to the best formats — glTF and X3D — is far from perfect now in Blender 2.8. E.g. glTF exporter doesn’t apply modifiers, materials remain gray, transformation hierarchy has duplicated nodes. And X3D exporter can crash. As a workaround, OBJ exporter always works 🙂 )

Andrzej Kilijański wrote a few very nice articles about Castle Game Engine recently:

1. Updates in Castle Game Engine Admob Service (also available in Polish) describing his recent improvements to our AdMob Android Service.

   We support now reward ads from AdMob, and the callback TAds.OnFullScreenAdClosed provides now detailed information why the user did not watch ad.

   See also wiki page listing breaking changes in CGE for more information how you can upgrade your code.

2. Castle Game Engine stable 6.4 or beta 6.5 which version to use? (also available in Polish).

   Spoiler: use 6.5 🙂 It has been a while since the last stable version, and while we’re working on the next stable release (6.6), right now it makes more sense to use the “snapshot” 6.5 version (the download link is at the main page), especially for new projects, than the older stable 6.4.

   See also (much longer 🙂 ) complete list of changes since the last stable release.

3. Free Pascal OpenGL App – Exception on window close (also available in Polish). This may affect you if you use Linux with proprietary NVidia drivers and stable FPC. The solution is to upgrade your FPC version, a process described in detail in the article.

Thousand thanks go to Andrzej Kilijański for writing these articles, and for continuously submitting new improvements to CGE! You can follow all his posts here, or you can also follow only CGE-related stuff in English or CGE-releated stuff in Polish.

Andrzej also added ASTC (texture compression) support to CGE lately, which is a nice GPU-compressed format available on most mobile devices (starting from 2nd generation of Mali-T600 series, Adreno 400, Apple A8). CGE now understands it (when ASTC images are inside KTX file format) and can auto-generate textures compressed to ASTC.

I implemented a new comfortable workflow for localization using the CastleLocalizationGetText unit. It is documented in details in the manual about localization and is demonstrated by a revised examples/localization/gettext/ demo.

It was tested by localizing to Japanese an upcoming release of “Escape from the Universe” on Nintendo Switch. I will make more news about the game itself later 🙂

Details of new localization features:

• Supports localizing user interface (designed using CGE Editor) really easily (just call TranslateAllDesigns). In more complicated cases, you have TranslateDesign or TranslateProperties.

• It can generate GetText PO template files, to serve as immediate starting point for translators (use GenerateGetTextPo).

• You can use CastleTranslateResourceStrings to translate strings declared in Pascal code as resourcestring. This is just a simple wrapper for FPC GetText.TranslateResourceStrings (it understands CGE URLs, works on all CGE platforms including Nintendo Switch etc.).

• It’s extensible by overriding TCastleComponent.TranslateProperties. A single component can have multiple properties to translate (e.g. TCastleEdit has Text, Placeholder).

• texture-font-to-pascal tool gets additional command-line option --sample-get-text-mo to add all characters mentioned in given GetText MO file.

Everything is documented, read and follow the links from our manual about localization.

P.S. In related news, the “Escape from the Universe” English version (for Europe and America) just passed the review by Nintendo, and it will be available on Nintendo Switch since August. I’ll post more information about it later 🙂 What it means for you is that Nintendo is completely fine with games being developed with Castle Game Engine 🙂

1. Animating transformations (translation, rotation, scale) from the glTF format is supported now.

2. Playing, cross-fading and resetting the animations is now optimized, and exposes some new features.

   New methods available now:

   • TCastleSceneCore.StopAnimation

   • TCastleSceneCore.ResetAnimationState

   • TTimeSensorNode.Start

   • TTimeSensorNode.Stop

   We now store and use more efficiently the “reset” state of the animation. See the new TimeSensor.detectAffectedFields . Previously, our Spine importer had special (and unoptimal) code to reset the state of bones not affected by the current animation. This mechanism is now more uniform (used by all animations, e.g. those imported from glTF too) and faster (we internally call ResetAnimationState just once for an animation start).

   Using the TTimeSensorNode.Start and TTimeSensorNode.Stop you can control simultaneous animations within one scene. See the demo examples/animations/simultaneous_animations_one_scene, it controls two independent animations defined in a single glTF file.

3. view3dscene has a new “Animations” panel to test animations comfortably.

   • Show it using the toolbar button “Animations”, or menu item “Animations -> Animations Panel”, or by pressing Ctrl+A.

   • It allows to run animations easily, controlling their looping, forward, transition (cross-fade time), speed.

   • It adds buttons to “Stop Animation” and “Reset Animation State”, performing appropriate scene methods.

4. Fun fact: this commit was one of the most difficult commits to write during this work.

   And the commit only adds a (60-line) comment in the middle of the code. The comment contains a proof that actually no code is necessary to achieve what I need! 🙂

   There was actually another commit to demo-models to interactively test that my proof is right. The scene is in demo-models animation/spine_animation_blending_test subdirectory, you can open the exported/test_animation_blending.json file with view3dscene.

   And, of course, the next day I refactored the code, and made the comment shorter too 🙂

We now support collision detection using our physics engine (Kraft). You can be notified when a particular object collides, and you can check with what it collided.

Big thanks for implementing this feature go to Andrzej Kilijański!

Collisions can be checked in two ways:

1. By getting a list of colliding TRigidBody objects from TRigidBody.GetCollidingTransforms. Works like get_colliding_bodies() in Godot.

2. By using OnCollisionEnter and OnCollisionExit events on TRigidBody. This is similar to Unity.

Simple example to demonstrate it is in examples/physics/physics_2d_collisions directory of the engine.

We also have new properties on TRigidBody, and some internal things are now cleaner (again thanks to Andrzej Kilijański!). New properties:

• TRigidBody.Exists

• TRigidBody.AngularVelocity

• TRigidBody.AngularVelocityDamp

• TRigidBody.MaximalAngularVelocity

• TRigidBody.LinearVelocity

• TRigidBody.LinearVelocityDamp

• TRigidBody.MaximalLinearVelocity

First of all, sorry for posting so seldom recently. At Cat-astrophe Games we have been working on our first title on Nintendo Switch, of course using CGE! Many of the new features described below are a result of that, and of course you can use them already, they are part of Castle Game Engine 6.5.

New features and notable bugfixes:

1. New sound backend using FMOD. You can select it at runtime following our instructions. FMOD offers even more cross-platform capabilities than our default OpenAL, in particular FMOD supports also consoles like Nintendo Switch. FMOD also allows to load more sound formats (like mp3). In the future our integration should also allow you to use FMOD Studio and call FMOD events from code.

2. material_properties.xml now allow to convert images to a particular format (independent of GPU compression or downscaling). This is useful when you e.g. want all images as DDS for performance reasons (DDS reading is fast, as there’s no extra decompression).

3. “Warmup cache” element in CastleSettings.xml allows to preload some images or scenes. This means that you load them once, in Container.LoadSettings, and not later (e.g. at loading UI state from .castle-user-interface file).

4. We have better FpMake installation instructions.

   On a related note, we have new demo scripts using InstantFPC: instant_fpc_test_list_pascal_files, instant_fpc_test_open_window. If you often find yourself writing shell scripts, I encourage you to try InstantFPC 🙂 Feel the power of Object Pascal and CGE, while following similar trivial workflow as when writing shell scripts — just write and execute.

5. CGE editor improvements:

   • Viewing and editing vectors is now easier, as you don’t need to expand the subcomponent.
   • Double-click on a Pascal file opens it in Lazarus, with correct project.

6. In your applications, you can use

   {$ifdef CASTLE_AUTO_GENERATED_RESOURCES} {$R castle-auto-generated-resources.res} {$endif}

   instead of previous

   {$ifdef MSWINDOWS} {$R automatic-windows-resources.res} {$endif}

   This has 2 advantages:

   1. CASTLE_AUTO_GENERATED_RESOURCES is only defined by the build tool, when it actually created the castle-auto-generated-resources.res. So e.g. compilation from Lazarus will still work seamlessly too (it will just not include resources).

   2. It’s more future proof, we may decide to use castle-auto-generated-resources.res on other platforms too in the future (since FPC resources are cross-platform). This could provide more general way to “embed” data in the application executable than current image-to-pascal, texture-font-to-pascal, file_to_pascal_string.

7. New option <data exists="false" /> is possible in CastleEngineManifest.xml

8. Other notable bugfixes:

   • Fixed tiLoading scaling (use Theme.LoadingImageForWindowHeight).
   • Fixed texture-font-to-pascal output.

Have a lot of fun with Castle Game Engine!

1. Our sound engine was refactored to support various backends. There are 3 backends available now:

   • OpenAL (full-featured, with spatial (3D) sound support),

   • SOX (only useful for testing — executes command-line sox to play files),

   • and Nintendo Switch sound backend (not open-source, only available for developers who signed an agreement with Nintendo).

2. A new sound demo in examples/audio/play_sounds is available. This allows to test mixing multiple sounds in various formats at runtime.

3. Sounds XML file now supports <alias> to create an alias for another sound, or for a group of sounds.

   The latter case allows to play a random sound from a configured set of sounds, without any extra code necessary. This makes it a nice feature for sound designers, that can edit the sounds XML file but probably don’t want to write actual Pascal code.

First of all, notice that big shiny button on the main page to download CGE version 6.5. Try it out!

While we work on making next stable 6.6 (or maybe 7.0?) release perfect, you should enjoy using the latest 6.5 snapshot. It’s in practice very stable (at Cat-astrophe Games company we even use it in production). It also contains a ton of new features compared to the last stable release (6.4, more than a year ago), and you should enjoy them:)

Probably the biggest new feature is the Castle Game Engine Editor. It is documented in the manual, and our “Getting Started” page was also updated to clearly advise using it. The 6.5 engine snapshots contain the editor (as well as other tools) in a ready, compiled version. Just execute bin/castle-editor.

Editor and packaging improvements from April:

1. Selecting file in the file browser (bottom of the editor) opens a small asset preview (useful for scenes, images, and quickly playing sound files).

2. Double-clicking in the file browser opens a suitable viewer, like view3dscene or castle-view-image.

3. The editor, build tool and some other tools are now also provided in compiled form, and more integrated. E.g. you no longer need to define CASTLE_ENGINE_PATH environment variable if you just run the editor (or build tool) from the bin subdirectory of the engine. They will find the CGE code (and other tools) in any case.

4. view3dscene and castle-view-image (formerly called glViewImage) are also distributed along with the engine. No need to download them separately.

5. When using snapshots, the CGE version number contains the GIT commit hash.

6. Compiling with the build tool now automatically places relevant DLLs alongside the EXE file on Windows.

7. CGE applications automatically use Libpng if available, and only fallback on FPImage. You do longer have to compile with any symbol to use Libpng.

8. Editor “File Browser” automatically hides some files/dirs, like castle-engine-output.