• 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.

You can now easily integrate your mobile applications with Tenjin, an analytics service with emphasis on install attribution (“from where did users install this application”). The idea is to have more knowledge about your organic and paid (from marketing campaigns) installations, to better make decisions how to promote your application.

New tenjin service can be declared in your CastleEngineManifest.xml file. Read the documentation:

• Android tenjin service

• iOS tenjin service

The service sends to Tenjin:

• initialization (user device data, e.g. Android/iOS version),

• purchase details (when user makes in-app purchase), so you can correlate them with your marketing campaigns,

• custom events you send by trivial TCastleTenjin.SendEvent

Note that we are not associated with Tenjin in any way. We just added to CGE a component to easily use their mobile SDK. The Tenjin is in general a paid service, although basic install attribution is free.

Please refer to the Tenjin documentation to know more about Tenjin features, and how to view these statistics.

The Pascal API will be extended soon with easy option to opt-in/out of the statistics by user.

We also introduced a new mechanism how services can declare their information: CastleEngineService.xml files.

• Right now Tenjin and FMOD services use them, and they allow to copy 3rd-party binary libraries (that we cannot distribute within CGE) into your mobile project.

  This system will be extended to simplify services creation in the future. Platform-specific independent services work cool like this.

• See FMOD Android service, FMOD iOS service, and in particular their example CastleEngineService.xml in Android FMOD service.

The new Tenjin service may also serve as a good example of a service that integrates with a 3rd-party SDK in Objective-C (on iOS) and Java (on Android). It makes a basic integration, and allows for basic communication with Pascal through TCastleTenjin.SendEvent.

Important fixes:

1. Editor on Windows: Fixed a random crash when doing F9 on Windows.

2. Fixed physics crash on i386 (32-bit CPUs)

3. Editor UI fix: Alt+tab and back no longer clears selection, no longer resets the preview in bottom-right corner.

4. Fixed castle-engine package-source – it was accidentally by default creating a zip file, but with tar.gz extension. Now it correctly by default creates a zip file with zip extension, it also reacts correctly to --package-format=targz .

Website improvements:

1. API docs searching for short/common words like X or Up fixed.

2. We have a new page Gallery -> Assets (3D and 2D Graphics, Sound) listing various useful places where you can download good quality assets (graphics and sounds) for your CGE games.

   It just lists a few sites with good quality stuff useful with CGE. The list is absolutely very subjective, based on my (Michalis) opinion and just reflecting what I’m using myself when I need a ready graphic/sound. I like good quality things, useful in games, and free on clear open-source licenses (although I’m OK when the site has paid assets too — e.g. I’m cool with recommending Sketchfab, as long as they also support assets on open-source licenses).

   Before you ask: Yes, we should have Castle Game Engine Asset Store some day 🙂 In the meantime, I would encourage to submit to OpenGameArt.org assets with [CGE] in the name (this has been approved by OGA moderators as the way to go).

3. Simpler talk to us page to show the 4 important ways of contact: Discord, forum, GitHub issues, Patreon.

Small engine improvements:

1. We have an automatic tool to check correctness of our Lazarus packages in tools/internal/check_lazarus_packages/. This checks that our LPK contain all the necessary files (which also means they’ll be recompiled on changes), and is automatically run by our Jenkins after every commit / on every new branch to check it.

2. New simple demo examples/user_interface/test_all_state_events, replaces old examples/window/window_events.

1. You can now choose the platform (Windows, Linux, Android, iOS…) to build and run from the editor. This platform is then used by compile, run, package, install build tool commands. This means that, if you have cross-compilers set up (hint: use fpcupdeluxe) then you can now easily build for various platforms, right from the GUI editor, without resorting to command-line and playing with environment variables.

2. Another new feature, also related to the cross-platform development, is specifically for Linux/FreeBSD developers that want to target Windows too:

   You can now run Windows application on Unix seamlessly — if only you have WINE installed. The build tool, as well as GUI editor, will invoke wine / wine32 / wine64 under the hood, if you run Windows build on Unix. From the command-line, it means you use castle-engine run --os=win64 --cpu=x86_64 (or --os=win32 --cpu=i386 for 32-bit Windows) while your current (source, host) OS is Unix.

   Together, this means that if you have FPC cross-compiler from Linux to Windows installed (again, use fpcupdeluxe — it’s easy 🙂 ), and WINE installed (it should be included in the packages of all Linux distributions), then you can just switch in CGE editor platform to Windows, and press F9, and see the Windows application being compiled + run on your Linux without any fuss. The compilation / testing is then equally easy as for normal native Linux build.

3. To make things balanced, we also have one new feature for Windows developers to make it easier for them to build apps for Unix (Linux, FreeBSD) desktops:

   You can set trivial global boolean CastleDataIgnoreCase, to easily run application with castle-data URLs that have wrong case on a case-sensitive filesystem. E.g. your file in the data directory may be called my_texture.png. Normally, accessing it by URL like castle-data:/My_Texture.png doesn’t work on Unix, as the file system honors the case (in contrast to Windows, where it works OK).

   Setting CastleDataIgnoreCase means that we search for the file name (and all directory components on the way) ignoring the upper/lower letters difference. It will raise an error only when it is impossible (no such file found, or ambiguous, e.g. you have both my_texture.png and My_Texture.png on disk — this is perfectly possible on case-sensitive filesystems).

   While this is slower (so we don’t really advise it as the “final solution”), but it is useful to quickly deploy applications tested mostly on Windows into Unix. In the long run, we still advise you to just honor the case, and thus make things work without CastleDataIgnoreCase, but using CastleDataIgnoreCase is now a possible and quick solution when you need it.