Joystick improvements

Posted on

Joysticks demo in Castle Game Engine

Thanks to Eugene Loza work on the Steam release of “The Unholy Society”, you can now detect when joystick is being connected or disconnected.

Simply assign your own event to Joysticks.OnConnect and OnDisconnect.

By default nothing is done. But you can call e.g. Joysticks.Initialize to reinitialize joysticks, thus automatically accounting for the newly connected or disconnected joysticks. A demo of it is inside our examples/joystick/ application.

In games where joystick support is essential, or in “multi-player games on a single device” (many people playing on a single computer with multiple joysticks connected) you can use these events to automatically pause the game, display the player configuration screen etc.

This allows to meet Steam recommendations on joystick behavior.

Comments on the forum ➤

iOS improvements

Posted on

d1

iOS is the platform used by Apple iPhone and iPad devices. We’ve made a number of improvements to it, caused by upcoming The Unholy Society for mobile:

  • New build tool options to build and deploy (“archive” in Xcode terms) iOS application from the command-line (in batch mode). For example, use castle-engine package --target=ios --package-format=ios-archive-ad-hoc to get an IPA file of your application, which can be uploaded to your devices or TestFairy. It is documented in the Castle Game Engine for iOS page.

  • Suport for square compressed textures on iOS.

    Note: BTW, castle_engine_auto_generated.xml was renamed to CastleAutoGenerated.xml, following our conventions for other CGE-special files.

  • FreeType support on iOS. This means you can freely load font files (TTF, OTF) at runtime on iOS. You don’t need to do anything special to activate it, just load font files as decribed in our manual and it will work on iOS.

Comments on the forum ➤

Android improvements – view3dscene-mobile alpha, glTF reading and more

Posted on

view3dscene-mobile
view3dscene-mobile: Options screen, with table view

We’re busy making view3dscene-mobile and The Unholy Society for mobile 🙂 This caused a number of Android-specific improvements to CGE:

Comments on the forum ➤

The Unholy Society Release

Posted on

The Unholy Society

We’re proud to announce the release of “The Unholy Society”, a quirky 2D adventure game by Cat-astrophe Games. The game is available right now on Steam (for Windows and Linux) and Nintendo Switch.

The game is using our Castle Game Engine for everything, of course 🙂 The programming part was done by two CGE developers — Michalis Kamburelis and Eugene Loza. And the complete game credits go to the whole Cat-astrophe Games team of course.

This is only the first part of adventures of our hero BonBon. Soon it will be available on mobile devices (iOS and Android) too! Subscribe to Cat-astrophe Games news to comment and learn more.

Comments on the forum ➤

Remote logging sample, TestFairy integration on Android and iOS

Posted on

TestFairy with Castle Game Engine projects

I added to our Castle Game Engine two very useful features for remote debugging:

  1. You can register custom event on the ApplicationProperties.OnLog list. This allows to observe all the CGE logs (including warnings).

    For example you can send these logs to a remote server. This CGE example shows how to do it. It assumes you have your own server with a simple PHP script somewhere (the PHP example script is also included in the sample code).

  2. You can integrate your mobile game with TestFairy. It is a mobile testing platform that allows to distribute test applications easily (on both Android and iOS). It can also (optionally) gather logs from testers, their device details (phone model etc.), and even record videos of their playthrough.

    For video and logs gathering in CGE, you need to use an Android service test_fairy and iOS service test_fairy.

    Note that TestFairy is a paid service. But they also have a free plan (Essentials Kit).

Comments on the forum ➤

What is gamma correction, and thoughts about how it will find it’s way in future CGE and X3D

Posted on

glTF in Castle Game Engine

Recently I did a little reading about what is “gamma correction” in computer graphics. It’s actually a simple concept with a simple implementation (at least in the basic approach), and I summarized my knowledge here: Gamma correction in X3D and glTF.

I investigated how it relates to the glTF standard (and it’s sample implementation). Of course it will eventually find it’s way into Castle Game Engine and future X3D too.

Comments on the forum ➤

Convert to X3D (from glTF, OBJ, STL, Collada, …) and change X3D encodings using online Castle Game Engine converter

Posted on

Convert to X3D webpage

I made a cool online tool using Castle Game Engine:

Convert your 3D models to X3D!

It allows to

Underneath, it uses tovrmlx3d (command-line application distributed
together with view3dscene)
.

It’s free to use for everyone. It’s of course open-source, both the tovrmlx3d and view3dscene, and a set of scripts (PHP, Docker and shell scripts) to make it work as an online tool in a secure and reliable way.

More information on the tool page. Give it a shot, test your models on it! 🙂

Comments on the forum ➤

Animating by mesh deformation in Spine, physics spiral of death avoidance, examples and manual upgrades

Posted on

Spine Free-Form Deformation example
  1. We now support Spine “Free-form Deformation”, which allows to animate (deform) the mesh by moving particular vertexes around. This is a great feature to animate e.g. facial expressions.

    A demonstration how it works in CGE is here. An instructive video how to create FFD animation in Spine is here. We also have a sample model using it inside our demo models, in spine/free_form_deformation.

    Big thanks go to Trung Le (kagamma) for implementing this!

  2. Thanks to Andrzej Kilijański, our physics integration is now secure from the “spiral of death” that could occur when the physics simulation takes a long time to calculate (and, in effect, physics would need to account for larger and larger time spans, taking even more time).

    It works automatically, but you can adjust Viewport.Items.PhysicsProperties.MaxPhysicsTicksPerUpdate to tweak it.

  3. I made lots of updates to our manual and CGE examples, such that they describe the most advised way to use CGE API (after recent refactors). Almost everything now uses the TCastleViewport and TCastleWindowBase and initializes navigation and camera in a simple way.

Comments on the forum ➤

Big engine plans for 2020, Trello boards, X3D PBR

Posted on

The Unholy Society - sister talk
Castle Game Engine editor with scene manager menu
Effects of dynamic batching
New Raspberry Pi in Michalis hands :)
escape_universe_screen_1
Escape from the Universe - space map design
Escape from the Universe on Nintendo Switch - design
Castle Game Engine - strategy game demo - hexagonal Tiled map

As the 2019 is ending, it’s a good moment for a summary. What did we achieve, and what do we want in 2020?

  1. First of all, I’m very happy with a huge number of new engine features. This includes CGE visual editor, significant improvements to the important APIs (viewports, cameras, user interfaces), Nintendo Switch support, glTF support.

    This leads me also to our most critical TODO for 2020: We really need to release the next CGE version 7.0, as a “stable” version. Yes, it will be called 7.0 (not just 6.6) — we have a number of new major features (and some unavoidable incompatible changes).

    The release-blocker now is making the “gizmos” to allow to comfortably transform TCastleTransform in the editor.

  2. I want to say enormous “thank you” to everyone who contributed to the engine in 2019, or made games using CGE. In particular big thank you goes to the Eugene Loza, Andrzej Kilijański and Kagamma for your pull requests and all the conversations.

    This point also leads me to another TODO: I want to manage our work better. We want to make the best open-source game engine, and I’m not going to stop until we get there 🙂 For this purpose, I created public Trello boards to manage CGE work. If you’d like to join CGE on Trello, just let me (Michalis) know. Everyone is invited.

    Note that Trello is not supposed to replace GitHub issues. GitHub is still great to submit bugs (issues) or PRs. But Trello may be better to organize tasks (by task here I mean ““something that needs to be done”, which isn’t always a bug, and some tasks have complicated dependencies — some tasks are blocked by other tasks, have subtasks etc.). I feel that Trello is great to manage such tasks.

  3. Technical most important features to implement in 2020:

    1. Delphi compatibility. You asked for it, and it’s started. It will open us to a whole new pool of engine users (and potential contributors).

    2. Support glTF skinned animations. glTF is becoming the de-facto standard for interchanging 3D animated models. We already support glTF, but we miss this important feature.

    3. Physically-Based Rendering. I’m leading the X3D 4.0 specification changes related to this. We want to finish the spec in January, and later implement PBR in CGE.

    That’s it, in summary. Of course I have more plans 🙂

Have the best 2020! Let’s make good code, and good games. We are open-source, we love writing code, we love telling stories, we love designing fun games. Let’s do it:)

Comments on the forum ➤

Last refactor before CGE 7.0 release: Say hello to TCastleViewport and TCastleWindowBase, say goodbye to TCastleSceneManager and TCastleWindow

Posted on

multiple_viewports

This week I finished the last big engine API change before the next release! TCastleSceneManager is now deprecated: instead you should use TCastleViewport to display 3D models. This makes things much simpler, and it allowed me to make TCastleViewport defaults much better.

1. TCastleViewport

A simplest working source code demonstrating this (it will compile — get the engine and test it!) looks like this:

uses SysUtils,
  CastleWindow, CastleSceneCore, CastleScene, CastleViewport, CastleCameras, CastleVectors;

var
  Window: TCastleWindowBase;
  Viewport: TCastleViewport;
  Scene: TCastleScene;
begin
  Window := TCastleWindowBase.Create(Application);
  Window.Open;

  Viewport := TCastleViewport.Create(Application);
  Viewport.FullSize := true;
  Viewport.AutoCamera := true;
  Viewport.AutoNavigation := true;
  Window.Controls.InsertFront(Viewport);

  Scene := TCastleScene.Create(Application);
  Scene.Load('data/bridge_final.x3dv');

  Viewport.Items.Add(Scene);
  Viewport.Items.MainScene := Scene;

  Application.Run;
end.

See the CGE examples: 3d_rendering_processing/view_3d_model_basic.lpr for a complete code with some additional comments.

The advantages of the new approach:

  1. The API is simpler (easier to explain and use).

    Previously, TCastleViewport was in most practical cases reserved for “secondary viewport”, that shows something also visible in the “primary viewport”. The “primary viewport” was TCastleSceneManager with DefaultViewport = true. This entire complication (and complication of terminology – “how is scene manager different from viewport”) no longer exists.

    Now you just use TCastleViewport to display a world (composed from a tree of TCastleTransform and TCastleScene). Period.

    To display the same world from two cameras, just copy one TCastleViewport.Items to another. Or assign the same TCastleRootTransform instance to two TCastleViewport.Items.

    To have multiple viewports (cameras) display the same world, simply assign the Items property of one TCastleViewport to another. You can also create your own TCastleRootTransform instance and assign it to as many TCastleViewport.Items properties as you want. Demo of this is inside CGE examples: 3d_rendering_processing/multiple_viewports.lpr.

    So all previous use-cases are covered in a more natural way.

  2. Moreover, this allowed me to minimize compatibility break while still changing some defaults. Since TCastleViewport was so seldom used, we change it’s default properties:

    The FullSize=false default is consistent with all other UI controls. This way it is less surprising (when instantiating from code or in CGE editor).

    The AutoCamera=false and AutoNavigation=false are better defaults after recent camera refactor. The “false” default on these properties makes more sense — while the auto-detection is nice for quick demos, it is bothersome and sometimes surprising for non-trivial applications, so it’s best to have the auto-detection “off” by default.

    On TCastleSceneManager these defaults do not change (as it would undoubtedly cause a lot of breakage, since you use TCastleSceneManager so much in existing applications).

2. TCastleWindowBase, TCastleControlBase

Also TCastleWindow and TCastleControl are deprecated, in favour of their “Base” counterparts: TCastleWindowBase and TCastleControlBase. Why:

  • This way you don’t have a default viewport (scene manager) instance, which avoids some traps (the default navigation may catch some keys), and it is often not necessary.
  • This way you create the TCastleViewport yourself, as many as you need. So you have more power over the engine. This way it is clear that TCastleViewport is just a regular user-interface class: you can create it as many times as needed, you can position and resize it however you like.

  • This way you can create and adjust the TCastleViewport using CGE editor, just like any other UI control.

Many parts of the manual and examples have been updated to show “the new approach”. I’m working to finish updating the manual now.

Comments on the forum ➤