Asynchronous downloading using TCastleDownload for Delphi

Posted on

asynchronous_download with Delphi
remote_logging with Delphi

Our TCastleDownload component, that supports asynchronous downloading of resources, now rocks with Delphi too. It supports downloading from http and https (and other URL protocols supported by Castle Game Engine).

You can test with Delphi e.g. these examples:

Most features you expect are supported:

  • Asynchronous operation (TCastleDownload connecting and downloading doesn’t block the main thread),

  • various HTTP methods (GET, POST with post data…),

  • getting MIME type from server response,

  • updating progress (total bytes, downloaded bytes),

  • aborting download in the middle is instant and doesn’t cause any further problems.

  • Both http and https work smoothly on Windows.

    For https, note that you have to use OpenSSL DLLs. You can get the 2 necessary DLLs from engine win64 openssl libraries or engine win32 openssl libraries.

    We advise to compile at least once using CGE editor that will place the DLLs automatically alongside your EXE. You only need to specify in CastleEngineManifest.xml that your project depends on Https, see dependencies in CastleEngineManifest.xml.

  • The code also works on Delphi/Linux. Tested with not-yet-merged delphi-linux branch.

    http downloading works (test e.g. using — because it’s not so easy to find unencrypted http now).

    https unfortunately doesn’t work for now, i.e. it will likely answer “SSL library not found” if you run it on a modern Linux system. It seems Indy requires really old OpenSSL library version (1.0 ?), not available in e.g. latest Ubuntu. And it’s not even OpenSSL 1.1, which is already old but known to be required by some applications (so installing OpenSSL 1.1 will not help). There is a PR to support newer OpenSSL in Indy, but seems it was never finalized.

The underlying implementation uses Indy (TIdHttp component). It is built-in in Delphi, so you don’t need to do anything. We have an alternative implementation using TNetHttpClient, though testing showed it has really bad speed, so we don’t recommend it. For more internal comments see the source code:

If you’re interested in http and https downloading using Delphi, without Castle Game Engine too, then you may be interested in my test of TNetHttpClient and TIdHttp.

Comments on the forum ➤

Slides and examples from 2 ITDevCon presentations about Castle Game Engine, more notes about recent developments

Posted on

Michalis at ITDevCon 2023
  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:

  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).

Comments on the forum ➤

Catch me at ITDevCon 2023 in Rome giving 2 presentations about Castle Game Engine

Posted on


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 🙂

Comments on the forum ➤

Using Delphi “welcome page” to show your, also docs updates, also coming soon: new navigation components and Delphi + Linux

Posted on

Delphi welcome page showing README in Markdown
Delphi welcome page showing README in Markdown

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 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

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!

Comments on the forum ➤

Docs for devs coming from Unity, editor improvements: 2D camera gizmos, per-component warnings

Posted on

Reporting warnings
2D camera gizmo

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?

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:

    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!

Comments on the forum ➤

Upcoming talk on “Zlot Programistów Delphi 2023” (Polish conference), collected materials from past conferences about our engine

Posted on

Zlot Programistów Delphi 2023

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.

Comments on the forum ➤

Various improvements: examples, Android, shadow maps, Delphi compatibility, view3dscene, CI…

Posted on

MD3 animations
MD3 humans
Projecting texture
Radiance Transfer

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/ 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.

Comments on the forum ➤

Automatically reload data at design-time

Posted on

"Lynch" gamejam game - in Blender

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.

Comments on the forum ➤

Translations of “Modern Object Pascal Introduction for Programmers” to YOUR language

Posted on

Visual Studio Code - Pascal code completion
VS Code running Castle Game Engine task

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 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 🙂

Comments on the forum ➤

Android: upgraded everything! (Google Play Services, OpenAL, AdMob, API level, Gradle…)

Posted on

Game Services Demo in Castle Game Engine
Game Services Demo in Castle Game Engine

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, 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:

  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.

Comments on the forum ➤