Tomorrow (Sunday, 22 November) at 13:30 there will be a presentation about Castle Game Engine at MiniDebConf Online #2 (see schedule). Come and listen 🙂

Here’s a 37-teaser I made for it: https://michalis.xyz/nextcloud/s/mRjBQEmW429NB8Q.

And in the meantime, watch pretty videos from Enes Geven — upcoming mobile game, using CGE:

1. I’ll give a presentation about Castle Game Engine at MiniDebConf Online #2 “Gaming Edition”, an online Debian conference devoted to game development. The presentation is already recorded :), and I hope it is good. I focus on Castle Game Engine editor. I create a 3D level in Blender and put it in a 3D CGE game, I do some code editing, and I build a 2D game for Android too — all in 38 minutes. I hope it will serve as a nice introduction to CGE, from scratch, going over the core engine/editor features and showing how to use it in practice.

   Afterwards there will be ~7 minutes for live questions.

   My presentation starts on Sunday, 22 November, 13:30 UTC, see schedule.

   You’re most welcome to attend 🙂

2. As a teaser, see the presentation about CGE + view3dscene for Web3D 2020 that was this Wednesday. This is 21 minutes, and focuses on graphic features we offer in view3dscene (I mention there CGE, but don’t go into details how to use it from developer perspective).

3. I implemented some additional X3D nodes to describe 2D geometry: Disk2D, Polyline2D, Polypoint2D, TriangleSet2D.

4. We no longer depend on libGLU, even on desktops where we use OpenGL (not mobile OpenGLES) by default. This was a long-time coming move. The remaining usage of libGLU in CGE eliminated:

   1. You can use TCastleScene with X3D geometric primitives (like TSphereNode, TDisk2DNode and more) to render “quadrics” (previously, 2 old CGE examples used libGLU for this).

   2. We have own routine to generate mipmaps for ancient GPUs (on modern GPUs, we use glGenerateMipmaps since a long time of course).

I’m happy to be swamped with things to announce about the engine! 🙂 So, after previous announcements this weekend, one more list of new stuff 🙂

• We have an extensive documentation how blending (partial-transparency) works. While the engine tries its best, it’s not always possible to make blending automatically “just work”. This documentation should help you understand what and why you can tweak.

• We have important fixes for edge-cases when handling MessageOK, progress bars or TCastleViewport.AvoidNavigationCollisions by Andrzej Kilijański.

  Moreover, Andrzej submitted a big PR that introduces a huge upgrade to handling sprite sheets in CGE. It is under review now (i.e., waiting for Michalis 🙂 ), stay tuned!

• We have renamed mouse button names/types to buttonXxx and TCastleMouseButton. This way they do not conflict with LCL. The old names mbXxx still remain, but are now deprecated, and we will be able to remove them in later CGE (7.2?). Thanks to Eugene Loza!

• In the editor, we now expose “Scene (Optimal Blending for 2D Models)”, which is just TCastleScene with Setup2D performed.

  It is better than the now-deprecated TCastle2DScene. Dealing with TCastle2DScene was sometimes uncomfortable: when you wanted to derive descendants and mix 2D and 3D models in your game. And existence of TCastle2DScene was not really justified: in the end, it is a completely trivial variant of TCastleScene, the Setup2D just sets "RenderOptions.BlendingSort := bs2D" (really, that’s it! nothing more needed for 2D scene).

• I added an example of using CastleXMLUtils unit in examples/short_api_samples/xml_utils/.

• Our Jenkins (see wiki docs) is now integrated with GitHub, and it sets “build status” on GitHub. This means we can quickly recognize failing commits, branches, PRs etc.

  ( It’s not always the fault of the branch/PR author, so don’t worry — I’m diagnosing all fails and will let you know if this is something you need to take care in your PR. )

With many thanks to Kagamma (Trung Le), we now support screen-space reflections in Castle Game Engine! It is a cool technique that generates reflections completely in screen-space, using color and depth buffer information to look for the reflected color.

It is trivially easy to use, just toggle TCastleViewport.ScreenSpaceReflections boolean. As we don’t have material information available in screen space (yet, because we do not have deferred rendering), so everything in the whole viewport is reflective now. That said, the effect is extra pretty and just works “out of the box” on various scenes, so I’m sure it will find it’s use even in current “everything is reflective” form 🙂 You can configure glossiness for the entire viewport by TCastleViewport.ScreenSpaceReflectionsSurfaceGlossiness (in 0..1 range, by default 0.5).

You can also test it with view3dscene, just toggle menu item View -> Screen Effects -> Screen Space Reflections.

Our screeen effects GLSL API also got a small upgrade by the way. We now expose screenf_01_position varying and functions screenf_01_get_color(...) and screenf_01_get_depth(...) to quickly query the screen.

More upgrades to screen effects are coming. I would like to wrap screen effects in components, designable in CGE editor!

You can now configure RenderOptions of every TCastleScene. Simply access it like MyScene.RenderOptions.OcclusionQuery := true. It is available also in the editor, as you can see on the screenshots 🙂 All the features are documented in TCastleRenderOptions class, in particular you can:

• Configure lighting, textures

• Configure blending, blending equations and sorting

• Configure occlusion query (powerful method of optimization in some cases, when many shapes are typically occluded by others and camera moves slowly)

• Easy wireframe, solid wireframe rendering (note: not yet working on mobile, i.e. OpenGLES; let us know if this is important to you!)

• Configure point and line sizes

This mechanism replaces (and deprecates) previous Scene.Attributes.

As part of this rework, we also deprecate or even remove some stuff that had very low usage.

In particular, Scene.Attributes.OnRadianceTransfer and Scene.Attributes.OnVertexColor are now removed. They were causing quite a complication throughout the renderer, and were never ready for “production” usage due to being inherently slow (doing per-vertex work on CPU). Their effect can still be achieved by a simple utility that maintains the X3D Color node, updating it every frame. So if you need this (and can accept the slowness of per-vertex processing on CPU) you can still do it, our sceneutilities.pas example unit demonstrates this in practice, and is used by dynamic_ambient_occlusion and radiance_transfer examples. Feel free to reuse SceneUtilities in your projects in you need an upgrade path from the OnVertexColor and OnRadianceTransfer.

1. With great thanks to Eugene Loza, we now have a working Undo system for Castle Game Engine Editor!

   • You can undo / redo any action.
   • The undo / redo menu items shows the previous/next operation description.
   • History is trimmed smartly based on approximate size in memory.
   • See the pull request for details.
   • Just try it! It’s bound to Ctrl + Alt + Z shortcut now.

   We want to work on it some more before release: correctly handle transformation changes by gizmos, correctly handle record changes (like TCastleColor) by dialogs (right now these actions will be glued to the next undo; so the design remains correct, you just don’t have the “granularity” of undoing/redoing that you may expect). I’d also like to experiment whether we can assign it to Ctrl + Z when OI is not focused (right now undo is bound to Ctrl + Alt + Z to avoid conflicts).

2. You can now edit names of components in the editor’s tree view (click or press F2). Also thanks to Eugene Loza!

3. Right-clicking in hierarchy now exposes a context menu with some useful functions, in particular you can add new component as a child of selected. The credit for this goes also to Eugene Loza – thank you!

4. Thanks to Andrzej Kilijański, we have a “Clear” button to clear currently displayed warnings.

5. Fixed deleting a component (deletion should be recursive, previously the children were hidden but remained in memory and prevented from reusing the same Name).

6. The shell list view is better, with directories.

7. The dialog to open URLs (e.g. for TCastleScene.URL) by default starts in project’s data directory, to make it natural to choose files there.

Escape from the Universe is now available in Japan for Nintendo Switch!

This is a Japanese version of our English (for Americas and Europe) version.

As some of you know, I’m wearing two hats — I’m the author of Castle Game Engine and I’m the CTO of Cat-astrophe Games, an indie game company where we plan to achieve great things with our technical skills, and also cats. Escape from the Universe was developed by Cat-astrophe Games some time ago, ported to Nintendo Switch, and now it has been translated to Japanese — all 100% in Castle Game Engine! The Japanese localization and a ton of testing was done by Worker Bee Inc.

The whole approach to localization is 100% open-source and part of CGE: see the manual section Localization (translation) using CastleLocalizationGetText. I hope this shows that our localization support is fully capable of handling a large, professional project, done in cooperation by 2 companies.

If you have Nintendo Switch, you have now no excuse not to play this game 🙂

Here goes an unorganized list of engine features and fixes done lately 🙂 Enjoy, and see if you can find something for yourself in this menu 🙂

1. You can now increase the number of allowed lights per shape using Scene.RenderOptions.MaxLightsPerShape. view3dscene has a menu item to experiment with it (“View -> Max Lights Per Shape…”). A test model is in demo-models: gltf/multiple_animated_lights.

2. view3dscene allows to test multiple simultaneous animations. Just select the checkbox Enable Multiple Simultaneous Animations in the animations panel (Ctrl + A), and now you start/stop the animations independently. The animations are controlled using TTimeSensorNode.Start and TTimeSensorNode.Stop, just like in the example simultaneous_animations_one_scene.

3. Thanks to Andrzej Kilijański, changing TLevel.Player after the level is loaded is now fixed. This fixes various applications relying on it, like the old “The Castle” game. It is demonstrated by fps_game example, just press F1 to recreate player. It works reliably in all cases, with 1st and 3rd-person navigation.

4. In code you can iterate using for .. in over TCastleTransform and TCastleUserInterface children.

5. Fixed opening Lazarus when it is installed from Debian packages (lazarus-ide binary), thanks to Eugene Loza.

6. TCastleViewport.PositionToRay utility. This allows to get a 3D ray from a 2D viewport position and use this ray to e.g. perform collisions with the world geometry to determine anything you like.

7. TUIContainer.SaveScreenRgba method allows to grab a screenshot to RGBA image. An example is in examples/short_api_samples/save_screen_rgba/save_screen_rgba.lpr.

8. Fixed glTF look in case of no explicit material.

9. Fixed gravity when reading glTF camera (in glTF, gravity is always +Y).

10. Fixed TCastleViewport.Transparent to ignore X3D Background nodes (it was always documented like this, but got accidentally broken ~year ago).

A number of improvements and fixes to creatures and items defined by resource.xml were done. Also, our example animations/resource_animations was completely redone, and example fps_game now has a proper gun for shooting 🙂

1. Weapons defined by CastleItems support reloading, with reload animation, ammo capacity and currently loaded ammo. Demo in fps_game .

2. Auto-determine pool of animations. For animations not defined by castle-anim-frames/MD3, using pool is most advised, to get performance and animation blending.

3. Introduced orientation=”..” to resource.xml options. Allows to mix models in glTF, castle-anim-frames and any other formats easily within one project.

4. resource_animations example is now:

   • designed using CGE editor.
   • it is much simpler, spawning creature “by the book” (using CreateCreature) instead of demonstrating its animations in hacky way.
   • clearly advises the approach “single glTF file” instead of setups with x3d/castle-anim-frames.

5. The ShootingEye from fps_game with no/poor animations is replaced with a pretty plasma gun from OpenGameArt. The model has been retouched by Michalis and exports nicely to glTF.

6. Deprecated using different URLs for different animations. See how to define animations in resource.xml. Different file per animation doesn’t match the advised usage (one glTF file with all animations), is not efficient (the same file will be switched back-and-forth to show various animation states, if reused by multiple creatures) and makes animation blending impossible.

7. Fixed blinking of animation from castle-anim-frames when defined in resource.xml

8. Fixed changing bounding sphere radius for resources loaded from resource.xml

Our online conversion tool was updated to include all the latest improvements done in Castle Game Engine in the last months.

In particular, you can now use it to convert glTF 2.0 files to X3D (in classic or XML encoding) and the output will automatically use X3D PhysicalMaterial nodes to express glTF PBR materials.

In general our approach to convert glTF -> X3D is documented here. So if you’re unsure how given glTF construction is translated to X3D, this page probably has an answer 🙂

You can open the resulting X3D files in view3dscene or any other engine tool.

Reminder: you can also use view3dscene to do the same conversion (interactively or in batch mode). Use “File -> Save As X3D…” menu item, or command-line as documented here. We provide the online tool just as a convenience for people who don’t want to install view3dscene.