Engine improvements: 2D rendering (TGLImage) – customize shader, documentation, getting contents from GPU

Posted on

  1. I wrote a wiki page documenting two approaches for 2D rendering using Castle Game Engine. Advised
    reading for people implementing 2D games 🙂

  2. You can customize the look of TGLImageCore using the TGLImageCore.CustomShader. Or you can customize the look of TCastleImageControl using TCastleImageControl.CustomShader. The demo: examples/images_videos/image_render_custom_shader.lpr.

  3. You can now assign the TCastleImageControl.DrawableImage. This allows you to render TGLImage on GPU using any fancy method, and then use it as a source of TCastleImageControl efficiently.

  4. Remember that you can draw one TGLImage over another, or draw arbitrary (2D or 3D) things into the TGLImage, using fast GPU rendering. The demo how to do this is in examples/images_videos/draw_images_on_gpu.lpr.

  5. You can get the contents of TGLImageCore to TCastleImage (thus getting the memory from GPU to RAM, available to CPU) using the GetContents helper method.

Comment on this post ➤

Engine improvements: User-interface – horizontal/vertical layout groups, on-screen keyboard and FreeType on Android, better UI scaling

Posted on

"The Unholy Society" fight UI, implemented with UI scaling and TCastleHorizontal/VerticalGroup layouts
"The Unholy Society" fight configuration UI (internal), using TCastleHorizontal/VerticalGroup layouts inside a scroll view
  1. We include new classes TCastleHorizontalGroup, TCastleVerticalGroup to easily layout your controls horizontally or vertically.

  2. FreeType library on Android (thanks to Benedikt Magnus!).

  3. TCastleEdit.AutoOnScreenKeyboard (also thanks to Benedikt Magnus!). Note that the keys from the on-screen keyboard are not yet automatically passed to your applications — we’re working on it.

  4. Many parts of the user-interface (TUIControl descendants) are now calculated using floating-point values, and can even be specified using floating-point values. E.g. you can now use FloatWidth instead of Width, CalculatedFloatWidth instead of CalculatedWidth, ScreenFloatRect instead of ScreenRect and so on. Some of the public properties have also just changed to be floats (like padding, margins, anchors deltas), which may break compatibility in rare cases.

    The primary reason for this change is that when using UI scaling, it doesn’t really make sense to limit sizes or positions to integers. They do not hit the exact pixel boundaries anyway (in case some UI scaling is applied), instead they should be rounded to pixels only at the very bottom of the rendering code. So anchors and such should be calculated using floats, otherwise a Round() in the middle of an operation (before we work in the “final” resolution) would needlessly make UI controls “snap” to an invisible grid.

    A minor reason is also that this is more friendly to animations. Although animations could be done earlier too (having an “animation driver” remember position as float). But it’s easier now, you can just animate existing float properties, like

    Control.AnchorHorizontalDelta := Control.AnchorHorizontalDelta + UpdateSeconds;

    in your OnUpdate event.

  5. Improvements to VisibleChange to help with implementing controls that react to children changes.

Comment on this post ➤

Engine improvements: Rejuvenated PlayAnimation method (easily play animations backward, with blending, stop notifications…)

Posted on

"The Unholy Society" NPC (and enemy), animated with PlayAnimation
PlayAnimation demo with animation blending
view3dscene controllig animation forward/backward

I have a large backlog of new Castle Game Engine improvements to announce 🙂 Let me try to make it up, by making a new announcement more-or-less daily for the following week. Remember that everything I describe is available to you right now: simply use the Castle Game Engine version from GitHub (6.5).

  1. We start with the improvements to our PlayAnimation method. It is the primary way to run animations using Castle Game Engine (documented in the manual).

    • New overloaded PlayAnimation version with TPlayAnimationParameters, that allows to specify:
    • New overloaded PlayAnimation(AnimationName: string, Loop: boolean) version. This replaces (deprecates) older overload with "Looping: TPlayAnimationLooping" parameter — the TPlayAnimationLooping did not really prove to be of much use, so it’s simpler to just specify Loop as a boolean.

  2. I have also written a large documentation “How to animate things using X3D”. This may be useful for developers that want to understand how the X3D nodes are used for animations. The PlayAnimation method, under the hood, uses the X3D nodes.

Comment on this post (1 comment now) ➤

Connect4 – new Android game using Castle Game Engine

Posted on

Connect4 screenshot

We’re proud to present Connect4, a free game for Android published by Benedikt Magnus and LanIstAn today!

The game is using Castle Game Engine, with our 2D user-interface rendering, and includes music, localization (English, Polish, German, Spain), and networking support. You can plan against a computer, or against a friend over the network. I believe this is the first game with networked play done using CGE.

I really like this part of developing Castle Game Engine — seeing how others are using it to create the coolest things. Congratulations and thank you!

We also have a ton of new features added to Castle Game Engine lately. In particular, thanks to Benedikt Magnus we now have:

Thousand thanks!

And I’ll be posting more about the new CGE features later.

Comment on this post ➤

Castle Game Engine is now Embarcadero Technology Partner

Posted on

Chinchilla model in X3D, based on high-poly version in "Big Buck Bunny"

We are now officially Embarcadero Technology Partner!

What this means, in simple terms, is that Michalis has full access to the latest Delphi version, with all the Delphi platforms (including Android and iOS), for free.

This should be great news for everyone waiting on Castle Game Engine + Delphi compatibility:) We have no more excuses now, Castle Game Engine will have to work perfectly with Delphi!

Thanks go to Embarcadero, and in particular Jim McKeeth, for making this possible.

(P.S. I curse myself for making this announcement on the one day of the year when everyone else is making jokes 🙂 Yes, this is very real, and is happening! Our supported compilers and IDEs page is already updated about it.)

Comment on this post (4 comments now) ➤

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 (1 comment now) ➤

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

Posted on

Shadow maps in Castle Game Engine

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

"The Unholy Society" curve on bridge
  1. Our website has moved: It is now on https://castle-engine.io/ . 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 https://castle-engine.sourceforge.io/ continues to work, but it now simply redirects to https://castle-engine.io/ .

    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: https://castle-engine.io/latest.zip.

  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 (4 comments now) ➤

Mobile View3Dscene Coming Soon

Posted on

view3dscene-mobile: Options screen, with table view
view3dscene-mobile: navigation method popup
view3dscene-mobile: About screen

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

Lego "buggy" model in Collada
view3dscene controllig animation forward/backward
Engine in Collada

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 ➤