The usual Android CPU, used by most of physical Android devices, is Arm (32-bit or 64-bit). But sometimes it makes sense to build for Android x86 CPUs (32-bit x86, 64-bit x86_64). The main use is to run such applications in emulators and virtual machines, like emulators provided in Android SDK or a virtual machine installed using ISO from Android-x86 project.

To do this, build Android APK using our build tool like this:

castle-engine package --os=android --cpu=x86_64

You can add --fast and/or --mode=debug if you want.

Then just transfer the resulting APK inside the Android machine.

If you use an emulator installed by Android AVD Manager, and visible on the adb devices list, you can even install and run (showing logs from the device) using the standard install and run commands of our build tool, like this:

castle-engine --os=android --cpu=x86_64 install
castle-engine --os=android --cpu=x86_64 run

Note: Setting up the emulator using command-line AVD Manager was unexpectedly hard, due to an enormous amount of questions I had to answer about the emulated machine. I recommend to use GUI to create new emulators instead, run Android Studio and from More Actions choose AVD Manager.

Note: The behavior of command castle-engine package --target=android, which you can use to create an APK for a “normal” Android device, has not changed. It still builds only for Arm (32-bit and 64-bit, aka Aarch64), assuming these are systems used on actual devices. Though we’re open to change this some day (if usage of Android x86 rises, and will be useful for more than just “developers testing apps in virtual machines”).

This has already somewhat worked in the past, but now we made it better:

1. Instructions to setup environment for this are adjusted on Android docs and Android FAQ. Following the stuff related to Android/x86 is completely optional, so if you have a working Android setup and are not interested in x86 support, just ignore it.

2. Our support libraries are now packaged with x86/x86_64 variants too:

   • https://github.com/castle-engine/android-freetype
   • https://github.com/castle-engine/android-openal (note: while it works, according to logs, but I have not been able to actually hear any sounds from OpenAL on Android/x86; from what I can tell, audio output just doesn’t work on Android/x86 with OpenAL; if you need it, I would suggest as a next step to test Android/x86 with FMOD).
   • https://github.com/castle-engine/android-tremolo
   • https://github.com/castle-engine/libpng-android

   The precompiled libraries are inside CGE services on Android. So you don’t need to do anything, just package for Android using the build tool commands shown above, and it will add the required libraries.

Nudged by the report of high memory usage I want to seriously optimize memory usage of CGE. Right now X3D nodes cost too much in memory — which limits some use-cases (when spawning a lot of TCastleScenes would be the most natural solution), and it affects both loading and runtime performance (as loading is slower when you need to clone/initialize more memory, and performance is slow when the cache is underutilized).

A first wave of improvements has already landed in the engine. A 2nd wave is in progress — it depends on remaking how all X3D nodes are set up, so it’s a big rework (but it was a long time coming).

Things done now:

1. We now have an efficient step interpolation mode (see TInterpolation), used automatically by sprite sheets and glTF models with step animation.

   While “step” interpolation was possible previously, but it was (ab)using the linear interpolation calculation, by duplicating keys. This was wasting both memory (2x data needed) and time (doing useless lerp operations).

2. We have simplified our X3D nodes inheritance. We use now TNodeFunctionality (a simple component system inside X3D nodes) with some descendants like TTimeDependentFunctionality and TTransformFunctionality. We no longer use Pascal interfaces for them. There are actually 2 reasons for it:

   1. In some cases, we really wanted to share implementation, not just API. So interfaces were never a proper tool.

      In effect our new TTimeDependentFunctionality is a much simplified and more natural old TInternalTimeDependentHandler, the new concept just fits our needs better.

   2. I never really grew to like COM interfaces. In FPC/Lazarus we have CORBA interfaces, and I made no secret that I like CORBA interfaces much more (basically, they work more like Java and C# interfaces, and are not entangled with unrelated things like memory management or COM technology). But Delphi only has COM interfaces, so CORBA interfaces are not available to us.

      This introduces quirky code when using interfaces, as we do not want the automatic garbage collection that the COM interfaces bring (and one has to watch out for it, even with hacked _AddRef, _Release like TComponent does). So one has to watch for lifetime of temporary values.

3. CoordinateInterpolator in sprite sheets can be often much simpler or even removed completely. This saves memory and execution time.

This year DelphiCon, an annual Delphi conference, is fully online and free. As we’re working hard on a Delphi port right now of course I will show Castle Game Engine there! I guess it will be the first public showing of CGE on Delphi.

Register for the talk here!

Our presentation is on November 17 (Wednesday). The whole conference is 16-18 November, there’s a lot of talks including stuff around cross-platform dev — check it out 🙂

We improved behavior of gizmos (for translating, rotating, scaling TCastleTransform in the editor):

1. The translation mode is more comfortable for 2D games. When you have typical 2D projection (orthographic, and camera looks along -Z axis) then

   • clicking on a special box in the middle of the gizmo,

   • or clicking on the Z arrow (previously a useless blue dot in case of such typical 2D projection)

   … allows to move the object simultaneously in X and Y. This allows to just move the object in 2D freely. This is done thanks to Andrzej Kilijański!

2. Fixed a case when translation may behave a bit crazy when the transformation had both rotation and non-uniform scale applied.

3. Fixed imprecise calculations (that caused the gizmo size to “tremble” sometimes) when using on a scene with large bounding box.

We now have an extensive docs about occlusion query in Castle Game Engine.

We also fixed occlusion query for shapes with blending, and made it behave correctly when batching is used (right now, batching has to be disabled for the scenes that use occlusion query).

On a more general note: Sorry for the relative silence in the news in last 2 weeks. We’re busy making a few things at once, big (memory optimizations, Delphi compatibility, docking editor) and small (Android x86, editor gizmos improvements). I will gradually post about them 🙂

We now load OpenGLES 3 context on mobile when possible (but still fallback to OpenGLES 2).

Core Castle Game Engine for now doesn’t actually use any OpenGLES 3 functionality. But we make available SetTransformFeedbackVaryings for shaders, which can be utilized by components like Particle Emitter (particle system for 3D and 2D in CGE) to now work on mobile.

Many thanks go to Trung Le (Kagamma) for implementing this!

iOS note

We made it work for both Android and iOS. But then we disabled it for iOS, at least for now.

Because it caused a small regression in Unholy Society — sometimes using FBOs causes a weird shift in further display. This was observed only on iOS + OpenGLES 3 (same code works OK on everything else: OpenGL on desktops, Android with OpenGLES 2 and 3, iOS + OpenGLES 2). Evidently Apple didn’t make the OpenGLES 3 truly backward compatible with OpenGLES 2. If you want to try it anyway (everything else works, the regression likely doesn’t affect most applications), adjust the code responsible for context creation on iOS in tools/build-tool/data/ios/xcode_project/cge_project_name/OpenGLController.m. You want to use this:

    EAGLContext *context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES3];
    if (context == nil) {
        context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
    }

Further details about this will follow. Ideally we want to workaround this problem at CGE level, and just create OpenGLES 3 context on iOS by default, same as on Android. If this will be impossible, we’ll give you a choice whether to try creating OpenGLES 3 context on iOS in CastleEngineManifest.xml.

We made great progress porting Castle Game Engine to Delphi.

• Running an engine in a window (using TCastleWindowBase) on Windows works.

• User interface controls (things in CastleControls, CastleUIControls units, like buttons, images, edit boxes etc.) all work.

• Reading and writing design files, like .castle-user-interface, that you create using CGE editor works. We’re using a version of FpJson and FpJsonRtti from FPC, with minimal adjustments to make them compile in Delphi.

• Examples from examples/user_interface now work in Delphi.

• XML compatibility much improved. This gives us compatibility layer to access XML in Delphi using similar classes as we use in FPC DOM and friends.

• Tested now on both Delphi 11 and 10.4.

• Tested now on both Windows 32-bit and 64-bit.

• Reading PNG has a fallback on built-in PngImage unit available in Delphi. This is used if libpng DLL is not available at runtime.

See the previous news post for all plans about Delphi port. Everything described here is public of course, you can take a look at how it works already: see the pull request. In particular you can try it yourself, just take delphi branch from Andrzej Kilijański’s CGE fork.

Arch Linux users can now install Castle Game Engine from AUR (Arch User Repository).

The package is available on https://aur.archlinux.org/packages/castle-engine-git/ . Follow the standard AUR installation process:

• Do it manually following AUR docs, like

  wget https://aur.archlinux.org/cgit/aur.git/snapshot/castle-engine-git.tar.gz
  tar xzvf castle-engine-git.tar.gz 
  cd castle-engine-git/
  makepkg -sri
  

• Or use a helper like paru. Once you have it working, just use paru -S castle-engine-git.

Thanks go to Kagamma (Trung Le) for doing this!

Enjoy much faster PNG loading on Android now, as the libpng library is automatically packaged with your applications. Various measurements, like this one, or testing “The Unholy Society” UI loading time confirm that the speedup is huge, even more than 10x compared to previous FpImage that we used on Android.

In general, there’s no need to do anything for developers. The Android service “png” will be automatically added to the projects that include some PNG files in their data. But you can also request PNG explicitly (just for Android, or for all applicable platforms), follow the docs.

And you can enjoy a new faster level loading in our new platformer release on itch.io, that includes an Android (APK) build.