Animation Blending

Posted on

PlayAnimation demo with animation blending

Animation blending means that the transition between animations is smooth. Without animation blending, the old animation instantly stops and the new animation plays. With animation blending, there is a short time during which the old animation “fades out” (it’s applied with decreasing strength) and the new animation “fades in” (analogously, it’s applied with increasing strength).

The movie below shows this technique in action in new Castle Game Engine. Notice how animation changes are sharp when TransitionDuration is zero, but they are smooth when TransitionDuration is larger. This is especially visible when switching between “Idle” and “Attack” animations on the 3D knight model.

This feature was implemented thanks to Castle Game Engine supporters on Patreon, in particular thanks to Robert Daniel Murphy who wished for it. Thank you! Please support me to see more cool features 🙂

How to use this

Use TCastleSceneCore.PlayAnimation with TPlayAnimationParameters, and set TPlayAnimationParameters.TransitionDuration. TransitionDuration is the time (in seconds) when when previous animation fades-out and new animation fades-in, usually values around 0.1-0.5 make sensible smooth effect. TransitionDuration = 0 (default) means that no animation blending occurs.

We have a new demo examples/play_animation/ to test the PlayAnimation method, including Loop, Forward and TransitionDuration.

Additional cool features of our animation blending

  1. Note that animation blending happens even when you restart the same animation. We show this in the movie by restarting the “Walk” animation — note that “old Walk” blends smoothly into “new, restarted Walk” when Transition is non-zero.
  2. Animation blending works for any field that can be linearly interpolated. So it works for animating translations, rotations, coordinate sets and everything else. It works for mesh deformations, or bone animations produced by Spine. It works for 3D or 2D.

Caveats (aka “things that, sadly, do not work yet”)

  1. For now, the animation blending doesn’t work for animations defined by castle-anim-frames (which you probably use to export animations from Blender). Fixing this requires improving the castle-anim-frames loading a bit.

    Background: Animation blending only works when the same mesh is used by all animation frames, but in case of castle-anim-frames we cheat a little and we have many (precalculated) copies of the mesh. This was supposed to be fixed one day anyway, to decrease memory usage (see the TODO here). It turns out that this fix is also needed to enable animation blending.

  2. For now, there is no way to define TransitionDuration for animations run by our TCreature system (using resource.xml) files. The resources animations (like TCreature) are done a little differently, without directly calling PlayAnimation, and they require a bit different code to make use of animation blending.

Both of these will be fixed one day (AD 1 is a work for ~2 days, AD 2 is a work for ~0.5 day). Let me know if any of this is critical for your project, and I’ll try to make it rather sooner than later! 🙂

Comment on this post ➤

Thoughts about X3D (our scene graph), including PBR (physically-based rendering)

Posted on


Castle Game Engine is using X3D as our scene graph. This means that we have a huge number of nodes (like Transform, Shape, IndexedFaceSet) that are nicely documented in the X3D standard. And you use these nodes throughout the engine (by loading files, like X3D files, or constructing the scene using these nodes from Pascal code — see example here or (2D) here).

As our engine grows, and we get more features, I also propose some extensions to X3D, to add more features both to X3D and to Castle Game Engine. I decided to summarize them in the wiki:

Some of these proposals are already implemented in Castle Game Engine (e.g. CommonSurfaceShader, consistent RGB texture treatment, shadows). Some are planned (e.g. PBR, and binary meshes using glTF integration). All the comments are always welcome!

We also talk about these things on x3d-public mailing list, and I encourage everyone to join. If you have an opinion how X3D should look like (in the context of Castle Game Engine usage, or not!), or if you wonder how to do something using X3D — this is the list 🙂

Comment on this post ➤

New server, new fixes and new (small) features

Posted on

  1. Our website has moved: It is now on . Our own server (in Los Angeles), our own domain. This makes our website independent from SourceForge. And it opens the door for some cool new features (online 3D models converter, screenshot generator, notifications from WordPress).

    The website on SourceForge continues to work, but it now simply redirects to .

    Our most important downloads (engine, view3dscene) have also moved, to be independent from SourceForge. They are now hosted on GitHub. This makes downloading smoother (no more SourceForge “download redirect” page). BTW, did you know we have a permanent link to the latest CGE download:

  2. Important fixes:

    • Mouse look handling on Windows 10 has been fixed.

    • Fix for Windows Intel GPUs version <= 8: use fixed-function pipeline.

  3. Small new features:

I have some more cool news to share, stay tuned! 🙂

Comment on this post ➤

Mobile View3Dscene Coming Soon

Posted on


Let us introduce a new mobile application based fully on Castle Game Engine. It’s a mobile version of our view3Dscene. Basically, it opens scenes in supported 3D formats, and lets user to walk / explore them, navigate through viewpoints and take screenshots. It also includes some demo scenes. As it should be a regular mobile app, not a game, we had to add many new GUI-related features into the engine.

The mobile view3dscene is developed on GitHub by Jan Adamec. We plan to release it soon.

New features available in the engine, added because view3dscene-mobile needed them:

  • Examine camera uses new gesture recognizer to detect pinch-to-zoom and two-finger panning gestures. The panning was possible only with the white round touch control before, so we can get rid of it for Examine camera now.

  • We handle screen DPI setting to scale UI on Android and iOS and present properly sized controls to the user. App works both on tablets and phones in both landscape and portrait modes. The Window.Dpi is now correct on both Android and iOS.

  • New controls: SwitchControl represents variable with on-off state (i.e. a touch-friendly checkbox), and powerful TableView control that has been designed to provide easy way to present dynamic lists with accompanying images or custom controls. It has similar interface as the native iOS UITableView or Android ListView.

  • Option to have the operating system status bar on (with carrier name, clock, battery status). Games usually hide it, which is also the default in our engine, but it may be useful for regular app to leave on. It also applies to the bottom bar with software buttons on Android. To use this in your own applications, set fullscreen_immersive=”false” in CastleEngineManifest.xml and design your UI to leave space at the top following Container.StatusBarHeight.

  • As view3Dscene is an app to view all supported 3D file formats, apps made with Castle Game Engine can now define the file extension associations for Android and iOS in their manifests. See view3dscene-mobile CastleEngineManifest.xml for an example how to define file associations in your own applications.

This post was written mostly by Jan Adamec, who is developing view3dscene-mobile since November 2017. My thousand thanks go to him, both for working on view3dscene-mobile and for implementing many missing necessary features in the engine!

Comment on this post ➤

Playing animations backward, build tool output dir, fast rendering to TGLImage and other new features

Posted on


New features implemented this week:

  1. You can now easily play the animation backward, passing the Forward = false parameter to PlayAnimation. Internally, X3D TimeSensor node is enhanced with a new field TimeSensor.fractionIncreasing.

  2. view3dcene has menu item “Forward” to test above.

  3. Build tool has a new command-line option --output to place the generated files (executables, packages, castle-engine-output dir) anywhere you like.

  4. Collada material transparency is now read OK, you can test on various models here.

  5. dmOverwrite draw mode for TCastleImage.DrawFrom/To to copy pixels without any blending (thanks to Eugene Loza!)

  6. Fast rendering to image on GPU (using FBO) using TGLImage.DrawFrom and TGLImage.RenderToImageBegin. Example in examples/images_videos/draw_images_on_gpu.

  7. String is now always UTF-8, just like in Lazarus LCL. This changes the treatment of localized (non-English) characters inside AnsiString (the default string). The engine now behaves just like Lazarus (LCL), regardless if you use TCastleControl (with LCL) or TCastleWindow (without LCL), and treats all strings as containing UTF-8 characters. This change is done in CastleUtils initialization code. Advantages:

    • consistency with Lazarus, that already does the same.
    • consistency across platforms. It’s easier to catch bugs when string is always UTF-8 on Linux, Windows, Mac OS X… E.g. this bug (reproducible only on Windows) is now fixed.
    • our TCastleFont rendering was already assuming UTF-8 encoding of strings. Some of our XML manipulation also assumes that we want UTF-8 encoding.
  8. And various smaller bugfixes:)

P.S. If you like what I’m doing, please support Castle Game Engine development on Patreon. Thank you!

Comment on this post ➤

Spine Bezier paths support, some fixes

Posted on


New features:

  • We now support Spine paths. They are converted to NURBS curves internally, and you can display them or use them from code to do anything you like (e.g. animate camera or some character along the path). See Spine support in Castle Game Engine for notes.

  • view3dscene has new menu items in the “Edit” section: “Hide Selected Shape”, “Reveal All Hidden Shapes”


  • We now treat Intel GPU on Windows with driver version >= 9 more like a normal GPU: assume they can make cubemaps, and generate mipmaps. See here.

  • Fix testing OpenGLES on 64-bit Windows (using Mali or Angle). See also here, and see updated links to get OpenGLES on Windows.

  • Fix compiling with CodeTyphon FPC. Thanks to Benedikt Magnus!

    Note that Michalis still advices to use normal FPC and Lazarus with Castle Game Engine, not CodeTyphon. I simply trust more in FPC and Lazarus developers, they care about making open-source Pascal code in a proper way, and with good quality.

Comment on this post ➤

Castle Game Engine 6.4 release – physics, iOS services, shader pipeline upgrade, big API improvements (vectors, transform) and more

Posted on


We’re proud to announce Castle Game Engine 6.4 release! Castle Game Engine is a free, open-source game engine written in Object Pascal. We support both 3D and 2D games. We are cross-platform (desktop, Android, iOS — with the help of our own build tool and scalable user-interface components). The complete list of the engine features is here, so go ahead and download it and try!

New features in 6.4 release:

  1. Rigid-body physics. Under the hood, we use Kraft Physics Engine for all the calculations. Kraft is developed by Benjamin “BeRo” Rosseaux and thousand thanks go to him for implementing this wonderful physics engine. Integration of Castle Game Engine with physics engine was requested and sponsored by Castle Game Engine supporters on Patreon.

  2. Many new services are available for iOS games: Apple Game Center, in-app purchases, analytics (Google Analytics, Game Analytics), Facebook SDK and sharing photos. Most of these were implemented for our “Escape from the Universe” release for iOS.

  3. Terrain generation API upgraded, terrain demo improved, and a new game demo showing terrain editing, planting trees and destructible objects was implemented thanks to supporters on Patreon. The demo is called Wyrd Forest, and you can download a complete source code and binary release on GitHub or watch a movie here.

  4. Jan Adamec is working on a mobile view3dscene — a viewer for X3D, VRML, and all the other formats supported by Castle Game Engine (Collada, 3DS, MD3, STL, Spine JSON…) for Android and iOS. He also implemented various new CGE features in this release — thousand thanks!

  5. Shader pipeline rendering code was much improved, to completely unify mobile (OpenGLES) and desktop (OpenGL) shaders — this means that both desktop and mobile can do Gouraud or Phong shading, and mobile renderer can use bump mapping, steep parallax bump mapping, specular maps, and other advanced material features from CommonSurfaceShader. Also, the desktop rendering uses now shader pipeline by default. So, the rendering code is more functional and faster and simpler at the same time:)

  6. New powerful TCastleTransform class is introduced. This allows to transform scenes (TCastleScene instances) in a comfortable way. It is also the ancestor of TCastleScene, so you can now e.g. trivially move the TCastleScene by just doing Scene.Translation := Scene.Translation + Vector3(1, 2, 3);.

  7. New modern API for vectors and matrices.

  8. Other new things supported: support “Dragon Bones” for creating animated 2D models, support https protocol, support KTX texture format.

  9. Other API improvements: using Delphi-compatible Generics.Collections containers throughout the engine, camera API simplifications, drawing ellipses, rectangles lines on TCastleImage (thanks to Eugene Loza!), improved FPS API and documentation, base units are now compatible with Delphi.

    I advice existing Castle Game Engine users to read upgrading to CGE 6.4 notes.

  10. Various engine examples were improved, in particular we completely reimplemented rift (fixed_camera_game) engine example.

Together with the new engine, we also release view3dscene 3.18.0 — our 3D and 2D model browser, and glViewImage 1.8.0 — our image browser. These tools are useful when working with the engine (to quickly check how does the engine handle given model or image), but are also perfectly useful on their own, to view or even post-process your files.

At this moment, I also want to ask you to support the engine development on Patreon. This support really helps me, and is very appreciated. Various 6.4 features (like physics integration!) would not happen without this.

If you have not yet seen my plans for 2018, read them — I have a plan that should make our engine the best engine ever 🙂 In short: editor component (to get standalone editor, like Unity3d, and to get editing inside Lazarus/Delphi, like GLScene, and to get runtime inspection/editing of the game world), Delphi compatibility, glTF and PBR, and looking closely at WebAssembly and pas2js.

Comment on this post ➤

New release this weekend, last pre-release notes

Posted on


We’re ready for the next Castle Game Engine 6.4 release. This weekend (Friday / Saturday), I’ll announce and upload everything 🙂

In the meantime, here’s a list of engine improvements we did in January:

  1. Drawing ellipses (and circles), rectangles, lines on TCastleImage thanks to Eugene Loza.

  2. Photo service on iOS and Android, thanks to Jan Adamec.

  3. DXF exporter application, thanks to @rweinzierl on our Discord.

  4. Many improvements to the engine examples:

    • rift (fixed_camera_game) example was completely reimplemented. It now uses TUIState, has muuuch simpler code, and is portable to mobile (Android, iOS).
    • Terrain example reimplemented, has now much more functions (like adjusting shader parameters) and better defaults (some taken from wyrd-forest), and is portable to mobile too (Android, iOS).
    • Various fps_game improvements for Android.
    • sandbox (now just “isometric_game”) code improved (although it still uses a very simple approach to rendering) and it can compile to mobile (although input still relies on a keyboard).
  5. Sound buffer improvements and fixes: TSoundBuffer is a class now (although it should be invisible to you, as it’s automatically managed by the sound engine). And it correctly “survives” if the application was paused / resumed on Android. So you can safely do Buffer := SoundEngine.LoadBuffer(‘sound.wav’) in Application.OnInitialize and then play this buffer at any time later.

  6. Easier way to adjust ApplicationName: just set ApplicationProperties.ApplicationName.

  7. New Viewpoint.fieldOfViewForceVertical field.

  8. New property Attributes.SolidColor to make Attributes.Mode = rmSolidColor reliable with the shader pipeline.

  9. The assets:/ protocol is deprecated, better use now castle-android-assets:/. Read more about the protocols supported here, and reasons for name change are listed here. This should be internal (invisible during normal engine usage), as cross-platform applications should never explicitly use this protocol.

Comment on this post ➤

Integrate your iOS games with Google Analytics, Game Analytics, Facebook, open URLs, share text…

Posted on


Happy new year everyone!

In preparations for releasing Escape from the Universe on iOS, I have implemented a number of new “services” on iOS. They allow to integrate your games easily with various iOS frameworks.

The detailed information how to activate all these integrations is here, you just add a 1 line to your CastleEngineManifest.xml and then use a trivial Pascal routines/classes for everything.

Have fun with Castle Game Engine in 2018 ! 🙂 And if you had not seen it yet, take a look at our plans for 2018 – it starts now.

Comment on this post ➤

Plans: 6.4 release ASAP, visual editor soon, 2018 roadmap

Posted on

"Sad Sam" cat
Chinchilla model in X3D, based on high-poly version in "Big Buck Bunny"
Editing SceneManager.Items at design-time

I’ve been doing some thinking about the Castle Game Engine future.

Basically, I’m excited — we’re at a point where I feel the engine is seriously great. It has been proven by developing a number of cross-platform games and demos and more are in-progress. And I feel we can seriously start to compete with other game engines, in Pascal or not, even the big ones whose names start with “U” :).

The plans, in short:

  1. Release the Castle Game Engine 6.4 as soon as possible
  2. Start developing a visual editor (both inside Lazarus / Delphi and as a standalone application) as soon as possible
  3. Work in 2018 on the most important/requested features (in rough order): Delphi compatibility, visual editor, glTF, and looking closely at the WebGL target

More details:

1. Release the Castle Game Engine 6.4 ASAP

My initial primary goal for the 6.4 release was Delphi compatibility. I documented it publicly and made some progress (also our containers now use Delphi-compatible Generics.Collections). But it’s simply taking me a long time, partially because I’m distracted by other cool tasks on the engine, partially because I’m working on various games using the engine.

I know that many of you want the Delphi compatibility, and you have all the right to scold me for taking so long to finish it.

As for the good news, we’ve made a lot of engine improvements since the last release, 6.2. Rigid-body physics, big API improvements (new CastleVectors API, TCastleTransform class), modernizing the renderer code (which resulted in using modern shader rendering for everything, by default, and in possibility to have Phong shading and bump mapping on mobile), Apple Game Center, in-app purchases, KTX, and more smaller stuff…

Note that one the biggest new features, physics integration, was done explicitly thanks to your request on Patreon, and thus: it happened because you support me on Patreon. It would not happen otherwise (at least not so soon). I’m really grateful for that, and I hope that using the engine is as much fun for you as it is for me to extend it 🙂 Thank you!

After a bit of thinking, I decided that we will release the next version of Castle Game Engine as soon as possible, which means: try to do it in 2017, eventually do it in the first week of 2018. Yes, that soon. Looking above, we have a lot of improvements done since last release, and it’s becoming hard to keep it unreleased for me 🙂 All of my new games are using the new engine features, and I consider the current state of “unstable” GitHub code to be actually… very stable.

The Delphi compatibility of course remains on the nearest roadmap, it’s just scheduled for 6.6 release now.

2. Visual editor (inside Lazarus / Delphi and as a standalone application)

I believe that the biggest missing feature, which sets us behind some other game engines, is the lack of a visual game editor. Yet, it is something very easy to make, with the right design — so, let’s do it! I want to make a working prototype of it ASAP, release it with 6.6, and polish it within 6.8 release.

I have a couple of design requirements of the editor, and together they determine how I’m going to implement it:

  1. The editor must be available as a standalone editor application. So you download Castle Game Engine and it’s not just code — it’s also a ready CGE Editor application that you can use to create a project, drop some 2D and 3D assets, invoke your favourite Pascal editor (Lazarus or Delphi), then press Build to compile a game.

    So the Castle Game Engine Editor will also wrap our build tool (to build your project for any platform, including desktop and mobile, which in turn uses FPC or Delphi compiler underneath), view3dscene (to view 3D and 2D game assets) and glViewImage (to view simple images). It can also contain some ready project templates — so instead of Clear project you can start with “3D first-person shooter” or “2D platformer” template.

    The designed hierarchy can be saved to a .cge-control files (serialized just like .lfm and .dfm), and the project uses TCastleWindow to load it (inside TUIState) and play. This is our ultimate flexible architecture to develop “pure games” applications (where OpenGL context is your only user-interface): TCastleWindow with a number of TUIState instances using TUIControl inside.

  2. The editor must also be available as integrated inside Lazarus / Delphi, to edit the TCastleControl contents on a normal LCL / VCL form.

    Once the castle_components.lpk is installed, you should be able to double-click on the TCastleControl to edit the game world inside. This is quite like GLScene or FireMonkey experience — a RAD tool to edit your game right inside the environment you know and love.

    It’s actually already started:) Double-click on TCastleControl under a new Lazarus (where my patch to add ocoRenderAtDesignTime is already included). You will be presented with a question whether to add some 3D sphere to your game. This dialog will be replaced with a full-featured world editor:)

  3. Finally, the editor must also be available to inspect and edit a running game. When you run the game, you can invoke the editor to inspect a hierarchy of TUIControl, including a scene manager with a hierarchy of TCastleTransform. You can view and edit the game world right there, while your game is running.

    This should provide an experience similar to running your game in game engines like Unity3d.

Once my mind was settled that I really want all the three possibilities above, the way to implement them seemed obvious: make a Lazarus component TCastleEditor, using LCL (portable to Delphi VCL), that can edit a hierarchy or TUIControl and TCastleTransform.

  1. Use TCastleEditor inside Castle Game Engine Editor (done using Lazarus) to edit a TCastleWindow instance (a window that shows only a game content).
  2. Use TCastleEditor inside Lazarus when double-clicking on TCastleControl.
  3. When the game is compiled from the Castle Game Engine Editor, make it possible to include the TCastleEditor in the runtime, by using the LCL backend of TCastleWindow (-dCASTLE_WINDOW_LCL) and handling some key (F12?) to automatically show TCastleEditor (in a separate window, by default, maybe dockable too).

3. Plans for 2018

  1. Release 6.4 with the current features: ASAP (maybe even 2017).
  2. Full Delphi compatibility and a working prototype of a visual editor (covering all 3 use-cases): 6.6 release.
  3. Visual engine editor fully working: 6.8 release.
  4. glTF 2 support, along with PBR (physically-based rendering).
  5. Look closely at pas2js progress, or WebAssembly compiler in FPC. As soon as we can reasonably adjust our code to it (e.g. it needs to support generics), port CGE to WebGL using pas2js! Yes – compile your games using Castle Game Engine to run in the browser (without any plugins). This will be huge, and I want to do this as soon as technically possible.

There are more plans of course. But the above should give you an idea where my priorities are.

4. Thank you!!!

Thank you for reading this long post. If you reached this far, maybe you would like to talk or help us with the development (not only coders are needed!). Finally, supporting me on Patreon really makes a difference, so please consider it.

Thank you all for the wonderful 2017!

Comment on this post ➤