This is a small infrastructure change for us, but you can also follow this for your own projects, if you already use GitHub Actions to build your applications.

For some time, we have been using self-hosted real Raspberry Pi machines to build our releases (of Castle Game Engine, Castle Model Viewer and PasDoc) for Raspberry Pi. This includes 32-bit Raspberry Pi (with support also for older OS version, based on Debian bullseye) and 64-bit Raspberry Pi (with support for OS versions >= based on Debian bookworm).

However I was doing tests to see can we use GitHub-hosted Linux runners (thus, available for free, and maintained for us) to build our releases for Raspberry Pi. The idea is to run Raspberry Pi in a virtual machine (not only do cross-compilation to it) to be able to also run tests on it.

Turns out there’s a ready ARM runner GitHub Action that does exactly this. Examples of using this for Pascal applications:

• I’ve done testing can we use it reliably to build FPC + Castle Game Engine applications, which you can see in the repository michaliskambi/test-arm-runner-for-cge. The workflow file inside shows how to build CGE application for Raspberry Pi using this runner.

• I adjusted PasDoc snapshots building to use it. See PasDoc workflow here.

• See also Castle Game Engine workflow.

• See also Castle Model Viewer workflow.

We have switched all our projects to building Raspberry Pi releases using this approach now.

Recently we did some updates to our VS Code extension for Castle Game Engine and the Pascal LSP.

1. VS Code extension now uses the FPC path you set for more things. Namely, the build tool (which is executed when you press “Compile” from VS Code) will reliably use this FPC. This means that there’s no need to have FPC on $PATH anymore to use CGE from VS Code. Just configure FPC location in VS Code and everything should “just work”.

   Further notes:

   • Direct link to the extension in the marketplace.

   • We actively develop our VS Code extension, see the changelog for all details. I (Michalis) use it during all my work on the engine nowadays, so I really need it to be good and handle code in various stages of “in progress” 🙂

   • Reminder: The extension is useful for development of any Pascal projects, whether using Castle Game Engine or not. Pascal syntax highlighting and code completion (provided by LSP) work regardless of the Castle Game Engine. Only the “Compile”, “Run” features rely on CGE project (CastleEngineManifest.xml).

2. Our Pascal LSP (pasls binary present in engine downloads) also got updates. It now better reports errors, capturing all possible Pascal parsing errors and returning useful error messages for them — with filename, line and column number. The idea is that, when working, you naturally sometimes have a code that isn’t (yet!) correct, so the code tools sometimes cannot provide their services (completing, jumping to definition etc.). In such case it’s important that you get useful errors, why is your current code wrong.

   • Reminder: While nowadays we test our LSP mostly with our VS Code extension for Castle Game Engine, but it’s not limited to VS Code. Every editor that supports LSP, including Emacs and NeoVim should be capable of using this LSP for code completion in Pascal projects.

Our website looks a bit different all around since last week 🙂

• We have upgraded the underlying Bootstrap (which serves as the base for our look) from version 3 (rather ancient at this point) to the latest 5.3.

• We took this opportunity to make some small improvements:

  • dark-themed navigational bar,

  • navigational bar properly collapsing on mobile (or just narrow window sizes),

  • search box in the navigation bar,

  • simpler “Donate” button leading to streamlined Donate page,

  • from the main page we have a link “Video Tutorial” to our presentation from Dev Days of Summer 2024.

• In some cases (like link colors and font), we decided to follow the new Bootstrap defaults.

This is a preparation for a bigger website redesign. What we have now, thanks to using the latest Bootstrap 5.3 and thanks to being simple (generally following Bootstrap conventions, with only minor customizations) should lend itself nicely to bigger redesign.

What bigger redesign, you ask? 🙂 Well, we’ve been planning a website redesign for some time now, to make it both more impressive and communicate our intentions better. Attaching to this post a cool main page redesign from Adrianna Matejek. This is something which we want to eventually reach!

We’re proud to present ready Steam integration in Castle Game Engine!

Features:

• Use Steam API to
  • Control achievements (list, get, set state).
  • Get some information (country, language, VR mode, Steam Deck, whether some DLC is installed).
• Works on all supported platforms: Windows, Linux, macOS.
• Works with all supported compilers: FPC, Delphi.
• Ready Pascal unit CastleSteam.
• Ready example in the engine sources: examples/steam.
• We have put deliberate effort into solving some technical things in a clean way: the integration doesn’t need any “wrapper” Steam library (you only need Steam DLL/SO from Valve, not anything additional), the integration code is clean and cross-platform (in particular, we use SteamAPI_ManualDispatch_GetNextCallback and friends – no assembler, no hacks to simulate C++ VMT in order to receive callbacks). This implies that our integration should “just work” on any platform supported by Steam, forever, reliably.
• We have further plans related to this. The most immediate: release Castle Game Engine on Steam! We are finishing setting up our Steam page. Next: add more features from Steam API, like support joysticks using Steam (allows to handle any joystick type, and user can customize the handling in Steam) and Steam Deck-specific API (e.g. activate on-screen keyboard on Steam Deck).

Everything is documented on our Steam documentation page. It has also been mentioned on slides in 2 recent conferences — see Cologne FPC/Lazarus Meeting 2024 slides, Delphi Programmer’s Meeting (Polish) 2024 slides.

This big work has been largely done by the late Eugene Loza.

If you like what we do, we appreciate your donations.

1. We’ve made a big optimization to processing of large worlds (which means: many TCastleTransform in a viewport), that in particular benefits cases when you use shadow volumes.

   This changes how an important rendering code works. We now make 1 pass to collect all the shapes, and reuse results of this pass a few times — 2x without shadow volumes (because we render opaque and then transparent objects), 4x for shadow volumes (was 5x before the optimization, but I managed to completely remove one). This means that “traversing transformations” (which matters for large worlds) is 2x-5x faster now.

   This matters for a number of applications, in particular it is impactful for applications using shadow volumes and non-trivial amount of scenes: pirates demo for Dev Days of Summery 2024 or games like DSRally from DiDi.

   For some technical details, see notes in the GitHub issue and notes about AddRenderEvent (how to make custom rendering code now).

   (This was done over a month ago, but I finally got to announcing it: ) ).

2. We made a big refactor to the shadow maps processing.

   The immediate benefits are: much simpler code (using shadow maps is no longer entangled with texture coordinate generation in ProjectedTextureCoordinate) and fixes for some cases, like using shadow maps and occlusion texture.

   The more long-term benefits: This opens the door to finally improve shadow maps to work cross-scene and be trivial to activate from editor. The way forward is now clear: remove the TShape.InternalShadowMaps, pass the shadow maps when rendering, thus enabling the shadow maps from one scene to another.

3. Small inspector rendering optimizations, and FrameProfiler shows now also rendering time spent in DrawPrimitive2D and TDrawableImage.

4. Nintendo Switch version updated.

   While we cannot publicly share much details, the overview is simple: the very latest version of the engine is available and tested for Nintendo Switch, using the latest software stack for developing games from Nintendo). We also added “Run -> Platform -> Nintendo Switch” to the editor menu, so building can be done from GUI.

5. Improvement: In the design mode (that is, in editor), we always have precise collisions. You no longer need to worry to toggle TCastleSceneCore.PreciseCollisions just to select things in the editor.

6. Fix: Important fix has been pushed for physics. If you modify a transformation of TCastleTransform that has children TCastleTransform, and these children have physics behaviors (colliders, rigid body) then it’s automatically OK now.

7. Fix: Saved JSONs are a bit shorter. No need to write JSON object for a vector / color with default value.

8. Fix: Container.MousePosition during Motion events could be wrong due to recent Motion events collecting. It’s OK now. This also fixes mdRotate option of the TCastleWalkNavigation.

9. Fix: Billboards in multiple viewports are now rendered OK. This also fixes lights gizmos in editor, when using camera preview. This also fixes lights gizmos in editor in terrain demo blinking.

10. Improvements: examples/lazarus/model_3d_viewer for various UI improvements.

11. Improvements: default .gitignore for new projects is improved to ignore some files produced by Delphi.

A recording from my presentation in 2023 is now available on YouTube. This talk is titled “Advanced Castle Game Engine: forms, 3D generation, shaders, customization” and I presented it at ITDevCon conference in Rome almost exactly 1 year ago. I go through 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.

More:

• Slides from the talk are available here,
• recording of the 1st talk (preceding it and introducing our engine, editor, coding in Pascal, physics) is here,
• all collected resources (slides, recordings, examples) from past conferences are here.

Enjoy, and if you like it please support us on Patreon!

Today’s news is a combo of new things 🙂 I am back from 1.5 weeks of conferencing (first in Germany then in Poland). I have fresh energy, new demo and slides for you to enjoy!

1. First of all, I have merged to CGE master branch an initial design of TCastleMoveAttack component that allows to easily define a creature AI. The idea is to attach this behavior to any TCastleTransform and make it behave like a typical FPS games enemy — it will walk toward (configurable) enemy, it will make a short range attack, it will run away from enemy when low on health etc.

   It cooperates with the TCastleLiving behavior that represents something that has hit points and can be dead / destroyed. You will typically add TCastleLiving to each enemy (otherwise enemy is indestructible) and to the player (camera or avatar, depending on if you make a 1s-person or 3rd-person view).

   It is configurable what is the enemy for each TCastleMoveAttack — they can track and attack any TCastleLiving. So they can attack the player, or fight with each other — lots of fun possibilities!

   There are some important TODOs remaining to be finished in this regard, so I emphasize that the way this component works will change (in particular, the movement will change to follow physics). Do not use it yet for bigger projects — though you can certainly use it already to have some fun 🙂 I also emphasize that this is not the only way to make enemies logic in Castle Game Engine — you can always code your own logic, creating new behaviors (see e.g. “3D FPS Game” template for a starting point).

   The existing documentation for now is in API reference of CastleLivingBehaviors unit and you can take a look what the examples do:

   • examples/creature_behaviors
   • examples/fps_game
   • New demo project from “Zlot Programistów Delphi” conference last week
2. Enjoy the new demo project mentioned above from “Zlot Programistów Delphi”: Demo game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack.

   It’s a complete game with level designed using Blender, level props from Sketchfab, enemies from Quaternius, enemy logic using TCastleMoveAttack and TCastleLiving. The game code shows simple things like game “win” (you “win” the game when you reach a certain invisible box in the level), game “lost” (when player’s life drops to zero), walking with mouse look, shooting at enemies.

   The example is naturally compatible with both FPC/Lazarus and Delphi.

3. Finally, the slides from my presentation at “Zlot Programistów Delphi” 2024 are available.

   Note that they are in Polish, as the event is mostly in Polish. If you have trouble translating anything, and want to learn it, just let me know 🙂 Some of the topics overlap with slides I used for my Cologne lecture so you can find some explanation there too.

I’ve done a presentation about our engine at FPC & Lazarus meeting today in Köln, and I think it went really well. I had more time than usual, so after an introduction to the engine, I could go in more depth about some recently added features, including:

• TCastleComponentFactory (with some cool improvements announced last here, demo usage in examples/space_shooter.)

• Our new Steam integration. More about it in a dedicated news post coming soon!

• Our new (work in progress, but already cool) TCastleMoveAttack component, providing out-of-the-box working creatures AI (so they can walk toward a configurable enemy, attack, run scared, die… typical “FPS-game enemy” logic in a ready tweakable component). See also our roadmap about it. It’s not yet finished, but it does work (on a walk-attack-behavior branch, see new examples/creature_behaviors version there). I showed some initial fun and promising results — see the slides below for screenshots!

The slides from the talk are available here. They are also embedded below:

Cthulhu fhtagn! This news post contains a collection of Cthulhu renderings I posted in recent years — it turns out I post quite a lot of Cthulhu stuff. Usually, when I don’t have a perfect screenshot to illustrate a news post, I just pick something pretty rendered using our engine — it turns out that often this “something pretty” is Cthulhu for me 🙂

Completely unrelated to the screenshots, here are a few new features we’ve added to the engine lately. And if you like what we do please support us on Patreon!

1. Our command-line build tool has a new option unused-data to perform a crude analysis of what data in your project is possibly unused.

   This means that some files inside the data subdirectory of the project have been detected as unused, so they don’t seem to be loaded by code or required by other data files. This means that keeping them inside the data subdirectory is possibly needless. Files inside the data subdirectory (that are not excluded by the CastleEngineManifest.xml rules) are automatically packaged with your application (for example, if you create an Android APK, or a package to ZIP for desktop platforms). If you have some unnecessary files there, then possibly you distribute more than you need, and you could have a smaller application.

   To test this use command-line to enter your project and just execute castle-engine unused-data.

   I emphasize that this is crude analysis. It uses some assumptions that may be wrong, definitely are sometimes wrong, and they may result in errors in both ways (some unnecessary files may be undetected; some detected files may actually be used). Don’t trust this analysis without your own judgement. But it may be useful in some clear cases, when there are easy and obvious ways to optimized your applications size. If some files are indeed unused, consider moving them outside of data (e.g. to subdirectory like data-source) or excluding packaging them by CastleEngineManifest.xml rules, or even removing them (you have them in version control anyway, right?).

   This mechanism allowed to make CGE download size smaller by 30 MB recently 🙂 So yes, it is practically useful (albeit not magic, savings are not that big).

2. The Priority of a sound can be now configured on TCastleSoundSource and TCastlePlayingSound (in addition to being configurable on TCastleSound, as before). See the TCastleSoundSource.Priority, TCastlePlayingSound.Priority, TCastleSound.Priority properties. They are all multiplied, just like Volume and Pitch — see manual about sound for usage description. Thanks go to Dennis Spreen for implementing this!

3. We have extended TCastleComponentFactory.ComponentLoad with a powerful optional mechanism: if you pass an additional instance of any class descending from TPersistent, we will set the published fields of that instance to refer to the new components created by TCastleComponentFactory.ComponentLoad.

   The mechanism is really comfortable to use. It solves a common need when using TCastleComponentFactory.ComponentLoad: you want to access from code a subset of new components.

   See for example how rockets are instantiated in our space shooter example. Consult also API docs of TCastleComponentFactory.ComponentLoad, they discuss everything with example snippets.

4. We have added ApplicationProperties.FreeDelayed utility. As the name implies, it schedules removing a component soon. It’s a bit similar to TCastleTransform.RemoveDelayed with FreeItem=true (that also got important fix by the way), but using ApplicationProperties.FreeDelayed is more straightforward in some cases: you don’t need another TCastleTransform to schedule freeing.

   Example usage is in space_shooter demo.

5. We expose a few properties to determine the quality of generated spheres, cylinders, cones:

   • TCastleSphere.Stacks
   • TCastleSphere.Slices
   • TCastleCylinder.Slices
   • TCastleCone.Stacks
   • TCastleCone.Slices

   Note that there’s no TCastleCylinder.Stacks — cylinder doesn’t need it, it always has one stack.

6. “Copy URL” command is now available in the editor context menu when you right-click on a file in the bottom panel.

   Nice to easily paste the URL into Pascal code to load.

   For files within data, it will use a protocol castle-data:/. Like castle-data:/gamestatemenu.castle-user-interface, castle-data:/level.gltf.

   For files outside of the data subdirectory, it will be reguar file:/... URL with absolute path on your system. Like file:///home/michalis/sources/castle-engine/lynch/demo-images/lynch_screen_1.png. This is naturally less useful: you should not place hardcoded paths in your code, as they work only on your system.

7. Slowly but surely we modernize our joysticks (gamepad) API. We have now separate TJoystick.LeftAxis and TJoystick.RightAxis. Test how they work in examples/deprecated_to_upgrade/joystick demo. See our roadmap for joystick API plans.

A new option at TCastleFont is available that activates distance field font rendering. Using it is trivial: just set up TCastleLabel with custom font in TCastleFont, following the manual about text and fonts. Then toggle TCastleFont.DistanceField checkbox to true.

This is an alternative technique for rendering fonts which results in font having better quality if you “upscale” it, that is: render large font size (e.g. because TCastleLabel.FontSize is large, like 100.0) but the underlying font texture is small (that is: TCastleFont.OptimalSize is smaller, like 30.0).

The font rendered using distance field fonts always remains “crisp” on the edges.

The technique, at least in our current implementation, has some drawbacks — see TCastleFont.DistanceField API documentation. Never the less, it definitely results in a more crisp text look in many practical cases.

An extreme examples of it are available in (maybe even a bit too extreme, it shows actually some issues) is the new example: examples/fonts/distance_field_fonts.

This feature has been implemented largely by the late Eugene Loza. We miss you.