Category: Uncategorized

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;

    1 2 3 4

    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).

We have an important change to one of our most important concepts: states (TUIState descendants) are now called views (and descend from TCastleView).

It’s a change in terminology, and a change in API. While previously you were changing states using class functions and properties, like TUIState.Current := Xxx, now you should use regular container methods, like Container.View := Xxx.

Oh, and to this we add a new slick UI when opening the project 🙂

Why?

It addresses two things:

1. The name “state” was too generic and thus meaningless. Almost every variable and object instance in your application can be called some “state”.

   It made sense if you think “user interface state” or “state of a state machine“… but the sole word “state” is too generic.

   Moreover, TUIState class name is not consistent with CGE naming. And TCastleUIState or TCastleUiState are too convoluted. So for a long time I knew it will have to be renamed to TCastleState or TCastleView. I finally finished the work to go with TCastleView.

   “View” doesn’t seem too bad name. It clearly communicates it’s something visual and is a way to “see” CGE stuff. And, view isn’t that often used as a noun, so when someone says “This view is amazing” you can fairly safely assume they talk about TCastleView (assuming you’re in the middle of CGE manual, not on a hiking trip 🙂 ).

   It is consistent e.g. with React view.

2. The way we changed states, using TUIState class methods/properties, could be improved to use simple methods on Container.

   This way there’s often no need to know what is the “central” container (TCastleControl.MainControl is now deprecated) and every container has it’s own, separate, state stack (or rather: view stack now). This makes things simpler if you try to use multiple containers or TCastleControl (whether for LCL, VCL or FMX). You can just do

   MyControl.Container.View := PlayGame;

   1	MyControl.Container.View := PlayGame;

   instead of

   TCastleControl.MainControl := MyControl; TUIState.Current := PlayGame;

   1 2	TCastleControl.MainControl := MyControl; TUIState.Current := PlayGame;

   This is already reflected in new TCastleControl docs.

Upgrading

This change is 100% backward-compatible. The old code will continue to work, though we advise you to upgrade to new names and container methods/properties.

In total, the upgrade path in typical applications is rather straightforward, although it will require to do a lot of replacements (I recommend to commit everything to your version control before doing the upgrade, and then have a nice diff to audit with state->view upgrade):

1. Rename TUIState -> TCastleView.

2. Remove CastleUIState unit from your uses clause. Make sure unit CastleUIControls is there (it likely is there already).

3. Change in ApplicationInitialize:

   TUIState.Current := ...

   1	TUIState.Current := ...

   to

   Window.Container.View := ...

   1	Window.Container.View := ...

4. Change in various states (views):

   TUIState.Current := ... TUIState.Push(...) TUIState.Pop(...)

   1 2 3

   TUIState.Current := ... TUIState.Push(...) TUIState.Pop(...)

   to (respectively)

   Container.View := ... Container.PushView(...) Container.PopView(...)

   1 2 3

   Container.View := ... Container.PushView(...) Container.PopView(...)

5. Optionally, as a final touch: rename your units and designs.

   Previously we called them gamestatexxx . With class like TStateXxx, with variable like StateXxx.

   Now we advise to call them gameviewxxx . With class like TViewXxx, with variable like ViewXxx. If you choose to go with rename, you will likely find that a general interactive rename state->view, and accepting 99% of the replacements, it the way to go.

   You can just rename them everywhere. Remember that the unit also refers to the design, doing something like

   DesignUrl := 'castle-data:/gamestatemain.castle-user-interface';

   1	DesignUrl := 'castle-data:/gamestatemain.castle-user-interface';

   So if you rename both the unit and design (which we recommend, to keep F12 working nicely in CGE editor) then change also that line of code to

   DesignUrl := 'castle-data:/gameviewmain.castle-user-interface';

   1	DesignUrl := 'castle-data:/gameviewmain.castle-user-interface';

New editor UI when opening new project

This is accompanied by a cool upgrade to our CGE editor UI. It happened because of independent reasons (I did UX testing on a live human at Christmas :), and came back with lots of nice conclusions) but it is nicely connected with the whole views terminology.

Now, when opening any project, you will be greeted with a UI to

• compile and run / stop the project
• create a new view (Pascal unit and design)
• open an existing view

This UI emphasizes your most recommended actions after opening the project.

Docs

Our documentation, including important chapters about view events and managing views, has been upgraded to new terminology.

Our examples are also fully upgraded now to use view terminology everywhere.

“Lynch”, my gamejam game done using Blender and CGE, is now on itch.io — https://cat-astrophe-games.itch.io/lynch. Easy download for Windows and Linux.

The full source code and data are available on GitHub.

I did some cool post-gamejam improvements:

1. Added sounds: new ambience, footsteps, statue sound.

   The demo code shows my recommended approach to add footsteps sound for 3D walking game, see the TFootstepsBehavior class in GameBehavior unit.

2. Added 2 water surfaces.

3. Added some creepy logic for the statues behavior 🙂

   The code of it is again quite nice and you can reuse it for your projects. It is in GameBehavior unit. I will let you figure out on your own what is exactly this “creepy logic” :), just play the game!

4. Fixed octree creation (the roof was extremely high-poly by accident, at it was causing problems).

   I also added better facility to debug such things in CGE. Octree creation for shapes happens now reliably on load, and you can debug what is taking the most time by using our profiler. Just set Profiler.Enabled := true and look at log.

With so much going on around the engine, I barely have time to write it all down in news 🙂

First of all, we had our open meeting on Discord 2 weeks ago. A short summary:

1. I showed our new physics features. You know, the things merged in that huge merge right before the meeting 🙂

   (Since the open meeting, I have actually merged the 2nd big part of this work: physics joints!)

   The documentation how to use physics is available along with a lot of examples in the engine examples/physics subdirectory.

2. I showed our Pascal LSP, to provide intelligent code completion in Visual Studio Code and other editors.

3. I showed other small features:

   • “Change class” ability in CGE editor

   • Wireframe view in CGE editor

   • Published fields are now auto-initialized

   • Easy shadows

   • My experiments for Pascal attributes

4. We showed some things in progress:

   • Work on new fps_game, upgrade to both functionality and graphics. Done together with Adrianna Matejek and Alya Vaneskehyan.

   • Work on Android on-screen keyboard by Andrzej Kilijański. It is now in PR #423.

5. I described some plans. I guess the most important — release a new CGE version around Christmas (hey, so it’s really soon! 🙂 ).

   Then release 7.0 in January 2023. Most important things to finish: new materials components, AI behaviors, Steam integration.

6. Then Coldzer0 gave us a great update about the progress about using Castle Game Engine from JavaScript through QuickJS.

   It exposes a really nice and comfortable JS API. And you can create instances, assign callbacks, and generally have the same power as CGE in Pascal.

   More information about it will come as available. My recommendation: look into scaling the implementation, to account for our 100+ classes and components :), and look into porting e.g. “3D FPS Game” template to JS.

I would like to immediately announce next open meeting: 5th Open Meeting: Spring 2023. Join us March 18th (Saturday), 2023. At the usual hour 15:00 UTC. Go ahead and click on the link to the meeting on Discord, there you can click “I’m interested”, see it in your timezone and add to the calendar.

You’re welcome to watch Michalis presentation tomorrow, December 21, at Embarcadero Enterprise CodeRage 2022.

The topic of the presentation is using Castle Game Engine as a 3D visualization tool that you can add to the existing Delphi applications. As part of it, I also want to show for the first time a new feature, requested a few times by Delphi users — yeah, you guessed it, a CGE control you can put on FMX or VCL form! Of course, the talk will also feature a general overview of the engine capabilities, regardless of how you want to use it.

The hour is 3:00 PM in CST (Central Standard Time (US)).

The event is free, you can register a seat following this link or just watch a live stream on YouTube Embarcadero channel.

My mind is completely blown by the capabilities of OpenAI chat bot ChatGPT. It can tell jokes, invent stories and protagonists, write documents with game pitches, play an RPG game with you, pretend to be a virtual machine with an access to an Internet in a weird alternate universe (I checked, it works, you can even do wget https://castle-engine.io in that universe)…

Here are some interesting experiments with relation to Castle Game Engine and Pascal.

Integrating Castle Game Engine with PhysX

PhysX is a physics library from NVidia. It is not integrated with Castle Game Engine as of now. We use Kraft physics engine in CGE now.

As far as I know, no one has ever attempted so far to integrate PhysX with Castle Game Engine. Internet search doesn’t show any results even for PhysX in any Pascal application.

Yet AI can write ready code to do it..

My prompt: Write Pascal code implementation integrating PhysX with Castle Game Engine.

Bot answers:

It also added a short explanation. See the screenshots.

AI just integrated 2 libraries, never ever before integrated in the whole history of the universe.

Sure, there are a lot of problems with this code. It doesn’t really compile, the usage of TVector.One is wrong, there’s no unit called CastlePhysX…

But it’s like written by a programmer that knows CGE, knows PhysX and understands the core of the task. And was just too lazy to check on some API details.

• It is using CGE vectors API,

• It is using PhysX API (DuckDuckGo confirms that PhysX has concepts like PhysXWorld, PxTransform, PxRigidDynamic).

• It runs the simulation ~60 times per second, and uses Pascal Writeln to output the result. It added initial velocity to the object, to observe that it changes position. This is exactly what I would do in my first attempt at such application, to test the integration.

Next day, I realized I can ask it to fill the remaining stuff. I can say things like “Given the Pascal example as below: … , implement CastlePhysX unit”. Yes it works. I still didn’t reach a complete code that compiles… but wow. This is impressive.

Generating HTML documentation from Pascal source code (like PasDoc)

Let’s try something else. Let’s make it perform the job of PasDoc.

My prompt: Generate HTML documentation for the Pascal class declared as below:

(here I pasted actual long multi-line code declaring the TCastleButton class, cut down to public and published sections)

Answer with complete HTML code that can be easily copied and pasted.

It answered…

Next prompt: Show me the HTML markup of the above.

Bot answered with HTML markup…

Here is the HTML markup for the documentation of the TCastleButton class:

Yes, it’s a real HTML code. It’s cut — just a limitation of free ChatGPT version I guess, they limit the length of the answer.

It performed the basic job of PasDoc (convert Pascal code with comments -> HTML)….

Holy f**.

We held a gamejam in our Cat-Astrophe Games studio this Friday and I decided to make a short “walking simulator” game to refresh my Blender skills and of course test that the result works in Castle Game Engine!

The resulting game is on https://github.com/michaliskambi/lynch . It’s very much unfinished, I overestimated what I can do in a short amount of time — but I also learned a lot: using Archimesh, using Geometry Nodes, and generally I think I managed to made OKayish 3D model of a house + surroundings with reasonable proportions in game.

Enjoy the screens and (really trivial) code 🙂

P.S. The prominent pretty 3D asset comes from Bronze figurine of Cthulhu, from Sketchfab, by Jedi2583.

After lots of work from Andrzej Kilijański and myself (started back in February this year), the big new physics features have landed! They are merged to the master branch of our Castle Game Engine now.

A full news announcement will be released once I’ll get some sleep :), short version:

• new components to setup rigid bodies / colliders (also in the editor),

• forces API,

• 3rd-person navigation improvements to also be able to use physics,

• buttons to run simulation from editor,

• and much more…

Preliminary new (rather short now) docs are here.

I could direct you to the list of commits in the PR, but it’s too big to browse nicely on GitHub, so let me try to crash our website by pasting the result of git log master..physics > physics-log.txt below 🙂

And remember we have a 4th open meeting this Saturday. The meeting will take place at the usual hour (15:00 UTC) on our Discord. You can go to the meeting already and click there “Interested” and add it to your calendar. See you there! I will of course, among other things, present the new physics.

And now: