Cthulhu fhtagn! This news post contains a collection of Cthulhu renderings I posted in recent years — it turns out I post quite a lot of Cthulhu stuff. Usually, when I don’t have a perfect screenshot to illustrate a news post, I just pick something pretty rendered using our engine — it turns out that often this “something pretty” is Cthulhu for me 🙂

Completely unrelated to the screenshots, here are a few new features we’ve added to the engine lately. And if you like what we do please support us on Patreon!

1. Our command-line build tool has a new option unused-data to perform a crude analysis of what data in your project is possibly unused.

   This means that some files inside the data subdirectory of the project have been detected as unused, so they don’t seem to be loaded by code or required by other data files. This means that keeping them inside the data subdirectory is possibly needless. Files inside the data subdirectory (that are not excluded by the CastleEngineManifest.xml rules) are automatically packaged with your application (for example, if you create an Android APK, or a package to ZIP for desktop platforms). If you have some unnecessary files there, then possibly you distribute more than you need, and you could have a smaller application.

   To test this use command-line to enter your project and just execute castle-engine unused-data.

   I emphasize that this is crude analysis. It uses some assumptions that may be wrong, definitely are sometimes wrong, and they may result in errors in both ways (some unnecessary files may be undetected; some detected files may actually be used). Don’t trust this analysis without your own judgement. But it may be useful in some clear cases, when there are easy and obvious ways to optimized your applications size. If some files are indeed unused, consider moving them outside of data (e.g. to subdirectory like data-source) or excluding packaging them by CastleEngineManifest.xml rules, or even removing them (you have them in version control anyway, right?).

   This mechanism allowed to make CGE download size smaller by 30 MB recently 🙂 So yes, it is practically useful (albeit not magic, savings are not that big).

2. The Priority of a sound can be now configured on TCastleSoundSource and TCastlePlayingSound (in addition to being configurable on TCastleSound, as before). See the TCastleSoundSource.Priority, TCastlePlayingSound.Priority, TCastleSound.Priority properties. They are all multiplied, just like Volume and Pitch — see manual about sound for usage description. Thanks go to Dennis Spreen for implementing this!

3. We have extended TCastleComponentFactory.ComponentLoad with a powerful optional mechanism: if you pass an additional instance of any class descending from TPersistent, we will set the published fields of that instance to refer to the new components created by TCastleComponentFactory.ComponentLoad.

   The mechanism is really comfortable to use. It solves a common need when using TCastleComponentFactory.ComponentLoad: you want to access from code a subset of new components.

   See for example how rockets are instantiated in our space shooter example. Consult also API docs of TCastleComponentFactory.ComponentLoad, they discuss everything with example snippets.

4. We have added ApplicationProperties.FreeDelayed utility. As the name implies, it schedules removing a component soon. It’s a bit similar to TCastleTransform.RemoveDelayed with FreeItem=true (that also got important fix by the way), but using ApplicationProperties.FreeDelayed is more straightforward in some cases: you don’t need another TCastleTransform to schedule freeing.

   Example usage is in space_shooter demo.

5. We expose a few properties to determine the quality of generated spheres, cylinders, cones:

   • TCastleSphere.Stacks
   • TCastleSphere.Slices
   • TCastleCylinder.Slices
   • TCastleCone.Stacks
   • TCastleCone.Slices

   Note that there’s no TCastleCylinder.Stacks — cylinder doesn’t need it, it always has one stack.

6. “Copy URL” command is now available in the editor context menu when you right-click on a file in the bottom panel.

   Nice to easily paste the URL into Pascal code to load.

   For files within data, it will use a protocol castle-data:/. Like castle-data:/gamestatemenu.castle-user-interface, castle-data:/level.gltf.

   For files outside of the data subdirectory, it will be reguar file:/... URL with absolute path on your system. Like file:///home/michalis/sources/castle-engine/lynch/demo-images/lynch_screen_1.png. This is naturally less useful: you should not place hardcoded paths in your code, as they work only on your system.

7. Slowly but surely we modernize our joysticks (gamepad) API. We have now separate TJoystick.LeftAxis and TJoystick.RightAxis. Test how they work in examples/deprecated_to_upgrade/joystick demo. See our roadmap for joystick API plans.