Fixes to third person navigation component and example:

• Fixed the design-time behavior — the existence of TCastleThirdPersonNavigation should not affect behavior of camera at design-time.

• TCastleThirdPersonNavigation.DistanceToAvatarTarget secured in case it is zero, previously it got us into weird transformation bug.

• TCastleNavigation.ZoomEnabled behavior on TCastleThirdPersonNavigation fixed

• Accidental playing of walking animation (even if you don’t hold “W” key) fixed.

Fixes to UI:

• Switching to TCastleUserInterfaceFont.Outline = 0 fixed.

• Updating group when child TCastleUserInterfaceFont.FontSize changes fixed.

• TCastleUserInterfaceFont.Outline changes now row height of controls like edit or label.

LSP server:

• Important fix to avoid crash due to range check error.

• Tested with VSCodium and officially documented on VS Code page.

I can’t count anymore how many times I’ve been asked “when is the Dark Mode coming to CGE editor” 🙂

One answer is: It is already possible. We use LCL and our editor just follows your OS (Windows, GTK, …) theme. If you switch your system theme to something dark, then all your applications (including CGE) will become dark. There are small improvements to it in the physics PR too — I hope to finally finish and merge it this weekend!

Another answer is: We will get to the dark mode (in a cross-platform way, that can be activated specifically for CGE editor) one day, just because we have to 🙂 No matter how hard it may be with LCL.

Here’s a dark mode design by Adrianna Matejek. Thank you!

We have a number of enhancements to our 2 large documentation pages (targeting mostly advanced engine users / developers):

1. Custom Components documentation was extended with description how do we advise to create children components in your custom components. This is useful when you want to create a new component, register it in CGE editor, and you want to use existing components as children.

   1. You can have internal children (using SetTransient).

   2. You can create regular components in OnCreate method that the user can later completely change and even remove (free).

   3. You can have subcomponents (where user can configure properties, but shouldn’t free / assign a different instance).

   All cases are documented with example code.

2. We have a big Coding Conventions page that documents a lot of low-level and high-level guidelines about how the engine is developed. It starts with some mundane stuff (like indentation — 2 spaces, never tabs!) but later discussed more interesting topics that I recommend to read:

   1. Our guidelines for BeforeDestruction usage. Big thanks for Andrzej Kilijański for talking it over with me — it’s a very powerful mechanism when combined with clear guidelines when to use it.

   2. You can (and should) free the things you allocated; you should never free other things, unless explicitly allowed.

   3. What can be nil.

   4. Declarative API (classes with independent properties) is simple to use.

   5. Optimize smartly: profile, optimize where it matters (and not where it doesn’t), think about smarter algorithms and moving CPU work to GPU to get big benefits.

   6. Fix warnings (let the compiler help you write reliable code). (Shining example: recent critical TCastleThirdPersonNavigation fix for seemingly-random bug.)

   7. Be consistent in API design.

   8. Backward compatibility is important; having a consistent (easy to learn) API and useful features is even more important.

This post’s image follows our tradition if there’s no clear image to illustrate this, just search for any pretty 3D model. It turns out that if you search for “documentation” on Sketchfab, one of the things that comes up are 3D models of Raspberry Pi, which we love and support in CGE (both as a platform where you can work, and as a platform to which you can compile your games). So here’s a screenshot of CGE editor rendering a 3D model of Raspberry Pi Pico by abdou bouam.

Extending our glTF support, we now handle texture coordinate transformation following the KHR_texture_transform extension.

The glTFs using it can be generated e.g. by Blender if you transform UV Map using the Mapping node (see the screenshot at this post).

If you use Visual Studio Code, we have a new manual page for you and an LSP server distributed and tested with Castle Game Engine that provides a perfect Pascal code completion.

Most important link

Read everything here: Visual Studio Code with Castle Game Engine.

What is an “LSP server”

LSP (Language Server Protocol) is a protocol to define code tools functionality (e.g. code completion) in a way independent from the text editor.

• Multiple text editors can act as LSP clients, e.g. VS Code (where the LSP originated), Emacs, Neovim.

• They can access any LSP server. There are lots of LSP servers, in particular there are a few suitable for Pascal.

What I did

I was having some fun exploring the options and I actually got to work 2 LSP servers targeting Pascal: Philip Zander (Isopod) LSP server and Ryan Joseph (genericptr) LSP server. They both use Lazarus CodeTools underneath.

I then modified them (both) adding some CGE-specific features and testing how to make them perfect. I wanted to have it all — support for VS Code (which I know many people like), Emacs (which is my favorite text editor), out-of-the-box support to complete code using CGE API, working everywhere (I tested both Linux and Windows).

1. We had a few conversations with Philip Zander (thank you a lot for all the information how everything works and being open to my PRs!), I made our fork with Castle Game Engine enhancements, I submitted some PRs back: #1, #2, #4.

2. I also made a fork of LSP server from Ryan Joseph and submitted PR #33.

My forks add support for additional configuration using INI file and you can make LSP servers trivially aware of CGE paths this way. The details of my additions are in README files on both LSP servers.

Note: Both the above LSP servers actually come from initial Arjan Adriaanse work (though, after 3 commits, it seems he didn’t maintain it further) on github.com/arjanadriaanse/pascal-language-server.

Finally, I gathered a lot of notes and links about existing options to use LSP with Pascal.

Making it easy to use

As a last step, I made the setup as easy as possible to use:

• Our LSP server is just packaged along with CGE downloads from today. If you download CGE, then you also download an LSP server we advise.

• I tested it with our bundled FPC. CodeTools need to access newly added fpc-cge wrapper.

• I documented everything about VS Code integration (LSP server and more) as a nice manual page.

This was a lot of integration work 🙂 And it’s not finished! A lot of pieces can be improved and/or it can be made to work more out-of-the-box. It is possible we’ll have our own Castle Game Engine extension for VS Code one day. It could take care of LSP, help with debugging and running CGE projects from VS Code, maybe more?

Stay tuned 🙂 Do you like this? Please support our work.

So I have now around 5 things in parallel in progress 🙂

1. Review and merging of new physics (components for colliders, rigid body, joints) with Andrzej Kilijański. It takes a while, but it’s also a large change, and I want to iron out various API details.

2. Working on big upgrade to FPS game graphics with Adrianna Matejek and Alya Vaneskehyan. Aside from a prettier demo, I get from them a ton of feedback about engine experience from a perspective of experienced 2D and 3D graphic artists. And I have a ton of resulting good TODOs and priorities that will over time find their way into the egnine (some of them already did).

3. I’m planning restructure of our settings. I would like to deprecate our CastleSettings.xml in favor of a design like CastleProject.json that allows to specify more, and is editable in editor too. In addition to current settings, it would also allow to define some project-wide components (like sounds and fonts that should be loaded and available for the entire application lifetime).

   While a plan is written down, I will likely postpone it after 7.0 release.

4. I have a great plan how to allow to visually customize materials and material effects in CGE. We have some unique challenges and unique features (our compositing shaders or easy mirrors are really great, we just need to expose them in a way that is simple — both from editor and from Pascal to use).

   I consider this high priority and want to push to make it happen before 7.0 release.

5. I’m organizing a Windows certificate so that our EXE files are less scary to run on Windows 🙂

Some things done lately that are already available in CGE master branch:

1. New property TCastleTransform.RenderLayer to force some things to be rendered in front of others. Particularly useful in 3D, e.g. to display weapon in FPS game always in front of other 3D objects.

2. New property PreciseCollisions and deprecating previous complicated Spatial property. This is anyway part of old “simple physics” — while still available, with time we will want to move everything to new physics, so PreciseCollisions is doomed to be deprecated (at some future point, after 7.0 release) too. But for now it’s great to e.g. easily control how FPS navigation by TCastleWalkNavigation behaves.

3. Important fix for DistanceCulling with shadows.

4. Testing LSP servers with Pascal! More about it in next news post 🙂

We continue to improve the editor to make it easier to design large 3D and 2D games.

1. Context menu of each component (available if you click with right mouse button on a component in the hierarchy panel, on the left) contains now a menu “Change Class…”. This allows to change:

   • any TCastleUserInterface class to another TCastleUserInterface class (for example change empty group to a color rectangle),
   • any TCastleTransform class to another (for example change light type between point / spot / directional),
   • any TCastleBehavior class to another (for example, change collider between sphere / box / mesh etc. in the upcoming physics work),
   • any non-visual class to another (for example, change font class to a family of fonts with different bold / italic etc. versions).

2. You can now select multiple TCastleTransform instances by clicking on them with Ctrl key held down in the design (middle) panel (which shows 3D view in case of 3D viewports).

   Multiple selected transformations are also better shown now.

   This is great to select e.g. a number of light sources or scenes and change their properties (e.g. intensity or color of the lights).

   Note: For now, you cannot transform (move/rotate/scale) a multi-selection using a gizmo. But we have made now a first step to enable this too in the future:)

3. You can now add TCastleBehavior from right-click menu when another TCastleBehavior is selected. Esp. useful when adding collider alongside rigid body — this is great for upcoming physics.

4. Use Alt+1, Alt+2 etc. key shortcuts to quickly switch between interact / select / move / rotate / scale tools.

5. Use Escape key shortcut to reliably focus the design (middle) panel. This is great if you want to use e.g. F (focus) or 1 / 3 / 7 key shortcuts. In case you stand on an edit box, the Escape key will reliably switch focus to the design.

You can speed up the compilation of all future projects if you initialize “compilation cache”. Underneath, it means we will just compile all CGE units to a special “cache” directory (stored inside user directory, independent from the current project) and we start compilation of each project by taking all CGE precompiled units from this cache.

The effect: your compilation can be lighting fast. In my tests, if the cache is initialized,

• It takes 2.5 seconds to build a Linux application.

• It takes 10 seconds to build an Android APK.

And these are times of the first build, on a newly created project.

How to initialize cache?

In CGE editor, use the menu command “Run -> Cache (Precompile Engine For Current Platform)”. By default it will cache compilation for current platform (e.g. Linux or Windows where you run the editor). Switch the platform using “Run -> Platform (To Build And Run) -> …” menu item, and redo the “Run -> Cache (Precompile Engine For Current Platform)” for each platform.

Note: The menu commands to initialize the cache are only available when you have some project, any project, open. This is just a consequence of our current UI (we already have output console, and platform choice, when the project is open). But the created cache is actually independent from the project.

Or you can do it using the command-line CGE build tool, if you prefer (and your compiler, like FPC, is available on PATH environment variable). Just execute something like this:

castle-engine cache # cache for current platform
castle-engine cache --target=android # add cache for Android, both 32-bit and 64-bit

Why like this?

Right now: Without the cache if you compile the project for the first time, we actually always compile the engine too. Moreover (with or without the cache) all the compilation output (like .o, .ppu files) is stored in project-specific castle-engine-output.

Why?

• This makes things simple. It means that we just provide to the compilers your main source code (program or library) and the paths to all sources (of your project, and of the engine). And the compiler (FPC or Delphi) just does whatever is necessary.

• It means that switching compilers, FPC versions etc. is not an issue. Again, the compiler will just do what it should. E.g. the compiler should realize that standard units have changed compared to previous compilation.

• It is friendly to engine developers 🙂 Changing the engine unit has the same effect as changing your project source code. In both cases, the compiler just figures out the minimal set of units to recompile.

• The debug/release modes change not only the compilation options of your application, but also of CGE units. This is helpful e.g. to activate certain additional assertions and range checks in the engine.

• It allows you to set, within each project, some defines that affect engine compilation. For example you can change CastleWindow backend by using appropriate define. In general we want to make this use-case not important (it would be e.g. cleaner to switch CastleWindow backend by using a particular unit, it would also make it better for cache) but it is still practically useful for now.

We have designed the cache mechanism to not interfere with these advantages:

1. The current cache contents (.o, .ppu files) are copied over but without overwriting the current .o, .ppu files in the project. So the precompiled units from cache are a starting point to your project’s compilation directory. But the precompiled units do not overwrite the existing ones, moreover the compiler will overwrite them (in the project) if e.g. you have changed CGE since making the cache. So the cache tries hard not to conflict with what you’re doing.

2. There is a separate cache for each mode (debug,release,valgrind).

1. Use Viewport -> Wireframe mode menu, or just hit Alt+Z shortcut, to toggle between viewing:

   • Polygons,
   • Wireframe or
   • Polygons + Wireframe (internally known as weSolidWireframe).

2. At design-time, in “Fly” mode, mouse scroll wheel now does zoom (if you don’t have right mouse button pressed; when right mouse button is pressed, it changes moving speed, as before).

   More details:

   Zoom (by mouse scroll wheel) is now available for all navigation modes, including TCastleWalkNavigation. Although it is disabled on TCastleWalkNavigation by default, but you can just enable it by MyWalkNavigation.ZoomEnabled := true (or clicking on ZoomEnabled checkbox in editor).

   Editor and view3dscene enable this zoom by default.

   Also, zoom-in now honors collision detection. Though at design-time we disable collision detection.

3. We’ve done a few fixes to make TCastleWalkNavigation navigation, including mouse look, work even when the camera is a child of some other TCastleTransform with some transformation.

   This gives you more flexibility where do you place TCastleCamera in the transformation hierarchy.

Playing and testing physics, in preparations for merging into CGE master branch:)