We now use GitHub Actions to automatically test and build CGE, in addition to our existing CI with Jenkins.

The main advantage of GitHub Actions for us, from a high-level view, is that they are more friendly to new contributors.

1. They work in every fork (even before you do any pull pequest) automatically.

   Jenkins, OTOH, only processes the main repository and PRs to it. Jenkins doesn’t even know about a fork if you don’t ever make a PR.

2. You will see GitHub Actions execution for each commit, nicely presented in GitHub UI. E.g. if you do PR, and you break compilation with some particular FPC version, you will immediately see which FPC version was broken by this commit (detailed logs are also available).

   This was also true for Jenkins, but the GH Actions results just look immediately more informative, with a breakdown into which job failed. In case of Jenkins, you got short information that a job failed, and you needed access to our Jenkins to see all the details why it failed.

3. Execution of all GH Actions (workflows, that in turn contain jobs) is also publicly visible.

The instructions what to do after each push are in .github/workflows/test-and-pack.yml in repo. This is somewhat equivalent to the Jenkins instructions in Jenkinsfile. You can all see them and propose edits to them.

Our workflow uses the same Docker image as our Jenkins to have the same environment for builds.

We also experimented with setup-lazarus-environment action on plain Ubuntu image — and it worked mighty fine, it was trivial to run a GH Action using FPC/Lazarus on plain Ubuntu without having any custom Docker image. Still, we’d need to extend that “plain Ubuntu” with some tools we need for some automatic CGE tests, and in the end (esp. since as our Docker image is useful for other purposes too, like interactive building and Jenkins) it was easier to just use our Docker image in GH Actions.

To be clear, we still also use our beloved Jenkins, but we’re just exploring an alternative.

• Jenkins still gives us ultimate control over the whole process — configuration on master, ability to setup slaves in any way we like (we right now have Linux, Windows, Raspberry Pi slaves, and will soon resume macOS slave thanks to macStadium). E.g. it’s not a problem to have Windows slave with Delphi 11 Enterprise installled, or Raspberry Pi slave.

• It remains to be seen how much of it is worth “switching over” to GH Actions and how much should remain on Jenkins in the foreseeable future. I know that you can run GH workflows on self-hosted machines, but I suspect with this comes both the trouble and the power inherent in the fact that you maintain these machines, their resources like CPU and disk space, yourself. So for now, at least most GH workflows will be on GH-hosted servers, and we shall see how much this is really problematic to us and how much we enjoy it.

• There’s also a question of “money and control”, unrelated to the technical superiority of this or that solution. GH Actions are free for open-source projects (but the infrastructure is closed and depends on GitHub). Jenkins servers require maintenance (which I usually enjoy) and have a cost (paid by my company Cat-astrophe Games which shares some of the Jenkins infrastructure), OTOH Jenkins remains open-source and under our control forever.

• Well, for now I’m just having fun with more automation tools :), and just experimenting.

Thank you all for today’s meeting!

I think it went good, my only regret is that we want to have more participants! To facilitate this, I’m immediately announcing the next meeting, 3 months from now. Reserve the date! 🙂 Join our Discord right now and click “I’m interested” on the “2nd Open Meeting for CGE Users and Developers“.

Summary:

Things in progress:

1. light-components branch by Michalis, with lights (point, spot, directional) as components that you can visually add/modify in CGE editor; also more flexibility where lights are cast and received; also Phong shading by default, and limit of lights per shape increased to 64.

2. physics branch by Andrzej Kilijański, with colliders and rigid body components as behaviors, that you can add and adjust in CGE editor; also auto-size by default for colliders.

3. Testing GitHub Actions as another CI tool, in addition to our existing Jenkins.

Next plans:

1. Camera and navigation: a few inter-connected new features: 1. camera visible in viewport, 2. design-time and runtime camera and navigation separate, 3. navigate on right-click, like in other game engines (Unity, Unreal).

2. fps_game – AI using behaviors. Setup whole FPS game in editor. light-components branch actually already has example design how it would look like.

3. Publish CGE as a tool on Steam.

4. Assign and override materials in CGE editor.

5. CGE 7.0-alpha.2 release ASAP, CGE 7.0 in 2022!

As announced previously, we’ll have a meeting today, and everyone is invited!

Join Michalis Kamburelis and other Castle Game Engine developers, contributors and users.

The meeting will happen at 16:00 (UTC timezone) on Saturday, 5th March.

Meeting will be on our Discord channel #open_meeting.

• This is the direct link to the event on Discord. Right now you can click Interested button on this event and add it to your calendar (click on … to see the options).

• Simply join Castle Game Engine Discord before the meeting starts, and join that channel.

Please keep your mic muted when you’re not speaking, to avoid the noise 🙂

1. New utility TCastleTransform.RemoveDelayed to remove TCastleTransform but not immediately. This is great if you need to remove some TCastleTransform from children list, but you also iterate over the children list right now.

2. We no longer use windres utility, instead we generate Windows resources in memory using FPC’s units from fcl-res package.

   Our build tool now uses fcl-res units to actually build a resource file in memory, and write the resulting RES file. This means we can write the Windows RES file without the help of any external tool, and without creating some intermediate/temporary RC/manifest files. Everything happens in memory, in a cross-platform way.

   This is nicer for people with Delphi, who want to compile applications without the need to download windres from FPC/MinGW/MSys.

   This is also nicer for people doing cross-compilation from e.g. Linux to Windows. Previously this required Linux version of windres, which needed installation of MinGW binutils on Linux. Now this utility is not necessary.

3. MultiTexture features are now restored in shader renderer. All models from demo-models/multi_texturing and described on our X3D multi-texturing page now work with latest CGE and view3dscene.

1. Long time ago, we had to disable optimizations with FPC on Aarch64 (64-bit Arm) as they were too unstable. But were happy to revert this 🙂 With FPC >= 3.2.2, optimizations on Aarch64 work flawlessly, and so we enable them. This affects Android, iOS and macOS Silicon targets.

   The optimizations will remain disabled if the build tool detects you’re using FPC 3.2.0 and compile to Aarch64. You will see appropriate warning about it in the output. For this reason, we recommend that you upgrade to the latest stable FPC, 3.2.2.

2. Fix to usage of Compressonator on Linux: detect also lowercase compressonatorcli executable, following new Compressonator file naming in Linux.

3. Fix to usage of PVRTexTool. We adjusted compression format names to follow latest naming from PVRTexTool Command Line Options.

4. GameAnalytics SDK usage on Android upgraded to 6.2.6.

Continuing the recent trend of using “just a screenshot of CGE rendering some nice glTF model when I have no better idea for a news image” here are 2 renderings of phones. “Retro Phone” (Sketchfab) by Marek Picheta is licensed under Creative Commons Attribution. “Phone booth” (Sketchfab) by YJ is licensed under Creative Commons Attribution as well.

I wrote this announcement a ~week ago, which feels like ancient times now. Since then, Russia attacked Ukraine. Right now bombs are falling on the heads of people in Ukraine, including people who use and develop CGE, including my friends and their families. I feel terrified, outraged and powerless — this horrible thing just happened, just because some murderous madman in Russia decided to play war.

We already announced this meeting earlier on Discord, and I propose we go ahead and try to do this meeting on 5th March… and hope the world will be at a better place, not worse, by then. I will let you know if we decide to reschedule.

Let’s meet and talk! Join Michalis Kamburelis and other Castle Game Engine developers, contributors and users.

The meeting will happen at 16:00 (UTC timezone) on Saturday, 5th March.

Meeting will be on our Discord channel #open_meeting.

• This is the direct link to the event on Discord. Right now you can click Interested button on this event and add it to your calendar (click on … to see the options).

• Simply join Castle Game Engine Discord before the meeting starts, and join that channel.

Please keep your mic muted when you’re not speaking, to avoid the noise 🙂

More details what can happen:

Many factors tell me that meeting together would be great 🙂 It will be a great way to ask and answer “live” some CGE questions. It will be a great way to showcase what I’m working on. And I want to invite everyone else to showcase what you are working on too! I hope to make this a 2-way show, in which everyone interested has time to take the stage and show whatever (s)he wants, ask any questions etc.

1. A small convenience when writing float values: you can input an expression, like pi, pi / 2 or 2/3 instead of typing the actual value (3.14…, 1.57…, 0.6666….).

   Any expression using CastleScript is allowed.

   This is nice e.g. for angles for which we use radians (consistent with X3D, OpenGL, many other APIs). So you have to think in terms of pi (not degrees). At least now you can write pi/2 instead of calculating 1.57... in some external calculator. (An even better solution, to both display and edit angles in degrees, like just 180deg that just means pi automatically, is possible in the future. My main fear with it is that people will get confused that API still expects radians, and passing Angle:=180 will not work as expected. So for now, you have to use radians all across CGE, but it’s just easier now.)

   It is nice for any other use-case when it’s easier to write an expression than result. 1/3, 2/3, 10+1/3 are some examples.

   As a funny example of abusing this, note that you can even use random function from CastleScript 🙂 So you can input in CGE editor value random() and get different result each time 🙂 I’m sure it’s a unique feature of CGE that you can assign an unpredictable value to a property 🙂

   This is all just an “editing convenience”. The value is calculated immediately as you change focus / press Enter, and it is stored as a simple float (not as CastleScript expression) in the actual property, in serialized JSON etc.

   We have also changed the division operators in CastleScript to work like in Pascal: / makes float division, div makes integer division.

   If you want to use such expression in your own applications, go ahead: just call ParseConstantFloatExpression instead of StrToFloat.

2. The “Output” tab has a simple context menu (right-click). It allows to clean it, copy selected line, copy all lines (to the clipboard). Great to copy-parse error message to show it someone.

3. I have changed the editor start form. No revolution (yet — I do have a more interesting redesign on a TODO list), I just wanted to expose nice buttons to open examples and support us on Patreon.

Two news about our TCastleWindow class:

1. The TCastleWindow and TCastleControl are now (again) advised to be used through these simple names.

   There is no more need to use the names with Base suffix, TCastleWindowBase and TCastleControlBase. They are now just deprecated aliases to the simpler names without the Base suffix.

   Underneath, this happened because of a change I announced at the end of 2021: The old deprecated TCastleWindow.SceneManager and TCastleControl.SceneManager are now removed. They were causing complicated dependencies (in the end TCastleWindow / TCastleControl code should not deal with viewport/scenes specifics), and the assumption that “every window starts with a default scene manager” was unnecessarily complicating understanding of CGE, and even the name SceneManager was outdated (we call it just “viewport” since a long time). The deprecated CastleWindowTouch was also removed — just use TCastleTouchNavigation.

2. We now use a Unicode (UTF-16) version of WinAPI throughout our TCastleWindow backend on Windows. This fixes support for international characters in window caption and in native open/save dialogs.

This is yet another post when it was hard to find a screenshot expressing the API improvements 🙂 So here’s a rendering of window glTF model from SketchFab, by Yury Misiyuk in Castle Game Engine editor. The window glass nicely utilizes the material possibilities of PBR, the reflections of a dirty/old glass are nicely realistic and completely dynamic. Here I show them with lights designed in CGE editor — a feature that is correctly in development.

New method TCastleViewport.PositionFromWorld allows to map a viewport (3D) position into user interface (2D) position. This allows to:

1. Place UI element exactly where some 3D thing is.

   The example examples/viewport_and_scenes/position_from_world shows how to position a TCastleLabel so that it always remains at the TCastleSphere middle, regardless of how you move and zoom the camera.

   It comes down to these lines of code:

   { calculate SphereViewportPosition, position of the sphere middle in 2D viewport coordinates. } SphereWorldPosition := MainSphere.LocalToWorld(Vector3(0, 0, 0)); SphereViewportPosition := MainViewport.PositionFromWorld(SphereWorldPosition); { SphereViewportPosition is immediately useful to determine LabelAttached position } LabelAttached.AnchorDelta := SphereViewportPosition;

   1 2 3 4 5 6

   { calculate SphereViewportPosition, position of the sphere middle in 2D viewport coordinates. } SphereWorldPosition := MainSphere.LocalToWorld(Vector3(0, 0, 0)); SphereViewportPosition := MainViewport.PositionFromWorld(SphereWorldPosition);   { SphereViewportPosition is immediately useful to determine LabelAttached position } LabelAttached.AnchorDelta := SphereViewportPosition;

2. Measure the (potential) size of 3D element on the screen. In turn, this allows to transform 3D elements to make them look on screen in some desired way. For example, you can adjust 3D scale, to force some 3D object to have certain size on the screen, regardless of how far it is from the camera.

   The same example examples/viewport_and_scenes/position_from_world shows how to position a TCastleText so that it always has the same size, no matter how far away the pivot is (regardless of how much you zoom in/out the camera). Try out the demo, you can rotate and zoom like crazy — the 3D text will rotate, the sphere will get smaller or larger, but the size of the text will remain the same.

   It comes down to these lines of code (note: PositionFromWorld and SphereViewportPosition calculation is the same as in previous use-case):

   { calculate SphereViewportPosition, position of the sphere middle in 2D viewport coordinates. } SphereWorldPosition := MainSphere.LocalToWorld(Vector3(0, 0, 0)); SphereViewportPosition := MainViewport.PositionFromWorld(SphereWorldPosition); { calculate Sphere1UnitSizeOnScreen, how large is 1 unit in 3D space around sphere, on the screen. } SphereWorldPosition1 := SphereWorldPosition + Vector3(0, 1, 0); SphereViewportPosition1 := MainViewport.PositionFromWorld(SphereWorldPosition1); Sphere1UnitSizeOnScreen := PointsDistance(SphereViewportPosition, SphereViewportPosition1); { use Sphere1UnitSizeOnScreen to keep the TextAttached size similar on screen, regardless of how far is the scene. } TextAttachedScale := 100 / Sphere1UnitSizeOnScreen; TextAttached.Scale := Vector3(TextAttachedScale, TextAttachedScale, TextAttachedScale);

   1 2 3 4 5 6 7 8 9 10 11 12 13

   { calculate SphereViewportPosition, position of the sphere middle in 2D viewport coordinates. } SphereWorldPosition := MainSphere.LocalToWorld(Vector3(0, 0, 0)); SphereViewportPosition := MainViewport.PositionFromWorld(SphereWorldPosition);   { calculate Sphere1UnitSizeOnScreen, how large is 1 unit in 3D space around sphere, on the screen. } SphereWorldPosition1 := SphereWorldPosition + Vector3(0, 1, 0); SphereViewportPosition1 := MainViewport.PositionFromWorld(SphereWorldPosition1); Sphere1UnitSizeOnScreen := PointsDistance(SphereViewportPosition, SphereViewportPosition1);   { use Sphere1UnitSizeOnScreen to keep the TextAttached size similar on screen,   regardless of how far is the scene. } TextAttachedScale := 100 / Sphere1UnitSizeOnScreen; TextAttached.Scale := Vector3(TextAttachedScale, TextAttachedScale, TextAttachedScale);

1. I created a nice documentation about managing states. Some of this information was already available, but scattered over the manual and not so clearly organized. The new page should serve as a clear documentation how states are supposed to be used.

2. We have a nice list of TCastleTransform descendants with screenshots in the manual page about the viewport. This should serve as nice description “what I can put in a viewport”.