New component TCastleBackground allows to define a nice background for 3D games. Just add it to the design by Add Non-Visual Component -> Background (you can add it to any component, but it’s most natural to do it on viewport) and then set TCastleViewport.Background to it.

1. You can provide up to 6 textures that define 6 sides of a skybox. See wikipedia about skyboxes.

   How to make such skyboxes?

   • Sample cubemaps can be found e.g. on OpenGameArt and Emil Persson’s large cubemap collection. They are provided by setting URLs like TCastleBackground.TexturePositiveX (our naming follows e.g. X3D and Emil Persson’s conventions).

   • You can render them in Terragen.

   • You can render them in Blender.

2. You can define a sky gradient using TCastleBackground.SkyTopColor, TCastleBackground.SkyEquatorColor, ground gradient TCastleBackground.GroundBottomColor, TCastleBackground.GroundEquatorColor, and additional gradient to smooth transition from sky to ground TCastleBackground.SmoothEquator.

   The sky and ground colors are visible if you don’t provide the 6 textures for a skybox, or if some of them use alpha for transparency.

Lately I’ve done a number of rearrangements in CGE units, to make the engine code cleaner (easier to understand, both for new people and seasoned devs):

1. Units map documentation is now up-to-date and more straightforward.

2. Unit dependencies outlined in units map are (again) automatically checked by check_units_dependencies internal tool (using ppudump from FPC underneath).

3. A lot of obscure/internal units have been renamed to CastleInternalXxx or marked as deprecated. We’re not finished with this cleanup yet, see more potential units that can become internal. But our list of units is already much shorter, making CGE API smaller so simpler to learn.

4. Subdirectory src/3d is now src/transform. It contains TCastleTransform and friends, and is suitable for both 2D and 3D.

5. Subdirectory src/x3d is now src/scene. It contains TCastleScene and friends (like TCastleViewport). I moved the 2 big units that define X3D fields and nodes to a subdirectory src/scene/x3d. The code loading particular model formats is now in src/scene/load, and some formats even get their own subdirectory, like src/scene/load/spine.

6. I added subdirectory src/base_rendering, that contains some base OpenGL units (and will contain in the future alternative subdirectories for OpenGL, Vulkan etc.).

7. We no longer use opengl subdirectories inside various other CGE directories. Things from base/opengl/, images/opengl/ mostly move to base_rendering. Things from scene/opengl/, ui/opengl/ mostly move to parent dir, i.e. just scene, ui.

   Why?

   The original idea for separating units that depend on OpenGL from things that don’t was that it would make it easier to recognize what needs to change when we add another renderer (like Vulkan).

   However, a lot of CGE units now depend on OpenGL only “very indirectly” and they have a clear API independent from OpenGL. For example, CastleControls unit depends on OpenGL, but actually both its interface and implementation are completely independent from OpenGL, and they will likely look the same when we have Vulkan available. They just use TDrawableImage and DrawPrimitive2D that make sense for any renderer.

   Similar notes go for e.g. CastleScene or CastleViewport. They depend on OpenGL now, but if (when?) we’ll jump to Vulkan, they will continue to exist with the same API, and even they’ll retain most of their implementation. We will just introduce then an abstraction layer, to make renderer “pluggable”, so that underneath TCastleScene, TCastleViewport, TCastleUserInterface will refer to the “current renderer” to do their drawing.

   All this meant that keeping these units in opengl/ subdirectory was not really very helpful. In fact, most of important CGE units were in opengl/ subdirectories, which was likely more confusing than helpful. E.g. ui/ looked like a mostly empty directory (mostly just joystick units) until you looked in ui/opengl/ that contained a lot of important classes.

8. A few usages of is nested were cleaned — as it is not supported by Delphi. We previously tried to use “is nested” on FPC and anonymous methods on Delphi, but this resulted in a code complicated with ifdefs. It’s better to stick to a common subset of FPC and Delphi for now, which means — no “is nested”, no anonymous methods. (Of course you’re free to use them in your own projects, if you only care about using one of these compilers.)

P.S. I don’t really have any relevant screenshot to go with this post. So enjoy a screenshot with a sample Tiled dungeon map from here, rendered of course using our examples/tiled/map_viewer 🙂

I’ve added an example project examples/user_interface/custom_cursor showing how you can implement a custom cursor in your applications. It’s very flexible — the custom cursor is just a UI element, synchronized with mouse position, and it can contain an image, a viewport (with animated scene) or anything else you want. You even design the custom cursor in the CGE editor.

We have extended our documentation how to put engine on Lazarus (and soon Delphi too) form. It now discusses also where to initialize CGE in this approach, how to use states and UI, and makes it clear that mixing TCastleControl and TCastleWindow in one application is not allowed.

I advise every CGE developer to run these 2 new examples today! 🙂

1. examples/component_gallery is a 12-page demo of possibilities of user interface components in CGE. Run the demo, and browse the pages to see what is possible. Then explore the demo in the editor (open designs data/page_xxx.castle-user-interface) to see how you can do this.

   The screenshots from this demo also augment new manual page about user interface.

2. examples/viewport_and_scenes/transform_primitives shows possibilities of primitives (sphere, cylinder, cone, sphere, plane, box, text) in the viewport.

   The screenshot from this demo also improves manual about viewport.

We have a new component TCastleImageTransform, which is now the most advised way to place simple image inside a viewport. This is great for static backgrounds in games, backgrounds that move with player, static pieces of 2D levels etc.

So we now have 2 advised (simple, available in editor, full-featured) ways to handle images:

1. TCastleImageControl (if you want image be a UI)

2. TCastleImageTransform (if you want image be inside TCastleViewport, which means it is part of the game world, and it moves along with the rest of the world or with game camera).

New TCastleImageTransform allows to easily e.g.:

• adjust pivot TCastleImageTransform.Pivot – pivot doesn’t have to be in the center, in can be anywhere, e.g. in any corner of the image, whatever is comfortable in your situation.

• repeat the image a number of times using TCastleImageTransform.RepeatImage.

• control the image size by referring to “what size it should pretend to have” instead of only by applying a float scale multiplied by the original size, see TCastleImageTransform.Size.

These features were possible previously too (by using image inside TCastleScene) but now they are more comfortable, exposed as more natural properties.

We’re moving further with Vampyre Imaging Library integration, to have more features related to image loading and at the same time less code to maintain in Castle Game Engine.

1. We now use Vampyre always, by default, with both FPC and Delphi. This makes our code simpler and more consistent.

   Note: our castle_base.lpk depends on Vampyre Lazarus packages, to use Vampyre packages in a clean (Lazarus) way, using all compilation configuration done by Vampyre authors. This is important if you compile using Lazarus (though project LPI file, that in turn uses LPK packages).

   After updating to latest CGE, be sure to use “Preferences -> FPC and Lazarus -> Register Lazarus Packages” in CGE editor,or just open in Lazarus and compile these 2 packages:

   src/vampyre_imaginglib/src/Packages/VampyreImaginePackage.lpk
   src/vampyre_imaginglib/src/Packages/VampyreImaginePackageExt.lpk
   

   This doesn’t matter if you compile using Delphi, or using CGE build tool that executes FPC directly (passing paths to CGE and Vampyre, without relying on Lazarus LPI/LPK information).

2. We now rely on Vampyre for loading and saving of BMP, PPM and RGBE image formats.

   I completely removed the old code for handling these image formats (without Vampyre) in CGE. This means less code in CGE which makes me happy 🙂 Moreover, Vampyre brings some extra features: handles RLE-compressed BMP files, can save RGBE files with compression.

3. We synchronized with latest Vampyre Imaging Library code, and reenabled JP2 and TIFF saving using Vampyre. We check TSingleImage.SaveToStream to know if it’s successful.

4. For now, you can still disable Vampyre usage, by removing {$define USE_VAMPYRE_IMAGING} from our src/common_includes/castleconf.inc.

   If you have a good reason to do this (disable Vampyre), please tell us (on forum or Discord) — we want to know about it. In the future, Vampyre may be just non-optional dependency of CGE, and we’ll integrate more and just use Vampyre as our image container in memory (right now we copy data between Vampyre and CGE TCastleImage, TGPUCompressedImage, instead of referencing it).

Documentation is the theme of recent news, as I work intensively on updating our manual 🙂

1. Added section about TCastleBehavior.

2. Improved X3D example to show building a mesh.

3. Update to user interface page is in progress, using an updated version of examples/component_gallery. It is not yet finished, but I feel it is already better.

4. Documentation about AAB (Android App Bundle) added, documentation about Android signing updated.

5. Logging docs updated.

6. Some outdated pages have been just removed, as they were outdated and described stuff of low importance (like TCastleOnScreenMenu, that is nowadays easier to do as just TCastleVerticalGroup with a number of buttons). Also the order of pages have been reworked, to put most important things at the top.

I implemented TCastleTransformReference to reference another TCastleTransform within the same viewport. This is an efficient way to use the same TCastleTransform multiple times, which is great for memory and speed. Consider using this when you need a lot of copies of something, e.g. lots of trees or grass patches.

All the TCastleTransformReference instances share the same state with the original, e.g. they will play the same animation. In practice, you will probably most often use this with static (not animated) models.

The detailed usage documentation is already part of the manual, at the bottom of “Tutorial: Designing a 3D world” page.

Note: from code, you can even just place the same TCastleTransform instance multiple times within the same viewport using code, even without TCastleTransformReference. This is documented too.

If you haven’t yet compiled any application for Android, now is the best time!

1. First of all, our documentation how to setup Android tools and build your first Android application is now much shorter and easier to follow. It properly documents now:

   • The easiest approach to installing Android SDK. I removed a lot of outdated steps that you don’t have to do.

   • It clearly advises fpcupdeluxe and explains how to use it.

   • It documents using CGE editor to switch platforms, build + install + run on Android.

2. Android building now works with latest Java 17. No need for downgrading to older Java, because older Gradle wrapper couldn’t handle it.

3. The default Android target platform is now 31. Previously we targeted platform 29. Due to Google Play requirements we had to upgrade to 30, and we decided to take it one step further to 31. (required by latest androidx.core).