With big thanks to Simon Booth (Peardox), who provided the necessary machine to be mercilessly used by our Jenkins, our downloads now feature a ready binaries for Raspberry Pi 64-bit OSes.

This is a fully-functional and tested engine version. Get the engine, install FPC, and you’re ready to design and build games on your cool device!

To install FPC, you can install it from Raspberry Pi packages (sudo apt install fpc) or you can build FPC yourself. In the latter case, be sure to not use the latest stable version, 3.2.2, due to known issues. Instead, use 3.2.3 (fixes_3_2 branch of FPC) or latest FPC 3.3.1. You can build FPC yourself e.g. using fpcupdeluxe or a script like this.

The builds have been tested on Raspberry Pi version 4. They should support this or later Raspberry Pi OS versions, so they should be compatible with Raspberry Pi version 5 as well (though we have not yet been able to actually confirm it — give us a shout if you have Raspberry Pi OS 5 and have tested it!). The same goes for existing 32-bit Raspberry Pi engine downloads.

I’m proud to publicly show two articles I recently wrote to teach Castle Game Engine!

They assume zero initial knowledge and they show the most important pieces of our engine. As such, I highly recommend reading these articles, whether you’re a newcomer or an experienced developer familiar with the engine. Read them here:

1. Part 1: Castle Game Engine installation, editor, designing a 3D world, views, testing physics. (PDF version: 22 pages)

2. Part 2: Coding using Pascal and Castle Game Engine API, behaviors, selection and hover, reusing a design of a 3D object. (PDF version: 33 pages)

The articles guide you through creation of a simple fun application — the titular “bad way to play chess”. If you want to play a ready game, download and install it from here (ready binaries for Linux and Windows). If you want to get the source code, clone the GitHub repository at https://github.com/castle-engine/bad-chess/.

All the techniques shown in the article are recommended ways to use the engine, they are proven to be comfortable and flexible for a wide range of games, and we work on keeping them optimal. The article and examples are suitable for both FPC and Delphi developers.

The articles have already been published in the Blaise Pascal Magazine. Also our supporters on Patreon have received an early preview of both articles. If you like our engine and these articles, we really appreciate if you can support us on Patreon!

This is probably a bit surprising news, coming from a game engine written in Pascal 🙂 Don’t worry, there are improvements relevant for Pascal too, at the bottom of this post!

That said, I do love playing with new toys, and a toy I played with recently was C++ Builder. C++ Builder is Embarcadero C++ compiler and IDE, closely integrated with Delphi and so Pascal. I played with exposing our engine classes to C++ developers. It turns out it is really trivial to expose full Castle Game Engine API (with all classes and features) to C++ developers this way!

For example, you can now write code like below to operate on TCastleScene from C++:

__fastcall void TViewMain::ClickMove(TObject* Sender)
{
    Scene1->Translation = Scene1->Translation + Vector3(0, 1, 0);
}
 
__fastcall void TViewMain::ClickBunny(TObject* Sender)
{
    Scene1->Url = "castle-data:/Bunny.gltf";
}

The end result is that our engine API is 100% available for C++ developers. This includes

• using our classes like TCastleWindow or TCastleControl to initialize the window or control (on FMX or VCL form),

• using our views (TCastleView descendants) to manage bigger projects,

• using TCastleViewport, TCastleScene and other viewport features to render 3D and 2D content,

• using TCastleButton and other engine user-interface controls,

• loading components (view contents, or smaller things) designed in CGE editor.

All the related classes are just available to you as C++ classes. The Pascal units are available as C++ header files. Properties, methods, global routines, enums etc. — just everything works and is exposed in C++ using concepts analogous to Pascal. This is the amazing power of C++ Builder.

The examples are in the latest engine official download, in particular:

• Example delphi/cpp_builder/fmx shows using TCastleControl inside FMX form,

• Example delphi/cpp_builder/window shows using TCastleWindow, with views, loading a design, operating on TCastleScene and more. It faithfully recreates in C++ one of recent CGE Pascal examples from the ITDevCon 2023 conference.

Follow the installation procedure inside, in particular please note you have to build and install Delphi packages. This generates the C++ header files and the object files to be linked.

Don’t worry, we’re still a Pascal game engine 🙂 And we continue to love and promote Pascal. The beauty of this integration is that it doesn’t require any maintenance, our Delphi and Pascal code is just completely automatically available for C++ developers with equivalent capabilities. So, going forward, we are fully committed to supporting both Pascal and C++ developers this way.

I am excited to see where this will take us 🙂 If you have C++ Builder, and wonder about using Castle Game Engine with C++ this way, please go ahead and be sure to report any issues or success stories!

Please note that right now the CGE documentation remains Pascal-oriented. I hope that the above two C++ Builder examples (in examples/delphi/cpp_builder/) are enough to give you an example how Pascal concepts map to C++. If it’s unclear how to access anything from C++, let us know (ask on forum, Discord…).

While doing this, we polished by the way some engine pieces useful for Delphi (Pascal):

• We introduce a new castle_engine_window Delphi runtime package. This includes units that work with our TCastleWindow component. While you don’t have to use this runtime package to build Pascal CGE applications using TCastleWindow (instead, new projects by default will just link to CGE Pascal units, without using the package) but it’s an important stepping stone to make Delphi aware of all our classes and go with GetIt.

• We now automatically cooperate with default Delphi and C++ Builder convention to put exe files in a project subdirectory like Win32/Debug/, Win32/Release/, Win64/Debug/ and so on. We will detect this situation and access data directory automatically correctly, so that your applications using data directory will work correctly out-of-the-box in this case.

• We have explicitly switched our XML vendor in Delphi to OmniXML, for all platforms. This is a fast cross-platform XML vendor. We use it on all platforms with Delphi now (not MSXML on Windows) to have most consistent cross-platform behavior.

Our usually-weekly news announcements have been quieter in November, I know. I blame it on me being somewhat exhausted from a ton of work and talking about the engine recently. But let’s get back on track, let me do some noise in the upcoming days about all things we did / are doing 🙂

Let’s start with font and text updates.

1. Our default fonts, embedded in the engine, have been extended to include over 2000+ common Unicode characters to cover most languages in the world. This means that, for most people, rendering the special characters in your native languages should just work out-of-the-box

   This applies to all kinds of rendering. In particular using TCastleLabel (2D, UI) and TCastleText (3D, in viewport). As long as you leave their CustomFont equal nil (default) to keep using the default font.

   Rendering X3D / VRML (using any engine tool, like view3dscene) also now automatically shows local characters. Test e.g. various international “Hello World” X3D examples from this page (open .x3d or .x3dv files linked from there in views3dcene).

   Note that it doesn’t change what characters are present in your custom defined fonts. You still can (and should) customize the TCastleFont.LoadCharacters to include all glyphs from all languages you plan to support.

   Almost all common glyphs are included, except the languages that have really typically a lot of characters: Chinese, Japanese and Arabic. If you find your language characters missing, let us know, and I will likely “just add a few more characters” to the default font. Unless your language has really a lot of specific glyphs.

2. The embedded 3D fonts have also a bit higher quality (generated with 25 size instead of 20).

3. To counter the explosion of font data in the engine (which could slow compilation time), we followed this with some cleanups:

   • We removed some old unused UI fonts from the engine (with sizes 10, 15, 18).

   • We removed 11 font variants embedded previously to support 12 possible combinations of X3D FontStyle (3 typefaces, bold or not, italic or not). Now we just embed Sans-Serif font, not bold, not italic, by default.

     To render other fonts, we advise to define custom fonts, as documented in Text and fonts manual. Define as many fonts as you want, use TCastleFontFamily to define a collection (bold or not, italic or not) of fonts to be used e.g. with TCastleLabel.Html rendering. See the fonts/html_text example.

     If you want to specifically render X3D with full support for 12 variants possible by FontStyle, then do what view3dscene source code now does: embed the additional fonts and adjust DefaultFontData map to use them.

   • We renamed font files to be independent of the font size, so that we can easily change sizes in the future. All in all, src/fonts is now much simpler.

4. We have also fixed rendering of fonts on ancient hardware, without OpenGL 3.

   This typically happens on Windows virtual machines, that have ancient OpenGL 1.1 by default. And we deliberately do support it. We’re committed to supporting any OS configuration, as long as that OS has security support; so e.g. modern Windows is supported, no matter on how poor hardware you will use it; but Windows XP is not :). Note: if you want to get newer OpenGL on Windows virtual machines, Mesa builds for Windows are quite useful. Unless of course you can enable “real” 3D acceleration by making host GPU used efficiently by OpenGL inside the client.

Notes about things planned, but not done here:

1. We want in the future to enable loading “on demand” additional font glyphs (for entire language sections) from font files. This would mitigate the current need to just embed a lot of font glyphs by default.

2. We want to finish distance field fonts rendering method, to improve the font quality without the need for alternative font sizes.

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:

• examples / network / asynchronous_download

• examples / network / remote_logging

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 http://neverssl.com/ — 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:

• TCastleDownload Indy handler

• TCastleDownload TNetHttpClient handler

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.

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.