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 🙂

First of all, you can actually test our Android integration (and many upgrades described below) by trying out these test applications (APK) on your Android device.

We are also releasing these demo applications (and more!) on Google Play, to give everyone a really easy way to test CGE on Android. More about it when we’ll upload and publish everything 🙂

Now, the details about the Android changes done lately:

1. Google Play Games integration code was upgraded to use the latest (v1) API. Building of Android packages doesn’t make any “deprecation” warnings anymore.

   Everything is supported and tested:

   • Signing-in,
   • achievements,
   • leaderboards,
   • savegames.

   Actually a further upgrade to the sign-in logic is coming, through Google Play Games v2. They are almost equal (in code too) to v1, except the sign-in is even more automatic.

2. Example examples/mobile/game_services presents how to use Google Play Games. It show using automatic sign-in, achievements, leaderboards, savegames.

   The usage from Pascal comes down to the TGameService class.

3. Updated OpenAL (sound playback) service on Android (thank you to Andrzej Kilijański!).

   This fixes issue with stuttering sound playback on new Android devices.

   Note that OpenAL is used automatically when you build your game for Android, and you use sound. Declaring dependency on sound or having any *.wav, *.ogg file in data automatically adds this Android service.

   Changes related to new OpenAL:

   • We use latest OpenAL C++ code from OpenAL Soft (tag 1.23.1).

   • We use CMake compilation following Android guidelines.

     The manual compilation process is described in details on Andrzej blog, but you don’t need to do it yourself. We added C++ code and CMake configuration to the Android project, and it will be “compiled correctly and automatically” when you build Android application using CGE. Just build Android application as always, using CGE build tool or editor, and it will just create APK or AAB for you.

     Note: The C++ source code size is just 3.9 MB (previous precompiled libs were 1.3MB). So size isn’t any problem to distribute, it’s literally just 2.6 MB more.

   • A nice internal side-effect is also that updating to the latest OpenAL will be easier. We don’t host precompiled OpenAL libraries anymore, https://github.com/castle-engine/android-openal is now archived and useless. We will only need to update OpenAL sources in the CGE service, and Android compilation process (Gradle) will take care of building everything for all relevant platforms.

   • New OpenAL uses underneath Oboe.

   • Note: we use shared libraries following Google recommendation.

4. Updated Google AdMob on Android to use latest API – 22.1.0. (Thanks to Andrzej Kilijański!).

   If you’re interested in using AdMob in CGE, see admob service docs. Note that Pascal API for mobile ads didn’t change, you don’t need to adjust anything, just upgrade to the latest CGE.

   Older API was deprecated by Google.

5. Increased Android compilation SDK level to 33.

   This will be needed soon for new Google Play uploads.

6. Increased also Android minimum SDK level to 21. This means CGE supports only Android >= 5.0.

   AdMob requires Android API level 19.

   Oboe 1.7.0 requires Android API level 21.

   Realistically, testing also requires us to bump Android versions — we cannot test on very ancient Android devices, as we don’t have them anymore 🙂

7. Various pieces of the Android build process updated, to use latest Android Gradle plugin (8.1.0), Gradle (8.0), CMake, AndroidX approaches, and generally follow latest recommended practices.

8. Documentation updates:

   • main Android page
   • Android services
   • Adding new Android services
   • Android FAQ
   • Android information in CastleEngineManifest.xml
   • Android “google_play_games” service docs

9. The “base” Android project type was removed, as it was only a maintenance burden at this point.

   For all practical purposes, you need to use “integrated”, that has a bit of Java code and enables integration with a number of services (many in Java, some in native code — like OpenAL). And “integrated” was a default since a long time.

   Maintaining the “base” project wasn’t really useful anymore, since we didn’t recommend to ever use it.

10. Android services heyzap and google_analytics have been removed. The ecosystem moves fast, and some things just aren’t available anymore.

    Heyzap has been acquired by Fyber (which was later acquired by Digital Turbine). Maybe Digital Turbine offers a similar SDK, it remains to be tested.

    Google Analytics has been deprecated by Google and actually crashes on new Android devices. Google recommends migrating to their Firebase Analytics, we may add support for it in future CGE versions. Currently the best mobile analytics, integrated with CGE on both Android and iOS, are provided by game_analytics service.

As part of Castle Game Engine 7.0, we want to create a new behavior that will be a highly-customizable component that can perform typical enemy intelligence (moving, attacking) in 3D games.

More details in about our plans here.

Today, presenting work-in-progress by Alya Vaneskehyan (a 3D graphic artist from Cat-astrophe Games studio) on a new enemy, a cyber-punkish styled robot. The robot features both short-range (melee) and long-range (shooting) attack possibilities, since we want to demo them both 🙂

We’ve done a number of improvements to blending and billboards, to support more use-cases, and to make some cases “just work out-of-the-box”.

Before we start, just download latest version of Castle Game Engine and open a new example examples/viewport_and_scenes/billboards_blending_in_3d. It will illustrate most features mentioned in this post clearly 🙂

New features:

1. Existing 3D sorting algorithms (sort3D, sort3DOrigin, sort3DGround) now order by projecting shape point on the camera direction (instead of measuring the distance from shape point to camera position).

2. By default TCastleBillboard adjusts to camera direction, not vector from camera to billboard origin. (One can get old behavior by setting TCastleBillboard.MatchCameraDirection = false.)

   The end result of these 2 points is that if you use TCastleScene with TCastleBillboard, it will have perfect sorting even for extremely thin layers, like when loaded from Spine. Out of the box, i.e. default blending sorting and default billboard behavior are good.

   This works as long as TCastleBillboard.AxisOfRotation is zero or equal to camera up. The sorting is 100% reliably correct in this case.

3. Moreover, if TCastleBillboard.AxisOfRotation is +Y (default), then all you have to do is just to flip TCastleViewport.BlendingSort to sort3DVerticalBillboards. sort3DVerticalBillboards is a new option that sorts perfectly for billboards rotated around Y.

   Blending in manual was extended to mention the new option.

4. The TCastleBillboard transformation algorithm was also improved. It is now faster, and it is applied without any delay (you will never observe artifacts caused by potential-1-frame-delay between changing camera and transforming billboards to account for it).

   The TCastleBillboard transformation also accounts now for billboards instantiated many times. Whether you use TCastleTransformReference or Multiple viewports to display one world, all instances of the billboard will be now correctly oriented toward the camera.

5. In both new blending methods and billboard algorithms, I’m proud that I actually achieved a bit of code simplifications and optimizations. It’s nice when the better result is also just internally simpler, and the calculations involved are also simpler. E.g. sorting methods no longer transform 8 points of a box (they only transform 1). E.g. billboards get camera vectors in world space without any extra calculation (and these camera vectors correspond to current viewport).

We’ve done a number of “quality of life” improvements to properties manipulation in the Castle Game Engine editor.

1. We simplified the display of floats and vectors. No need for excessive trailing zeroes. Instead of 0.00 0.00.0.00 or 1.00 2.00 3.00 we now display 0 0 0 or 1 2 3 which is much easier to “parse” by a human eye.

2. Editing vectors and components of vectors automatically updates everything immediately. E.g. if you edit TCastleTransform.Translation.X to 10, the TCastleTransform.Translation will update immediately to 10 0 0. And if you edit the vector TCastleTransform.Translation to 42 0 0, the TCastleTransform.Translation.X will update immediately to 42.

3. The TCastleTransform.Direction and TCastleTransform.Up are now exposed in the “Basic” tab. Thanks to above improvements, you can now clearly see they are synchronized with TCastleTransform.Rotation — changing one changes the other.

4. TCastleImageTransform.Size is now more comfortable to edit: simply type single float to set both X and Y to the same value. E.g. type 10 to set Size to 10 10 (in Pascal this would mean Vector2(10, 10)). This is consistent with TCastlePlane.Size, TCastleTransform.Scale and similar properties: typing a single float sets all vector components to be equal.

5. The display and input of angles and rotations now displays / accepts degrees.

   Note that the Pascal API still accepts angles in radians. This is standard (in X3D, glTF, Math routines etc.). I experimented and looked at how others (Blender and Godot) present angles to make the end result useful and not confusing. To this end:

   • Angles are now displayed as degrees in CGE editor.

     And the fact that they are in degrees is explicitly shown by wrapping them with deg(xxx) text. So the angle looks like deg(45).

     We are deliberately explicit that the angles are in degrees, to avoid confusion.

     This affects both angles displayed as angle of axis+angle rotation (like TCastleTransform.Rotation saying 0 1 0 deg(45)) or as single float number (e.g. if you expand the TCastleTransform.Rotation to reveal the Angle (W) component).

   • When you input an angle value, you can keep the "deg(...)" wrapping, or you can input just the number. In the latter case, we will automatically add "deg(...)" around, so we interpret input as being in degrees anyway.

     This is similar to what both Blender and Godot are doing too, likely for similar reasons (have API in radians, but for display and input in editor — degrees are easier to use).

     This affects both single-value fields and 4D vectors. So for single-value field (like TCastleTransform.Rotation.W) typing "45" is understood as "deg(45)". For editing rotation as 4D vector (axis + angle) typing "0 1 0 45" is understood as "0 1 0 deg(45)". You will see the "deg(...)" added immediately, so it is hopefully clear what happens.

   • To be consistent, you can also use Deg in Pascal. It’s just an alias for DegToRad.

     The deg(....) case doesn’t matter. Deg or deg or DEG are the same. To interpret expressions in editor, the deg is a function in Castle Script.

   • This is also applied to 2D image rotations in TCastleImageControl.Rotation and TCastleImagePersistent.Rotation. Degrees everywhere!

The International Pascal Congress has finished and I’m packing home.

This was intensive and very positive experience.

My stuff:

• I had a workshop about Castle Game Engine (4 days, 1 hour per day) and a talk about graphics and game engines in Pascal. I got a lot of positive feedback about both the talk and the workshop and the engine 🙂 I’m coming back confident we have a great thing on our hands. (And we have to finally release engine version 7.0 and spread the word about it as wide as possible!)

• The slides from my presentation on Castle Game Engine at IPC 2023 are linked from here. The talk wasn’t easy to prepare (I wanted to cover a lot of things) but it seems it went really good. I went from a general description of modern GPUs and their APIs, through overview of various Pascal libraries and game engines for graphics, and ended with overview of things I consider important when making/choosing game engine.

• The above link Castle Game Engine at IPC 2023 also leads to notes from my CGE workshop and a bit silly (created during the workshop, with everyone watching) demo application.

In a broader context, about Pascal, and Delphi and FPC, this was invigorating as well. I met really great people, using both FPC and Delphi (really a mixed bunch, some people preferred Delphi some FPC/Lazarus, many were using both, like me).

• Including Marco Cantu, Delphi project manager. A heard a few presentations of language features (some specific to Delphi), and overall I am impressed by the direction Delphi is taking. Modern language (e.g. I was surprised by the power of inline variables and certain type inference involved, and I have to say I’m a fan now). Tools to build modern applications (RAD server). Looking at the landscape of other languages and integrating (FMX for Python devs).

• We also had a presentation about the upcoming Fresnel from Lazarus, and what it really means (CSS, Skia in FPC too), by Mattias Gaertner and Detlef Overbeek. This nicely connected with other talks about how important is the web target for everyone now — it was a prominent topic, along with pas2js, in the Bruno Fierens from TMS Software presentation. This is an exciting time — finally we think about a new approach to design visual applications, not only extending a dated VCL design. (Don’t get me wrong, LCL is nice, we’ve come a long way since VCL. But LCL inheritance from VCL is visible and causing issues — like the “absolute” layout by default, integer coordinates etc. Unlike web applications using CSS that can support both desktop and mobile with drastically different aspect ratios and physical sizes.)

Overall, I come back even more confident about some CGE decisions I was thinking about:

• Web target is super important. I already wrote about our plans for web target here.

• I absolutely want perfect support for both FPC and Delphi. I want to support both, and I want to support both equally well. They both go in good directions now. Some changes will be compatible, some incompatible between Delphi and FPC, but I don’t mind — let’s show the world that Pascal is a modern language, let users choose compiler they like, and as long as the core language stays compatible — I don’t mind a little incompatible libraries around. We’re in for interesting times.

  Maybe it also means switching to using CGE UI in CGE editor sooner than I originally planned. Because this opens the door to compile CGE editor with both FPC and Delphi, and to deploy CGE editor as a web application too.

• I was thinking about exposing CGE to Python developers at some point in the future. I was happy to learn this matches some Embarcadero ideas too. See DelphiFMX4Python: Python GUI module powered by Delphi’s FireMonkey framework. Supporting Windows, MacOS, Linux, and Android GUI development. And see python4delphi: Free components that wrap up Python into Delphi and Lazarus (FPC). And during talks, Marco (I believe correctly) pointed out that Python is enticingly close to Pascal in terms of thinking about “clean and readable programming language syntax”. Except they miss strong typing! My idea about attracting Python developers to CGE is therefore consistent.

  It is also nice to see Embarcadero active on GitHub.

  I also got some nice hint about using Delphi from Linux 🙂 I want to try it out and post about it later 🙂

Overall, I have a ton of notes, and a ton of new enthusiasm for both our engine, and Pascal in general.

In related notes, I just added a page “why Pascal” to our documentation — this is understandably a question we often get, and I want that page to be a good answer.

Have fun everyone! Back to packing now 🙂

It’s a pleasure to finally close a big TODO from our roadmap. This refactor took 122 commits, and it reworks a core rendering code in the engine. This was hard to do but also was a lot of fun — I used this opportunity to do a lot of code simplifications. These simplifications also translate to some performance gains.

New features / improvements

Blending sorting is now much better:

• It can be controlled using simple TCastleViewport.BlendingSort.

• The default is sortAuto, which auto-detects and uses best blending sorting for 2D or 3D (depending on camera parameters). For many applications, you should no longer even need to touch this, blending should “just work”. This was tested also with our bigger games The Unholy Society and Escape from the Universe.

• The new algorithm sorts all shapes, from all scenes. So it can account for transparent objects transformed in any way (using any hierarchy of TCastleTransform) and even for cases when multiple scenes’ shapes may result in mixed order. E.g. some transparent objects on the big (level) TCastleScene may be in front, and some behind, transparent objects of some creature TCastleTransform.

• To address non-trivial cases we have new TCastleViewport.OnCustomShapeSort event. You can define sorting function, using any criteria you want. See TShapeSortEvent for details and example event implementation.

Batching is now more powerful and easier to use:

• Batching can be activated by TCastleViewport.DynamicBatching, and thus configurable from CGE editor too.

  Remember you can invoke in CGE editor “Edit -> Show Statistics” (F8) to see the rendering statistics. They will reflect batching — the number of rendered shapes will drop.

• Batching now works cross-scenes. That is, shapes from one scene can be merged with shapes from another, unrelated scene, if their de-facto rendering settings (material, texture) match.

  Also more cases are now allowed for batching. In particular, batching now works for shapes (even from different scenes) with the same image loaded, and for TCastleImageTransform with the same image loaded — these cases, while seem trivial, are important when you design 2D maps.

  This makes batching much more universal, it works in more situations.

  In particular, designing your world using a big number of TCastleImageTransform instances is now reasonable — 100×100 TCastleImageTransform instances will not cause 100*100 draw calls, they will be batched into as few draw calls as possible (maybe even one, if you just use one image for all tiles). Example: examples/isometric_game.

• The global variable DynamicBatching is deprecated. Prefer to use TCastleViewport.DynamicBatching.

Occlusion culling is now easier and more powerful:

• Just toggle TCastleViewport.OcclusionCulling. There is no per-scene configuration. It’s a trivial checkbox in a viewport, so you can easily test does it gain anything in your case.

  It has been activated for examples/fps_game/, our 3D impressive demo. It’s also showcased in examples/viewport_and_scenes/occlusion_culling.

• Fixed to not trust occlusion query when scene is instanced many times in viewport, e.g. using TCastleTransformReference.

• Fixed for background (skybox) – the 1-frame delay was too noticeable for the background quads, so we don’t use occlusion culling for skybox sides.

• New TCastleViewport.OcclusionSort, with the same options for sorting as blending has. Allows to make occlusion culling even faster.

  TCastleViewport.OcclusionSort allows to use the same enums as TCastleViewport.BlendingSort, and it also allows to use custom sorting using TCastleViewport.OnCustomShapeSort event.

Others:

• New option TCastleRenderOptions.InternalColorChannels exists to limit which RGBA channels are written by rendering given model. Allows for some cool graphic tricks.

  Also it was necessary to make tricks that require rendering something only to the depth buffer, without touching the color buffer. See the fixed_camera_game example.

  For now this property is “internal” — I’m unsure how much it will be actually useful, and we want to reserve the right to remove it if it will become too unconvenient to maintain. Admittedly it may work a little weird — it doesn’t write some RGBA channels, but it still writes the depth values, so it’s a little hard to control what is visible behind it. If you find it useful anyway, please let me know about it 🙂

• OpenGL resources that are associated with X3D nodes are now stored in much more straightforward way, avoiding lookups using any dictionaries, and avoiding reinitialization when you move scene from one viewport to another. This makes accessing texture resources and screen effects’ shaders a simple and instant operation, instead of previous inefficient search.

Backward compatibility

This is a compatibility-breaking change, no way around it. The old sorting method, that was only sorting inside a scene, was inherently incorrect. Trying to maintain it for backward compatibility would make code really complicated, and API too. So you just have to adjust — set the TCastleViewport.BlendingSort if needed.

As always, if you have questions about upgrading, ask us!

What we did to address backward compatibility:

• From editor: We make a warning if your scenes use non-standard blending sort on import.

  We make a warning also if you used old Viewport.Items.BlendingSort.

  Judge whether the new version works, adjust TCastleViewport.BlendingSort if needed, and save the design to remove the warning.

• From code: RenderOptions.BlendingSort is just removed. Deliberately, there’s no way to sort only within scene now. We always sort within viewport.

  Same for Viewport.Items.BlendingSort. Same for TCastleScene.Setup2D.

  The compilation should break, forcing you to upgrade to new the new TCastleViewport.BlendingSort. It takes different arguments (sortXxx enums) and works much better. As explained above, you likely don’t need to set it at all. In my experiments, in almost all cases I just removed the calls to removed methods / properties and things are now automatically good.

• Default BlendingSort = sortAuto automatically adjusts to your camera.

  Setting typical 2D camera, by TCastleViewport.Setup2D or any other method, will activate 2D blending sorting.

  I’ve done a few iterations of this — I considered Setup2D not doing anything, or having obligatory AdjustBlendingSort (without default=true) or having a set like [seBlendingSort2D] or making Setup2D just set BlendingSort:=sort2D. Ultimately in all usages of TCastleViewport.Setup2D, in CGE and our games it was obvious that using new BlendingSort:=sort2D is a good idea.

  Eventually BlendingSort:=sortAuto won everything. It fills all use-cases nicely and easily. It is also naturally the default TCastleViewport.BlendingSort property value.

Special considerations for custom rendering

By “custom rendering” I mean here things that override TCastleTransform.LocalRender to issue direct OpenGL(ES) commands. For example Kagamma’s (Trung Le) projects:

• Particle Emitter, see news.
• Effekseer Integration, see news.
• Spine Runtime for Castle Game Engine.

If you perform custom rendering, without using TCastleScene nodes, note that things are a bit different now. TCastleScene.LocalRender only schedules shapes to be rendered later. So your custom rendering will always happen before the CGE TCastleScene rendering, so objects with custom rendering are assumes to be behind for blending. This shouldn’t really matter for rendering non-blending, but it may matter for rendering with blending.

I have a plan to play with it more, to make custom renderers more flexible. In the future, everything, including custom rendering, should make one “collect stuff for rendering” phase, and then all collected things should be executed. Right now, we do more “collect rendering” phases (once for opaque, once for blending) to also avoid breaking too many things for custom rendering algorithms. But it will change — so an optimization on top of existing work, and improvement for custom renderers, is coming.

Support our work

This was hard, and fun, work 🙂 Like it? Please support us on Patreon!

One of bigger things we plan to have ready (before 7.0 release) is Steam integration. This actually means 2 things:

1. Easy Steam integration (using “Steamworks SDK”) in your projects. This means accessing “Steamworks SDK” directly (without any “wrapper” library necessary) and being able to easily report to Steam things like achievements.

   Once initial integration will be finished, exposing more Steamworks features should be a breeze.

   Thanks to Eugene Loza, this is already in review: Steam PR.

2. We also want to actually publish “Castle Game Engine” as a tool on Steam. This way you will be able to find, install, upgrade CGE using Steam, of course on all supported desktop platforms: Linux, Windows, macOS.

   As the engine will be a Steam application itself, we’ll have fun achievements
   too — e.g. “compile your first CGE game”, or “see 100 compilation errors” 🙂

   This is in progress, we have already bought the Steam page and we started to fill it with content. As soon as it’s somewhat ready, we’ll want to open it — to allow you to wishlist it, then we’ll release “early access” version on Steam.