Month: November 2019

We were incredibly busy lately, preparing the release of The Unholy Society for PC (Windows, Linux) and Nintendo Switch. It’s a game by Cat-astrophe Games, using Castle Game Engine, programming by two of CGE developers — Michalis Kamburelis and Eugene Loza. Check out our trailer and game information on the game page and wishlist us on Steam!.

In the meantime, we have a number of improvements to the engine from November:

• We have exposed methods to perform “mouse look”. They can be used to make mouse dragging without being constrained by window borders. New demo of both dragging methods is available in examples/2d_standard_ui/dragging_test.

• We support a new Spine feature to export a single atlas for multiple skeletons. It’s quite cool, often allows to significantly reduce the total necessary atlas sizes. To use it, you need to open Spine file through an URL like this: my_animation.json#atlas:my_atlas_name instead of just my_animation.json. See our Spine documentation for details.

• New OrientationInterpolation2D allows more efficient 2D rotation interpolation. It is automatically used by Spine animations.

• Our build tool allows to configure package format by --package-format option (allowed values for now are: default, directory, zip, targz). You can also configure whether version number appears in the resulting filename by --package-name-no-version option.

• Programs using Application.ParseStandardParameters will now automatically handle the --log-file command-line option, that allows the user the configure output log file. Note that, in order to make this work, you should not call InitializeLog before command-line options are parsed. Our examples, like portable_game_skeleton, show how to do this.

• The default sound “importance” is now 10, instead of “maximum”. This seems much more reasonable. See our new docs of sounds XML files.

To celebrate #ThankYouPatrons day in the weirdest and most-programmer-friendly way possible, today we merge into the “master” branch of Castle Game Engine a big refactor of the camera code! This is a huge work, started 4 months ago, and causing 110 new commits.

It includes a number of new inter-connected features:

1. The API to control the camera (viewer position, direction, up, projection etc.) and navigation is now much simpler. Check out API docs about new TCastleAbstactViewport.Camera and TCastleAbstactViewport.Navigation.

2. You can now configure both camera and navigation visually, using the CGE editor.

   When you select a viewport (most usually a TCastleSceneManager instance), or anything inside a viewport (like a TCastleScene), there will appear a new set of buttons on the toolbar. The “hamburger” button there contains a menu with useful operations to configure camera and navigation. The “initial” camera vectors will be stored in the design, as well as the chosen navigation component.

   (The buttons to translate/rotate/scale scenes are not yet handled — coming soon!)

3. We split previous camera class into two concepts, TCastleCamera (“what is current viewer position/orientation and projection”) and TCastleNavigation (“how to handle user input to change the viewer position/orientation”).

   This caused a lot of work to make it right, and also to keep backward-compatibility as much as possible. I’ll list reasons for making it in another post — it’s a story in itself.

4. We provide easy means to turn off “auto-detection” of camera and navigation. Just set AutoCamera and/or AutoNavigation to false.

   I recognize now that this “auto-detection” is sometimes undesired or even surprising. I would advise most games to set both AutoCamera and AutoNavigation to false right after creating TCastleSceneManager. CGE editor will do it by default too, soon.

5. TCastle2DSceneManager is now deprecated, as it is useless. You can now easily request orthographic camera with TCastleSceneManager (call Setup2D method, or just set yourself Camera.ProjectionType = ptOrthographic and configure Camera.Orthographic properties). This makes things much simpler. We never needed any special class for 2D, our TCastleSceneManager is for both 2D and 3D — now it’s obvious 🙂

6. It is now configurable which camera (from which viewport) controls “central” features like headlight, X3D ProximitySensor, audio listener. Set TCastleSceneManager.MainCamera for this.

7. CGE editor received a number of smaller improvements along the way. E.g. you can now duplicate (Ctrl + D) transformations/scenes too, assigning SceneManager.MainScene and other references works.

Thanks to Andrzej Kilijański and our physics engine Kraft, we add two features to our physics support:

1. We now support triggers. A trigger is a rigid body through which other objects “pass through”, but it still reports a collision. This is useful to observe when something passes through something else.

   E.g. coins in “Mario” games could be implemented as triggers — when player collides with them, they are consumed, and player does not “bounce off” them like from a wall.

   An example of using trigger is available in examples/physics/physics_2d_collisions, the green rectangle acts as a trigger there.

2. You can adjust physics properties by adjusting SceneManager.PhysicsProperties.Xxx. See the TPhysicsProperties docs.