Great news: New major version of FPC (Free Pascal Compiler), the compiler of our game engine, was just released. New features are documented here. You can get it e.g. from SourceForge or using latest fpcupdeluxe.

Castle Game Engine is of course 100% compatible with it. I was watching and testing FPC SVN branch leading to this release. So I encourage everyone to upgrade their FPC installations. As always, we recommend using CGE with the latest FPC stable.

Note: Following our supported versions docs, you can also use some older FPC versions (we will maintain compatibility with FPC >= 3.0.2). So you don’t have to upgrade, for now we promise to keep compatibility with FPC 3.0.x for the next CGE release.

Note: if for some reason you have to stick to the old Castle Game Engine 6.4, I maintain a v6.4-fixes branch with minimal CGE 6.4 changes to make it compile with FPC 3.2.0. Although I would encourage everyone to upgrade to latest CGE that will soon be released as CGE 7.0 with ton of new features.

Our Docker image has been updated to include FPC 3.2.0, and actually use it by default. See also Jenkins docs.

Gamma Correction and Tone Mapping are now implemented in Castle Game Engine. They can be trivially controlled by global variables GammaCorrection (by default it is on for PBR materials) and ToneMapping.

Gamma Correction is a way of making lighting calculations more correct (see e.g. here and here for explanation; my analysis of various implementation is here).

Tone Mapping is just a fancy name for nice-looking color processing, that makes the final look more visually pleasing. It is independent from the gamma correction (technically), although they both “change the scene colors” so are often considered together. We now implement 3 tone mapping operators (based on glTF sample viewer): see TToneMapping. Note that you can easily do your own color processing (thus providing functionality equivalent to these tone-mapping operators) by using Effect node like in this example: tone_mapping.x3dv from demo models.

I wrote a new manual chapter about Gamma Correction documenting all of this, and my description of gamma correction in various engines was also extended.

We introduced TCastleSceneCore.DefaultAnimationTransition property.

This is a really easy way to request animation cross-fading (blending) which makes changing animations look much smoother. Just set this to some non-zero value to have smooth animation change. It’s the time in seconds, often it’s reasonable to start with something small like 0.1.

This is also configurable in the CGE editor (as it’s a published property). Our “New Project” template 2d_game is using it.

And it’s available in resource.xml file for the creature. Our examples/fps_game/ is using it for the “knight” creature. Like this:

<model url="knight.gltf" pool="10" default_animation_transition="0.25">
  <idle   animation_name="Idle"    />
  <walk   animation_name="Walk"    />
  <attack animation_name="Attack"  />
  <die    animation_name="Die"     />
  <hurt   animation_name="Damaged" />
</model>

This also brings improved switching to the default state (like idle or walk) after Attack/Hurt. This makes animation change smoother for creatures using resource.xml, whether you use default_animation_transition or not.

We can now read lights from the glTF file.

The lights have to follow glTF extension KHR_lights_punctual. It’s a popular extension supported e.g. by Blender -> glTF exporter. So you can just add lights in Blender, export to glTF, open in CGE, and the lights are there!

This works for “punctual” glTF lights, which are converted in a very straightforward fashion to X3D lighting nodes: PointLight, SpotLight, DirectionalLight.

Demos:

• demo-models/gltf/punctual_lights (open the glTF file there in view3dscene or adjust any engine example to open it using TCastleScene.Load).

• examples/fps_game (level now includes lights designed in Blender and exported to glTF).

• Editor template for 3d_fps_game (as above, the lights are now designed in Blender and exported to glTF).

A number of improvements all across the engine:

1. ApplicationProperties.ShowUserInterfaceToQuit. Useful to hide that “Quit” button on mobile. Used by the editor new project templates for 2D and 3D games.

2. Saving screenshot to the best location, automatically determined: Container.SaveScreenToDefaultFile, lower-level SaveScreenPath. This is important as you cannot assume that your application can write to the current directory when installed. This featue is also already used by the editor new project templates (press F5 in 2D and 3D games).

3. Viewport.TransformUnderMouse represents the current TCastleTransform under the mouse. It’s easier to use than lower-level Viewport.MouseRayHit.

4. The default orientation (important if you use TCastleTransform.Direction property to rotate your models) changed from otUpYDirectionMinusZ to otUpYDirectionZ. The new default makes us work out-of-the-box intuitively with glTF models.

   I wrote a lot of text why this change, although breaking compatibility, makes sense on our page documenting upgrade process from CGE 6.4. See also manual about it.

   If you use TCastleTransform.Direction and want to restore compatibility, just set TCastleTransform.DefaultOrientation := otUpYDirectionMinusZ; somewhere early (like in the Application.OnInitialize callback).

5. Our build tool now does output filtering to hide many useless FPC warnings that occur when using Generics.Collections. This is better than disabling these warnings through FPC command-line options, this way e.g. compiler will still warn about instantiating abstract classes.

6. view3dscene gets a new command-line option --project, automatically used by the editor if you double-click on a scene file in your project. In effect, the castle-data:/ protocol will also work as URL for textures etc. inside X3D, glTF and other files.

7. CGE editor has now context menu when you right-click on files section at the bottom. You can open file manager, delete the file, refresh the directory.

8. For PointLight / SpotLight, radius < 0 means “infinity”. This is useful to convert glTF lights, that may have range equal 0 to mean infinity. So we just convert 0 to -1.

9. New glTF tests:

   • Camera transformations can be animated too in glTF, it works in Blender exporter and CGE as well

   • Invoking glTF animations from X3D TouchSensor

If you click on “New Project” in the Castle Game Engine editor now, it will propose 4 useful templates:

• Empty

• 2D game

• 3D FPS game

• 3D model viewer

I advise everyone, new and old engine user, to check out these templates. You can get the latest engine version from our main page, as usual. Just unpack and run bin/castle-editor executable. (Or you can get the source code from GitHub).

I tried hard to make these templates small but also very useful as a starting point.

They show how to use most important engine features (design viewports, scenes, basic UI in the editor), advise using TUIState to split your code into states, show how to react to basic input (clicking on game field to do something).

Note that “3D FPS game” doesn’t use the item/creatures logic from the CastleCreatures unit, documented in the manual about utilities for typical 3D games. Instead the 3d_fps_game presents much simpler (but also more flexible to extend) approach to implement creature AI, by dealing directly with TCastleScene.

I have implemented a service that allows to easily query about the current user activity (walking, running, cycling etc.) on an iPhone.

Services are ways to enhance your applications with additional code that has platform-specific implementation and may link with 3rd-party library. See more about iOS services and Android services. You declare them in CastleEngineManifest.xml and then just build your application using our build tool.

We now have a new iOS service called activity_recognition. A demo is inside the examples/mobile/activity_recognition subdirecory of the engine source. The demo is cross-platform, however it will not report any activity on other platforms than iOS for now.

The Pascal API is documented in CastleActivityRecognition unit (in particular see TActivityRecognition class).

Hello everyone!

We have a big and important, but simple request. We’ve reworked the handling of the joysticks and gamepads in Castle Game Engine, with a lot of new features that include serious improvement of joysticks API, access to a huge joysticks database by SDL2 with hundreds of joysticks definitions, autodetection of joysticks, detection of connection/disconnection of joysticks, etc.

However, because we have very limited access to hardware, we are unable to test how well those new features work. And therefore we need your help to test if everything is working as expected on different hardware joysticks/gamepads.

You can download and build “joystick” project from “examples” in this fork: https://github.com/eugeneloza-clean/castle-engine. It is not yet merged into CGE master, but of course it will be — that’s why we ask you to help with testing!

Ready precompiled binaries for Windows 64 bit and Linux 64 bit are here.

If you have access to a hardware joystick or gamepad, please use this tool and tell us (e.g. using forum):

1. Your joystick name and operation system (Linux or Windows)

2. Name your joystick was detected in Castle Game Engine

3. If your joystick was correctly autodetected. If not, can you find your joystick in the list of joysticks and try using it?

4. Did the axes and buttons on your joystick corresponded to the axes and buttons displayed in the tool? Note, that the names of the buttons and exact joystick layout may be different, but right stick must be right and upper button must be the upper one.

Thanks a lot!

And thanks a lot to Eugene Loza for developing it all!

In preparation for The Unholy Society on iOS…

1. Packaging of textures specific to given platform by the build tool has been fixed, to really package only textures useful on given platform.

2. The build tool auto-generate-clean subcommand was improved: by default it cleans only unused files in the auto_generated subdirectories. Call the castle-engine auto-generate-clean --all to clean all current auto-generated files.

3. Vibrations on iOS now work.

1. With the help from Valgrind, I made a few significant optimizations to the engine animations, in particular affecting the skinned animation of glTF:

   • We update VBOs during animations much faster (we upload it more directly when possible, without recalculating some useless structures along the way).

   • Some primitives are kept in GPU much better (previously we wasted GPU space sometimes, needlessly duplicating some data instead of uploading it to GPU without transformation).

   • OptimizeExtensiveTransformations and InternalFastTransformUpdate make sense, and are enabled for fps_game, I’ll work on making them “just done by default” ASAP.

2. I have introduced a pool of items for fps_game — more functional and more optimal solution to manage creature instances. The example knight creature in fps_game already uses it.

3. I added a limited support for PBR specular-glossiness parameters. It’s converted to PBR metallic-roughness parameters at import (this means it is limited, e.g. we cannot handle specularGlossinessTexture). It’s far from perfect, but at least the result looks sensible for models that contain only pbrSpecularGlossiness specification, and no pbrMetallicRoughness parameters.