Castle Game Engine 2D physics using Kraft

Posted on

Castle Game Engine 2D physics demonstration. A quick 2D game where a plane is using spheres to shoot the boxes 🙂 The physics is done using the fantastic Kraft Physics Engine!

The code to do this is 100% open-source, you can view it on GitHub here: physics_2d_game_sopwith (the main code is in “game.pas” unit).

Also, we now have a manual page describing how to use physics in Castle Game Engine.

This work was sponsored by Castle Game Engine supporters on Patreon. If you want to help in the engine development, please support me on Patreon! Thank you!

Comment on this post ➤

Castle Game Engine physics – Mesh Collider

Posted on

More progress integrating Castle Game Engine with Kraft Physics Engine!

  1. New physics classes (TRigidBody, TCollider and descendants) are now part of the Castle Game Engine core.

    To use this yourself, see the T3DTransform.RigidBody property, and the TRigidBody and TCollider descendants documentation.

    The example code on should also help 🙂

  2. We have mesh collider, to perform collisions with a scene mesh.

    The mesh collider was beautifully trivial to implement. I honestly didn’t expect it to be so easy to code. Lots of kudos go to Benjamin ‘BeRo’ Rosseaux for creating the wonderful Kraft Physics Engine!

This was implemented thanks to the supporters of Castle Game Engine on Patreon. If you like what I do, please support Castle Game Engine on Patreon!

Comment on this post ➤

Castle Game Engine integration with Kraft Physics Engine

Posted on

First results of Castle Game Engine integration with Kraft Physics Engine! 🙂

The physics demo source code is in GitHub in engine examples.

Kraft Physics Engine by amazing Benjamin ‘BeRo’ Rosseaux. Open-source, clean Object Pascal code, portable (Delphi, FPC, including FPC on Android and iOS).

I want to extend this a bit, and will post more details (on Castle Game Engine news/blog) soon. For now just enjoy the video 🙂

The physics fun was sponsored by Castle Game Engine supporters on Patreon. If you want to help in the engine development, please support me on Patreon!

Comment on this post ➤

New features: KTX (Khronos texture format), nvcompress, X3D helpers…

Posted on


As a little break from the work on Delphi compatibility, I added some new features to the engine 🙂

  1. KTX (Khronos Texture format) support throughout the engine. See the details about KTX features supported. KTX format is in many ways an alternative to DDS, with a clean specification, supporting the same features (GPU compression, 2D and 3D textures…). The KTX Khronos page has links to various tools that can create KTX files.

    You can test it now by downloading glViewImage 1.7.0! Sample KTX files are e.g. inside official KTX repository.

  2. Support nvcompress for automatic compressing of textures for GPU.

    nvcompress is part of the NVidia Texture Tools. It is cross-platform (Windows, Linux…), free and open source. On Debian and derivatives (like Ubuntu) you can install it simply by apt-get install libnvtt-bin. Thanks to Eugene Loza for advicing it!

    The nvcompress will be automatically used underneath when you call castle-engine auto-generate-textures in your project. This requires using our build tool to manage your game project.

  3. Our fps_demo shows how to easily get texture compression in your games. See the material_properties.xml in fps_game for how to trivially compress your textures to DXT1 and DXT5. See material_properties.xml and texture compression documentation for more information.

    There was also an important fix to using this approach for textures referenced from X3D.

  4. Useful helpers for X3D building, to easily create and modify X3D graph:

    • New methods AddChildren, RemoveChildren for grouping nodes (like TTransformNode, TGroupNode).
    • New methods CreateShape, CreateTransform for geometry nodes (like TBoxNode, TIndexedFaceSetNode).
    • Also on geometry nodes: Coord, FogCoord, TexCoord and some more are now simple properties.
    • SetXxx methods available to set various multiple-value (array) fields. Use them like this:
      Coord.SetPoint([Vector3(...), Vector3(...)]);
      IndexedFaceSet.SetCoordIndex([0, 1, 2]);

      These look much better than

      Coord.FdPoint.Items.Assign([Vector3(...), Vector3(...)]);

      and they always cause an appropriate update (they automatically will call Changed for you, and send the new value using X3D events).

    This is all part of my ongoing effort to enable you to operate on X3D graph more comfortably, without accessing “somewhat-internal” fields instances in FdXxx (like FdChildren, FdCoord…).

  5. Improved and simplified lets_take_a_walk example (examples/3d_sound_game/).
Comment on this post ➤

Delphi base compatibility, Spine improvements, other stuff :)

Posted on

Delphi running CGE base test :)
  1. Intensive work on the engine Delphi compatibility is ongoing 🙂

    We can now actually compile and run in Delphi (10.2) a simple console demo using our “base” units. Vectors, matrices, colors, rectangles, time measuring, logging, a lot of string and class and other utilities… it’s all working in Delphi. This is the demo code.

    In parallel, I’m fixing the syntax of all the code to compile in “FPC Delphi test mode”, this is providing a nice baseline to later compile in the actual Delphi. On this front, I almost finished porting everything non-visual (I’m finishing the X3DNodes unit, which is a huge unit that depends on almost everything non-visual in the engine). So, we’re close 🙂

    The “FPC Delphi test mode” means that we use FPC, but in Delphi mode, and disable macros, and disable operators like += etc. And I can run on Linux too, which is comfortable for me 🙂 So it’s like “make FPC behave as much as Delphi”. Any changes required at this stage would be required by Delphi too. To use it, you can set environment variable CASTLE_ENGINE_TEST_DELPHI_MODE to “true” before running the build tool.

  2. Units cleanup was done along the way. I rearranged some units, to remove some uncomfortable dependencies (when too many units are inter-dependent on each other). In effect, we now have a “files” unit group that includes units from old group “net” + units dealing with files. More details in the units map in the wiki.

  3. Spine (2D animations format) improvements:

    1. When animating in Spine using Bezier curves (translations or rotations), the resulting movement in our engine is now exactly what you see in Spine.
    2. Animating the scale in Spine is now fixed (it was accidentally changing the order of layers).
  4. DDS (image file format) improvements: support reading DX10 + DXGI_FORMAT_R8G8B8A8_UNORM case (produced e.g. by PowerVR Texture Tools when converting RGBA image to DDS).

  5. In a spur of the moment, I wrote a short page about “What are range and overflow checks (and errors) in Pascal” 🙂

  6. TDebug3D class is a new simple approach to visualize debug things attached to 3D objects.

Comment on this post (1 comment now) ➤

New modern API for vectors and matrices

Posted on

Chinchilla model in X3D, based on high-poly version in "Big Buck Bunny"

Our unit CastleVectors was completely reworked this week, and it now features a new, comfortable API for vector and matrix types, using “advanced records” (records with methods).

I hope that you like the changes 🙂 Of course you can already test it all by using the engine version from GitHub !

Type names

The main vector and matrix types (using Single-precision) are now called TVector2, TVector3, TVector4 (in short: TVector{2,3,4}) and TMartix{2,3,4}. So we have 2D, 3D and 4D vectors (4D vectors are useful for “homogeneous coordinates” in 3D, and to store colors with alpha). And we have 2×2, 3×3, 4×4 matrices.

These correspond to previous array-based types called TVector{2,3,4}Single and TMatrix{2,3,4}Single. As you can see, we have removed the Single suffix, as these types are used very often throughout the engine and, as such, they are our “default” vector and matrix types.

As before, we also feature vectors with Double precision (TVector{2,3,4}Double), and based on various integer types (Byte, Integer and Cardinal). They are all available in 2D, 3D, 4D variants, and are implented using the new “advanced records approach” and are consistent with Single-precision vectors.


  • As these types are “advanced records”, they include various methods, class methods and constants nicely grouped within the record. This makes the API look nicer, e.g. now you can write MyVector.Length instead of VectorLen(MyVector). They have one field, Data, which is defined like array [0..2] of Single for TVector3. This allows to keep them fast (in terms of speed, and memory layout). See the documentation of the generic 3D vector (this API is used by both TVector3 and TVector3Double).

  • You can access the individual components of the vector as V.X, V[0] or V.Data[0]. And the last two notations are checked, even at compile-time, so this will make a clear warning (that index is 3, but should be between 0..2):

    uses CastleVectors;
      V: TVector3;
      V[3] := 123; // incorrect example, index should be in 0..2 !
  • All the operators, like + and *, are overloaded on vectors and matrices. Just like with old types.

  • These types work in both FPC and Delphi. They work without the FPC macros (as Delphi doesn’t support them). I wish they could use generics, but they cannot (it’s not possible to put constraints on Pascal generics to enable efficient arithmetic operations on fields).

  • Along with it, triangles (TTriangle{2,3,4}) was also remodelled as a record, and the Double-precision equivalent (TTriangle3Double) was removed (not really useful, and implementing it without macros or generics is uneasy). See TTriangle3 documentation.

  • Along with it, the TBox3D was a bit improved, it now has Min and Max properties, that look friendlier than Data[0] and Data[1]. See TBox3D documentation.

  • Along with it, the color types have changed too, as TCastleColor and TCastleColorRGB are still just aliases for (respectively) TVector4 and TVector3. See CastleColors unit documentation.

  • The new vectors vaguely resemble the vectors from Delphi standard unit System.Math.Vectors, but are better in many ways. We offer many more types and with many more methods. And, frankly, our naming is more consistent, IMHO 🙂

Backward compatibility

While the change is for good, it is not 100% backward-compatible. I put a lot of effort to minimize the compatibility “disruption”, adding many “glue” functions and types to keep your existing code working (and merely warn about being “deprecated” during compilation). But there is still chance that you will need to change something in your code to make it compile with the engine >= 6.3 API. Read the hints below, and please ask on the forum if you’re unsure how to upgrade.

The changes that break compatibility (things that you will have to change in your code in order to compile):

  • When declaring constants, your old code may use this:

    const MyConstant: TVector2Single = (1.0, 2.0); // old code

    As the vectors, matrices, colors and triangles are now record types with a Data field, so it has to be changed to:

    const MyConstant: TVector2Single = (Data: (1.0, 2.0));
  • The TBox3D.Data, and your custom array of TVectorXxx types, are no longer “arrays of arrays”. They are now “arrays of records”. Your old code may use this:

    Box.Data[0, 0] := 0.0; // old code

    This has to be changed to:

    Box.Data[0][0] := 0.0;

    Or this, if you want to avoid any “getter” properties and just access the (addressable) variable directly:

    Box.Data[0].Data[0] := 0.0;
  • Although you can still access the vector component using V[0], this is now a “getter” property. It often doesn’t matter… unless you want to use it as var or out parameter for some function, or if you use C-like operators like +=. So if your old code has this:

    V[0] += 10; // old code

    This has to be changed to this:

    V.Data[0] += 10;

    Of course, in this case you can also just resign from using C-like operators, and have this:

    V[0] := V[0] + 10;

    Or this:

    V.X := V.X + 10;
Sidenote: I tried a different approach to backward-compatibility too (keeping both old and new APIs in parallel) but this was creating more compatibility problems than it was solving (gory details in the KEEP_OLD_VECTOR_API comments in this commit).

Have fun with the new API, and, as always, please ask on the forum if you have any questions!

Comment on this post ➤

Generics.Collections in the book and CGE

Posted on

To help you familiarize with the Generics.Collections unit, I wrote a nice chapter about it in the “Modern Pascal Introduction”. It’s a longer chapter, with 4 nice examples using containers from Generics.Collections.

In the related news: complete migration to Generics.Collections in Castle Game Engine is done 🙂 We now use Generics.Collections for all the purposes where we previously used the FGL and CastleGenericLists units. This brings us closer to Delphi compatibility, and it makes code better (Generics.Collections works with records out-of-the-box, it has a TDictionary with a much cleaner API, etc.)

Also, Michalis is back from vacations, with lots of new strength 🙂

Comment on this post ➤

Generics.Collections, vacations

Posted on

Wizardry VII - Crusaders of the Dark Savant
Half Life 2: City 17
Half Life 2: We don't go to Revenholm
  1. I am going on vacation, so I will be (mostly) offline for 2 weeks 🙂 So, please have patience with any questions to Michalis — I will get back to you, but with some delay!

    I don’t have a new screenshot from the engine for this news. Instead, I wanted to share some screens from the games I like — the games that inspired me to make games (and, subsequently, an engine to make games 🙂 ).

  2. The GitHub code now contains a start of migration from FGL unit containers to Generics.Collections unit containers. The Generics.Collections contains a much richer (and Delphi-compatible) generic containers. I use generics a lot in the engine code, so this will be a larger change.

    The main classes from Generics.Collections are TList<T> and TObjectList<T>. TObjectList<T> is very similar to the TFPGObjectList<T> you know from FGL.

    Generics.Collections were implemented in FPC by fantastic Maciej Izak, who also put a lot of work to actually make them part of the FPC standard library in FPC 3.1.1. In older FPC versions, we currently use a local copy of them (in src/compatibility/generics.collections/src/ ). This “compatibility” path should be automatically added to your unit search path for all our supported compilation methods. If you use the build tool, be sure to recompile the build tool after getting the latest code from GitHub.

  3. The requirements on FPC version increase, in order to use Generics.Collections (unit names with dots). We now require now FPC >= 3.0.0. See also FPC versions supported docs.

  4. I’m also working on a new improved API for vectors / matrices, based on advanced records, somewhat cleaner and also Delphi-compatible. More news when I’ll get back from vacations 🙂

  5. Our Automatic Cloud Build server has now cool scripts to switch FPC versions, which allows me to automatically check that the engine compiles with various FPC versions, and on various platforms. I really enjoy continuous testing, time to set it up always “pays off” by doing a lot of things automatically for you, and Jenkins rocks!

Comment on this post ➤

Castle Game Engine 6.2 release – iOS, CommonSurfaceShader…

Posted on

CommonSurfaceShader with steep parallax bump mapping and self-shadowing
Castle Game Engine sound/music player
Knocker in STL format, by Shira,
Robot woman in the STL format, by Shira, see

We’re proud to announce the release of Castle Game Engine 6.2!

Download it from our main page.

New features in this release:

  1. Trivially easy recompilation of your games for iOS (through an XCode project). You can now use our build tool to recompile the same game for all our platforms (desktops, Android, iOS, web plugin…). The iOS documentation was extended to describe everything necessary.

  2. CommonSurfaceShader is our new “material on steroids” that allows you to configure material by normalmaps, specular maps, shininess maps, ambient maps… We include an extensive documentation and examples of it (in new demo models).

  3. Improved Blender exporter. It’s now easier to install (it’s now a normal Blender add-on), and it can generate a CommonSurfaceShader node with all the goodies described above. The artist can now comfortably set normalmaps, specular maps and much more in Blender, and they “just work” in the engine.

    The CommonSurfaceShader and Blender exporter improvements were implemented thanks to the support on Patreon. If you like what we do, please consider supporting the engine development on Patreon. This really helps me spend more time on the engine, and develop cool features like this!

  4. Other build tool improvements, for all platforms:

  5. Other API and examples improvements:

    • TSound.Offset to get/set sound offset in time.
    • Sound/music player in examples/audio/audio_player_scrubber.
    • STL format support
    • Our ray-tracer now supports textures and smooth normals.
    • TCastleEdit (example in examples/2d_standard_ui/edit_box/ )
    • Application.ParseStandardParameters, Application.Version

Together with the new engine, we also release a new version of view3dscene 3.17.0, our viewer for X3D and other 3D formats. As a tool developed using the Castle Game Engine, it inherits all the enhancements 🙂 You will probably be most interested in new CommonSurfaceShader node and STL format support.

Comment on this post ➤