We plan to release version 7.0 (stable) at the end of this year, 2022 (with an unofficial but hard deadline for 7.0 release at Christmas 2022 :) ).
Maybe there will be another alpha or beta release in 2022 before the full 7.0.
Numerous smaller editor improvements, like double-clicking to open Pascal files at proper file and proper line
Inspect your game hierarchy and logs at runtime — just press F8
Integration with Vampyre Imaging Library
macOS improvements: Cocoa backend in TCastleWindow and more
Many new notable examples
Android support for Arm64, many new services, upgrades to build infrastructure
Run it by simply executing "castle-editor" binary in the "bin/" subdirectory of our release zip.
It comes with 4 templates for new projects: empty, 3D model viewer, 2D game, 3D FPS game. These showcase nicely editor possibilities and were designed as a good starting point for your applications.
Editor allows to visually design TCastleUserInterface (like TCastleButton, TCastleLabel) and TCastleTransform (like TCastleScene) hierarchies.
Editor also manages (creates, compiles) Castle Game Engine projects, using our build tool underneath.
Integrated with our tools (runs view3dscene, castle-view-image etc. when double-clicking), can preview data (models, images, sounds).
Runs a configured compiler: FPC or Delphi.
Runs a configured Pascal code editor when double-clicking on Pascal files: Lazarus, Delphi, Visual Studio Code, custom (Emacs…).
Primitives like box, sphere, 3D text in editor are available, esp. useful for easily designing.
glTF 2.0 full support and realistic rendering upgrades.
Including Physically Based Rendering materials, unlit materials and textures. This is supported in both glTF and X3D formats. The X3D nodes follow new X3D 4.0 standard.
Animation of transformations and skin.
Metadata support (e.g. from Blender custom properties), can also be used to set colliders.
See https://castle-engine.io/creating_data_model_formats.php for details of glTF 2.0 support.
Nintendo Switch full support. See https://castle-engine.io/nintendo_switch
Much better API for viewports and cameras.
TCastleTransform hierarchy, use
TCastleViewport, always. It is a normal user interface control, you can set it’s size/position as any other UI control.
The concept of camera (where are you looking at) and navigation (whether we handle some keys/mouse to move the camera) was split.
TCastleViewport.Camera is always created, and corresponds 1-to-1 to the parent viewport.
TCastleViewport.Navigation is optional, you can explicitly create an instance of
TCastleWalkNavigation and assign them there.
Auto-detection of camera is by default off. This way you can reliably use
Viewport.Camera.Translation := ..., without worrying that some auto-detection will override them. Use
Viewport.AutoCamera := true to explicitly request this auto-detection.
Auto-detection of navigation is by default off. This way you can reliably set
Viewport.Navigation := ... (or leave it
nil deliberately) without worrying that some auto-detection will override it. Use
Viewport.AutoNavigation := true to explicitly request this auto-detection.
Big user interface classes improvements.
Easy functions to serialize / deserialize TCastleUserInterface and TCastleTransform hierarchies (see CastleComponentSerialize unit) as JSON files.
CastleSettings.xml file support to easily define scaling and default font.
New controls: TCastleCheckbox, TCastleDesign, TCastleHorizontalGroup, TCastleVerticalGroup.
Float positions / sizes for everything.
castle-data:/ protocol (more advised than previous
ApplicationData function). The “data” directory is documented https://castle-engine.io/manual_data_directory.php in a new manual page. It is also listed on a reworked manual page about networking, downloading and URLs https://castle-engine.io/manual_network.php.
TCastleTransformDesign to refer to a designed
xxx.castle-transform file, which can be used similar to Unity prefabs,
TCastleBehavior to enhance
TCastleTransform functionality by behaviors like
examples/creature_behaviors/. See also Castle Game Engine for Unity developers.
Optimizations and profiling features:
Built-in simple profiler (TCastleProfiler, use through the Profiler singleton). See https://castle-engine.io/wp/2018/08/25/headlight-built-in-simple-profiler-more/
Built-in frame profile (TCastleFrameProfiler)
Integration with Nintendo profiler
Large speedups, see news: https://castle-engine.io/wp/2019/10/13/numerous-optimizations-and-dynamic-batching/ .
Dynamic batching now available.
Loading optimizations (see here).
Everything described in the updated optimization docs on https://castle-engine.io/manual_optimization.php
New screen effects API, you can now make screen effects over any UI control (just place it as child of
TCastleScreenEffects), and they are much friendlier to use. See https://castle-engine.io/wp/2018/07/29/new-screen-effects-api-and-demo-text-node-optimizations-multi-texture-modes-fixes/ . Also new GLSL screen-effects functions. See also news about screen-space reflections.
Easy mirrors on flat surfaces (see https://castle-engine.io/wp/2018/10/08/simple-water-using-castle-game-engine/ )
Aside from new Physically-Based Rendering (using
PhysicalMaterial in X3D), also unlit rendering (using
UnlitMaterial in X3D) and Phong lighting model (using
Material in X3D) got serious improvements. Explicit node for unlit rendering makes some cases more natural. Improvements to Material allow to configure everything using separate textures naturally (diffuseTexture, specularTexture, ambientTexture etc.), and we add natural slot for occlusion maps.
Shadow maps, clip planes available with OpenGLES renderer (this improves all platforms using OpenGLES by default: Android, iOS and Nintendo Switch).
Two methods, with demos: https://castle-engine.io/manual_text.php
CastleLocalizationGetText allows to easily translate UI design (created e.g. using CGE editor), including generating template for translators to translate UI design.
Animation blending (https://castle-engine.io/wp/2018/03/21/animation-blending/)
Many new features related to PlayAnimation. TPlayAnimationParameters allows to specify things like StopNotification callback, playing backward etc. (see https://castle-engine.io/wp/2018/04/21/engine-improvements-rejuvenated-playanimation-method-easily-play-animations-backward-with-blending-stop-notifications/ ). Additional methods like StopAnimation, ResetAnimationState.
Ability to easily play simultaneous animations using TTimeSensorNode.Start/Stop.
Spine mesh deformation animation
Notable new examples:
image_display - demo of image formats reading capabilities and speed
use_designed_curve - demo of following along a curve
shader_override - overriding shaders with your own
tiled/strategy_game_demo/ - Complete working strategy game, with maps designed using Tiled, working equally well with hexagonal/orthogonal/isometric maps (thanks to new Tiled API), user interface designed using Castle Game Engine Editor and TUIState. See also https://castle-engine.io/wp/2019/01/06/strategy-game-demo-using-cge-and-tiled/ , https://castle-engine.io/wp/2018/12/28/tiled-maps-improvements/ .
tiled/map_viewer/ - Simple viewer for Tiled maps. You can pan and zoom maps, and load any Tiled map.
headlight_test/ - Shows new
audio/play_sounds/ - Test mixing sounds.
localization/gettext/ - Localization example, translating resourcestrings and UI designed in CGE editor.
screen_effects_demo/ - New screen effects API demo.
viewport_and_scenes/anisotropic_filtering/ - Using anisotropic filtering.
network/asynchronous_download/ - asynchronous, cross-platform downloading using TCastleDownload.
network/remote_logging/ - remote logging, basis of communicating with REST server using TCastleDownload.
third_person_camera/ - 3rd-person navigation (with avatar) demo.
animations/expose_transformations_to_animate_children - attach objects to animated bones, e.g. attach a weapon (switch at runtime between a sword, axe, nothing…) to character’s hand.
advanced_editor - advanced usage of UI designs (
xxx.castle-user-interface), transformation designs (
xxx.castle-transform, like prefabs in Unity), and creating and registering custom editor components. See news: https://castle-engine.io/wp/2020/12/20/new-tcastletransformdesign-component-like-prefab-for-tcastletransform-example-advanced_editor-showing-advanced-usage-of-designs-and-custom-components/ .
collisions - demo of using our collision routines.
--target=android to build both 32-bit and 64-bit binaries.
New Android services:
Many upgrades to build infrastructure (new Gradle version etc.)
AdMob upgraded, and supports TAdWatchStatus that reports why user did not watch the ad.
GPU compressed textures support for square textures (Apple makes it harder to support non-square textures).
Build tool has command-line options to create IPA file or even upload the build to TestFlight, see iOS building page.
FreeType is supported so you can freely load fonts at runtime.
Other build tool improvements:
Filtering of messages (better output, that avoids some unnecessary warnings from specializing generics containers, but at the same time leaves these warnings enabled for your code)
Collision detection (TRigidBody.GetCollidingTransforms, OnCollisionEnter, OnCollisionExit).
Split into multiple backends, and FMOD backend added, see https://castle-engine.io/fmod .
More features for sounds XML files, like aliases and groups. See https://castle-engine.io/wp/2019/04/29/new-sound-features-alternative-backends-new-demo-aliases/
LoopingChannel, to easily play multiple sound tracks, ambience tracks etc.
New way to play sounds by
TCastleSoundSource (TODO: in progress to make it clickable in CGE editor)
Last but not least, stuff "around" CGE:
Docker image with docs: https://castle-engine.io/wp/2019/02/16/using-castle-game-engine-with-docker/
New forum https://forum.castle-engine.io/
License simplified. The engine is "LGPL with static linking exception" (i.e. you can use it in commercial applications) out-of-the-box. See https://castle-engine.io/wp/2018/05/30/nurbs-simplified-license-just-lgpl-out-of-the-box/ and https://github.com/castle-engine/castle-engine/blob/master/COPYING.md for details.
API searching, switching between stable/unstable API docs.
New Patreon rewards and goals including conferences, Occulus port and more :)
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 the source of this page in AsciiDoctor (simple wiki-like syntax) and create a pull request to Castle Game Engine WWW (cge-www) repository.