I have a lot of pending news from recent engine developments (big refactor to rendering, lots of OpenGLES improvements, Tiled improvements) but for today, the most important thing:

Join Embarcadero DelphiCon 2023, an event celebrating 28 Years of Delphi, and listen to our talk “Getting Physical in Your Games with Castle Game Engine” on Thursday (February 16, 2:00 PM in Central Standard Time). As always be careful to recalculate timezones, personally I found it easiest to register and then add particular event to the calendar by clicking on the appropriate link, and then I can let my calendar software do all timezone calculations 🙂

You can also just watch the event on Embarcadero YouTube, they stream it live.

My talk focuses on new features coming in 7.0-alpha.3, with a special emphasis on physics. I spend a significant part of this talk doing funny things with physics :), there is also a nice overview of CGE usage for 3D in general, I also fall in love with a particular sound effect. My talk is prerecorded this time, and as such I can already spoil that it was impossible to fit everything into my 1-hour slot, and I will be releasing some “bonus” videos afterwards, if you can’t get enough of my rambling and will want more after DelphiCon 🙂

And while I show there everything in Delphi, since it’s DelphiCon, it is really all the same if you’re an FPC/Lazarus user!

My talk description:

Castle Game Engine is an open-source cross-platform 3D and 2D game engine. We’re aiming at a huge engine release “7.0” shortly after Delphicon 2023. As such, I’d like to show the latest juicy stuff we’ve been working on: physics, shadows, rendering huge maps, using engine as part of VCL or FMX form. The session will start with an introduction to using the engine with Delphi. Everyone interested in making games using Delphi is welcome!

While technically I’m busy on shadow-volumes-new branch (despite the name, it has spiraled into a number of generally useful rendering code refactors; rendering on both modern and ancient GPUs will benefit, as various things are improved and the code gets simpler too)…

…let me make a non-technical post 🙂

We really appreciate your donations and, going forward, this is ideally the way to fund the development of the engine, The main goal of donations is simply to cover the cost of people, so that they can work on the engine full-time, which in turn just translates to more features, faster. Right now we have 1/2 developer on a payroll (Andrzej Kilijański, paid from Michalis Kamburelis own pocket) and hiring him was a great decision — having Andrzej made a big difference, the engine progress in recent years owes much to his work. Imagine we can have 10x of that 🙂

Our recommended way to donate is a monthly subscription on Patreon. Patreon offers a number of traditional payment methods.

On top of making things easy, Patreon also offers a unique reward for donors: 4 physical sticker with CGE logo that you receive after 3 monthly donations at 10 USD tier. See the photo 🙂 They ship worldwide, I tested 🙂

But there are other options, always listed here. These include:

1. If crypto-currencies are your thing, you can donate using:

   Ethereum: send to this address: 0x0b0e37c7391C7268DEc9c0De63bA5A3b1B42baCe

   Bitcoin: send to this address: 1FuJkCsKpHLL3E5nCQ4Y99bFprYPytd9HN

2. GitHub Sponsors

3. Open Collective

Whichever option, whichever tier you choose — big thank you!

I’m serious about developing the engine, I’m serious about making something that enables you to develop great games with open-source software. We are doing it… wow, I just found the oldest news post from 2004. So 18+ years now. The engine is now old enough to drink and do other adult stuff 🙂 And you can see at our regular news, for so many years that we don’t stop and we don’t plan to stop. I hope you enjoy this journey and want to support us along the way. Financial funding is, in the long-term, something that allows to work on the engine just as a regular thing, with as much people and time we can afford. Your support really changes what we can achieve and how fast we can do it.

Enjoy creating games with Castle Game Engine!

To start the weekend, I added a new example to Castle Game Engine showing the navigation in games like “Eye of the Beholder”: moving on a grid, rotating by 90 degrees, crawling a dungeon with a group of heroes 🙂

The example is in examples/eye_of_beholder directory of engine sources. Just open with CGE editor and run. The level has been designed in Blender.

You can move and rotate using keys or by clicking on buttons (so it also works on mobile).

See the screenshots on the side — can you tell which one is the original “Eye of the Beholder” game and which is our example? 🙂

This post somewhat retracts yesterday’s post, because I had a busy sleepless night and fixed some issues with loading Tiled in TCastleScene that I mentioned yesterday 🙂 I did a significant refactor of how it works.

I’m proud to say that loading Tiled maps into TCastleScene is now our recommended approach to using Tiled maps. The big benefit of this approach is that you can place additional objects, like sprite sheets in TCastleScene, over the map easily (and specialized API to place/move units on map will appear soon too). TCastleTiledMapControl will soon be deprecated, in light of this.

The following improvements are done:

1. First of all, we have new example application examples/tiled/map_viewer_in_viewport where you can test everything I announce today. It is a simple Tiled map viewer, underneath loading Tiled map to TCastleScene.

   You can test that it is functionally just as good, if not better, than examples/tiled/map_viewer approach.

2. Huge optimization, by internally using a single draw call for all consecutive tiles using the same tileset. This allows to effortlessly support our test map 400×400 in examples/tiled/map_viewer_in_viewport/data/maps/desert_big.tmx with 100 FPS, at whatever zoom.

3. Support for all map types: Orthogonal, Isometric, IsometricStaggered, Hexagonal.

4. Correct support for all flip combinations (diagonal, horizontal, vertical).

5. Fixed layer Z ordering and offset application for all layer types.

6. Fixed origin (map left-bottom corner is now at 0,0).

7. Support for “Smooth Scaling Safe Border”, to fix rendering artifacts when using smooth scaling on tilesets without proper alpha bleeding.

8. I’m proud that my refactor actually made the code over 2x smaller and simpler 🙂 Line count dropped 1210 -> 510 for the x3dloadinternaltiledmap.pas unit.

If you like my sleepless nights’ work, please support us on Patreon 🙂

OK, this post title is probably too long 🙂 But I really want to announce a few related things, and talk about related plans. Bear with me, and read on if you’re developing 2D games using Castle Game Engine with something like a map underneath.

1. I’m happy to announce a very powerful and easy to use optimization for TDrawableImage rendering: almost automatic batching. The way it works is really simple: if your rendering code is mostly just a sequence of calls to TDrawableImage.Draw, then you can surround it with TDrawableImage.BatchingBegin and TDrawableImage.BatchingEnd calls (these are class methods) to achieve a significant speedup.

   Underneath, batching for TDrawableImage means that rendering many times the same image gets grouped into a single OpenGL(ES) draw call, and so it’s much faster. It works because GPU has great performance if you tell it to render million quads with a single draw call, while it’s quite inefficient if you use million draw calls to render one quad each.

   E.g. this code actually does just 2 draw calls now, not 200:

   TDrawableImage.BatchingBegin; for I := 0 to 99 do MyDrawableImage1.Draw(100, 10 * I); for I := 0 to 99 do MyDrawableImage2.Draw(100, 10 * I); TDrawableImage.BatchingEnd;

   TDrawableImage.BatchingBegin; for I := 0 to 99 do MyDrawableImage1.Draw(100, 10 * I); for I := 0 to 99 do MyDrawableImage2.Draw(100, 10 * I); TDrawableImage.BatchingEnd;

   This should be a great tool for people doing lots of image rendering.

2. Using the above batching, I have greatly optimized our 2D Tiled rendering control TCastleTiledMapControl, that now internally always activates this batching.

   As Tiled rendering uses TDrawableImage to render each tile, it benefits greatly from the new batching.

   Moreover, as another optimization, TCastleTiledMapControl no longer renders tiles that fall outside of its render rectangle. This rendering was useless, and it could cost significant time.

   I have also added a test map, examples/tiled/map_viewer/data/maps/desert_big.tmx, with 400×400 tiles, to demonstrate this optimization. Before optimization, it had 2.7 FPS on my system (yeah, less than 3 FPS…), clearly demonstrating that previous rendering was unoptimal. After adding batching, FPS increased to 24, and then avoiding rendering useless tiles gets us to nice 61 FPS. The FPS stay reasonable even at significant zoom out.

   You’re welcome to test it all yourself, just build and run examples/tiled/map_viewer/ yourself.

3. In parallel to improving our simple 2D drawing (TDrawableImage, TCastleTiledMapControl) we also pursue another way to render 2D things in Castle Game Engine: render your whole 2D world as a number of objects (like TCastleScene and TCastleImageTransform) in a viewport.

   The approach to put things in scenes and viewports is in general much more feature-rich. Scenes can have physics, they can easily render sprite sheet animations, they can be designed visually in CGE editor (see e.g. Platformer demo done in editor this way), they also work in 3D (so a lot of work and optimizations benefits both 3D and 2D games).

   This means that in general, we advise you to use scenes and viewports for 2D games. Our new project template “2D Game” shows this approach.

   That said, the approach of “scenes and viewports” is admittedly not as efficient as (much simpler internally) rendering using TDrawableImage, TCastleTiledMapControl. This is especially visible if you try to design a big map for 2D game. Both memory (because of our X3D nodes memory usage) and performance suffers (because our DynamicBatching cannot yet handle some cases, and it doesn’t batch across scenes, so it’s worse than TDrawableImage.BatchingBegin and TDrawableImage.BatchingEnd in case of maps).

   There’s no single best solution (yet) to this “dualism”. We work on optimizing our scenes and viewports, and until it is perfect — I hope you can enjoy 2 methods of rendering 2D stuff. They are documented on How to render 2D games manual page.

4. Pursuing the approach to render things using scenes, with many thanks to Matthias (from Free Pascal meets SDL) you can now load Tiled maps to TCastleScene. Simply point TCastleScene.URL to a Tiled map file (.tmx).

   This allows to render map inside a viewport, mix it with other viewport things (like scenes with sprite sheets) and use viewport camera (also at design-time) to pan and zoom the map. And you can even rotate map, even in 3D 🙂

   The loading is not yet efficient, and doesn’t account for some map types (like isometric or hex). So TCastleTiledMapControl remains our recommended approach to render Tiled maps for now — but at some point in the future using TCastleScene should be fully efficient and functional and then it will be advised as more feature-packed.

5. I have been playing with creating isometric games (without Tiled help) too.

   The result are new demos examples/isometric_game and examples/isometric_game_3d.

   They use TCastleViewport with items (like TCastleImageTransform and TCastleScene with sprite sheets) to express the map and objects on it.

   They show how it’s a feature-rich approach — e.g. isometric_game_3d has cool shadows 🙂

   It is possible that in the future we could have a built-in tiled editor in CGE. I still haven’t decided when is the right time to pursue this — for now, relying on Tiled is great, but a built-in tiled editor remains an interesting option.

6. Finally, the optimizations necessary for great performance when you use lots of small scenes and images to render maps are really in progress 🙂

   I’m now working on branch shadow-volumes-new that, despite the name, includes a few useful renderer refactors. In particular it changes the way our shape renderer needs to be initialized / finalized, opening the door for cross-scene batching.

Thanks for reading! This was a complicated post, as admittedly what we do may be a bit confusing — we do pursue (and even document) 2 approaches for 2D maps, and we improve them both. But we also have a preference which one should “win” in the future (viewport and scenes!) but it will take time to get there with full performance. I hope what we do is clearer now and that you will enjoy the journey 🙂

As always, please ask on our Discord or forum if anything is unclear.

And we appreciate supporting us on Patreon. We also opened the option to donate using Ethereum if crypto is your thing 🙂

I’m thrilled to present Castle Lines 2D, a set of custom CGE components done by Korchazhkin Sergey (KumurTash on GitHub). They extend our Castle Game Engine editor functionality allowing you to draw 2D lines and polygons (possibly textured, possibly non-convex) right inside the editor!

The basic idea is that

• You add a component TCastleLine2D or TCastlePolygon2D to a viewport,

• You right click on the component in hierarchy and select “Edit Mode ON”,

• Then you just click around to add / move / delete points (left mouse click adds/moves, right mouse click deletes).

• The editor remains fully functional during this, so in particular e.g. zooming or panning the view works as always.

The components are open-source, on GitHub: https://github.com/KumurTash/CastleLines2D. In addition, a great usage documentation (with screenshots) and API reference are available. Go ahead, download it and test!

We have a forum thread open where you can certainly post comments and contact the author.

The polygon does not have to be convex (but it cannot be self-intersecting). It can be textured (and the texture may be repeated and scaled). The line can have non-trivial thickness and also be textured. The way line segments are connected (joints) is also configurable.

It’s really a complete code and documentation that adds to our editor something I personally never even dared to attempt. So seeing this makes my heart warm 🙂 I have to say in general that seeing others adding custom extensions to CGE and just using CGE to make cool stuff is extremely rewarding. So please everyone share what you’re doing in Show Your Projects forum category or Discord channel #show_your_projects 🙂

Our Castle Game Engine download page now recommends Windows users to download the engine as a self-extracting installer (EXE), which is a typical installation method on Windows.

The installer is done using excellent and popular Inno Setup. It will install CGE to a user directory, like C:\Users\USERNAME\AppData\Local\Programs\Castle Game Engine. The installer automatically creates menu and desktop shortcuts, shows you the license summary, runs CGE editor for the 1st time if you want and generally makes the whole process completely straightforward for Windows users.

This is similar to e.g. VS Code, that also uses InnoSetup and installs for the current user. Note that we don’t install VS Code with CGE (though we may in the future), and as always you have a choice which IDE to use — VS Code, Lazarus, Delphi, Emacs or really any text editor you find suitable to edit Pascal.

As a bonus, unpacking using the InnoSetup is also much faster than unpacking the zip using built-in Windows zip support.

TODO: Note that the installer right now does not make system-wide install. I have an option to activate system-wide installlation for CGE (and the setup can offer you a choice whether to install for current user or system-wide). But it is hidden for now, because system-wide installation means that examples are read-only, and it means you cannot easily explore + just build / tweak the examples. At some point in the future, we should allow you to open example by making a copy of it and then we’ll reenable the option for system-wide installation here. Note that everything else worked smoothly with system-wide installation, the CGE editor and build tool work as usual, our tools in general have always been written to handle the case when they are installed in read-only directory.

Since you know I love automation and CI / CI, of course the whole process of building the installer is automated, and thanks to InnoSetup it was really trivial to automate. So the installer is rebuild using Jenkins after every commit (that passes a number of automated checks) and you always have the installer for the latest CGE snapshot available.

1. We keep a ISS file describing how to package CGE.

2. Our pack_release.sh script has an option to, once it prepared the CGE distributable files, instead of zip it can create a setup. To do this, it calls iscc with parameters that define input, output directory, version etc. It looks like this (this is bash script):

   # Detect iscc location INNO_SETUP_CLI='iscc' if ! which "${INNO_SETUP_CLI}" > /dev/null; then # if not on $PATH, try default location INNO_SETUP_CLI='c:/Program Files (x86)/Inno Setup 6/iscc.exe' fi   # See https://jrsoftware.org/ishelp/index.php?topic=compilercmdline # and https://jrsoftware.org/ispphelp/index.php?topic=isppcc (for preprocessor additional options). "${INNO_SETUP_CLI}" \ "${ORIGINAL_CASTLE_ENGINE_PATH}/tools/internal/pack_release/cge-windows-setup.iss" \ "/O${OUTPUT_DIRECTORY}" \ "/F${ARCHIVE_NAME}" \ "/DMyAppSrcDir=${TEMP_PATH}castle_game_engine" \ "/DMyAppVersion=${CGE_VERSION}"

   # Detect iscc location INNO_SETUP_CLI='iscc' if ! which "${INNO_SETUP_CLI}" > /dev/null; then # if not on $PATH, try default location INNO_SETUP_CLI='c:/Program Files (x86)/Inno Setup 6/iscc.exe' fi # See https://jrsoftware.org/ishelp/index.php?topic=compilercmdline # and https://jrsoftware.org/ispphelp/index.php?topic=isppcc (for preprocessor additional options). "${INNO_SETUP_CLI}" \ "${ORIGINAL_CASTLE_ENGINE_PATH}/tools/internal/pack_release/cge-windows-setup.iss" \ "/O${OUTPUT_DIRECTORY}" \ "/F${ARCHIVE_NAME}" \ "/DMyAppSrcDir=${TEMP_PATH}castle_game_engine" \ "/DMyAppVersion=${CGE_VERSION}"

3. And that’s it 🙂 Jenkins archives the resulting exe, our scripts copy it to a GitHub release of the next snapshot, and we link to them.

The process was very straightforward I have to say, and in the future we will likely add an easy option to package your games into a self-extracting Windows installer too (using InnoSetup under the hood). For now, you can roll such setup on your own, using the output of CGE package in “directory” format as a start (input for Inno Setup) and following above notes and just Inno Setup documentation.

We’ve made a lot of editor improvements lately, including features, fixes and UX improvements. This post goes with big “thank you!” to everyone testing and providing feedback! I am seriously proud of how the engine became much more user-friendly and approachable in the recent months. A number of big changes (big in their impact, but often quite easy to implement) made wonders. UI for many things became straightforward, both for new and advanced users.

And I know it’s not the end — I have a lot of valuable feedback prioritized, and one more big UX thing (this time only for Windows users) will arrive this weekend 🙂

Enough bragging. New things I want to announce today:

1. “Run -> Run Parameters” menu, with options to disable sound, FPS limit, request window or fullscreen for the next application run. These menu options simply cause appropriate command-line parameters to be passed to the application. We supported these options since ~forever, now they are easy to actually use when working in CGE editor.

2. Dragging and dropping in the hierarchy of TCastleTransform will preserve their world transformation. For example, if you have a box X with translation, that is a child of transformation Y with some rotation, and you change the parent of X to Z — we will make the world transformation of X stay the same, so it will visually stay at the same place. Internally, the box X translation/rotation will be adjusted to the new parent Z.

   This is similar to how drag and drop in hierarchy of TCastleUserInterface already behaved, so these things (dragging UI and dragging TCastleTransform in hierarchy) are now more consistent.

   Moreover, you can now hold “Ctrl” when dropping to not preserve the world transformation when changing parent. And it affects both dragging UI and TCastleTransform.

   Limitation: We preserve the world transformation only when scale (of the source and destination object, in world space) is identity. Otherwise, our current math cannot preserve the transformation correctly in all cases, so we outright cancel the “preservation” feature when we detect any scaling.

3. Warnings and error lines are now properly colored in the output.

4. Drag and drop in the hierarchy is more natural when you want to insert an item as a child of something. Previously it required to drop it over the right side of the item, which was unintuitive (it was non-standard UX and we didn’t inform you about this feature anywhere). Now by dropping over the middle of the row, we understand you want to “drop inside” (insert as child).

5. We now show in UI a button to invoke context help (for the current class or property). I suspect that most advanced users already know to invoke it using F1. But new users were not aware of this super-useful feature — hopefully much more prominent now.

6. If you try to remove a component that cannot be removed (e.g. root of the design) we now provide a helpful explanation why it cannot be removed, instead of silently ignoring the command.

7. New light icons for our tools (translate, rotate, scale etc.) by Adrianna Matejek! Thank you!

8. Various improvements to “New Unit” dialog, now you just input “base name” and in simple cases let everything else be as default. The dialog also features now new unit with behavior and a better template for view.

9. The “Design” menu now clearly recommends the “New View” as the most often action you want to start there.

10. The list of views is now sorted by name (and can be sorted by other columns) once you open the project.

11. You can close the design with Ctrl+W. The current UI deliberately encourages to browse the views within the project, so exploring them (opening and closing) is natural.

12. Focus after undo (Ctrl+Z) allows to make next Ctrl+Z immediately. You can undo multiple steps now more reliably.

13. I added shadows to the default “3D FPS game” template design.

Enjoy new features and a happy New Year! 🙂

(Note: I will not make predictions for next year this time. Because I am hard at work making new Castle Game Engine release, planned for the Christmas that happened last week! 🙂 )

New stuff:

1. New property TCastleAbstractRootNode.BlendingSort, which you will usually use as MyViewport.Items.BlendingSort, allows to control the blending sorting when multiple scenes may have partially transparent objects.

   The full documentation how to set up blending correctly is here.

   It also supports now new options for sorting 3D objects: bs3DGround, bs3DOrigin. They may be useful in controlling the order better. For blending to work correctly, the engine must be able to decide what TCastleTransform in the front correctly.

2. You can now control the TCastleSoundSource playing of its main sound using TCastleSoundSource.SoundPlaying property.

   It is documented in manual about sound.

   It is also used by the sample footsteps component, shown in new documentation about behaviors. It is, in turn, used by my “Lynch” game demo — it proved to be very useful.

3. New property TCastleUserInterface.TooltipControl allows to control how does the tooltip look (and work).

   It is used by new new view3dscene versions with slicker buttons 🙂

Credits: level with trees from CGE #427 by Freedomax, Bronze figurine of Cthulhu from Sketchfab by Jedi2583.

At the beginning of December we merged a big work on physics (and many related features) and later we merged another big work on physics joints (another big merge, 363 commits). It’s time to provide to you some readable summary of all the improvements 🙂

I also wrote a nice documentation about physics. And remember that we feature a lot of physics examples.

New physics (and related) features:

1. New components, available in both editor and code, to control the physics.

   • TCastleRigidBody
   • Family of components descending from abstract TCastleCollider: TCastleSphereCollider, TCastleBoxCollider, TCastleCapsuleCollider, TCastleMeshCollider (only static), TCastlePlaneCollider (only static).

   Just add to any TCastleTransform (usually to TCastleScene or a primitive like TCastleBox, TCastleSphere) some collider in the editor (the rigid body will be automatically added too), and observe that it’s affected by

   • gravity
   • collisions with other objects

   There are lots of options to tweak how things behave. See API docs for documentation.

   Hint: If you’re like me, the first thing you will want to make is a “bullet” that hits something with some speed, so that you can see how it behaves on collision. To make a bullet, just set TCastleRigidBody.LinearVelocity on the bullet object to something non-zero.

2. New components have also additional features, like:

   • TCastleCollider.AutoSize (by default true) that sets many collider properties automatically. You can alternatively use TCastleCollider.CalculateSize calls explicitly. Or just set properties like TCastleCollider.TCastleSphereCollider.Radius and more explicitly.
   • TCastleCollider.Translation (adjusted automatically if TCastleCollider.AutoSize)
   • TCastleCollider.Rotation (adjusted automatically if TCastleCollider.AutoSize)
   • TCastleCollider.SizeScale (not adjusted by TCastleCollider.AutoSize, this is a feature — it can scale the collider calculated by AutoSize)

3. Colliders are also visualized. Juse use “Physics->Show Colliders” menu item.

4. There’s a new “Physics Simulation” mode available in the editor. Start it to make physics work. You can click around and modify the design even while the physics is running — this is a feature, albeit a bit dangerous one: the design is restored to the original state when physics stops.

   This is a great way to test how physics behaves without the need to actually run the game.

   Remember that it only runs physics simulation. In the future, more components may behave differently in this simulation. But it doesn’t run your project’s code (unless you put it into a custom component added to the project).

5. There is a new API to apply forces from code. This can be used to simulate forces other than gravity. For example wind or explosion.

   See demo physics_forces to test out various method to apply forces.

   See demo physics_persistent_forces_components to see example forces components we can make. This is like Blender’s forces to make wind etc.

6. Third person navigation:

   TCastleThirdPersonNavigation component got a significant upgrade that enables it to change transformation through physically-aware methods. By using physics to “drive” the navigation you get much more natural (physically-correct) movement and jumping.

   The way we change transformation is controlled by new TCastleThirdPersonNavigation.ChangeTransformation property. By default is has ctAuto value, which provides the most recommended way: if you have physics components (TCastleRigidBody, TCastleCollider) on avatar, we change using velocities, otherwise (this is backward-compatible) we change transformation directly.

   See TCastleThirdPersonNavigation.ChangeTransformation and TChangeTransformation docs for more details.

   third_person_navigation example was remade to use physics for movement. You can test various ChangeTransformation values.

   Going forward, we want to remake all our navigations to use physics. In particular, TCastleWalkNavigation (to walk/fly) will get a similar option soon too.

7. Changing the transformation (like TCastleTransform.Translation) of an object affected by physics is now more reliable. You can do it even if TCastleRigidBody.Dynamic=true (although you should refrain from doing it every frame — the entire point of TCastleRigidBody.Dynamic=true is that you allow physics to affect it).

   TCastleRigidBody.Animated is now really only an “optimization hint” passed to Kraft (determines if we should set body as krbtKinematic or krbtStatic, when Dynamic = false). It has no other effect on CGE code functioning.

   In particular, we allow changing TCastleTransform from code regardless of whether TCastleRigidBody.Animated = true or false.

8. We have new and powerful methods TCastleAbstractRootTransform.PhysicsRayCast and TCastleRigidBody.PhysicsRayCast. They return TPhysicsRayCastResult packed with information.

   Previously we only had TCastleRigidBody.PhysicsRayCast (new TCastleAbstractRootTransform.PhysicsRayCast allows to use it without starting from any particular TCastleRigidBody) and it didn’t return Point, Normal information.

   Also examples/viewport_and_scenes/collisions/ was extended to show PhysicsRayCast.

9. The editor has now big buttons to

   • play / stop physics simulation
   • play / stop the application

   from the CGE header. Stopping the application (this also applies to “Run -> Stop External Process”) is also more robust now (we make sure to kill the final application, not only build tool process, in case of “castle-engine run“).

10. Utility FindAllBehaviors (see physics_explosion for demo)

11. Editor adjusts to dark theme (if you request it from your OS) better.

12. We define new useful methods to override on behaviors, making behaviors more useful:

    procedure ParentAfterAttach; virtual; procedure ParentBeforeDetach; virtual; procedure WorldAfterAttach; virtual; procedure WorldBeforeDetach; virtual;

    procedure ParentAfterAttach; virtual; procedure ParentBeforeDetach; virtual; procedure WorldAfterAttach; virtual; procedure WorldBeforeDetach; virtual;

13. Finally, physics objects also support joints to connect and constrain rigid bodies.

14. Deprecation notice:

    For now, the old physics components (TRigidBody, TCollider) still exist, and the way to assign them still works (TCastleTransform.RigidBody, TRigidBody.Collider, TCollider.Create(const AParent: TRigidBody)).

    But, as the relation of old and new physics components can be a bit confusing, I would like to remove them rather sooner than later, likely before the 7.0 release. Please upgrade your physics usage to new components ASAP, and let us know on forum/Discord if you have any questions about how to upgrade!

    The TCastleTransform.Collides now has no effect on physics. Previously it had inconsistent effect on physics (TCastleTransform.Collides prevented collisions when exactly this TCastleTransform had a rigid body+collider, but TCastleTransform.Collides of parent didn’t matter).