New Features in Castle Game Engine 7.0

Visual editor
Village scene with outlines in glTF from Sketchfab ( <a href="https://sketchfab.com/3d-models/ftm-0970f30574d047b1976ba0aa6f2ef855" class="bare">https://sketchfab.com/3d-models/ftm-0970f30574d047b1976ba0aa6f2ef855</a> by Luis Fernandez )
Terrain with water and trees
Tiled isometric map
Tiled hexagonal map in "Strategy Game" demo
Escape from the Universe (Switch) - Japanese edition
The Unholy Society
Open-source, integrated with GitHub, GitLab, Jenkins

This page documents Castle Game Engine 7.0 new features. It’s a work in progress — as we work on making final official CGE 7.0 released.

1. Plans and Timeline

  • We will make another alpha release in 2024, called 7.0-alpha3. The new features are documented below.

  • We plan to release version 7.0 (stable) around the middle of 2024.

    See our roadmap for more long-term goals (not just in 7.0).

  • The most important feature after 7.0 release is the web target. This will be our focus for the rest of 2024. Our hope is to have web target working around Christmas 2024 — seems like a nice Christmas present :)

2. Features released so far

2.1. Already available in snapshot, will be released in 7.0-alpha.3

All features below are already available. Download the engine from our download page and enjoy them.

  • Physics

  • Visual Studio Code integration:

    • Intelligent code completion and syntax highlighting for all Pascal code (not necessarily CGE projects).

    • Integration with engine project building / running / debugging for Castle Game Engine projects.

    • Packaged in one neat VS Code "Castle Game Engine" extension with trivial configuration: just point it to your engine directory.

    • The underlying LSP server usefu also with Emacs, NeoVim and other text editors supporting LSP.

  • Delphi:

  • Easily activate shadows, just select checkbox Shadows at the light source to use shadow volumes.

    • By default only shapes that are 2-manifold are valid shadow casters.

    • You can also force to treat the whole scene as 2-manifold (useful when its 2-manifold when you sum all shapes, and shapes can use different materials) using TCastleRenderOptions.WholeSceneManifold.

    • Note: We plan to expose also our shadow maps in a similar easy-to-use fashion in future releases.

    • Both shadow volumes and shadows maps work on mobile (OpenGLES) too.

  • New component to support Tiled maps:

    • Part of the viewport (can be mixed with CGE scenes, sprite sheets…​),

    • Excellent performance to render huge maps.

    • Configurable layers.

    • Examples on examples/tiled/ upgraded, in particular we feature a complete playable turn-based strategy game.

  • Renderer improvements:

    • Correct and automatic blending sorting. Read blending documentation and news 1 and news 2 to understand the details. But the gist is that it now works much more "out of the box" in both 3D and 2D typical game scenarios.

    • Batching is easier to use (just flip TCastleViewport.DynamicBatching, observe the MyViewport.Statistics.ToString to learn if you achieved any performance improvement). And it is more powerful — it can now batch across the scenes and can batch more things, e.g. TCastleImageTransform with the same image will be nicely batched and rendered using one "draw call".

    • Occlusion culling is also simpler to use: flip TCastleViewport.OcclusionCulling. See examples/viewport_and_scenes/occlusion_culling for demo.

    • OpenGLES supports now almost all desktop rendering features: shadow volumes, shadow maps, 3D textures, occlusion query, anisotropic filtering, meshes with 32-bit indexes.

    • Using only modern OpenGL 3.x context features, if possible.

    • Using "core" OpenGL profile on macOS by default, thus having OpenGL 4.x API on macOS

    • More optimal drawing of line primitives and quads.

    • TCastleRenderUnlitMesh utility.

    • Fixes for older ATI GPUs.

    • New projects automatically contain code to use dedicated GPU (important on laptops with dual GPUs).

    • TCastleTransform.RenderLayer to render stuff in front.

  • User Interface improvements:

  • Many editor UX improvements. The most important ones:

  • Improvements around our views (formerly states):

    • Cleaner API to set / push / pop the view on given container.

    • Published fields of a view are now automatically initialized.

    • Editor greets you, when you open a project, with UX to open existing view, or create a new view. This communicates the recommended actions to user after opening a project, and emphasizes our focus on designinig you application around views. See relevant news.

  • Mobile:

    • Lots of Android services improvements: Google Play Games, OpenAL, AdMob.

    • Installation of tools is also simpler and better documented. See news.

    • The on-screen keyboard on Android is automatically invoked when you focus a TCastleEdit.

    • Lots of iOS fixes and improvements. As with Android, it takes some effort to keep up with the changes in the tooling (macOS, Xcode) and actual devices (iPhones, iPads) but we do this, so that you don’t have to :)

  • Improvements around our installation process:

    • On Windows and Linux, the engine download automatically includes a useful compiler (FPC 3.2.2) so that you can build CGE applications without the need to install anything extra.

    • On Windows, we now have a self-extracting installer, that is simpler and faster than manually unpacking zip, and registers our engine editor in Windows menu.

    • Raspberry Pi engine downloads for both 32-bit (Arm32) and 64-bit processors (Arm64 aka Aarch64) available officially. The Linux/Aarch64 versions are also tested on PineTab2, a nice Linux tablet from Pine64.

  • More important improvements without a clear category:

  • Lots of new or upgraded examples. E.g.

Not part of the engine release, but still cool to mention:

castle-model-viewer (formerly view3dscene) and castle-model-converter (formerly tovrmlx3d), our tools to view, convert and validate 3D and 2D models, also got many improvements.

  • castle-model-converter now supports:

    • --validate to perform only validation (not conversion).

    • --float-precision to control output floating-point precision.

    • reading from stdin, and --stdin-url to specify input type and base directory.

2.2. Released in 7.0-alpha.2

See full 7.0-alpha.2 release announcement for details.

2.3. Released in 7.0-alpha.1

See full 7.0-alpha.1 release announcement for details.

2.4. Released in 7.0-alpha.1: Expanded version

3. Advise for upgrading: Upgrade your pipeline from X3D to glTF

While X3D is still our scene graph format (which means that everything you render is composed from X3D nodes in memory, which practically means: Pascal classes TXxxNode), our main file format is now glTF, not X3D (which means that we advise to export from Blender to glTF, not to X3D).

The reason for that is practical. glTF is just better now, as a file format:

  • Although X3D offers a lot of features, but the existing Blender -> X3D exporter is extremely poor. It doesn’t support many features (e.g. it cannot export animations, or even textures in the latest version).

  • Moreover, the existing Blender -> X3D exporter doesn’t support features which are CGE extensions or are only in X3D 4.0, like PBR or normalmaps. We had an extended CGE exporter (to X3D) for older Blender, but it was too much burden to maintain. We also had castle-anim-frames exporter, but castle-anim-frames is a poor solution compared to proper glTF skinned animation.

  • Existing Blender -> glTF is actively maintained (by Khronos together with Blender), and supports all the features we like. In particular PBR, all possible textures and normalmaps, unlit materials, animations by transformations, animations by skinning, by morphing, metadata (from Blender custom properties).

  • glTF ecosystem is more active. By this I mean that great quality glTF models can be found e.g. on Sketchfab.

  • glTF is much smarter about "binary data vs text data", which results in it being both simpler and more efficient. glTF uses a binary stream for data that should be uploaded to GPU (in particular everything per-vertex), and it uses JSON stream for other things. This makes glTF files much faster to load. In contrast, X3D text files encode 100% things in text (and thus are often huge and slow to load), unless one uses X3D binary encoding (which is not implemented in CGE, and probably will never be — as it is still poor compared to glTF, as it only speeds up parsing but data still needs to be repacked for GPU).

So it seems reasonable to "just switch to glTF". I can now rely on Khronos to work on Blender -> glTF exporter.

We advise you to use glTF for all your future games, instead of X3D, now.

You can, although you don’t have to, switch your existing games to use glTF too. Of course we continue to support X3D model format in 100%, so you don’t have to. Things to watch out for:

  • In case of Blender, both the X3D exporter and glTF exporters convert (by default) "up" from +Z to +Y. However, they do it in a little different way. In effect, if you design a creature following Blender "front" convention, then it will look toward -Z direction after being exported to X3D, but in +Z direction after being exported to glTF. To be precise, X3D output is rotated 180 degrees around (0,1,0) compared to X3D output.

    • For games using X3D exporter for creatures, call "TCastleTransform.DefaultOrientation := otUpYDirectionMinusZ". This was the default in CGE 6.4, but in CGE 7.0 the default is matching glTF convention, which is "TCastleTransform.DefaultOrientation := otUpYDirectionZ".

    • If you switch your level models from X3D to glTF, remember to adjust any position you manually define (e.g. in code). Adjust it by rotating 180 degrees around (0,1,0). (For positions, you can just negate X and Z coordinates to achieve this.) E.g. camera or lights positions, if you ever define them in code.

  • The glTF exporter will create materials using PBR (physically-based rendering). If you prefer to use Phong lighting model (because it is faster, or because it just looks better in your specific case) then you can define GltfForcePhongMaterials (global variable in CastleLoadGltf unit) before doing any loading. If you don’t -> remember that materials will just look different, and you need to manually adjust them (automatic conversion is not possible, as there are just different equations underneath).

To improve this documentation just edit this page and create a pull request to cge-www repository.

Copyright Michalis Kamburelis and Castle Game Engine Contributors.

This webpage is also open-source and we welcome pull requests to improve it.

We use cookies for analytics. See our privacy policy.