1. The need to define symbol CASTLE_ENGINE_LGPL to get LGPL engine (otherwise you only had GPL) disappears. The whole engine can be used on a permissive LGPL terms out-of-the-box now, there is no point in defining the CASTLE_ENGINE_LGPL symbol anymore.

   I have clarified and simplified our license terms on https://github.com/castle-engine/castle-engine/blob/master/COPYING.md . In short: we’re exactly like FPC and Lazarus. Yes, you can make closed-source applications using CGE.

2. We have a new NURBS implementation, developed by Michalis from scratch. I deleted the old (GPL-only, copyright by White Dune developers) implementation in this commit, and later implemented new one (LGPL, copyright by me) in subsequent commits. So the LGPL engine supports NURBS now.

   The new implementation also got some serious optimizations (utilizing the fact that we usually calculate not one point on a curve/surface, but a number of such points in a series).

   The new implementation also features a helper method TNurbsCurveNode.Point. See this test for a quick usage example. This allows you to use NURBS curves calculation for any purposes, not necessarily by placing the NURBS nodes inside TCastleScene.

Busy month! Partially due to developing the last chapter of our game The Unholy Society, in which a certain-special-someone is scheduled to appear 🙂

New stuff in the engine:

• Important bugfix: Changing the FullScreen property of the window is now more reliable. The actual change (which may involve recreating OpenGL context) happens with delay, not immediately at the point you assign the “FullScreen” property. This makes it safe to use always, even during Window.OnOpen / Application.OnInitialize. Thanks for Ninjamida from Discord for finding this nasty bug.

• SceneManager.OnProjection event along with a demo switch_projection.lpr showing how to use it to toggle between orthographic/perspective projection.

• TAbstractBindableNode.Bound property.

• More reliable on-screen keyboard on Android thanks to Benedikt Magnus!

New website improvements:

• You can now comfortably switch between viewing API documentation for engine stable version (6.4) and unstable (6.5). The currently viewed version is clearly visible, and when switching we try to show the same identifier (if it exists in the other version).

• The “search” in our documentation is better now (highlights found terms, no messed up HTML) as I improved the “tipue search” functionality in PasDoc.

• I have adjusted our analytics (Piwik) settings to be compliant with GDPR and anonymize the IP addresses and delete old data. Our privacy policy was reflected about this.

  P.S. Have you seen a new pretty webpage of our studio Cat-astrophe Games ? 🙂 My cats are there!

Retired: GitHub -> SourceForge SVN synchronization

Our GitHub -> SourceForge SVN synchronization (using forked sync2git) started to have problems.

(Details: The synchronization repository got into a state unexpected for git-svn. Possibly the underlying reason was a random SourceForge connectivity issue, but that’s speculation.)

Since I don’t think anyone is using SourceForge SVN anymore, I just turned it off, and I made sure no links to SourceForge SVN repository exist anymore on our website. Please use only CGE repositories on GitHub from now on, in particular the main Castle Game Engine repository.

Note that you can still use either GIT or SVN client to get Castle Game Engine. GitHub supports doing “svn checkout” on a GitHub repository (or a subdirectory of it).

1. We added a simple demo how to detect which scene (TCastleScene) was clicked with the mouse: https://github.com/castle-engine/castle-engine/blob/master/examples/3d_rendering_processing/detect_scene_clicks.lpr .

2. The behavior of shadow maps when combined with CommonSurfaceShader is now correct. Testcase: https://github.com/castle-engine/demo-models/blob/master/shadow_maps/primitives_with_commonsurfaceshader.x3dv

3. view3dscene no longer uses console for various messages. Instead we display our own message box, with contents that can be copied to clipboard with Ctrl+C. This makes it more comfortable to use as a normal GUI program, in particular on Windows. Remember that you can always download the latest view3dscene snapshots from here. (Or you can compile view3dscene from source, of course.)

4. Our website supports now IPV6, HTTP/2, has better redirects (from www domain to non-www), and is HTTPS-only (non-secure HTTP merely redirects to HTTPS, and we use HSTS). Thanks to Raul Tambre for suggesting and testing these improvements!

To finish the week of many annoucements, here are 3 more engine features added lately.

BTW, I also wrote a wiki page documenting common properties to “make rendering prettier”. Check it out:)

New engine features:

1. Scene.Attributes.SeparateDiffuseTexture allows to get a prettier lighting behavior. The textures (in Appearance.texture or CommonSurfaceShader.diffuseTexture) will then really affect only the diffuse lighting term. This is generally better and prettier (specular highlights are then brighter), and it’s also more correct (according to X3D spec). But note that it is only possible in Phong shading (when Scene.Attributes.PhongShading is also true), and it makes rendering a little more expensive (for now).

   In view3dscene (see view3dscene from snapshots) you can use menu item View -> Separate Diffuse Texture (When Phong Shading) in addition to View -> Phong Shading on Everything. By default it is false, to be compatible with previous look, and also because it’s more consistent with Gouraud shading behavior. (And the Gouraud shading is default, in turn, for speed.)

2. Client and server classes for implementing TCP client/server communication in Castle Game Engine games are available. See the unit CastleClientServer, and the demos in examples/tcp_connection. Thanks go to Benedikt Magnus for implementing this!

3. You can now instantly disable/enable physics by setting SceneManager.Items.EnablePhysics to false/true.

Since a long time, you can automatically generate compressed and/or downscaled textures versions using our build tool.

This process is now smarter. Instead of detecting which files to update looking at file modifications times, it now looks at file contents (using fast MD5 checksums), and automatically creates/updates a castle_engine_auto_generated.xml file. The castle_engine_auto_generated.xml is automatically created and maintained in your data/ directory when you call castle-engine auto-generate-textures.

We plan to extend this feature even more, to store more information inside the automatically-maintained castle_engine_auto_generated.xml. In the future, this file can be used to:

1. Track the size of the texture. This allows to avoid trying to load non-square compressed texture on iOS, which is not possible — thanks to weird Apple limitations. Currently we just avoid using any auto-generated compressed textures on iOS.
2. Track the DXT* version generated, for the case when we automatically choose the best DXT* version depending on the image alpha channel. This would complete a currently unfinished-and-undocumented feature of <format name="DXT_AutoDetect" /> in material_properties.xml.

You can now comfortably localize (translate) your game.

Two approaches are possible:

1. Use our own localization class from the CastleLocalization unit. It can read from a number of translation formats (XML, JSON, CSV, GetText MO). It can translate user-interface controls, like TCastleLabel. The demo is inside examples/localization/custom/.

   For advanced users, the system allows to aid in localizing your custom classes too (see OnUpdateLocalization) and to add your own translation formats (see FileLoader).

   Thousand thanks go to Benedikt Magnus for developing this!

2. Use the standard GetText unit from FPC. You use GetText formats for translating (PO, MO), utilizing tools like PoEdit. The resourcestrings are translated automatically. The demo is inside examples/localization/gettext/.

   The engine uses resourcestrings for some internally-generated messages (and it will use them more), so these can be translated too.

In both cases, you can use a cross-platform CastleSystemLanguage unit that tells you the preferred user language.

Note that, while both approaches (GetText, our own) provide some infrastructure to aid you in translating (resourcestrings, special handling for UI controls), you can also translate things “explicitly” in both cases. Using the TMOFile.Translate(‘my_id’) in GetText, or Localization.Items[‘my_id’] in CastleLocalization.

So both systems are really flexible, and should fill all your needs 🙂

A related feature is also new TInputPressRelease.KeyString. This expresses key press as a string with UTF-8 encoding, and allows us to accept input of international characters across Castle Game Engine (for example in TCastleEdit). Many thanks go to Eugene Loza for this!

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.

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.

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:
     • StopNotification: Easy and reliable way to watch when animation stopped.
     • TransitionDuration: Animation blending (see my earlier post).
     • InitialTime: Start animation from the middle.
     • Forward: Play animation forward or backward.
     • It also, of course, allow to specify basics: animation Name and whether it loops.
     • It is the only way how we animate stuff in our new game “The Unholy Society” (well, aside from some user-interface animations), so it’s really flexible.

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

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:

• cross-platform support for networking using TCP,
• FreeType library available on Android, and
• we will have a custom localization system (in addition to being able to just use GetText for localization).

Thousand thanks!

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