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.

A few loosely connected improvements for building and mobile devices:

Android:

1. Fixed building on Android when the project folder contained spaces. We no longer use ndk-build that cannot cope with that.

2. Fixed (well, workarounded) crashes on Snapdragon (Adreno) Android devices when using parallax bump mapping.

3. Updated Android prerequisites documentation. Using latest Android SDK with latest Java is OK now, and we no longer need to use ancient Java 8. Latest Android SDK is OK with Java 11, and just using default-jdk package in Debian stable works.

iOS:

1. Compilation for iOS with FPC 3.2.2 is fixed. Just like FPC, we now define iOS as a separate OS from “darwin”, and thus we’re ready for macOS 11 (desktops running on Arm64 CPU).

2. Updated iOS documentation. Installing iOS cross-compilers using fpcupdeluxe works cool now.

Docker and releases:

1. Our Docker image has been upgraded. It is now based on Debian buster (current stable) instead of stretch (oldstable). We kept relying on stretch (oldstable) for a long time, as Android SDK required ancient Java 8 — luckily this is no longer the case.

2. Our Docker image contains now latest FPC version 3.2.2 and it is the default FPC version. Also the FPC trunk revision has been updated to latest revisions on 2021-07-18.

3. This also means that CGE binary releases are now compiled with FPC 3.2.2 (instead of previous 3.2.0).

I did not really have any good image for this post, so attaching a screenshot from new examples/3d_rendering_processing/detect_scene_hit 🙂 It is a simple demo of TCastleViewport.TransformUnderMouse.

Do you want to compile Castle Game Engine yourself, from our source code? As this is the first step toward contributing in the engine development, we can only encourage it 🙂

We now have a detailed documentation how to compile CGE from sources yourself.

And we have a video recording of this process on Linux:

Watch the latest video on our channel — demonstration how to create and edit sprite sheets completely in Castle Game Engine, how to put them on the scene, how to load Starling and Cocos2d sprite sheets and more! With thousand thanks to Andrzej Kilijański for presenting this, after implementing all features and examples shown here:)

Have a lovely Sunday!

And play our platformer demo, if you haven’t already 🙂 We have compiled version of the game, for Windows and Linux, ready here:

https://castle-engine.itch.io/platformer

You can download it manually as a zip file, or using comfortable Itch.io App.

We have also updated Castle Game Engine itch.io page to represent the engine better.

For developers, an additional treat is the examples/platformer/itch.io/ directory that contains the shell script and manifest files that show how to 100% automatically release your game on CGE. You can combine our build tool and itch.io butler to do this.

The platformer demo was developed by Andrzej Kilijański. For more information, see the README and the previous news about it.

Last but not least, after playing, you can watch the movie where Eugene Loza managed to play through the entire game without firing a single shot 🙂 For a more typical gameplay, pick up the weapon and fire with a Space key! Spoiler warning – of course watching the movie will kind of spoil the game for you. It’s probably more fun to play it yourself first:)