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.

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 🙂