Michalis was busy last week reviewing and merging many Pull Requests to our engine. Thank you everyone for your contributions, and your patience with me (sometimes when I’m busy finishing some other work in CGE, that takes priority, and PRs wait a bit), and keep it coming!

In particular:

1. We now support providing input data (as a stream) for HTTP requests (like PUT, or POST when TCastleDownload.HttpPostData is not enough), thanks to Vlad (phomm). Use the TCastleDownload.HttpRequestBody and see at examples/network/put_data/put_data.dpr.

2. We now support fast toggling of Tiled layers visibility thanks to Dennis Spreen. Simple example is part of map_viewer example, just set Boolean like TiledMap.Data.Layers[0].Exists := .... This is the exact method with example code.

   For future plans, see our “New API for Tiled layers” section in the roadmap.

3. Our deprecated library (for C, C++ applications that want to utilize CGE to display 3D models in any application) was extended to allow configuring input shortcuts thanks to Jan Adamec.

4. Our XML utilities have been improved to support reading and writing colors as hex values thanks to Eugene Loza.

   There is another big PR from Eugene incoming: Steam support! And more from Eugene: distance field fonts, Bootstrap upgrade, screen effects + blending…

5. Our build tool can now return more information: FPC paths, project paths thanks to Andrzej Kilijański. This is initial part of our upcoming big feature for VS Code users.

   There’s more from Andrzej as well: new navigation components, optimization for mouse move events, Android improvements…

And finally, we have also fixed CGE on FreeBSD and tested it with latest FreeBSD 14 version. We did it by fixing CastleGL, our dglOpenGL fork, to support FreeBSD. Thanks to Bartosz Jarzyna for reporting!

Thank you everyone for contributing. I hope you enjoy working with our game engine, and please keep it coming, we have big plans to be the best open-source game engine ever! See our roadmap to get inspired. Our features list wants to grow 🙂

Hi all! Our news have been quiet lately, let me fix this by a big list of recent developments 🙂

The list below is not really complete, we have some big thing (for Delphi people) already merged to CGE, but we’ll wait with announcing it until Delphi GetIt servers are fully back online. And we have another big thing (for VS Code people) almost finished. Stay patient 🙂

Onward with what we have to announce today:

1. Ticoban, a 3D Sokoban version made using Castle Game Engine, is available now for free. Go check it out! By Rafael Campos.

2. Editor now allows to drag multiple components in the hierarchy so you can more easily rearrange your components.

3. Throughout CGE, we now use CastleGL unit to access the OpenGL API.

   This is a minimal fork of dglOpenGL, originally done by Sascha Willems and Delphi OpenGL Community (DGL). Our fork makes it compatible with all CGE compilers and platforms by using our CastleDynLib unit under the hood. E.g. it adds Delphi/Linux compatibility.

   We use it in CGE for all compilers (FPC and Delphi) and all platforms using desktop OpenGL (Linux, FreeBSD, macOS, Windows, …).

   This makes things simpler — so we just have 2 units, and both are in CGE: CastleGL (desktop OpenGL) and CastleGLES (OpenGLES). So code can just do {$ifdef OpenGLES} CastleGLES, {$else} CastleGL, {$endif}.

   And dglOpenGL is much better base than built-in things in FPC or Delphi.

   • FPC has GL, GLExt, but their extension querying was not useful with modern OpenGL (was using deprecated, and removed in core, glGetString(GL_EXTENSIONS) instead of glGetStringi(GL_EXTENSIONS, i)).

   • Delphi has OpenGL, OpenGLExt units but only for Windows.

   • They both miss some things, e.g. WGL routines to initialize modern context on Windows.

   We have been able to simplify some CGE code, esp. around WGL or dealing with GLExt issues, thanks to migrating to dglOpenGL. You can read more about my thoughts in #334.

4. We’ve made a few CGE tester improvements and simplifications:

   • --no-window-create command-line option.

     Removed NO_WINDOW_SYSTEM define, no more IsConsoleMode check. The new --no-window-create option is better both for usage and development.

   • –filter command-line option, for both GUI and console testing, to filter tests by a wildcard.

   • Reliable reporting of both unhnandled exceptions and assertions’ failures, on both GUI and console.

   • Removed old FPCUnit-specific code. It was confusing now, without much benefit. We have completely own testing framework, though still heavily inspired by FPCUnit.

   • Cleaner compilation output (ignore deprecation warnings — tests knowingly use deprecated things, to test that deprecated stuff also works).

5. There have been some internal refactors to make relevant code easier:

   • CastleOpenDocument implementation split into include files, much more maintainable now.

   • UInt32 / Int32 used everywhere, instead of LongWord / LongInt.

   • TCastleContainer.LoadSettings can be called without context initialized — this is easier in some use-cases, see e.g. Delphi+FMX/VCL examples.

   • TCastleEdit caret blinking improved (reset after text change, fix for AutoRedisplay=false).

6. TCastleContainer has now TCastleContainer.PixelsWidth / TCastleContainer.PixelsHeight and Width / Height are deprecated.

   Goal: to make it more clear that PixelsWidth / PixelsHeight are the actual size of the container. The existing Width / Height was a bit confusing.

   We have TCastleContainer.UnscaledWidth / TCastleContainer.UnscaledHeight to get the size of the container when you think with UI scaling. They should be renamed to Width / Height in the future, so they’ll get new more intuitive meaning.

7. Now that Extended RTTI has been merged in FPC, we look with renewed interest at using some newer RTTI features in CGE.

   In particular, we have experimented some time ago with some ideas how we could use Pascal custom RTTI attributes. If both FPC and Delphi will have equal implementation, we really benefit a lot, we could add simpler API for publishing vectors, exposing test methods, exposing methods to be available as editor actions, etc.

As we get near the end of 2023, I want to simply thank everyone who supports Castle Game Engine in whatever way — on Patreon, by making games, by code contributions, by feedback, or just by simply being here and looking what we’re doing 🙂

The end of this year was a bit busy for me, admittedly, and I didn’t achieve yet some of our big goals I hoped for 2023 (like 7.0 release, or even 7.0-alpha3, or Delphi/Linux finish, or review of some very important PRs like Steam, new navigation components, Tiled improvements). But I hope to get there, there’s still one more week! 🙂 And we did a lot already, making the engine both more functional and also easier to use in many departments. See all things we added for 7.0-alpha3. We also have lots of new up-to-date training material, starting from “Bad way to play chess” 2 tutorial articles, though many manual updates, Pascal learning materials and finally slides and examples from all conferences I attended in 2023. I hope you enjoy this steady progress.

Onward with a description of most important recent API updates:

• Undeprecated and made read-only TCastleTransform.RigidBody. This is just a shortcut for Transform.FindBehavior(TCastleRigidBody).

• Temporary but important TCastleTransform.InternalMovesPhysicsBodies — workaround for some cases when using physics, and moving parent object from code whilst children objects have physics rigid bodies.

• New TCastleComponentFactory — load a serialized component and instantiate multiple times.

• New ComponentClone — deep-copy (clone) any component.

• Some long-deprecated CastleSoundEngine API removed (or moved to private, so not accessible): SoundEngine.Sound, SoundEngine.Sound3D, SoundEngine.PlaySound, SoundEngine.LoadBuffer, SoundEngine.FreeBuffer.

  Since a long time, we have better alternatives: play sound using TCastleSound, TCastlePlayingSound, TCastleSoundSource, TSoundEngine.Play. See the sound engine documentation. These new classes provide much improvement (are easier to use from code, and are possible to setup in editor too).

  If you have any questions how to upgrade old API usage, consult above manual, and talk to us! A short map:

  SoundEngine.Sound can most usually be just replaced with SoundEngine.Play

  SoundEngine.Sound3d replacement is more involved, you need to use TCastleSoundSource attached to some TCastleTransform.

That’s it for today, but I hope to have bigger news very soon — hopefully still in 2023 🙂 Have a good Christmas, holidays, and a happy New Year everyone!

And since this was a year of AI boom, enjoy 3 AI-generated CGE + Christmas themed postcards attached to this news post 🙂

Last week, I got my PineTab2 tablet, made by the PINE64 community. In a way, it’s an early Christmas gift I bought for myself 🙂 It’s a tablet running Linux on 64-bit Arm. My hope was to have something that can be a tablet (light device, can do tasks for which touchscreen input is comfortable enough, like read things and watch movies) but also can be a laptop (do e.g. coding, as it features a fully-functional Linux and a keyboard with touchpad). It took some tinkering, but I have to say my hope was fulfilled and I love it 🙂

It’s still a low-end device, by which I mean that it’s not very fast and when I have a choice — working on a regular modern PC / laptop is just faster. But it’s also not terribly slow. It is much more powerful than e.g. a Raspberry Pi 4 (e.g. examples/platformer runs on PineTab2 with ~30 FPS, which is playable; on Raspberry Pi 4, I could run it, but it wasn’t really playable). The device is fast enough to even use KDE Plasma by default (Though I’m a GNOME guy, I’m bound to install there familiar GNOME 3 or XFCE at some point; but for now I enjoy KDE, it’s an interesting change for me).

You can install there FPC, Lazarus, VS Code, and finally our Castle Game Engine and have fun making games. The default OS on PineTab2 is DanctNIX, which is Arch Linux ARM, and in practice it features most of software you would find on a regular Arch Linux, both from official packages and AUR.

Technically, it is just Linux on a 64-bit Arm CPU (known also as Aarch64).

You can guess where this is leading: The official Linux/Aarch64 downloads of Castle Game Engine “just work” on PineTab2. Enjoy!

There are no special instructions, just download, unzip and run bin/castle-editor inside, as on other platforms. Remember to also install FPC (Free Pascal Compiler), see below

FPC on PineTab2

While you can install FPC from the packages (sudo pacman -S fpc), you may experience linking problems with FPC 3.2.2. They result in errors with messages like undefined reference to__libc_csu_init’`.

When that happens, my advise is to install FPC 3.2.3 (from the fixes_3_2 FPC branch). I am testing now on FPC 3.2.3 + Lazarus IDE from recent main branch. I used my install_fpc_lazarus script for easy setup.

Castle Game Engine in AUR

About CGE package in AUR: While it should work in the future, first the FPC built into DanctNIX has to be upgraded (see above — FPC 3.2.2 will have problems at linking). Then we should update the castle-engine-git package to just add aarch64 architecture and it will rock, allowing you to install CGE on it by just yay -S castle-engine-git.

Editor binaries: GTK2 or Qt5

The CGE editor on Lonux comes with 2 binaries since some time: castle-editor (GTK 2) and castle-editor-qt5 (Qt5). To run the latter, you have to install qt5pas (sudo pacman -S qt5pas) but it does have occasional crashes, looks like some LCL Qt5 widgetset problems. I advise using castle-editor for now.

PinePhone, PineBook Pro

In theory, this support should extend as well to other PINE64 products using Arm64, like Pinebook Pro and PinePhone. They all “just run Linux on Arm64” so in principle should work.

I’m pretty confident that it will work on Pinebook Pro without any issues. I would assume it would be just an upgraded experience compared to PineTab2 in terms of performance, but without touchscreen.

I’m super-curious about PinePhone 🙂 If anyone has PinePhone, and wants to test can we install FPC and CGE there, let me know. I can help if you want, e.g. we can meet online and test it together.

Before you buy PineTab2

In case this post encourages you to actually buy PineTab2 tablet, please take into consideration:

1. I am enthusiastic about this tablet, and I’m also a Linux fanboy 🙂 I actually enjoyed testing 3 different OSes on this (DanctNIX, Ubuntu Touch, Rhino Linux) to see what works best. I enjoyed testing browsers to see what has best support for the touch screen, performance, and can play DRM content. I enjoyed playing with WiFi (while the laptop has a WiFi card, DanctNIX doesn’t feature a working WiFi driver, and the simplest recommendation is to use a WiFi dongle; Ubuntu Touch has a working WiFi driver, but comes with different issues around touchpad).

2. Make your own decision if you will enjoy above tinkering too 🙂

3. See PineTab2 wiki and reviews like Pine64 PineTab 2 unboxing and review by Ivon Huang, After 3 months of daily-driving tPineTab 2, ARM Linux tablet, I love but also hate it.

4. If you want a fast and fully-functional tablet that “just works” then a modern Android tablet or iPad may suit you better. (Though PineTab2 supports Waydroid so you can run Android tabs, but with performance hit.)

   And if you want a fully-functional laptop that “just works”, than a regular laptop may be better 🙂 PineTab2 wasn’t even supposed to be a laptop (for this, see Pinebook Pro). I just decided to test can it fulfill the role of a laptop, for some work, for me.

Since we had much talk on Monday about mobile development on our Discord, it is most suitable that I’m publishing today a toy we’ve made with my daughter this weekend in our Castle Game Engine 🙂

It’s a simple game we’ve designed for (and tested on) an Android tablet, but it is really a cross-platform toy, works on desktop or any mobile, any size.

The concept is simple: 2 cars, ride forward into infinity, avoiding the obstacles on the road. Deliberately with placeholder graphics and very basic logic — play with it, extend it, make it into your own toy! The README of the game summarizes the current features and possible extension ideas.

I actually have a bit modified private version, with my daughter we started to make our own graphics — some images are photos of real-life toys, some combine random things we found on the Internet. Consider the placeholder graphics in that project as an invitation to make your own experiments!

To get it, just download the latest version of the engine and open the example in examples/mobile/two_cars/ subdirectory.

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.