Recently I was making various improvements possible thanks to new viewport and camera handling. If you haven’t already, see our video about Viewports, cameras and navigation!

Improvements:

1. Few fixes to automatic projection calculation. Long story short: you can probably leave TCastleCamera.ProjectionNear and TCastleCamera.ProjectionFar at zero in your projects, 2D and 3D. They should be always automatically calculated to nice values.

   1. Default perspective TCastleCamera.ProjectionNear doesn’t depend on world box (to not increase when some object flies/falls into infinity).

   2. Default perspective TCastleCamera.ProjectionFar is now ZFarInfinity, regardless of ShadowVolumesPossible (which were usually true). So there is no far clipping plane — easy to use. We were testing the perspective matrix with “z far at infinity” already a lot (as it was necessary for shadow volumes anyway), and there’s no perceived loss of Z-buffer precision because of it.

   3. Default orthographic TCastleCamera.ProjectionNear and TCastleCamera.ProjectionFar are much smarter now, looking at world bounding box.

   4. Optimized: Do not calculate useless ProjectionFarFinite, do not calculate ItemsBoundingBox when not necessary (never needed for perspective, not needed for orthographic when explicit).

2. We have deprecated TCastleViewport.AutoCamera, TCastleRootTransform.MainScene, TCastleRootTransform.UseHeadlight. I consider it a significant gain for the engine — in particular TCastleRootTransform.MainScene was a thorn in my side for a long time, it was unnatural we needed to designate some scene as “main” to activate some engine features.

   Now you can achieve (almost) all their functionality through other means. See their docs for pointers. And the engine usage is simpler when you don’t need to be concerned about setting MainScene etc.

3. Upgraded simple_3d_demo with new Blender models.

   New castle Blender model is also part of demo-models, see castle subdirectory.

4. Upgraded fog_and_distance_culling to use glTF model and of course new TCastleFog component.

5. Fixed crash in simple_3d_demo when accessing previews of data files with GeneratedCubeMap.

Fog can be now added and configured using TCastleFog component. The component is also available in CGE editor, so you add and configure your fog without even writing any code.

The usage is simple:

1. You add a fog component anywhere to the design using “Add Non-Visual Component -> Fog (TCastleFog)” in editor.

2. You set it as active for given viewport by adjusting the TCastleViewport.Fog property.

3. Adjust the fog parameters, like TCastleFog.Color and TCastleFog.VisibilityRange, as you wish.

4. Optionally, you can adjust the background color to match the fog color. The fog looks most natural in this case. You can just adjust TCastleViewport.BackgroundColor and leave TCastleViewport.Background empty (nil) for a simple background color. See more about backgrounds.

I reiterated this in a simple manual chapter about fog.

The fog behavior in combination with Linear color space (gamma correction) also changed. Fog is now applied in final (sRGB) color space, this allows to match fog color perfectly to background color or UI easily.

I’m happy to present a new video about Castle Game Engine that shows how to design 3D and 2D game world from scratch, by creating a viewport (with cameras, lights, some primitives, some navigation). We start from the “empty” template and explore what we can do in a viewport. The video goes into details about camera and navigation features, with a common theme “how to see what you want to see”.

We cover:

• Building upon the “empty” template a simple 3D world with cameras, lights, primitives

• Building upon the “empty” template a simple 2D world

• Navigation in the editor using “Fly”, “Examine” and “2D” modes

• Various helpful commands for navigate in the viewport, like Focus Selected (F), View All (Home), Top/Bottom/Front/Back/Right/Left (1/3/7 Ctrl+1/3/7) and more

• Adding a navigation component to allow user to move around in the 3D world, customizing the move speed

• Adjusting the camera translation and rotation in various ways

• Using multiple cameras

• Adding some children to the camera (like a weapon in FPS games or a headlight)

• Making a camera be a child of something else (e.g. mount it at some vehicle or attach to some animated bone)

• ProjectionFar automatic and manual adjustment

• Finally, more friendly and obvious key shortcuts for various editing operations in editor (Ctrl+C, Ctrl+V, Ctrl+X, Delete, Ctrl+Z… they all do what you expect)

I hope you enjoy the video. Go ahead and download the engine for free and please support us on Patreon.

The related documentation is:

• viewport

• camera

• navigation

The accompanying news post describing the new camera and navigation features is here.

Be sure to watch also our recent “Castle Game Engine Intro Tutorial – July 2022”. It’s a nice companion to this video, that shows more the “3D FPS game” and “2D game” contents, how to add more complicated stuff (like sprite sheets and glTF models) to your design, and how to do basic code operations (play a sound, handle button click, shoot a missile).

Enjoy a new tutorial about creating games with Castle Game Engine, covering all CGE essentials and demonstrating them on the latest engine version!

We cover:

• Installation

• Creating a new project from “3D FPS game” and “2D game” templates

• Exploring the viewport, moving around, adding scenes, transforming scenes, lights, cameras (in 3D and 2D)

• Building and running

• Creating a sprite sheet (2D)

• Manipulating light (3D)

• Coding: Handling a button click

• Coding: Playing a sound

• Adding a new 3D object designed in Blender and exported to glTF

• Coding: Shooting a missile – spawning a scene, with translation and moving direction synchronized with the player, coding a TCastleBehavior descendant

It demonstrates the latest version of Castle Game Engine that you can download, for free, right now!

Like it, subscribe, and please support us on Patreon to keep the engine development going.

We’re proud to present a big upgrade to how cameras, navigation, and consequently all viewports work in Castle Game Engine. This is a result of over 3 months of work and we encourage everyone now to upgrade to the latest Castle Game Engine and try it out!

A video describing it all is also coming in the following weeks.

The documentation has been updated to reflect all the new features, in particular 3D viewport tutorial has been reworked, also 2D viewport (soon-to-be) tutorial, camera docs.

New features: Table of contents (this is a really long news post):

1. Upgrades to design-time (in editor) camera and navigation
2. Camera (TCastleCamera) is now a TCastleTransform descendant
3. Navigation at run-time (like TCastleExamineNavigation, TCastleWalkNavigation) is easier to use
4. Viewport editing improvements
5. And more improvements that just happened along the way:)
6. Upgrading

If you like this work, please support us on Patreon!

Upgrades to design-time (in editor) camera and navigation

1. You can see camera “gizmos” in the editor, visualizing field of view (in both perspective and orthographic modes).

2. Switch navigation method using the new Viewport menu between Fly, Examine and 2D. Key shortcut Ctrl+2 is useful to toggle between most often used Fly and 2D.

3. Hold right mouse button to use mouse look (in Fly) or move (in 2D) or rotate (in Examine). Right mouse button in general means “activate design-time navigation”.

4. In Fly mode: use also mouse wheel to change speed, AWSD / QE to move. (TODO: Soon mouse wheel will also do zoom in/out when right mouse button is not pressed. It will change speed only when right mouse button is pressed.)
   

5. We have more goodies and key shortcuts for navigation in the Viewport menu. Key shortcuts are deliberately inspired with Blender, Godot and Unity functionality:

   • View all (Home)

   • Focus selected transform (F)

   • 6 major views (top, bottom, left, right, front, back) available by keys 1, 3, 7, Ctrl+1, Ctrl+3, Ctrl+7. You can use numpad or regular alphanumeric keys to access them.

   • Toggle perspective/orthographic using 5. (TODO: We want to synchronize the views better.)

   • Synchronize current view to the selected camera using 0.

   • Synchronize the selected camera to view using Ctrl+0.

6. This all makes sense in both 3D and 2D. For 3D, you will usually use Fly navigation with perspective camera. For 2D, you will usually use 2D navigation with orthographic camera and Front view (shortcut 1).

7. We show a preview of view from the selected camera in editor. You can pin it to keep observing from the camera, regardless of the currently selected item.

8. Hold Shift when changing the UI or transform (to move, resize, rotate, scale) to avoid changing the selection. Previously this was bound to right mouse button, but now we want to leave right mouse button to only activate design-time navigation.
   

9. Design-time camera and navigation settings are saved to the design file.

10. The design-time camera and navigation are now independent from run-time (in your games) camera and navigation, which allowed us to make all these improvements.

11. TODO: We have a few improvements still planned around this. In particular, we want to combine current UI selection/move with transform select/move/rotate/scale. It is not intuitive that right now you have to use different modes for UI and transforms.

Camera (TCastleCamera) is now a TCastleTransform descendant.

This has a lot of implications making cameras more powerful:

1. Camera can have children, like any other TCastleTransform. For example:

   • You can make headlight by simply placing light (like TCastleDirectionalLight, TCastleSpotLight, TCastlePointLight) as camera child. The default light direction is -Z, which matches the camera direction in local coordinates, so the directional lights work perfectly as headlights by default. An example of this is in examples/viewport_and_scenes/headlight.

   • You can place weapons held by player in FPS games as camera children.

2. Camera can be a child of some other transformation. For example:

   • You can attach camera to a car or some character that is moving.

   • You can attach camera to a bone, even animated bone, exposed using ExposeTransforms. Camera can be animated this way.

3. You can have multiple cameras in your viewport.

4. Set TCastleViewport.Camera to choose the current camera used for rendering. It can even be nil, in which case no rendering is done. Camera Exists (as well as Exists of camera parents) also matter, non-existing cameras cannot render.

5. This is backward compatible. When reading old designs, we add the camera to Viewport.Items automatically.

Navigation at run-time (like TCastleExamineNavigation, TCastleWalkNavigation) is easier to use.

1. Just add navigation instance to a viewport, like any other UI control.

2. Navigation also reacts naturally to Exists.

Viewport editing improvements

1. Undo (Ctrl+Z) now preserves design-time camera and navigation.

2. More useful default viewport 2D/3D setups.

3. Improved new project “2D game” template: nice design-time camera, show spritesheets.

4. Improved new project “3D FPS game” template: nice design-time camera, show skybox, show animations in editor, show lights in editor, show headlight as camera child.

5. Better and more natural key shortcuts – Ctrl+Z, Ctrl+C, Ctrl+V, Delete.

6. Added Cut Component (Ctrl + X)

7. Added Save Selected… (save selected component to a design file)

8. Better handling of behaviors (TCastleBehavior descendants) in editor: selecting behavior shows bbox of parent transformation, F on behavior focuses parent transformation too.

And more improvements that just happened along the way:)

1. In 2D ProjectionNear, ProjectionFar can be, and usually should be, just 0 to autocalculate. This is just like it already was in 3D. I expect that in majority of applications you can just leave both ProjectionNear and ProjectionFar at default zero.

2. Inspector (F8) shows non-default values with different colors.
   

3. We now have TCastleControl.AutoFocus. See focus (receiving key input) on TCastleControl.

4. Optimization (and fix for some edge-cases) in how vectors are deserialized (set all components at once, not one by one)

5. Better TCastleExamineNavigation customization with Input_Rotate, Input_Move, Input_Zoom.

Upgrading

We put a lot of effort to make this change as backward-compatible as it reasonably can, including reading old designs. But this is a big change in how cameras work, both in editor and at run-time and under the hood. You should note that some things work differently:

1. Because camera is now part of Viewport.Items:

   • Viewport.Items.Clear now removes also camera. Use Viewport.Items.ClearExceptCameras to leave TCastleCamera existing.

   • Viewport.Items transformation now affects the camera. Get/set camera using GetWorldView / SetWorldView to apply camera position/direction/up in world-coordinates, regardless of parent (including Viewport.Items) transformation.

2. Some deprecated things around navigation have been removed. In particular Viewport.NavigationType no longer exists. Instead of Viewport.NavigationType := ntExamine now do Viewport.InsertFront(TCastleExamineNavigation.Create(SomeOwner));.

3. More about backward compatibility in this post.

4. If you have any questions, just ask on Discord or forum. We will help to upgrade 🙂

We recently held a gamejam at Cat-astrophe Games and I decided to tackle something fun: can I make a real-time multi-player shooter (like Quake), using Castle Game Engine and RNL? In 1 day, during a gamejam? In turns out that yes! 🙂

I’m proud to present Not Quake, a new demo of Castle Game Engine and RNL. You can download the client (just run it and play!) from Not Quake on Itch.io. Or you can download both client, server, as well as the source code from Not Quake on GitHub.

Done in ~10 hours, I went from nothing to a simple shooter game, where multiple people can join (from clients on Windows, Linux, macOS, even Android in theory – though input on Android is not ready yet), send chat messages, and finally run and shoot. I went for a simple client-server architecture for this, just as a first attempt, with a central server that talks with all the clients — many other ways to do this are possible, but this was simplest to start with and indeed it works reliably for such a simple game.

The whole networking was done using RNL: Realtime Network Library, UDP-based network library for real-time applications and games, by Benjamin Rosseaux.

If you like it, please support us on Patreon:

• Michalis Kamburelis (Castle Game Engine) on Patreon

• Benjamin Rosseaux (RNL, PasGLTF, PasVulkan and more) on Patreon

Notes:

• (Edit: new-cameras was already merged to master!) It relies on CGE new-cameras branch, which is not yet merged to master. I wrote more about new features there in this post. It takes me a while to finish it (and merge to CGE master branch) — I have there still TODOs to fix mouse look in editor on Windows, improve 2D viewports, improve undo wrt. to cameras.

• Now that I’m more familiar with RNL, I want to refactor some messages code, to make it both simpler and more powerful.

• It uses my fork of RNL for now, which contains a very ugly hack to hide occasional problem with sending messages. I have to debug whether it is caused by my code, or by RNL unit, and of course fix. Unfortunately the crash occurs ~randomly, and never when testing through localhost, only on remote server. So it’s a pain to catch it.

• There are problems with macOS (mouse look, freetype) and Android (all input) clients. For now, Linux and Windows clients are really stable and advised.

Our editor relies on the fact that multiple TCastleControl instances work OK. This is turn requires that Lazarus TOpenGLControl (ancestor of our TCastleControl) supports sharing OpenGL resources (CGE caches assume that OpenGL data is shared across contexts). I submitted Lazarus pull requests to fix this:

• for Qt5 (so you can use it now for CGE editor, as a reliable alternative to Gtk2 on Linux/FreeBSD platforms) – qt5: Allow sharing OpenGL context data between instances of TOpenGLControl (!95) · Merge requests · FPC / Lazarus / Lazarus · GitLab.

• for Cocoa (for CGE editor on macOS) – Cocoa: Allow sharing OpenGL context data between instances of TOpenGLControl (!96) · Merge requests · FPC / Lazarus / Lazarus · GitLab. This patch is already applied for the Lazarus version used by our Jenkins to build CGE editor for macOS for our main downloads.

This is now documented in CGE manual about GitHub Actions.

We’ve made it so easy to use GitHub Actions to get automatic builds for your projects, done by GitHub, after every commit. You have to try this 🙂

1. Download this file: build.yml and place it at .github/workflows/build.yml path in your project. That is, create a subdirectory .github, then subdirectory workflows, then put the build.yml file inside.

   See the sample project castle-game using it.

2. Then commit, push and just watch the GitHub “Actions” tab as it picks up the commit and automatically rebuilds the project for:

   • Windows (x86_64)
   • Linux (x86_64)
   • Android (APK contains both 32-bit and 64-bit ARM code)
   • macOS (x86_64)

   Ready files are available in the “Artifacts” section. Download them, unpack — ready binary release of your game, for 4 systems above. You don’t need to do builds.

   Note that they will disappear after some time (90 days by default). If you want to preserve them you can e.g. make a GitHub release with them (and maybe even we will automate this too in the future, to make auto-updated “snapshot” release).

The actions execute on GitHub-hosted servers, completely free for open-source projects. They rely on Castle Game Engine Docker image and use the latest CGE “snapshot” revision and latest stable FPC (3.2.2) now. The build is done by executing CGE build tool with proper options. You don’t really need to understand it all — our build.yml just does it for you.

This is my first shot at implementing a new feature in CGE: “Automatic Cloud Builds” that you can quickly turn on when creating new CGE project, and will place a suitable file to integrate your project with

• Jenkins (your own Jenkins instance, that has to support declarative pipeline and Docker, similar to CGE Jenkins). This implies using a Jenkinsfile like this.

• GitHub Actions – based on above, this implies using .github/workflows/build.yml.

• GitLab CI. This means creating a file like .gitlab-ci.yml (example in FPC repo).

You can now download view3dscene builds for macOS (Intel-based macs) and Raspberry Pi. These new platforms are an addition to the existing Linux and Windows builds, that of course remain available too.

view3dscene is a viewer for all 3D and 2D model formats supported by Castle Game Engine, in particular glTF, X3D, VRML, Spine JSON, sprite sheets. It is a useful tool for Castle Game Engine developers (when you double-click on a model in CGE editor we actually open view3dscene), and for anyone else who just wants to view pretty 3D models downloaded from the Internet (test e.g. on glTF files from Sketchfab).

view3dscene snapshots for macOS and Raspberry Pi are automatically rebuild by Jenkins after every commit to view3dscene and Castle Game Engine (that passes a number of automated tests) so they will continue to reflect the very latest features.

macOS notes:

1. macOS app bundle is not signed (for now). For the first time, you have to run it by clicking with right mouse button, choosing “Open” from the context menu, and then accepting to run an unsigned application. Next time you can run as usual, by just double-clicking on the application.

2. view3dscene for macOS benefits from latest huge improvements for macOS users in Castle Game Engine. It uses new CGE Cocoa backend (native look, easy build), is packaged to an app bundle etc. Thanks for MacStadium, we now have remote macOS machine available 24/7, for Jenkins and for interactive work, and this allows to build and test view3dscene on macOS forever.

Thank you all for joining on today’s 2nd open meeting!

I am immediately announcing our next meeting, on September 17th. Click here to register on Discord, add it to your calendar etc.

Summary of today’s meeting:

1. Summary of new/upcoming features:

   1. I talked about new camera/navigation features. On new-cameras branch, very very close to being finished + merged to master 🙂

   2. Andrzej Kilijański talked about new physics features. On physics branch, likewise very close to being finished 🙂

   3. I showed engine on macOS, a recent new feature.

2. I talked a bit about future:

   1. Stuff from from 2022 plans remains in place. We did some planned things, remaining: modifying materials, new examples/fps_game/, Steam, nodes optimization.

   2. I am doing lots of thinking about our “message to new users”. It comes down to better communication how we’re equal/competitive to other engines (cross-platform, editor, powerful OOP API), but also how we’re special (glTF, X3D, native Pascal) and what advantages come from it. I plan to reorganize our webpage to communicate this.

   3. Easy installers. Snapcraft on Linux. Package with bundled FPC and Lazarus (with Lazarus preconfigured for single window (anchor docking), dark theme).

   4. Automation. We want to provide ready files that will make your projects build by GitHub Actions and GitLab CI.

3. We talked about a few things:

   1. Code editor (I talked about how we decided to use Lazarus. Although VS Code is also very appealing — but Lazarus’ code tools for Pascal and debugger win)

   2. Kagamma mentioned: a way to assign events inside castle-editor. I did’t find time to address it, but the short answer is: yes!

   3. WebGL (using FPC WebAssembly) port is anticipated by everyone, including me 🙂