Big user-interface and editor improvements

Posted on

  1. The editor supports selecting, translating and resizing UI controls (possibly with snap). You may have already seen it in the movie.

  2. It is possible to use custom components within the editor.

    New build tool command “castle-engine editor” will run Castle Game Engine Editor within the current project, with possible project-specific components. It will automatically build CGE editor with additional project-specific components included.

    See the editor README, section “Include custom (project-specific) components in the visual designer”.

  3. The editor has menu items to adjust camera (Scene Manager Camera View All), and to reorder 2D scenes (Scene Manager Sort For Correct 2D Blending).

  4. Much more vectors and colors are editable and persistent in the editor. E.g. TCastleLabel.Color, TCastleTransform.Translation/Rotation/Scale.

  5. New property TCastleUserInterface.AutoSizeToChildren allows to adjust size to include all children. In particular useful for TCastleScrollView.ScrollArea.

  6. The user interface coordinates (all positions, sizes) are float-based now. In other words, TCastleUserInterface.Width, TCastleUserInterface.Height, and a lot of “friends” now have a type Single, not Integer. In some cases, we deprecated old integer-based property (like TCastleUserInterface.CalculatedWidth, TCastleUserInterface.ScreenRect) and added a new float-based replacement (like TCastleUserInterface.EffectiveWidth, TCastleUserInterface.RenderRect).

    Note: This change may break backward compatibility in some cases. You may need to adjust your code. This was unfortunately unavoidable, the API looked really messy when I was trying to maintain 100% backward compatibility (having both integer-based and float-based methods and properties). Details in this commit log.

    If you just did MyControl.Width := 100 it will work as before. But if you did e.g. MyInteger := MyControl.Width, or MyInteger := MyControl.Width div 2, it will no longer work, as Width is a floating-point value (Single) now. You will need to adjust your code. You can just write Round(MyControl.Width), or you can adjust your code to use float-based coordinates everywhere too.

    If you use rectangles, you can convert between integer-based (TRectangle) and float-based (TFloatRectangle) using MyFloatRectangle := FloatRectangle(MyIntRectangle) or MyIntRectangle := MyFloatRectangle.Round;.

    If you encounter troubles adjusting your code, please let us know on Discord or forums, we will help!

  7. TCastleUserInterface now has a size (Width, Height, FullSize properties). The TCastleUserInterfaceRect, TUIControl, TUIControlRect are all now just deprecated aliases for TCastleUserInterface.

  8. All UI controls have non-zero size by default. The base TCastleUserInterface class sets width and height to 100. This is more friendly (especially when using the editor) than previous situation when TCastleUserInterfaceRect / TUIControlRect had by default zero size.

Comments on the forum ➤

“Modern Object Pascal Introduction for Programmers” translated to Russian

Posted on

Thanks to Alexander Skvortsov and Yevhen Loza, the complete book “Modern Object Pascal Introduction for Programmers” is now available in Russian. Read it here in the Russian version:

My many thanks go to the translators for the huge task they did. The translation includes the complete text, comments in the example code, and they also improved and enhanced the English text as well.

It’s all merged now into the GitHub repository, where English and Russian sources (in AsciiDoc) live side-by-side.

P.S. If you’re looking for the English version, it’s (as always) here:

Comments on the forum (4) ➤

Article about CGE in Blaise Pascal Magazine (free for Patrons), also: meet me at Lazarus Professional Conference next week

Posted on

  1. The next issue of Blaise Pascal Magazine will contain a nice long article I wrote about Castle Game Engine! 20 pages, describing how to use the engine from absolute basics, showing how to construct a simple cross-platform 3D game using TCastleWindow, TCastleScene, TCastleTransform, SoundEngine features. I am quite happy with it 🙂

    I will also make the article available for all Patrons of Castle Game Engine at the end of this month (September). If you would like to support the development of CGE, now is the time 🙂

    The article is accompanied by a public example code and data.

  2. I will also be present next week an the Lazarus Professional Conference in Bonn. You can meet me on Saturday (22 September), during Community Day, when we will be showing Castle Game Engine.

    Please drop by to talk, or just to say “hi”:)

Comments on the forum ➤

X3D Standard Plans, Michalis Professional Membership in the Web3D Consortium

Posted on

Shadow maps in Castle Game Engine

Since a week, Michalis is a Professional Member of the Web3D Consortium. These are the people who make X3D specifications, see also our documentation how X3D fits within Castle Game Engine. By being a “professional member” I will have some extra access (e.g. to see draft specs of upcoming X3D versions) and some influence to take X3D into interesting places 🙂

My vision and goals for X3D is documented publicly in my “x3d-tests” wiki. This wiki contains an overview + lots of details what I would like to see in X3D standard. Many of the ideas revolve around bringing X3D more “aligned” with glTF 2.0 feature set. Which is of course closely tied with getting glTF 2.0 into Castle Game Engine, as an X3D scene graph. I believe that this is a solution in which everyone wins, i.e. we will have an engine with perfect interchange format (for which glTF 2.0 is now better, although X3D tries to catch up) and a perfect scene graph (where X3D shines already).

Comments on the forum ➤

Improvements: castle-data protocol, new editor features, AMD Compressonator, better model formats docs…

Posted on


We have a number of engine improvements to announce:

Comments on the forum ➤

Castle Game Engine Editor!

Posted on

Screenshot of selection at 2018-09-01 02:46:05
Screenshot of selection at 2018-09-01 02:46:15
Screenshot of selection at 2018-09-01 06:40:56
Screenshot of selection at 2018-09-01 06:41:27
Screenshot of selection at 2018-09-01 06:41:59
Screenshot of selection at 2018-09-01 06:43:27
Screenshot of selection at 2018-09-01 06:43:48
Screenshot of selection at 2018-09-01 06:43:56

I’m proud to present first public screenshots from the upcoming Castle Game Engine Editor!

The goal of the editor is to allow you to manage CGE projects (create, build, run…), visually design hierarchies (of user interface controls and 3D/2D models) and browse project assets. Yeah, just like those other big game engines:)

A more precise list of features is in the README at the editor source code. And this is all following my plan for editor in 2018.

What does actually work now?

  • You can create a project from a template, or open an existing project. Project is just any directory with CastleEngineManifest.xml file.
  • You can compile / run / package / generate textures and do other usual operations on the project. The output, like compilation output, as well as program log (regardless of the OS) is displayed at the bottom. The editor calls the build tool for these operations, which in turn calls FPC and other tools.

  • You can open and save a designed user interface (anything descending from TCastleUserInterface, formerly TUIControl) and 3D/2D game models (anything descending from TCastleTransform). They are serialized using Pascal RTTI (JSON format produced by FpJsonRtti). The editor, as well as your own game, use CastleComponentSerialize unit to do this. The files have extensions .castle-user-interface or .castle-transform and can be loaded with functions UserInterfaceLoad or TransformLoad.

  • You can edit the published properties of the selected component using the object inspector on the right. It’s all updated “live” in the middle window of course. If you save the edited file, and run the project, you will see that it’s actually using a new design.

  • See the screenshots for the initial stuff:)

Of course, many things are missing now, including some crucial things to make it actually useful for real applications. E.g. dropping new components on the design is not yet implemented. And dragging the UI controls, and TCastleTransform, visually (in the 3D window) is not possible yet. Well, there’s work ahead!

I’m really pleased with the result so far 🙂 P.S. If you like what I do, please consider donating to help in the development of the engine. Thank you!

Comments on the forum (3) ➤

Submit models to with [cge] tag, while we’re working on our Asset Store

Posted on

Screenshot of selection at 2018-08-30 17:14:29

We got excited and we decided to build our own Asset Store:) Initial plans are here.

While it’s being created, I suggest we upload models to and mark them by placing [cge] in the title. This way we can build the content for our asset store today 🙂 We have a persistent link to all models marked [cge], make sure your models appear there.

  • The point of the models tagged with [cge] (and later in our asset store) is to be available in formats that Castle Game Engine can handle. Like X3D, castle-anim-frames, Spine JSON. See the exporting documentation about how to export from various software.
  • Of course, just like all submissions, the assets must also be clearly marked with an open-source license. And, like all assets, you are strongly encouraged (but not required) to upload also a “source” model version (in Blender, Spine etc.), to allow people creating derivative works from it.

  • It is best to test your models in view3dscene (you can use stable view3dscene version, or view3dscene snapshots from the latest GitHub code). Run the animations to see they are OK too, using menu item Animation -> Named Animations (this calls the familiar method PlayAnimation in CGE).

Note: The assets I upload will also be available as part of CGE demo-models repository, in subdirectory So you can also get them from GitHub, and you can submit pull requests to add/modify them. But that’s just my choice, you can host your models in any way you like, just make sure to upload them 🙂

Comments on the forum ➤

Headlight, built-in simple profiler, more

Posted on


New stuff in the engine 🙂

  1. More comfortable control over headlight using TCastleSceneManager.UseHeadlight property. This allows to easily turn headlight on/off regardless of the MainScene existence and it’s contents.

    See also TUseHeadlight type docs. See also new TCastleSceneManager.HeadlightNode property to customize headlight shape.

    A new demo showing how to control the headlight is in examples/headlight_test/

  2. view3dscene has a new menu option Print Current Camera (Viewpoint) (Pascal) that outputs a suitable Camera.SetView(...) Pascal code.

  3. The engine includes a simple time usage profiler (TCastleProfiler, Profiler singleton).

    It is automatically used by various CGE loading routines.

    Simply call Profiler.Enabled := true, and you will get in the log profile of the TCastleApplication.OnInitialize execution.

    Display Profiler.Summary at any point, in any way, in your application, to show the currently gathered profile.

    See the TCastleProfiler docs for more.

    Sample output:

    -------------------- Time Profile begin
    Profile (speed of execution).
    Each line shows time, followed by [time spent in this process], followed by description.
    Lines are sorted within each group, to show the most expensive operation at the top.
    7.35 [7.35] - TCastleApplication.OnInitialize
    > 1.65 [1.65] - Loading .../character/soldier1.castle-anim-frames (TCastleSceneCore)
    > 1.49 [1.48] - Loading .../level/level-dungeon.x3d (TCastleSceneCore)
    > 0.78 [0.78] - Loading All Sounds From .../audio/index.xml (TRepoSoundEngine)
    > > 0.71 [0.71] - Loading .../audio/dark_fallout.ogg (TSoundFile)
    > > 0.00 [0.00] - Loading .../audio/flaunch.wav (TSoundFile)
    2.07 [2.07] - Prepare Resources .../level/level-dungeon.x3d
    -------------------- Time Profile end
Comments on the forum ➤