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.

1. You can now download Castle Game Engine 6.5 “snapshot” (build from the latest GitHub code) from here.

   Until I release a stable Castle Game Engine 6.6, this is the easiest way to test the very latest CGE features (including new GUI editor). I’m working now on making this snapshot fully-automatically updated by Jenkins, and I’ll probably make it linked from our main page soon.

2. Many editor improvements:

   • Images of TCastleButton are now configurable in the editor.

   • Properties are split into tabs Basic, Layout, Other, All. Note that the Layout tab contains both properties list and anchors UI.

   • Properties TCastleImageControl.Clip, ClipLine, Rotation, RotationCenter are now published and configurable in the editor.

   • You can edit colors in hexadecimal notation, like AABBCC. This allows to easily copy colors between CGE editor and GIMP/Photoshop etc.

   • You can configure TCastleScene animation in the editor (use AutoAnimation, AutoAnimationLoop properties).

3. TCastleWindowCustom / TCastleControlCustom are renamed to TCastleWindowBase / TCastleControlBase and are simpler to use now, as they by default have a defined background. Control it using the new Container.BackgroundColor and Container.BackgroundEnable properties.

   For new applications, I actually advise using TCastleWindowBase / TCastleControlBase instead of their counterparts TCastleWindow / TCastleControl.

   The downside of using TCastleWindowBase / TCastleControlBase is that you need to add a scene manager instance to them yourself (or using CGE editor). But that’s usually trivial: From code, just do SceneManager := TCastleSceneManager.Create(SomeOwner); Window.Controls.InsertFront(SceneManager);. Or just use CGE editor to add TCastleSceneManager to the appropriate xxx.castle-user-interface design.

   The upside is that you control the moment of creation of the TCastleSceneManager. You don’t have to create it right at the beginning of the application, you don’t have to keep it created until the end of the application. E.g. you can show a main menu, and only create TCastleSceneManager once user presses “Play”. You can even use our TUIState to nicely separate your application into states for this (1 state for “showing the main menu”, 1 state for “playing the game”), and our UI controls play nicely with this (whether you create them in code, or design in CGE editor).

4. FindFiles is now reliable and cross-platform. Can search recursively in game data (using castle-data:/ protocol) always, even e.g. in Android assets or Nintendo Switch game data.

5. TGLImage and TGLImageCore are finally merged into one class, TDrawableImage . This makes them simpler.

6. New class TCastleImagePersistent allows to load images (TDrawableImage) with caching, and can be used to configure image in the editor comfortably. It is used by TCastleImageControl and TCastleButton already.

7. Joysticks:

   • Refactored (moved a lot of code into platform-specific “backend” classes in separate, internal units).
   • Various API improvements. E.g. you can now just use Joysticks.Count, Joysticks[0].Axis (TVector2).
   • Joysticks work also on Nintendo Switch now.

8. Introduced static properties TRenderingAttributes.DefaultMinificationFilter, DefaultMagnificationFilter.

   This allows to e.g. easily disable mipmaps in all scenes on some cases, by TRenderingAttributes.DefaultMinificationFilter := minLinear;

Castle Game Engine now supports compiling your games to the Nintendo Switch console ! A modern, succesfull, indie-friendly console from Nintendo.

It is a full integration, really 100% of the engine works on Nintendo Switch. From the developer point of view, you just write cross-platform Pascal code using CGE units, and then you can recompile the application using the Castle Game Engine build tool with --target=nintendo-switch.

Note that the integration code with Nintendo Switch is not public and not open-source. It cannot be, as we are covered by Nintendo NDA agreements and we cannot disclose the technological details about how Nintendo Switch works. To develop on Nintendo Switch, you have to:

• Become a Nintendo Developer yourself, and sign the necessary NDA agreements between your company and Nintendo. You will most likely want to buy a developer version of the console, as well.

• Contact me (Michalis Kamburelis) through the non-public Nintendo developer forum. I can then share with you the necessary code that adds Nintendo Switch integration on top of the open-source CGE core, through the Nintendo forum, so Nintendo can confirm it’s legally OK with them. Of course you get this for free. The integration code cannot be open-source, but I still want to give it to everyone for free.

Enjoy a truly cross-platform game engine in Pascal!

Two new services are now available on Android:

1. Facebook – allows to connect your mobile application with Facebook application, and report analytics to Facebook. You can also log custom event “level achieved”.

2. Apps Flyer – connects your application to AppsFlyer, which allows to gather statistics how your application was installed.

• Shadow maps work on OpenGLES (Android and iOS) now!

• The Android building tools, which are part of our build tool, were updated. We use a new version of Gradle and Android Gradle Plugin under the hood, and by default we compile using Android platform 27. The minimal supported Android version is lower of course — it is 16 (Android 4.1), Android NDK doesn’t support older versions now.

• You can now build an APK for 64-bit version of Android, which will be required by the Google Play store since August 2019. Use our build tool to compile an APK with both 32-bit and 64-bit variants (for best compatibility): castle-engine package --target=android. Alternatively, you can build a 64-bit-only APK with castle-engine package --os=android --cpu=aarch64. This requires FPC 3.3.1 with Android/Aarch64 cross-compiler.

• The default project type is now “integrated”, which allows to define various services and also automatically adds OpenAL (sounds), Tremolo (OggVorbis reading), FreeType (font file reading) libraries to your Android project, if they seem necessary (if your data files contain some sound files, .ogg, .ttf etc. files).

• The latest source code of the Android libraries we use is available in relevant CGE repositories: android-openal, android-tremolo, android-freetype.

• A couple of bugfixes to Android building were applied. We now use Android NDK platform 16 (for 32-bit builds), not newer, to really work even on Android 4.1. We fixed FreeType usage (so that it works even on older Android devices). And we improved the documentation how to setup your Android SDK/NDK environment.

Because people will read again, I improved various parts of our documentation:

• New page about using CastleSettings.xml to easily configure UI scaling and default font, in a way that can be applied in game as well as in the CGE editor.

• Our Coding Conventions (and some related notes about contributing code to the engine) are now on our wiki. It’s long, so here’s a short version: write a code that is good (as simple as possible) and submit a pull request on GitHub.

• Improved the README about how to compile TCP connection demos using Lazarus.

• Large updates to our “planned features” page. A lot of stuff was done, or partially done, during the development of the upcoming CGE version 6.6. And a lot of new stuff is planned 🙂