Month: September 2018

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”:)

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

We have a number of engine improvements to announce:

• A new way to access data files is to use a special protocol castle-data, like this: castle-data:/images/my_image.png. This is exactly equivalent to using ApplicationData('images/my_image.png'). During development, it will simply load a file data/images/my_image.png from your project.

  The “data” directory is documented in a new manual page. It is also listed on a reworked manual page about networking, downloading and URLs.

  The advantage of the castle-data protocol is that it can be used easily from other data files, like X3D or xxx.castle-user-interface created by Castle Game Engine Editor or Lazarus .lfm. The CGE editor already automatically uses this protocol if you open an image or 3D model within the data subdirectory of the project.

• We use AMD Compressonator, cross-platform and open-source, instead of old ATI Compressonator / AMD Compress. See the documentation how to automatically compress your textures.

• New manual page nicely summarizes supported model formats.

• The editor keeps improving. You can add, delete components, you can start a new file from any root (so e.g. you can start building user-interface rooted in TCastleUserInterfaceRect, or TCastleSceneManager), you can see the effect of the UI scaling, we automatically detect when you open a file in project data (and use castle-data protocol), you can easily add a scene with a primitive (like a box or plane, using PrimitiveGeometry underneath).

• Our Jenkins (Cloud Builds) includes a macOS machine now. The Linux build now makes Linux/x86_64 builds.

• Performance fixes for CustomRenderingPass and weSilhouette.

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!