We have great news about Delphi compatibility with Castle Game Engine: We have basics (window, with images and text) working!

You can observe the work in this PR by Andrzej Kilijański.

Plans

The first goal is to make TCastleWindowBase with WinAPI backend working fully. This will make CGE working with Delphi for native Windows applications, using our advised approach (TCastleWindowBase). Of course more things will follow — we will want to have TCastleWindowBase running on other platforms supported by Delphi too (like mobile). And we will want to have TCastleControlBase that you can drop on FMX (and maybe VCL?) form too.

The immediate goal is now to enhance PR to include working JSON (which includes our serialization of designs) and then TCastleScene (which includes our most important rendering of 3D and 2D assets). Once this is done, most CGE examples will be compileable+runnable from Delphi.

Delphi versions

• We target the recent Delphi versions, up to and including the latest Delphi 11 of course.

• The port should work in principle on all Delphi versions with generics (>= 2009), though we may not be able to test it everywhere. But we’ll test at least on 10.4 and 11, and welcome anyone with older Delphi versions (but still >= 2009) to report.

• Every variant (free Community Edition, paid Enterprise) will be supported and tested.

• Note that we will not support ancient Delphi versions like Delphi 7. We’re aware some people use really old Delphi versions, but supporting these versions is not reasonable for us. It would require a serious effort to port code (e.g. generics) and then to keep testing every release with these old Delphi versions. In the end, Delphi 7 is really old. I advise everyone with Delphi 7 to either upgrade to the latest Delphi (the latest Community Edition is free, with some usage limits) or just switch to open-source cross-platform FPC/Lazarus.

Strings

We want the CGE API to be natural in Delphi, so the String type we use (when compiled by Delphi) is the default 16-bit Unicode Delphi string. Our font drawing (that has to deconstruct String -> sequence of Unicode numbers), and everything else, is adjusted to work with it.

Note: When compiled by FPC, we continue to follow FPC/Lazarus conventions: String is AnsiString and it just holds UTF-8 on all platforms.

(Sidenote: To be more precise, using UTF-8 everywhere is Lazarus/LCL convention. FPC AnsiString can use more complicated code-page aware mechanism. See 1, 2, 3, 4. Lazarus/LCL simplifies this (by adjusting some global vars) to “just use UTF-8 everywhere” and I think this is much simpler and thus better. It is also probably what many people expect (as a lot of FPC users are just Lazarus/LCL users). So we follow this in CGE too, setting the same global vars as LCL, to “just use UTF-8 everywhere”.)

So it’s a bit different between Delphi and FPC/Lazarus, but with the same goal: just follow the established default String meaning. Have the API natural for users coming from any compiler. For simple string usage from user code, this difference should not really matter — you write and glue strings as usual in Pascal, and both in FPC and Delphi the type and operators behave in a way that is natural.

External dependencies

For external dependencies (stuff specific to compiler and/or external to Pascal), we decide case-by-case on a best solution.

• For XML stuff, we have a small wrapper to expose Delphi XML API in a compatible manner to FPC API. You can use this XML API in your own programs too (thus handling XML in a way that is compatible to both Delphi and FPC), but you don’t have to.

• For URL stuff, we use FPC units with Delphi. (LGPL license of FPC RTL allows this.) This concerns units like URIParser. Majority of your code will use CGE API anyway, from CastleURIUtils and CastleDownload units, that of course work the same with Delphi and FPC.

• For JSON — the decision will come (but preferably we’ll just use FpJsonRtti with Delphi, as it would be easiest). Your code will use CGE API anyway in CastleComponentSerialize (or even higher-level TUIState.DesignUrl) so it will not matter for you.

• For FpImage — we will not use it with Delphi, instead relying on own image loading code (DDS, KTX, libpng for PNG etc.). It would be too cumbersome to try to pull whole FpImage into Delphi, and FpImage is not that important for us anyway (e.g. we load PNGs using libpng, without FpImage, due to FpImage being terribly slow; we load DDS and KTX without FpImage, as we need to load them efficiently to RAM and then to GPU, preserving compression like S3TC or ASTC).

Tools

Our first goal is to port the CGE runtime to Delphi — to make games using Delphi. The engine tools will mostly continue to be developed using FPC/Lazarus and they’ll just enable Delphi compiler as an alternative option. This means:

• Build tool and editor will allow to use Delphi dcc under the hood, instead of FPC.

  Ideally, they’ll just auto-detect the compiler, by default. If you don’t have FPC/Lazarus installed, but you have Delphi installed, they should just use Delphi by default.

• The editor itself will be compileable only by FPC/Lazarus, at least for now. As it seems not really reasonable to maintain it for both LCL and VCL/FMX at the same time, the differences are too much to maintain both versions in a painless way.

  This will make building editor with custom components on Delphi problematic at first. I mean, it will be possible — but you’ll just need an FPC/Lazarus for this, even if your game is using Delphi for the actual game build.

  We’ll be looking at better solutions for this. Maybe we’ll just have to figure out how to maintain editor that compiles with both LCL and VCL/FMX. But we have to experiment how to have it without a big maintenance burden (we do not want to just fork the editor for VCL/FMX, as it would not be maintainable in the long run).

1. We support a new way to define launch images on iOS. Launch images are something displayed by the iOS when the application is, well, launching. They are displayed immediately when you click the application, before any CGE code (even Objective-C code) has been run. Their point is to communicate to the user “the application is launching, please wait”, so that the (usually very short) delay when the application launches is not a problem (user will not look confused at the screen, wondering whether (s)he clicked the screen OK etc.).

   We now have a better way to define them, using a better mechanism called launch image storyboard. It is documented as part of CastleEngineManifest.xml. Just place something like this in your CastleEngineManifest.xml:

   <launch_images>
     <storyboard 
       path="launch-image.png"
       scale="1.0" 
       background_color="000000"
     />
   </launch_images>
   

   The advantages of the new system are: you can provide your graphic with any size (it will be resized to fit any iOS device nicely) and it works in iPhone landscape nicely (just like in portrait, of course).

   It’s also the advised way to define launch images on iOS now. You can ignore the iOS warnings from Xcode about the fact that we use the old (deprecated) approach to the launch images as well — for now we use both methods (old and new) for launch images, to work always, but in the end we’ll just remove the old approach.

2. In a related department, we have made it more flexible how our CGE “loading” image is displayed. This is the image displayed by CGE while the Application.OnInitialize is being executed. (So it happens after launch images, in case of iOS.)

   See the 6.1. Adjust loading image for a description how to set this image.

   We now expose Theme.LoadingUIScaling, Theme.LoadingUIReferenceWidthg, Theme.LoadingUIReferenceHeight to define how is the loading image scaled. You can set these properties to match the UI scaling settings in your CastleSettings.xml, and thus have loading image scaling matching perfectly the following CGE UI. This may be useful to seamlessly fade-in some splash image once your game actually starts.

   In the future I plan to automate this even more. We should allow to auto-generate Pascal code that defines the loading image, and so the synchronization with CastleSettings.xml will just happen automatically.

• We now gracefully tolerate:

  • Missing VorbisFile library. If missing, we will just not play OggVorbis files, but otherwise everything will work.

  • Missing FreeType library. If not available, texts will be rendered using the standard UIFont, instead of being invisible.

  It has been always our intention to tolerate missing external library dependencies as much as we reasonably can. Because “in the wild” there are many reasons why dynamic library may fail to load (some of them under the control of the developer, some not), so it’s best to tolerate these failures nicely.

  Of course they are reported using warnings (watch log), and as a developer you want to make sure to package your library correctly. But we want to tolerate here mistakes — a game without music is better than a game that crashes at start for user.

• We have fixed the automatic packaging of FreeType and VorbisFile DLLs on Windows. We added their necessary Visual C++ Redistributables dependencies (vcruntime140.dll, msvcr120.dll). The build tool and editor will automatically place all necessary DLLs alongside your EXE when building a Windows application.

• We have released a new version of our Platformer demo. It is now available on Android. Also the Windows build includes the Visual C++ Redistributables previously missing.

• Using F9 when Platform is Android in editor now “just works”. That is, it will execute package + install + run. So it will rebuild and run the project on your connected Android device (assuming you have installed Android SDK and cross-compiler).

• You can now choose the package format (zip, tar.gz, Android APK, Android AAB etc.) in the editor.

• Better treatment of “package format” throughout build tool for “package” and “install” commands. The “install” build tool command now takes --package-format argument too.

• The “install” on Android fixed, to look for APK with proper name.

I have documented how to implement in-app purchases on mobile (Android and iOS) on In-app purchases (wiki page). This is a much updated and extended version of what was previously in the TInAppPurchases class API docs.

(A complete example showing this will follow later too.)

Another new useful documentation page is how to create custom components. For this, the primary example is in examples/advanced_editor.

Spine is a great 2D animation software. We use it in Cat-astrophe Games LLC to develop games using CGE like Escape from the Universe and The Unholy Society (soon on Android and iOS!).

See Spine docs about using Spine.

Our Spine code was upgraded this week to handle various new Spine 4.0 format features. This includes new atlas format support, new curve interpolation spec in Spine files, and some other bits that have changed since Spine 3.x.

We now seamlessly handle JSONs exported from any Spine 3.x or 4.x versions. There is nothing special for you to do — just export Spine models to JSON as usual, and load by setting TCastleScene.URL.

Effekseer is a full-featured particle effect creation tool, open-source, cross-platform and with a big library of samples.

Thanks to Trung Le (Kagamma), we can now easily render Effekseer effects in Castle Game Engine. The integration uses the very latest Effekseer version (1.61a), and works on both desktop and mobile platforms.

Under the movies, we list detailed usage instructions, so read on 🙂

Usage:

1. Get the cge-effekseer code.

2. Follow the instructions in the cge-effekseer code README about getting the library — Precompiled Dynamic Library or Generate dynamic library guidelines.

   You can find the Windows and Android precompiled libraries linked there. You can also find the Linux precompiled library in this ticket. We have a repo with the fork of Effekseer + necessary wrapper library code to rebuild the library easy, see README_CGE there.

3. Test the demos/TestEffekseer inside. You will need to copy there the dynamic library of the Effekseer wrapper. For Windows, copy the libeffekseer.dll. For Linux, copy the libeffekseer.so.

   On Linux, you will also have to create a shell script to execute the application with modified LD_LIBRARY_PATH. Call it run.sh, and place there this:

   #!/bin/bash
   set -e
   # Include current directory in LD_LIBRARY_PATH, to find effekseer dynamic library
   export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:./"
   ./TestEffekseer "$@"
   

   Make the script executable (chmod +x run.sh) and it will be automatically used to execute this application (by castle-engine run and CGE editor F9).

4. Instructions about using it in your own applications are in cge-effekseer README.

5. To create your own effects, use the Effekseer editor and browse their samples. The process is independent of Castle Game Engine.

   In the end you export to xxx.efk file that you can load in Pascal’s class TCastleEffekseer. Also place the textures in Textures subdirectory of the effect (to be more precise: at the same relative filename as they are recorded in the Effekseer project).

Project cge-2d-water-effect by Trung Le (Kagamma) shows how to do a beautiful water for 2D games. The water is represented as a volume that you can easily move and scale around. It supports reflection and refraction.

Under the movies, we list detailed usage instructions, so read on 🙂

Technically, it is expressed as an X3D scene with a geometry and a special shader, that you should load into a special TCastleScene descendant: TCastleSceneScreenBuffer. The viewport containing this must also be of special class, TCastleViewportScreenBuffer.

The setup can be tested with any 2D game designed in CGE viewport. E.g. you can place water volume in our examples/platformer/ game demo.

Detailed usage instructions:

1. Get cge-2d-water-effect code.

2. Point your project to cge-2d-water-effect sources. E.g. add this to CastleEngineManifest.xml:

     <compiler_options>
       <search_paths>
         <path value="code/" />
         <path value="../../../cge-2d-water-effect/src/" />
       </search_paths>
     </compiler_options>
   

3. Include custom components in your project.

   1. Add to CastleEngineManifest.xml the line editor_units="CastleSceneScreenBuffer, CastleViewportScreenBuffer". See CastleEngineManifest.xml docs for examples.

   2. Open your project in CGE editor and use “Project -> Restart Editor (With Custom Components)”

   3. Be sure to also add CastleSceneScreenBuffer, CastleViewportScreenBuffer to some uses clause, to register components at runtime.

4. Copy the cge-2d-water-effect/data into your project data, e.g. into my-project/data/2d-water/.

5. Use TCastleViewportScreenBuffer where you would normally use TCastleViewport.

6. Add to viewport instance of TCastleViewportScreenBuffer. Load there castle-data:/water2d/2d_water_plane.x3dv. Move it, scale, duplicate as necessary to set up your water volume.

The particle system cge-3d-particle-emitter, developed by Trung Le (Kagamma), has a big update. Now it is possible to edit the particle effects right inside the CGE editor (using CGE editor capabilities to register and edit any component).

Under the movie, we list detailed usage instructions, so read on 🙂

Try it out:

1. Download the latest cge-3d-particle-emitter code.

2. Make sure you have the latest Castle Game Engine version, with latest editor and the build tool. We had some important updates to editor lately: fixed rebuilding editor on Windows (needs to wait for previous editor to finish before replacing the EXE), and to define CASTLE_DESIGN_MODE at compilation of custom controls.

3. Open CGE editor, and open the project cge-3d-particle-emitter/demos/gallery/CastleEngineManifest.xml.

4. Rebuild the editor to include the custom particle emitter and effect components. Just click on “Project -> Restart Editor (With Custom Components)” to build an editor with project-specific components.

5. Enjoy! Use the editor as usual. Open the design data/gamestatemain.castle-user-interface to see sample effects and emitters designed. Tweak all their options by exploring properties on the All tab.

Kagamma lists a few more new features in the forum thread:

• You can now use MiddleParticleSize, which allows to change particle size by performing linear interpolation to certain point (defined by MiddleAnchor) during it’s lifetime.

• New SourceType property, allows to define the type of emitter source (Box or Spheroid).

• New Burst property, allows to create burst-type emitter, useful for creating explosion effect.

• New AllowsUpdateWhenCulled property, very useful if you want to optimize particle’s performance, by stopping it’s updating when particle emitter’s bounding box is outside of view frustum.

• New AllowsInstancing property. If this is set to True, then you can use the same particle emitter on different transform nodes. Particles are calculated in local space, which means if you move the emitter, then it’s particles will also move with it. If you want particles to be calculated in world space, then set this property to False, which also disable the ability of instancing.

  (It becomes obvious once you play with it visually 🙂 )

• Despite it’s name, you can also use it in 2D, which means cge-2d-particle-emitter is now deprecated.