This is a cool new feature that allows you to use our editor in a bit non-standard way. Use the new menu item “Data -> Export Viewport to X3D, STL” to export the contents of the TCastleViewport to X3D or STL file.

To be clear, the main purpose of our editor remains to save the design to a Castle Game Engine-specific format (*.castle-user-interface, which is a JSON serialization of engine components, that can be later read back using CastleComponentSerialize routines). But this new feature allows to use our editor for other purposes. You can design a 3D or 2D world, export it to X3D or STL, and use it with a plethora of other 3D software. For example, you can:

• Open the X3D file in other X3D viewers, including viewers that can render X3D in a browser. Here’s a non-exhaustive list of software that can “consume” X3D files:
  • X_ITE that can render X3D in a web browser,
  • X3DOM, again able to render X3D in a web browser,
  • FreeWRL,
  • Our Castle Model Viewer,
  • Our Castle Model Viewer Mobile,
  • see X3D Resources for more tools. Many of them are free and/or open-source.
• Import the resulting X3D or STL files into other 3D software, like Blender.

Try it out! Just download the engine, create a new project (or open one of the examples) and use “Data -> Export Viewport to X3D, STL” to see what happens. Try out the new project template like “3D FPS Game”. Add there more engine components (see our documentation and in particular overview of components useful in the viewport) and have fun 🙂

In case of X3D, remember that:

1. The resulting file will refer to the resources (like models loaded in TCastleScene or textures) using relative paths. So you should keep the directory structure of the exported files intact, or adjust the paths in the X3D file manually.

2. The exported X3D files may use some X3D extensions, specific to our engine. You can just remove them as necessary to make the models compatible with other X3D browsers.

3. While you can load the resulting X3D back inside the engine editor, this will be just a single component TCastleScene, not all the components you exported. Solution: If you want to use CGE editor for authoring X3D or other model formats, just keep the original CGE editor files (.castle-user-interface) around, as the “source” version of your 3D / 2D world and export it to X3D as many times as you wish.

All the features supported by the export are listed below:

• It can export to any format supported by the engine, which means X3D (classic or XML) and STL right now. We plan to support also saving to glTF.

• Exported file by default is saved as export.x3d or export.stl in the data directory of your project. This is comfortable, just double-click on it to open it in Castle Model Viewer.

• TCastleScene is exported (as X3D Inline node wrapped in the appropriate Transform node).

• Transformation hierarchy (TCastleTransform) is naturally exported as Transform nodes hierarchy.

• All the lights. E.g. TCastlePointLight is exported as X3D PointLight node.

• All the primitives: TCastleBox, TCastleSphere, TCastleCone, TCastleCylinder are exported as X3D Box, Sphere, Cone, Cylinder nodes.

• Text is exported (TCastleText to X3D Text with FontStyle).

• Cameras (TCastleCamera) are exported as X3D Viewpoint or OrthoViewpoint nodes, depending on the projection type.

• Background (TCastleBackground) is exported as X3D Background node.

• Our navigation components, like TCastleWalkNavigation and TCastleExamineNavigation result in an X3D NavigationInfo node. The X3D node offers a subset of functionality from our engine components.

• Fog (TCastleFog) is exported as X3D Fog node.

• Tiled maps, that is TCastleTiledMap, is exported as a collection of X3D nodes that express given map.

• Terrain (TCastleTerrain, see our demo examples/terrain) is exported.

• Images in the viewport (TCastleImageTransform) are exported.

An additional use-case of this feature is to debug what some engine routines are doing.

• While in some cases we create X3D nodes during the export (e.g. for viewpoints and navigation info, in which case we have somewhat similar but far from identical functionality offered by our components like TCastleCamera and TCastleWalkNavigation)…

• …but in other cases the export just “reveals” the actual nodes used to to render given things (this is the case with e.g. lights, primitives, fog and background).

Have fun with Castle Game Engine and X3D!

Announcing a few more important fixes from the last ~month. As usual, remember that all the bugfixes are available immediately in the latest download. And if you like what we do, we appreciate your support on Patreon!

Bugfixes worth mentioning:

1. Fixed scaling TCastleMeshCollider.

   Scaling the TCastleScene by just setting the TCastleTransform.Scale, like MyScene.Scale := Vector3(100, 100,100) will now affect the physics as it should. The associated TCastleMeshCollider will behave properly, following the scale change. You can test this by changing scale at design-time (in editor) or run-time (from Pascal code) of course.

   I added an interactive demo of this in examples/physics/physics_test_scaled_mesh_collider.

2. Saving of STL files from our tools (like Castle Model Viewer, Castle Model Converter) now accounts correctly for X3D shapes with CW (clock-wise) ordering of vertexes. This is important, as STL files must have CCW (counter-clock-wise) ordering of vertexes. Thanks to Jan Adamec!

3. Water shader important fix (for some GPUs). Affects water in our terrain example, lynch gamejam project, water in demo-models.

4. (Before 7.0-alpha.3 release): Fixed Delphi crash at exit in -dRELEASE.

5. (Before 7.0-alpha.3 release): Fixed editor occasional crash when closing a view with camera preview open (testcase: press Ctrl+W right after selecting the camera in viewport).

6. (Before 7.0-alpha.3 release): Fixed window resolution on Retina screens. We now behave properly on macOS Retina screens, and we render with full resolution (result is “crisp”, not artificially upscaled by macOS), and dragging window between monitors behaves OK too. Big thanks to Jan Adamec!

7. (Before 7.0-alpha.3 release): Fixed clipboard on macOS (with Cocoa backend of TCastleWindow). Cut/copy/paste work as they should. Again thanks to Jan Adamec. They also react to Command + C / X / V, not Control + C / X / V.

8. (This was a hotfix at 7.0-alpha.3 release, initial upload had a bug but was quickly replaced with good one): Fixed “Configure Delphi to use engine” menu item (from our Delphi integration) to handle gracefully paths with spaces.

Sorry for the long news title and even longer news post 🙂 This is a very important bugfix and at the same time it couldn’t (reasonably) have been done in 100% backward-compatible way. We tried to explain everything below. If in doubt how to upgrade your projects (in case things will look different), don’t hesitate to contact us by forum, Discord or any other means, we’ll help! The core of the change happened in this commit on August 1st (2024), well before 7.0-alpha.3 release so it affects everyone who upgrades to engine after that date with a project created before that date.

What was fixed? A few properties of the TCastlePointLight, TCastleSpotLight and TCastleDirectionalLight had their default values applied incorrectly. That is, the default values were correct, but their effect was wrong. In particular, TCastlePointLight.Attenuation and TCastleSpotLight.Attenuation were not applied correctly.

The most visible consequence of the bug (now fixed): The default attenuation of positional lights (TCastlePointLight and TCastleSpotLight components), equal to 0 0 1 (realistic intensity falloff, following the inverse square law) was not applied. In effect, default lights didn’t have any “attenuation”, which means they were bright even on objects far away from the light position (very unrealistic). The behavior was equivalent to attenuation 0 0 0, although the property value was 0 0 1.

In short, what you may observe after the fix if you open a project created in older engine: Some of lights you have set up in your viewport (using TCastlePointLight and TCastleSpotLight) may look different, in effect your world may look darker.

Why the change is good? New lights behave in much more realistic way. It was obvious to me after doing the fix how many of our previous examples have been unrealistically bright, different than how other 3D software (like Blender or other game engines) treats positional light sources. Previous light look was incorrect, not following the attenuation value (0 0 1 behaved like 0 0 0) and not realistic (no light falloff is not realistic). The new behavior is correct, and much prettier by default.

Default intensity also changes: To account for the fact that new positional lights ((TCastlePointLight and TCastleSpotLight) are much quicker fading to darkness, we also changed their default Intensity ((TCastlePointLight.Intensity and TCastleSpotLight.Intensity) from 1 to 100. Previous default, 1, was too small to be useful with the new attenuation.

We also adjusted the default light setup when adding a new “Viewport (3D)” component in the editor. To make it work reasonably out of the box, useful for demos etc.

We are now more consistent with other applications. Specifically:

• Now, after the fixes, our default point light is quite like Blender’s default light. Comparing screenshots, it is obvious now they both have ~inverse square falloff, out of the box. Testing on a plane with boxes setup at 10 units around center — lighting works similar, see the screenshot in this post. This is great.

• Unity by default adds a directional light to the a new 3D scene, which naturally behaves differently than the point light (attenuation doesn’t matter, and much smaller intensity is reasonable). But if you add point light in Unity, with intensity 100, at height = 3, it behaves similarly to us — again, this is good consistency.

• We are also consistent with glTF lights, with inverse square falloff (which was why I chosen attenuation = 0 0 1 as a default long time ago). See glTF/extensions/2.0/Khronos/KHR_lights_punctual/README.md, “Within the range of the light, attenuation should follow the inverse square law as closely as possible”.

What to do to in your old projects to adjust to the new lighting?

This fix is necessarily breaking compatibility in some cases. If you relied on the fact that your positional lights by default did not have attenuation (because effectively attenuation 0 0 1 was treated like 0 0 0) then once you upgrade to the new engine version, you will notice that everything is darker.

1. The quickest, painless solution is to just set the Attenuation of the positional (point, spot) lights from 0 0 1 to 0 0 0. This disables attenuation. You can also readjust the Intensity from 100 back to 1 (without any attenuation, much smaller intensity values are reasonable).

   This is the simplest way to get back exactly the same behavior as before.

2. The alternative approach, that will take more time, but is also more recommended, is to keep the realistic attenuation (0 0 1) and adjust your light setup. We did this in all CGE examples.

   You can use more lights. You can add an additional directional light to make everything at least slightly brighter. It may even make sense to add 2 directional lights, with different directions in X and Z (but similar in Y) to simulate the daylight best. There’s no straightforward advice here, sorry — you have to experiment and decide what you want to be bright / dark, and how to achieve it using realistic lighting.

   You can also bump intensity of existing point/spot lights. It was automatically upgraded from 1 to 100, but other values (like 2) have not been adjusted. Consider increasing the intensity yourself.

Note: We looked into adding some hack to preserve the look of older setups, to keep compatibility. But it was causing more pain and complications. The problem of the old approach was not “wrong default property value” but “default property value was not properly applied”. We tried two “hacks for compatibility”, to make old lights look like they did, but they seemed both dangerous (making code really ugly to maintain) and confusing to users (since they had to essentially “activate a buggy behavior” under certain conditions). So, we decided to avoid hacks, and break compatibility, to just render stuff 100% correctly from now on.

What does not change, to be clear:

• If you have customized the attenuation of your lights previously, even very slightly (e.g. to 0 0 1.1) then it was applied OK. The bug only affected you if you left attenuation untouched, exact 0 0 1.

• Nothing changes in the way how attenuation equation matters (see X3D spec about how attenuation should be applied).

• The change doesn’t concern X3D nodes for lights (like TPointLightNode) and so nothing changes for lights you set up e.g. in Blender and exported to glTF or X3D. These look the same as before, and everything was and is correct in their case.

• The default TCastleDirectionalLight.Intensity didn’t change, it is still 1.

Things are better 🙂I (Michalis) feared this change, admittedly — as I realize this is a significant compatibility break. But after testing, and adjusting all our examples to follow it (honor attenuation = 0 0 1, physical)… everything looks so much better.

I hope you enjoy new correct and realistic lighting out-of-the-box!

Our news have been quiet in the last 2 weeks, and in effect we have a backlog of many neat new improvements to announce. So stay tuned, and be prepared for more noise than usual from our blog in the upcoming days 🙂

First of all, our presentation from Embarcadero Dev Days of Summer 2024 is available to watch on YouTube:

If you missed it (it was originally played on August 21st), we recommend you check it out! This is our latest and right now the most up-to-date presentation on how to make a new game using Castle Game Engine.

There’s an associated demo project: Pirate shooting balls at skeletons, using physics. Yeah, as the name implies, it is the most impressive and creative game ever made in 2024! 🙂

You can also browse the slides.

It makes sense for both FPC and Delphi users, naturally — as our engine supports both FPC and Delphi, and everything we show really applies to both. For Pascal editing you can use any IDE, including Delphi, Lazarus and VS Code.

We’re proud to release new version 5.2.0 of Castle Model Viewer and Castle Model Converter. They are distributed together, just head on to Castle Model Viewer downloads to get them both.

Highlights of this release (since 5.0.0):

• Engine upgraded to the finally released Castle Game Engine 7.0-alpha.3 version. The previous version was based on an engine effectively somewhere between 7.0-alpha.2 and 7.0-alpha.3.

• Reworked the shadow maps logic – much simpler now, using the shadows field at light node doesn’t process the scene graph “under the hood” anymore. Some difficult / buggy situations are thus solved and we are ready for future shadow maps improvements.

  Out of necessity, we also had to remove (already deprecated) support for using GeneratedShadowMap node in the Appearance.texture list. This was too convoluted to support (because shadow map does not affect the shape look like other textures on Appearance.texture, the shadow map effect is applied at the specific light source query). You can now only use GeneratedShadowMap inside the defaultShadwMap field of the light node.

• Float-based images support. In case of Castle Model Viewer, this means that loading 16-bit PNG images of float-based KTX images is useful for shader effects, as shaders will get full float values from the image. This extra precision sometimes matters a lot, e.g. if you use a texture for a heightmap in the shader.

• Cycle through viewpoints when you use Page Up, Page Down or the corresponding menu items.

• Fixed display when usign multiple viewports (Display -> 2 Horizontal Viewports, Display -> 4 Viewports).

Have fun with 3D! And consider supporting us on Patreon!

We are proud to present a big new release of Castle Game Engine, with lots of new features, improvements and fixes. The new engine version is available for download now.

The highlights of the release are below. For more details, see the full release notes. The number of this release, “7.0-alpha.3”, is a signal that we’re on our road to the big 7.0 release (see the roadmap and plans and timeline).

This release is dedicated to the late Eugene Loza. I miss you, dear friend.

The most important highlights of this release are:

• Physics. New components for colliders and rigid bodies, ability to run physics simulation in the editor, joints, layers, forces.

• Many rendering improvements: Correct and automatic blending, both batching and occlusion culling easier to use and more powerful, fully modern rendering on new GPUs, better support for ancient systems with old GPUs.

• Also OpenGLES (Android, iOS, Nintendo Switch) rendering supports now almost all desktop rendering features: shadow volumes, shadow maps, 3D textures, occlusion query, anisotropic filtering, meshes with 32-bit indexes.

• Shadows using shadow volumes are trivial to activate. Work is under way to expose shadow maps through a trivial property as well.

• Visual Studio Code integration. Our own VS Code “Castle Game Engine” extension with code completion and syntax highlighting for all Pascal code and easy building / running / debugging of Castle Game Engine projects.

• Delphi integration improvements: TCastleControl available for VCL and FMX applications, Delphi packages with IDE support, Delphi Linux support and more.

• Support for Tiled maps with a new component that is comfortable to use and efficient to render.

• User Interface improvements: better default font, UI batching, image regions and 9-slices borders visually configurable, mask component.

• Many editor UX improvements: modern color picker, unified tools to edit UI and transformations, wireframe view, “Change Class” menu action, Sketchfab Importer, finding components by name, multi-selection.

• Improvements to views (formerly states): better API, automatic initialization of the published fields, opening the project greets you with UX to manage views.

• Mobile improvements: lots of Android services improvements, Castle Model Viewer Mobile and more Android applications released on Google Play, lots of general Android and iOS fixes and improvements to make porting your games to mobile trivial, safe borders.

• Loading and saving: cache, MD3 improvements, X3D 4.0 improvements, custom model formats registration, STL saving.

• Inspector (press F8 / 3 fingers in a debug build of any project) improvements: tweaking boolean properties at run-time, hot-reloading at run-time to iterate on your graphics.

• Float-based images (e.g. for precise terrains) full support at loading and rendering (formats: 16-bit PNG, float-based KTX, 16/32-bit TIFFs).

• A lot of new documentation and examples. We in particular recommend 2 new tutorial articles introducing most important engine concepts: Bad way to play chess, aka 3D physics fun.

Support us

We appreciate your support on Patreon. There are also other ways to support us and if you’re a company, we’re open to cooperation (write to [email protected]). By 2024, Michalis, the lead engine developer, spent most of his life on the engine and doesn’t plan to stop. Moreover, Michalis now works on the engine full-time counting only on your support. So anything you can give is really appreciated!

Spread the word!

We don’t do much marketing. Because we suck at marketing. Help us — spread the word about this new release! Post about it anywhere you can. Talk about it in your communities — online or in the Real World. Tell your family about it (they really want to know). Reuse this news post and screenshots freely.

Have fun everyone and thank you for using the engine.

Enjoy a new example in our engine: examples/space_shooter. Features:

• Space ship (click anywhere on the screen, or use arrows, to move it).

• Background (drawn efficiently as one quad, with texture repeating to infinity).

• Rockets (fired by the player’s cannons). Each rocker has a collider and can detect when it hit an enemy. Rocket can be “armed” (destroys enemies) or “not” (just a ball that bounces off enemies).

• Enemies, played by the Mighty Rotating Rocks! They just move slowly towards the player. You can shoot them to destroy.

Technically:

• The player is just a TCastleScene inside a TCastleViewport, with input events handled in TViewMain.

• Using TCastleComponentFactory to create rockets and rocks. Each of them is defined by a reusable design.

• Using behaviors to define various behaviors of rocks and rockets.

• Using physics to handle collisions between rockets and rocks.

• Special component TTilingBackground to draw a background that (seems to) repeat to infinity. This is a reworked version of an old example background_tiling.

1. Next week, the Dev Days of Summer 2024 organized by Embarcadero starts!

   As you can guess, I’m in :), and you can watch the latest and greatest talk presenting Castle Game Engine on August 21th. The talk should make sense for all engine users, new and old — as usual I start with general engine overview, but then I go crazy and just develop a complete working game, live. I show using the editor and Pascal code (Delphi, though everything is really applicable just the same for FPC, and resulting project is compatible with both FPC and Delphi). I go through views, scenes, physics, behaviors, component factory, timers and more.

   I have finished recording the talk just this week (here’s a sneak preview of the project). During and after the talk I will of course be also available for live Q & A.

2. You can also catch me live, in person at FPC and Lazarus event in Cologne (Köln), Germany in October 2024. The event is on 10-11th October, my talk is scheduled for Friday, 11th October.

   In my talk I want to cover everything, from the game idea, through implementation using our engine, to the final deployment in Steam and Android (Google Play). I have a very intensive plan 🙂

   If you’re interested and have questions, please use the contact information at the bottom of this page. Detlef Overbeek will answer everything and help you get there.

3. Finally (with a good timing, just for those who cannot wait to see me 🙂 ) — my presentation from ITDevCon last year was recently published:

Be seeing you!

Tl;dr of this: download the latest Castle Game Engine and everything will be perfect! (or, at least: better!)

Remember that we follow continuous integration and delivery (right now using GitHub Actions) to continually release new version of the engine, 7.0-alpha.snapshot, after every commit that passes a number of automatic tests. So everything we say in these news posts is available right now in our downloads.

Recent important bugfixes:

1. Fixed frustum culling of shapes in scaled scenes.

   If you had TCastleScene with some scale, and TCastleSceneCore.PreciseCollisions, and observed disappearing shapes when rotating the camera — this is fixed now.

2. Fixed gizmos (lights, cameras) size (in editor) when they are within a scaled parent. By accident, previously the size was unreliable, could be too large for non-first child.

3. Fixed renaming components in editor on Linux / FreeBSD.

   We had a critical issue for quite some time in our editor on Linux / FreeBSD (all platforms using GTK2): occasionally, renaming components using the hierarchy tree (clicking there or using F2) was crashing. The problem was ~random, with some people experiencing it regularly, some never. 

   We have tracked the problem down to an 8-years-old Lazarus issue. Possibly, the issue was unaddressed for so long because, why the analysis of the problem was correct, the reproduction steps there were a bit difficult. Well, we have uncovered how to reproduce it easier, by editing in tree view 🙂 “Bumping” it in the Lazarus bugtracker resulted in super-quick fix from Lazarus developers — big thanks to Juha Manninen!

   If you use our official downloads, just grab the latest version and forget about it. We build using our Docker images which have Lazarus version properly patched.

   If you build Lazarus yourself, make sure to apply the relevant patch manually, as described here. Or just use latest Lazarus from “main” branch, which has this fix included.

4. Fixed crash at opening the project on macOS.

   See this merge request for details. Thanks for quick response of Lazarus devs, a version of this fix was quickly applied to Lazarus (main and fixes_3_0 branches). So just use Lazarus >= 3.5 if you build editor yourself.

5. Fixed editor packaged in our downloads on macOS. This was a silly mistake in our packing scripts, we packaged an editor for macOS, but then later script command was accidentally removing it 🙂

Note: There’s one more (really important) bugfix done lately to the lights attenuation. This will deserve a separate blog post to explain what happened. Stay tuned for future news.

Screenshot: Aston Martin Valkyrie-DVA by chiwei from Sketchfab. Traditionally, when I don’t have any special screenshot to illustrate the post, I search Sketchfab, download the model as glTF and show it rendered by our engine. This is one of the models in response to search string “bug fix” — due to same words in the description, though author of the model probably never thought someone will search Sketchfab for these words 🙂

Hi all! Today we announce a number of improvements for mobile (Android, iOS) development. They’ve been done while testing:

• Recently announced Castle Model Viewer on Android, see news.

• Updated Game Services Demo on Google Play.

• Updated Darkest Before the Dawn. A really old game developed using Castle Game Engine. Updated – no ads, use latest engine, released again on Google Play! Historically, this is the first game made for Android using Castle Game Engine, in 2013.

( Missed anything? See all Castle Game Engine applications on Google Play. )

Onward to engine improvements around the mobile:

1. TCastleContainer.SafeBorder — new property, working on both iOS and Android, exposing the safe area on screen edges where you should not draw anything important/clickable, because the system itself may draw important/clickable stuff on top of your application there.

   For example the system clock/battery/network state take space on top. The software home/back buttons may be on the bottom. Notch are present on some phones which obscure some part of some edge. See Android docs for display cutouts, and here how these displays look like. There are a few terms more-or-less interchangeable for this: safe area, insets, display cutouts on Android, status bar/bottom bar on iOS.

   Usually these are non-zero at top and bottom, but TCastleContainer.SafeBorder allows us to expose safe areas on potentially any screen side. Underlying API on Android actually gets all 4 sides. (Current code on iOS only queries for top safe area now, but we can improve it.)

   We also exposed TCastleContainer.OnSafeBorderChanged to notify about safe area changes. This is important, as applications dynamically switch orientation and/or enter/exit immersive fullscreen modes. So to support TCastleContainer.SafeBorder perfectly, make sure to react to TCastleContainer.OnSafeBorderChanged events.

   Our inspector (F8 on desktop, hold 3 fingers for 1 second on mobile) also shows them, as red bars.

   They behave OK with switchable orientations (portrait, landscape), phones and tablets and all supported Android versions, and it doesn’t break our behavior on fullscreen_immersive. This was some work to test 🙂

   How to actually support them — you need to move / enlarge your UI, to leave an extra space at the respective screen edges. You can move your UI (TCastleUserInterface.Translation), you can enlarge it (TCastleUserInterface.Height), you can use UI borders (TCastleUserInterface.Border), you can use padding available on some controls, you can also just add a solid-colored rectangle just for the sake of these insets. There’s no “automatic” answer, as you see — what to do depends on what UI you display. You can take a look what Castle Model Viewer for mobile does.

2. We have a new UI scaling method usEncloseReferenceSizeAutoOrientation. It is very similar to usEncloseReferenceSize, but automatically “flips” the reference width/height based on whether the current window sizes indicate portrait or landscape orientation. This means that UI controls have the same physical (real) size as your application orientation changes at runtime (e.g. because you support both portrait and landscape, and user just rotated the device).

   Designing for it is a bit more work. You have to account for both modes, portrait and landscape, as they result in different reference sizes. Your UI must fit sensibly in both cases.

   It is used by Castle Model Viewer for mobile so you can test it out and see how it works.

3. Gestures done with 2 fingers (on mobile) to zoom (pinch) and move (pan) with TCastleExamineNavigation have been quite improved. The code was simplified, the gestures now “kick in” instantly and they switch between pinch / pan dynamically, so you can effectively do both pinch and pan without releasing your fingers. This results in UX that feels much better to user.

   Again Castle Model Viewer for mobile is an example how it works. Run it and use 2 fingers e.g. on sample cat model to zoom/move it.

4. photo_service on Android was reimplemented to use modern approach on new Android devices and place the images reliably such that they appear in default “Photos” application.

   Using it is really trivial, just call TPhotoService.StoreImage. The full code (from castle-model-viewer-mobile) is:

   procedure TViewDisplayScene.ClickScreenshot(Sender: TObject); var Image: TRGBImage; ImageUrl: String; begin .. Image := Container.SaveScreen; try ImageUrl := FileNameAutoInc(ApplicationConfig('screenshots/'), 'screenshot_%d.png'); SaveImage(Image, ImageUrl); TPhotoService.StoreImage(ImageUrl); finally FreeAndNil(Image) end; ... end;

   procedure TViewDisplayScene.ClickScreenshot(Sender: TObject); var Image: TRGBImage; ImageUrl: String; begin .. Image := Container.SaveScreen; try ImageUrl := FileNameAutoInc(ApplicationConfig('screenshots/'), 'screenshot_%d.png'); SaveImage(Image, ImageUrl); TPhotoService.StoreImage(ImageUrl); finally FreeAndNil(Image) end; ... end;

5. We fixed saving files, when the subdirectory of the target file doesn’t exist. Our handler for saving to file:/ protocol now creates directory automatically.

   This makes sense for our engine, because we don’t want you to care about need for ForceDirectories and similar calls, because we don’t want you to usually care whether the protocol you use is file:/ or something else. We also don’t want you to depend on whether ApplicationConfig returns URL with file:/ protocol or something else (like future planned castle-config:/...). We also want constructions like SaveImage(..., ApplicationConfig('some_subdirectory/') + 'yet_another_subdirectory/foo.png'); to work automatically.

   A sample application is test_config_subdir.

6. We improved our Android documentation page (again — this seems to be most often updated documentation page of our website in 2024, maybe aside from roadmap 🙂 ). Simplified, and clearly recommends Android Studio. We work hard to make the Android process very simple and documented. At this point, installing Android Studio (not only Android command-line tools) is the best approach, IMHO — it has Java version that always works, has GUI-friendly access to emulators, mirroring, accepting licenses…

7. We improved our Android FAQ about emulator usage.

8. We improved our Android services list, to list all services and clearly specify which services are usually added automatically to the project.

That’s all, for this news announcement! We have a ton of new stuff, brace yourselves for more news 🙂 If you like this, we appreciate your support on Patreon, or other financial support , or other contributions. Reposting / resharing the news about our engine to interested people / places is in particular always appreciated!