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!

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 opengameart.org 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 opengameart.org submissions, the assets must also be clearly marked with an open-source license. And, like all opengameart.org 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 opengameart.org-submissions. 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 🙂

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
   

1. Sound engine improvements:

   • Easy additional simultaneous music tracks, for easily playing looping sounds, using the new LoopingChannel property.

   • Added a <group> element to group your sounds in “sound repository” XML files. See the manual about “Sound”.

   • We auto-detect extension (.wav, .ogg) if no URL is specified for <sound> in “sound repository” XML files (previously we assumed .wav).

2. The paper Tornado statistics in Ukraine based on new data is using Castle Game Engine for visualizations!

3. Our xxx_compile.sh scripts now just call the build tool. See this commit log for numerous reasons why this is better.

4. Our website is now protected by Cloudflare. In case of outage, you will see a cached version.

Sorry for being so quiet lately, lots of work! A big announcement about a big new feature is on the horizon, but I am not ready yet. 🙂

1. ClipPlane allows you to define custom clipping planes.

   See our documentation of nodes, X3D documentation of ClipPlane, and a simple demo or very complicated demo.

   Remember that this node can be specified in an X3D file (which you can open using e.g. view3dscene or load to TCastleScene), or it can be added and changed using Pascal code (use TClipPlaneNode class).

   While we already had this feature in the past, it was broken in the modern shader pipeline. It is fixed now, and will work both in modern OpenGL and on mobile OpenGLES 🙂

   • in OpenGL >= 3: use built-in gl_ClipDistance

   • in OpenGL < 3, keep using gl_ClipVertex,

   • in OpenGLES: use own castle_ClipDistance, discard in fragment shader.

2. We also have a new example showing how to use TInputShortcut and save it to a config file.

1. New class TCastleScreenEffects offers easier, and at the same time more flexible API to control screen effects.

   • It has a simple AddScreenEffect method that takes X3D node graph with TScreenEffectNode.

   • New demo showing screen effects is in examples/screen_effects_demo.

   • The screen effects can now be applied over any other UI control output (placed as children of TCastleScreenEffects). E.g. trivial TCastleImageControl or complicated TCastleSceneManager.

     For the special case when using with TCastleAbstractViewport (TCastleSceneManager, TCastleViewport), it is even easier, as TCastleAbstractViewport now descends from TCastleScreenEffects, and exposes AddScreenEffect method immediately.

   • We have also added new (float-based) GLSL functions available for screen effects authors. The documentation how to create screen effects shader code is here.

2. An important optimization of Text node memory usage. Previously a scene with many Text nodes could really eat a lot of memory.

3. BLEND* multi-texture modes fixed, and many multi-texture modes that can work only on RGB/alpha channels implemented in the shader pipeline. The specification of all supported multi-texturing modes is here.

Eugene Loza implemented basic Minecraft mechanics as a Castle Game Engine demo! You can build with right-click or dig with left-click.

The complete (clean and simple) source code is available on https://gitlab.com/EugeneLoza/CastleCraft .

See the movie:

The implementation of our “easy mirrors on flat surfaces” is more-or-less complete now. I’ll be working on a documentation and better demos soon. For now, see the description below.

Features:

• Setting up the mirror is a matter of using X3D node ViewpointMirror with RenderedTexture (to get a texture containing mirror), and applying this texture with generated coordinates by TextureCoordinateGenerator { mode "MIRROR-PLANE" }.

• A working demo is in viewpoint_mirror.x3dv. Just get the demo-models repository and open viewpoint_mirror.x3dv inside with view3dscene from snapshots or any Castle Game Engine 3D example. A better demo will follow shortly, showing also how to use this with Blender and Pascal, without hand-crafting an X3D file.

• Multiple mirrors work nicely and can produce recursive reflections (when a mirror is visible in a mirror). Each frame updates the mirrors based on their previous contents, so the recursion depth is practically unlimited with zero cost.

• A mirror texture can be mixed with material and other textures using multi-texturing, just like any other texture.

• The mirror geometry can be any complicated shape. It doesn’t have to be a simple quad! However, it should be more-or-less planar (we automatically calculate a best fit plane looking at geometry) in order to get sensible results.

• The texture mapping TextureCoordinateGenerator is done by shaders on GPU. So it remains fast even for complicated objects. The mirror itself is rendered using FBO.

This work is sponsored by the Castle Game Engine supporters on Patreon, in particular thanks go to Robert Daniel Murphy for requesting this feature. If you like what I’m doing, please consider supporting me! Thank you.

Mirrors on flat 3D objects that work “out of the box”! More information how to use this soon:)

This feature was implemented thanks to the support of Castle Game Engine on Patreon. In particular thanks to Robert Daniel Murphy for requesting this feature! Thank you everyone for supporting me.

We proudly present a new trailer for our game “The Unholy Society”:

It’s all in-game footage, everything is done using Castle Game Engine. Most of the graphics is done in Spine, and rendered and animated using TCastle2DScene (see more info about using Spine in Castle Game Engine). The UI (fight symbols, items) is using standard CGE UI (TUIControl descendants). We have a simple custom language for conversations and scripting (see also Google Doc version of this post).

You can wishlist the game on Steam!

The game is developed by Cat-astrophe Games, an indie game studio in which Michalis is the main (and only, although that may change soon) developer. Coincidentally, we’re doing all our projects using Castle Game Engine 🙂