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>

   1 2 3 4 5 6 7

   <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 "$@"

   1 2 3 4 5

   #!/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>

   1 2 3 4 5 6

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