1. I’m back from Rome, where I made 2 presentations about Castle Game Engine. I think the slides from both talks may be quite useful to everyone:

   1. 1st talk, “Creating 3D games and applications using Castle Game Engine” is a great introduction to using our engine. It describes using editor and basic CGE API, e.g. to move 3D objects, play sounds, push things using physics.

      The example projects may be quite useful to learn as well.

   2. 2nd talk, “Advanced Castle Game Engine: forms, 3D generation, shaders, customization (and more)” was dedicated to a few engine features… that I seldom have time to talk about 🙂

      We covered:

      • dropping TCastleControl on FMX and VCL form,

      • shader effects and screen (post-processing) effects,

      • generating worlds using X3D nodes,

      • writing custom components (the last point depends now on Lazarus to recompile custom editor — which didn’t seem an issue to anyone).

      • I also mentioned how UI scaling works,

      • supported Delphi versions,

      • reusable designs.

2. In other development, I recently finished the 2nd part of the article “The bad way to play chess: 3D physics fun using Castle Game Engine” for the Blaise Pascal Magazine. More about it in the future.

3. I am working (and I’m really close to finish) on Delphi/Linux port. This also brings other improvements (fixes for some mouse event on Windows, code improvements to bring CGE to all Delphi platforms using FireMonkey, dglOpenGL usage for OpenGL which will be also for FPC).

Lately I feel like a rockstar, traveling all across the Europe, singing about Castle Game Engine in every venue I can find 🙂

Here’s another opportunity to listen about Castle Game Engine and catch me in person: I will give 2 talks about our engine at ITDevCon, Delphi conference in Rome, 26-27th October 2023.

I will give 2 talks, both 1 hour-long:

1. Creating 3D games and applications using Castle Game Engine — This talk will introduce CGE. I will talk about using editor to design 3D worlds, with physics. Then I will show basic things you can do from Pascal: moving scenes, in response to user pressing some button, key, or clicking.

2. Advanced Castle Game Engine: forms, 3D generation, shaders, customization — This talk looks at 4 important CGE features:

   1. You can put engine rendering on Delphi FMX form.
   2. You can create and modify X3D nodes using Pascal, to build or modify 3D models — e.g. to display something from external sources (e.g. some machinery state) or to procedurally generate worlds.
   3. Compositing shaders using shader effects — original and powerful way to write shader code in our engine.
   4. Registering custom components in the editor — a gateway to extending what you can do in the CGE editor.

See you there!

If you’re close to Poland, you can also catch me at GIC (Game Industry Conference) next week. No CGE presentation this year as I hope to rest a bit and just listen to lectures. But I’m happy to talk about CGE always! Contact me in any way (you can find me on Discord and forum) to make sure we meet. And you can find my presentation from GIC 2022 linked here 🙂

I’m back from the Polish conference Zlot Programistów Delphi with lots of positive feedback and energy. This energy will result in something tangible in CGE — I decided to work on a new Delphi platform (Delphi + Linux) immediately, and already made good progress in delphi-linux branch!

From more Delphi-specific news: we now support Delphi IDE “welcome page of a project” that allows to prominently display a file, like README.md in Markdown, when one opens a project in Delphi. This makes projects look prettier in Delphi, and it makes total sense for us — since our templates and most examples already define a README.md.

I have also made big rearrangement in our installation docs. The installation page is now shorter than ever, reflecting our effort to make things “just work out-of-the-box when you install the engine”. In turn, there’s a dedicated page about Delphi support and Lazarus support. The ever-important editor page also got a number of updates.

Finally, I wanted to mention a big new pull request submitted by Andrzej Kilijański this week: New physics based first/third person 3d and platformer like modular navigation + input axis and others. Reviewing it, finishing touches and merging is our big focus now, because it brings a lot of critical features we talked about and carefully designed in recent months:

• It’s a set of behaviors that allow to easily set up a working navigation. Navigation for a large set of games — 1st-person FPS, 3rd-person, 2D games (like platformer) and more. Effectively, it will replace most of usage of our navigation components. The new behaviors attach to TCastleTransform (so they can “drive” a camera and/or a transformation hierarchy with some visible player), they are modular (so you can use and customize a subset of them, you can also add/remove some abilities to player at runtime), they are flexible (you can easier replace pieces of them with custom code).

• Connected to above, there’s also (initial design of) TCastleAxis, a great new approach to monitor inputs in CGE. It allows to easily query keys, mouse look and more from update events and behaviors. The core use-case is somewhat analogous to how you use inputs in Unity or Godot (though our design isn’t a clone, but we looked at competition to se what they offer and how we can even improve that 🙂 ).

• Connected to above, there’s also Kraft update. It brings a few improvements, I want to highlight a new feature expose in CGE: “sphere cast”, TCastleRigidBody.PhysicsSphereCast.

See the pull request description for docs. We welcome your feedback about the ideas described there, we welcome your tests of the branch of that PR.

As always, have fun creating games with Castle Game Engine and we appreciate if you can support us on Patreon!

Hey, are you looking to migrate away from Unity to an open-source game engine, that doesn’t charge any royalties for releasing on any platform?

• See our list of features and the engine overview for Unity developers.

• If you wonder about picking up Pascal we explain why it’s a modern and productive language and have learning resources.

• So just download the engine and play with it 🙂 Follow the manual for full docs.

• And if you want to know what’s coming soon: see our roadmap, including engine on Steam and web target. Recent developments are summarized here.

New features this week:

1. We improved how the camera gizmos for 2D are visualized and work. Now they show the projection near and far as a box, that makes sense both in typical 2D view (orthographic, direction -Z) and 3D (free view, perspective or ortho). Also we fixed rendering and selecting camera gizmos in some cases.

2. We added a tab with information or warnings specific to a given component to the object inspector panel (on the right).

   It reports now these warnings:

   • TCastleRigidBody without TCastleCollider or vice versa. Both these behaviors must exist to enable physics, only one of them isn’t really useful.
   • Physical objects with non-uniform scale. Non-uniform scale cannot be fully supported, due to the underlying limitations of physics engines.
   • TCastleMeshCollider with unassigned TCastleMeshCollider.Mesh.
   • Joint without a TCastleRigidBody and TCastleCollider.
   • UI element outside of the parent area. Mouse clicks would not reach such element.

   We had a long-standing plan to warn about some easy mistakes in the editor — this is a start. In the future we want to make these warnings more visible (as icons in the hierarchy, and as per-project “some warnings reported” icon) so you can quickly see if there are any warnings. For now, this is a start: when selecting given component, just look whether the Warnings tab appears.

   Note that we don’t really want to introduce now a lot of new warnings. A warning is only warranted if there’s a reasonably high chance that it’s a user error, not a deliberate setup. Moreover, in general our API design should minimize the possibilities to make such errors, by making invalid state impossible. That being said, no design shields users perfectly from all possible mistakes 🙂 So when we see you likely have an unexpected state (e.g. a rigid body component without a collider is just ignored) we warn about it.

Like the development? Please support us on Patreon!

This is a busy year for me, with many conferences where I can talk about our engine 🙂

If you live close, let me invite you to a conference in Poland: Zlot Programistów Delphi. Two days of lectures, in ~3 weeks (20-21 of September 2023) from now. I’ll have a talk about Castle Game Engine naturally!

I have also collected materials from some of the conferences where I spoke lately about Castle Game Engine.

Announcing a bunch of engine improvements all across the board 🙂

1. Examples:

   1. New example: examples/animations/split_long_animation. Shows how to play subrange of an animation. Replaces older MD3 demo, which was no longer relevant (because CGE now reads animations from MD3 perfectly).

   2. Improved example: examples/tiled/strategy_game_demo. Shows selected unit, more instructions. It’s a fully playable game using Tiled.

   3. New example: examples/viewport_and_scenes/projector. Shows how to project a texture.

   4. We moved Precomputed Radiance Transfer demoes to a separate repository.

      Reason: The radiance transfer shadows is not something we want to dedicate a lot of resources to support in CGE now.

      It was cool and educational experience to implement this in CGE many years ago. I learned also spherical harmonics along the way (and that repo contains also spherical harmonics visualization).

      But the current code of this demo is … dated. It is far from optimal, doing lots of work on CPU, simply because I never really got time to implement it efficiently. It also has some old CGE usage, that should probably get updated before this can be considered “official” CGE demo. Basically it’s not a code I’d recommend to look at to learn CGE. Even placement of PRM info is bad — I place this in X3D nodes, it should be rather separate files, to not mess with existing file formats (X3D, glTF) and be independent.

      As for the technique to make shadows, we concentrate now on shadow maps and shadow volumes. It’s already enough effort to support them perfectly 🙂 We don’t want to add a 3rd technique now.

      Maybe this will return some day to CGE core, with a reworked implementation (more on GPU), and reworked storage.

2. TCastleViewport.MouseRayHit and TCastleViewport.TransformUnderMouse improved: detect the object under the mouse cursor (or touch point) reliably, regardless if you hold some mouse button or move the mouse. Also detect on-demand (so cause no overhead for applications that don’t use it). Also TRayCollision.Transform utility added.

3. Android service to use TestFairy updated. It’s a 3rd-party service (free to a certain use limits) to help with testing mobile applications. It’s particularly useful to gather remote logs, to e.g. diagnose crashes on phones of your testers easily.

4. MD3 animations fixes – proper legs animations, FPS specific to animation, example examples/animations/md3_animations_tags shows full humans from Tremulous (combined from multiple MD3 models).

5. Fixed shadow maps in TCastleScene that is transformed.

6. Delphi 10.2.1 compatibility, more examples for Delphi fixed. As I mentioned a few times, last here, we are dedicated to perfect support for both Delphi and FPC 🙂

7. More information about default property values in custom components manual.

8. API of vectors like TVector3 was improved to expose and make writeable fields like XY, XYZ.

9. view3dscene navigation improved:

   1. Right click for mouse look (like in CGE editor)

   2. Change speed by mouse wheel (like in CGE editor)

   3. QE to fly up/down (in addition to space/C) (like in CGE editor)

   4. Supports center of rotation on navigation methods. Also new extension: autoCenterOfRotation, to essentially revert to old behavior: calculate center of rotation based on box center.

10. Fixed for ATI graphic cards.

    The BuggyPureShaderPipeline property is now completely removed (it is never buggy now 🙂 ), rendering on older ATI cards is now both more reliable and consistent with what happens on more modern GPUs (ATI or not ATI).

11. Continuous integration etc.:

    1. We have updated Debian version used in our Docker image to latest Debian bookworm. This was required to get latest Java 17 (required by latest Android Gradle Plugin, part of the Android build process).

       This also means that latest binaries that link with libc (like CGE editor) may not run on some old Linux systems. The usual symptom of this will be an error in console like this:

       /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
       

       That’s unfortunately how linking with libc on Linux works. If you experience problems — please report them, along with details about your system. We’ll see what we can do.

    2. Our Jenkins documentation page was reworked and improved, to describe how to set up your own Jenkins to use CGE Docker image and Jenkinsfile to build your projects.

When you change a file loaded into TCastleScene it is now automatically reloaded at design-time. The editor detects changing file by CGE sprite sheet editor, or changing any file by an external application (e.g. updating glTF file by exporting new version from Blender). In the latter case, the model will be reloaded when you switch back (e.g. using Alt+Tab) to the CGE editor application.

The logic to monitor files naturally only happens at design-time. At run-time, we don’t reload anything automatically, nor do we waste time on trying to detect the changes to files.

Right now, there’s no way to disable this detection, as it seemed to make sense in all use-cases. But we welcome feedback — if you have a workflow where this is undesirable, let us know 🙂

Note: The logic that detects changes isn’t 100% complete now. Some examples that still warrant manual reloading:

• We do not detect changes to secondary files, e.g. if you only changed a texture used by the glTF file, not the glTF file itself. We only watch the single file indicated by TCastleScene.Url.

  To force reloading file at design-time, just use “Reload URL” context menu item (right-click on TCastleScene in the editor hierarchy).

• When TCastleScene.Cache is used, the file will not be reloaded from disk in all cases. We should react to the cached file change properly in the future, for now you may need to reopen the design if your scenes use TCastleScene.Cache.

• Not all components implement necessary watching logic yet. For now only TCastleSceneCore does it. All components should eventually do it, e.g. TCastleTiledMap, TCastleImageTransform, TCastleImageControl.

I’m very happy to announce that my online book Modern Object Pascal Introduction for Programmers was translated into 5 languages as of now:

1. Bulgarian – thanks to Юлиян Иванов (alpinistbg)

2. Chinese (WIP) – thanks to 郑 (robsean)

3. Russian – thanks to Alexander (SpanerRh) and Eugene Loza

4. Spanish – thanks to Jorge Turiel Fernández

5. Ukrainian (WIP) – thanks to Vadim Vitomsky (iso4free)

All the translations are now prominently linked from the sidebar at “Modern Object Pascal Introduction for Programmers” and translations page. I also used this sidebar to prominently link to PDF version of the book (nice to print; 107 pages at this moment).

My big thank you! goes to everyone who has contributed to these translations (and to the book contents in general). It’s great to see that this book is useful for so many people. Let’s continue to show the world how Pascal is a productive and modern programming language. If you’d like to improve or propose a translation to a new language, go ahead — it is simplest to just fork the https://github.com/michaliskambi/modern-pascal-introduction/ repository and send a pull request.

On this note, I have been updating our page answering “why Pascal” to keep it a good argument why Pascal is a great tool to write your next application in 🙂

First of all, you can actually test our Android integration (and many upgrades described below) by trying out these test applications (APK) on your Android device.

We are also releasing these demo applications (and more!) on Google Play, to give everyone a really easy way to test CGE on Android. More about it when we’ll upload and publish everything 🙂

Now, the details about the Android changes done lately:

1. Google Play Games integration code was upgraded to use the latest (v1) API. Building of Android packages doesn’t make any “deprecation” warnings anymore.

   Everything is supported and tested:

   • Signing-in,
   • achievements,
   • leaderboards,
   • savegames.

   Actually a further upgrade to the sign-in logic is coming, through Google Play Games v2. They are almost equal (in code too) to v1, except the sign-in is even more automatic.

2. Example examples/mobile/game_services presents how to use Google Play Games. It show using automatic sign-in, achievements, leaderboards, savegames.

   The usage from Pascal comes down to the TGameService class.

3. Updated OpenAL (sound playback) service on Android (thank you to Andrzej Kilijański!).

   This fixes issue with stuttering sound playback on new Android devices.

   Note that OpenAL is used automatically when you build your game for Android, and you use sound. Declaring dependency on sound or having any *.wav, *.ogg file in data automatically adds this Android service.

   Changes related to new OpenAL:

   • We use latest OpenAL C++ code from OpenAL Soft (tag 1.23.1).

   • We use CMake compilation following Android guidelines.

     The manual compilation process is described in details on Andrzej blog, but you don’t need to do it yourself. We added C++ code and CMake configuration to the Android project, and it will be “compiled correctly and automatically” when you build Android application using CGE. Just build Android application as always, using CGE build tool or editor, and it will just create APK or AAB for you.

     Note: The C++ source code size is just 3.9 MB (previous precompiled libs were 1.3MB). So size isn’t any problem to distribute, it’s literally just 2.6 MB more.

   • A nice internal side-effect is also that updating to the latest OpenAL will be easier. We don’t host precompiled OpenAL libraries anymore, https://github.com/castle-engine/android-openal is now archived and useless. We will only need to update OpenAL sources in the CGE service, and Android compilation process (Gradle) will take care of building everything for all relevant platforms.

   • New OpenAL uses underneath Oboe.

   • Note: we use shared libraries following Google recommendation.

4. Updated Google AdMob on Android to use latest API – 22.1.0. (Thanks to Andrzej Kilijański!).

   If you’re interested in using AdMob in CGE, see admob service docs. Note that Pascal API for mobile ads didn’t change, you don’t need to adjust anything, just upgrade to the latest CGE.

   Older API was deprecated by Google.

5. Increased Android compilation SDK level to 33.

   This will be needed soon for new Google Play uploads.

6. Increased also Android minimum SDK level to 21. This means CGE supports only Android >= 5.0.

   AdMob requires Android API level 19.

   Oboe 1.7.0 requires Android API level 21.

   Realistically, testing also requires us to bump Android versions — we cannot test on very ancient Android devices, as we don’t have them anymore 🙂

7. Various pieces of the Android build process updated, to use latest Android Gradle plugin (8.1.0), Gradle (8.0), CMake, AndroidX approaches, and generally follow latest recommended practices.

8. Documentation updates:

   • main Android page
   • Android services
   • Adding new Android services
   • Android FAQ
   • Android information in CastleEngineManifest.xml
   • Android “google_play_games” service docs

9. The “base” Android project type was removed, as it was only a maintenance burden at this point.

   For all practical purposes, you need to use “integrated”, that has a bit of Java code and enables integration with a number of services (many in Java, some in native code — like OpenAL). And “integrated” was a default since a long time.

   Maintaining the “base” project wasn’t really useful anymore, since we didn’t recommend to ever use it.

10. Android services heyzap and google_analytics have been removed. The ecosystem moves fast, and some things just aren’t available anymore.

    Heyzap has been acquired by Fyber (which was later acquired by Digital Turbine). Maybe Digital Turbine offers a similar SDK, it remains to be tested.

    Google Analytics has been deprecated by Google and actually crashes on new Android devices. Google recommends migrating to their Firebase Analytics, we may add support for it in future CGE versions. Currently the best mobile analytics, integrated with CGE on both Android and iOS, are provided by game_analytics service.

As part of Castle Game Engine 7.0, we want to create a new behavior that will be a highly-customizable component that can perform typical enemy intelligence (moving, attacking) in 3D games.

More details in about our plans here.

Today, presenting work-in-progress by Alya Vaneskehyan (a 3D graphic artist from Cat-astrophe Games studio) on a new enemy, a cyber-punkish styled robot. The robot features both short-range (melee) and long-range (shooting) attack possibilities, since we want to demo them both 🙂