Inspect your game hierarchy and logs at runtime — just press F12

Posted on

Castle Game Engine Inspector - Mousey glTF animation
Castle Game Engine Inspector - Platformer
Castle Game Engine Inspector - Escape from the Universe

I’m happy to announce a feature that may forever change how you use Castle Game Engine! Simply recompile your game with the latest engine version, press F12 and behold… a powerful tool to see your log and hierarchy of objects in the game.

Watch a presentation:

Yes, this looks effectively like a (very minimalistic) editor-at-runtime. It is cross-platform and automatically available for all your games. Invoke it at any point, and inspect (soon: even edit) the visible CGE objects (UI, transformations, scenes…).

Features:

  • View the hierarchy of TCastleUserInterface and TCastleTransform at runtime (just like in CGE editor)

  • Select any component (by picking it from hierarchy, or hovering mouse over it with various “Auto-Select” options) to see its properties, updated in real-time

  • View logs (each time you press F12, we show 10 last logs, and we’ll collect any more logs that will be submitted while the inspector is open)

  • All panels (hierarchy, properties, profiler, log) can be hidden and shown independently

  • Inspector opacity can be controlled, to better see your game content underneath. The current opacity and panels are remembered when you toggle inspector by F12 repeatedly.

  • Powerful frame profiler shows where do you spend most of the time each frame: update, render, physics, swap. It also shows FPS history.

  • The key to invoke the inspector can be configured, you can also make it available in the release mode. By default, we assign InspectorKey := {$ifdef DEBUG} keyF12 {$else} keyNone {$endif};.

Note: long time ago I had a plan for a different approach to “editor at runtime” : compile with CASTLE_WINDOW_LCL backend, and add LCL UI — reused between “editor at runtime” and actual CGE editor. Downside: it would work only on desktops. For Delphi devs, it would also mean that we need to compile the game with FPC too. Upside: It would be easier to support 100% of editor features. What is the ideal approach? We’ll see 🙂 For now we develop CGE editor using LCL, and in-game inspector using CGE UI, and we’ll see how these 2 approaches converge.

Comments on the forum ➤

Various engine improvements – editing collections in editor, Tiled fix for multiple tilesets, API simplifications

Posted on

Editing collection in CGE editor
Editing collection in CGE editor
Tiled Map Viewer
  1. Thanks to Trung Le (Kagamma), you can now use collection editors in Castle Game Engine Editor just like in Lazarus.

    This allows to visually edit e.g. particle effect anchors in cge-3d-particle-emitter or a TDbf.FieldDefs from castle-db-aware-controls.

  2. Thanks to Matthias (Free Pascal meets SDL), we have an important Tiled bug fixed — in case you used multiple tilesets within one Tiled map. Testcases are within examples/tiled/map_viewer data.

  3. On our quest of simplifying CGE API, we recently removed a useless TInputListener class (it is now a deprecated alias for TCastleUserInterface) and the new non-deprecated name for TUIContainer is now TCastleContainer.

  4. view3dscene supports a new command-line option --no-x3d-extensions if you’d like to convert models from various formats (e.g. glTF) to X3D without any Castle Game Engine X3D extensions. While it may make the models a bit less functional in CGE, it makes them more readily useful with other X3D viewers like X3DOM.

  5. During the development of The Unholy Society for iOS, we noticed a weirdness with Release events on iOS, which stem from how iOS reports touchesEnded / touchesCancelled events. There’s nothing we can do about them (and every iOS application suffers from them, as far as we can tell, regardless of the engine/framework used to make it), so they are just documented now at iOS – Known Problems.

Comments on the forum ➤

Presentation about Castle Game Engine from DelphiCon 2021

Posted on

Our presentation about Castle Game Engine from DelphiCon this week is now available to watch on YouTube! I highly advise watching this to every CGE developer — regardless of your favorite Pascal compiler/IDE. I describe the engine features, and go into a very practical session where I modify one of our templates, showing a number of basic CGE features. I hope you enjoy this!

Comments on the forum ➤

Big Delphi port progress, beta download, watch my presentation at DelphiCon today!

Posted on

Castle Game Engine + Delphi: terrain example
Castle Game Engine + Delphi: compiler preferences
Castle Game Engine + Delphi: IDE preferences
Castle Game Engine + Delphi: 2D game
Castle Game Engine + Delphi: 2D game with log visible
Castle Game Engine + Delphi: play_animations demo
Castle Game Engine + Delphi: play_animations demo with glTF
Castle Game Engine + Delphi: JPEG by Vampyre Imaging Library

All Delphi users: Enjoy now easy link to download Castle Game Engine with Delphi support (beta version) on our main page!

And be sure to watch our presentation at DelphiCon 2021 today!

The development of Delphi port is now happening within PR #350. We have almost everything in CGE working now smoothly in Delphi!

Works:

Some examples that compile and work with Delphi (as well as FPC of course):

  • examples/user_interface/state_events
  • examples/3d_rendering_processing/collisions
  • examples/mobile/simple_3d_demo/
  • examples/3d_rendering_processing/view_3d_model_basic/
  • examples/3d_rendering_processing/view_3d_model_advanced/ (use this to load any model or image from https://github.com/castle-engine/demo-models ! )
  • examples/animations/play_animation
  • all 4 templates created by “New Project” from CGE editor
  • examples/terrain
  • examples/physics/*
  • examples/fps_game

(Soon, all examples will follow.)

For more information, consult also past news about Delphi: 1, 2.

This is a result of large work by Andrzej Kilijański and Michalis since many weeks. Please support us, and sponsor the development of next CGE features by donating on Patreon.

Comments on the forum ➤

Pepper & Carrot – 3D platformer prototype

Posted on

2021-11-07 04_19_45-Greenshot
2021-11-07 04_23_40-Greenshot
2021-11-07 04_24_29-Greenshot
2021-11-07 04_25_23-Greenshot
2021-11-07 04_23_14-Greenshot

We’re happy to present a new 3D platformer prototype made in Castle Game Engine – Pepper and the Potion of Jumping.

You can check out the source code and build it yourself from Pepper and the Potion of Jumping.

Most levels include collecting gems (currently yellow spheres) until you have enough to continue. There’s also a swimming level, 2 flying levels, and a couple of levels where you have to throw snowballs at Saffron, Shichimi, and Coriander. The final level is a ‘boss fight’ (kind of) against 3 dragons and a giant dragon head. Throw snowballs at them to win.

Credits go to ultidonki from our forum — thank you! Please post any feedback in the related forum thread.

Comments on the forum ➤

Foxy Misfortunes – top-down shooter made in Castle Game Engine

Posted on

2021-11-04-233136_1366x768_scrot
screenshot_foxy-misfortunes_384591856225
screenshot_foxy-misfortunes_384591894574
2021-11-04-232609_1366x768_scrot

 

Foxy Misfortunes is a simple top-down shooter with a funny NSFW theme. Download it for Windows, Linux and Android from Foxy Misfortunes (itch.io).

It’s a free and open source game done using Castle Game Engine by Eugene Loza. The source code is on Foxy Misfortunes (GitLab).

In the game you control Foxy – a fox girl who decided to go on adventure collecting golden coins and zapping enemies with lighting bolts, but it quickly turns out that her clothes are her hit-points. Warning: the game contains some adult-only elements, such as cartoon nudity (optional censored mode is available) and mildly suggestive themes.

Comments on the forum ➤

Invoke Visual Studio Code or Delphi from CGE editor

Posted on

Castle Game Engine editor preferences
Visual Studio Code editing Castle Game Engine  program

You can now easily choose to invoke Visual Studio Code or Delphi from the Castle Game Engine Editor preferences window.

This is in addition to the previous options to invoke Lazarus IDE or a custom editor (where you can easily configure e.g. Emacs, my editor of choice 🙂 ).

By default we have Autodetect, which selects the first of Lazarus, Delphi or Visual Studio Code — whichever we find on your system.

Visual Studio Code is a modern cross-platform IDE for various programming languages and frameworks. You can use it with Object Pascal and Castle Game Engine instantly.

Tip: Did you know there’s also a web version of VS Code, easily available? Just go to any repository on GitHub (like castle-engine) and press . (dot) on your keyboard. Woah — a full-featured editor running just in your browser! And it can sync settings. And it is integrated with GIT and GitHub — if you edit a repo where you’re not a member, it can easily create a PR from your edits. I recently listened to GitHub Universe 2021 talks, a lot of interesting content from GitHub, and they integrate new features into VS Code intensively.

The Delphi integration with CGE editor is not a final version — it will be better once we use DDE for inter-process communication to avoid opening new Delphi window each time. More on Delphi progress in later post.

Comments on the forum ➤

Building for Android x86

Posted on

Application running in Android  emulator (x86)
Application running in Android  emulator (x86)
Application running in Android  virtual machine (x86_64)
Application running in Android  virtual machine (x86_64)

The usual Android CPU, used by most of physical Android devices, is Arm (32-bit or 64-bit). But sometimes it makes sense to build for Android x86 CPUs (32-bit x86, 64-bit x86_64). The main use is to run such applications in emulators and virtual machines, like emulators provided in Android SDK or a virtual machine installed using ISO from Android-x86 project.

To do this, build Android APK using our build tool like this:

castle-engine package --os=android --cpu=x86_64

You can add --fast and/or --mode=debug if you want.

Then just transfer the resulting APK inside the Android machine.

If you use an emulator installed by Android AVD Manager, and visible on the adb devices list, you can even install and run (showing logs from the device) using the standard install and run commands of our build tool, like this:

castle-engine --os=android --cpu=x86_64 install
castle-engine --os=android --cpu=x86_64 run

Note: Setting up the emulator using command-line AVD Manager was unexpectedly hard, due to an enormous amount of questions I had to answer about the emulated machine. I recommend to use GUI to create new emulators instead, run Android Studio and from More Actions choose AVD Manager.

Note: The behavior of command castle-engine package --target=android, which you can use to create an APK for a “normal” Android device, has not changed. It still builds only for Arm (32-bit and 64-bit, aka Aarch64), assuming these are systems used on actual devices. Though we’re open to change this some day (if usage of Android x86 rises, and will be useful for more than just “developers testing apps in virtual machines”).

This has already somewhat worked in the past, but now we made it better:

  1. Instructions to setup environment for this are adjusted on Android docs and Android FAQ. Following the stuff related to Android/x86 is completely optional, so if you have a working Android setup and are not interested in x86 support, just ignore it.

  2. Our support libraries are now packaged with x86/x86_64 variants too:

    The precompiled libraries are inside CGE services on Android. So you don’t need to do anything, just package for Android using the build tool commands shown above, and it will add the required libraries.

Comments on the forum ➤

Optimizing memory usage, part 1: efficient step animation, using component system in X3D nodes (no interfaces), less memory used by sprite sheets

Posted on

Lots of sprite sheets with lots of animations

Nudged by the report of high memory usage I want to seriously optimize memory usage of CGE. Right now X3D nodes cost too much in memory — which limits some use-cases (when spawning a lot of TCastleScenes would be the most natural solution), and it affects both loading and runtime performance (as loading is slower when you need to clone/initialize more memory, and performance is slow when the cache is underutilized).

A first wave of improvements has already landed in the engine. A 2nd wave is in progress — it depends on remaking how all X3D nodes are set up, so it’s a big rework (but it was a long time coming).

Things done now:

  1. We now have an efficient step interpolation mode (see TInterpolation), used automatically by sprite sheets and glTF models with step animation.

    While “step” interpolation was possible previously, but it was (ab)using the linear interpolation calculation, by duplicating keys. This was wasting both memory (2x data needed) and time (doing useless lerp operations).

  2. We have simplified our X3D nodes inheritance. We use now TNodeFunctionality (a simple component system inside X3D nodes) with some descendants like TTimeDependentFunctionality and TTransformFunctionality. We no longer use Pascal interfaces for them. There are actually 2 reasons for it:

    1. In some cases, we really wanted to share implementation, not just API. So interfaces were never a proper tool.

      In effect our new TTimeDependentFunctionality is a much simplified and more natural old TInternalTimeDependentHandler, the new concept just fits our needs better.

    2. I never really grew to like COM interfaces. In FPC/Lazarus we have CORBA interfaces, and I made no secret that I like CORBA interfaces much more (basically, they work more like Java and C# interfaces, and are not entangled with unrelated things like memory management or COM technology). But Delphi only has COM interfaces, so CORBA interfaces are not available to us.

      This introduces quirky code when using interfaces, as we do not want the automatic garbage collection that the COM interfaces bring (and one has to watch out for it, even with hacked _AddRef, _Release like TComponent does). So one has to watch for lifetime of temporary values.

  3. CoordinateInterpolator in sprite sheets can be often much simpler or even removed completely. This saves memory and execution time.

Comments on the forum ➤

Watch our presentation at DelphiCon on November 17th

Posted on

Castle Game Engine window rendered from Delphi

This year DelphiCon, an annual Delphi conference, is fully online and free. As we’re working hard on a Delphi port right now of course I will show Castle Game Engine there! I guess it will be the first public showing of CGE on Delphi.

Register for the talk here!

Our presentation is on November 17 (Wednesday). The whole conference is 16-18 November, there’s a lot of talks including stuff around cross-platform dev — check it out 🙂

Comments on the forum ➤