Introducing TUIState.DesignUrl, DesignPreload, DesignedComponent

Posted on

TUIState in zombie demo

We expose TUIState.DesignUrl (and some friends) as a more comfortable alternative to the TUIState.InsertUserInterface method. InsertUserInterface was a method used by many CGE applications to load a designed UI into a TUIState. Advantages of the new TUIState.DesignUrl approach:

  1. It looks simpler. You do not need to think about UiOwner and FreeAtStop parameters passed to InsertUserInterface. You have TUIState.DesignedComponent to replace previous UiOwner.FindRequiredComponent.

  2. It allows to trivially use new DesignPreload property, a powerful way to load state data in the constructor (instead of at start), which is sometimes desirable — this way state can later start instantly, albeit at the cost of longer application initialization time and larger memory usage (e.g. textures and images used by state are preloaded in memory).

All of CGE examples and templates have been adjusted to use the new approach.

Previous code looked like this:

procedure TStateMenu.Start;
var
  UiOwner: TComponent;
begin
  inherited;

  { Load designed user interface }
  InsertUserInterface('castle-data:/gamestatemenu.castle-user-interface', FreeAtStop, UiOwner);

  { Find components, by name, that we need to access from code }
  MyButton := UiOwner.FindRequiredComponent('MyButton') as TCastleButton;
end;

New code looks like this:

constructor TStateMenu.Create(AOwner: TComponent);
begin
  inherited;
  DesignUrl := 'castle-data:/gamestatemenu.castle-user-interface';
  // DesignPreload := true; // use this to preload design in constructor
end;

procedure TStateMenu.Start;
begin
  inherited;

  { Find components, by name, that we need to access from code }
  MyButton := DesignedComponent('MyButton') as TCastleButton;
end;
Comments on the forum ➤

Full-featured Sprite Sheet Editor inside Castle Game Engine, also our own castle-sprite-sheet format

Posted on

Sprite sheet editor
Sprite sheet editor
New sprite sheet menu
Sprite sheet import Starling
Sprite sheet import atlas
Sprite sheet platformer demo - title
Sprite sheet platformer demo
Sprite sheet editor
Sprite sheet editor
Sprite sheet editor

Our CGE editor now includes a full-featured sprite sheet editor. This allows to create and modify sprite sheets that can be then trivially used (loading, playing animation) through TCastleScene. The resulting sprite sheets are saved in our own format (based on Starling XML) with extension .castle-sprite-sheet.

The editor is available by menu item Data -> New Sprite Sheet (or use the context menu, just right-click on the “Files” panel). You can start by opening an existing sprite sheet, or importing an existing atlas file, or just add animation from a series of images.

The sprite sheet is comprised from a number of animations, each with its own speed (number of frames per second). You can freely create/modify/rename animations, and move images (frames) between them.

  1. A simple demo of the new approach is in examples/sprite_sheets/sprite_sheets_demo/. Note that it was done 100% visually in the editor — no extra code necessary just to load/play sprite sheet animation.

  2. Andrzej is working on a much more impressive demo in examples/platformer.

See the documentation about using sprite sheets through TCastleScene.

All of this work was done by Andrzej Kilijański — thousand thanks for getting our sprite sheet support to a whole new level!

Comments on the forum ➤

Docker image, Android upgrades, Aarch64 optimizations, FMOD on Android

Posted on

The Unholy Society

A bunch of improvements of particular interest to mobile (Android, iOS) developers. In completely related news, stay tuned for The Unholy Society on Android and iOS release 🙂

Improvements:

  1. Updated our Docker image (affects also FPC/Lazarus used to build the default CGE releases) to:

    • for FPC 3.0.2, upgrade Lazarus version to 2.0.0
    • for FPC 3.0.4, upgrade Lazarus version to 2.0.12
    • for FPC 3.2.0, upgrade Lazarus version to 2.0.12
    • for FPC trunk, upgraded SVN revisions to latest 48998 (FPC) and 64830 (Lazarus). Also documented FPC trunk support.
    • use latest Android NDK layout for libraries (to adjust to changes described here (they removed ndk-bundle/platforms/ subdirectory) and here.

    Why? We want to use latest fixes from everything 🙂 We also want GTK2 fixes from latest Lazarus 2.0.12. We also want latest FPC trunk with fix for optimizations on 64-bit ARM (Aarch64), important for mobile platforms.

  2. Updated Android and fpcupdeluxe wiki docs to reflect new locations of Android libs in Android NDK.

  3. Our Android build process was updated to use latest Android Gradle Plugin (4.1.0). Note that this also requires newer Gradle (6.5+), it will be downloaded automatically in normal setups. This fixes building with latest NDK.

  4. We now have examples/mobile/achievements/ demo. This is almost identical to the “New Project -> 2D Game” template but also reports achievements to Google Play Games or Apple Game Center.

    Old example examples/2d_dragon_spine_game/ was removed. The template “New Project -> 2D Game” now serves better to show it.

  5. Aarch64 optimizations are now enabled when FPC is >= 3.3.1 .

    Note: we just assume that if we have FPC version >= 3.3.1 then it is at least revision 48104. Documented here, see Trello ticket.

  6. FMOD service on Android works! This allows to use FMOD sound library on Android easily. By Eugene Loza and Michalis. See FMOD service on Android docs and FMOD docs.

Comments on the forum ➤

Better code navigation, new units/states creation, new ways to open source code for editing, better integration with Lazarus project

Posted on

Code menu
New TUIState dalog
New unit with class dalog
New empty unit dalog

I’ve done a number of improvements to our editor and build tool to improve the advised organization of a CGE project and allow to comfortably edit Pascal code from CGE editor.

The goal of all these changes is to make editing CGE project easier. We want to turn the combo “CGE editor + Lazarus” into something like “Unity + Visual Studio”. CGE editor can manage your project and invoke Lazarus for you to do actual editing of Pascal files. (For those of you that would prefer to use Emacs or VS Code or other editor for Pascal: this is of course coming soon too. First we just want to nail down the Lazarus experience.)

To edit the unit you have now various options:

  • In CGE editor: enter the code/ subdirectory, and double-click on a Pascal unit.

  • In CGE editor: use menu item “Code -> Edit Unit …”.

  • In CGE editor: press F12 when some design is open. This will open the associated unit.

  • In Lazarus: open the project in Lazarus, and open necessary units. All Pascal files found on the search path are automatically part of the LPI project.

Engine and editor changes:

  1. All templates and most CGE examples now put the Pascal units in code/ subdirectory. I found that it is a much better layout than keeping all Pascal files in a top-level directory (that gets “crowded” with files in larger projects).

  2. All templates come with an initial .gitignore and README.md files. You can now push your new project to GitHub / GitLab etc. quicker.

  3. New Code menu in the editor, to edit Pascal code:

    1. Open Project in Lazarus

    2. Regenerate Project (overwrites LPR, LPI, CastleAutoGenerated) (more on this below)

    3. Edit Unit… (choose unit by a dialog box)

    4. Edit Unit Associated With Design (F12, searches for unit with same basename as current design but extension .pas)

    5. New Unit (also available on popup menu when right-clicking in the “Files” panel at the bottom):

      1. Empty
      2. With Class
      3. With State (it can even automatically add the state initialization!)

    Most of the new options are rather straightforward. But 2 things listed below require following certain conventions to make them work. You may want to adjust your existing projects to follow these conventions too (nothing bad happens if you don’t, these conventions are only necessary to allow editor to perform these operations automatically; your existing games work regardless):

    1. The option “Edit Unit Associated With Design” (F12) assumes that the filenames of Pascal units and designs match. That is, for design file like xxx.castle-user-interface it just searches for Pascal unit called xxx.pas (using search paths from CastleEngineManifest.xml). This means that e.g. using it with state_main_menu.castle-user-interface design file will not automatically find gamestatemainmenu.pas unit — we recommend you to rename your state file to gamestatemainmenu.castle-user-interface.

      (We accept also .pp extension, and unit name may be lowercase or CamelCase. But lowercase is advised as more reliable on case-sensitive filesystems. This follows FPC / Lazarus.)

    2. Adding new state to the initialization requires that one of the units (listed on game_units, reachable using search paths from CastleEngineManifest.xml) has special comments:

      {$region 'Castle Initialization Uses'}
      {$endregion 'Castle Initialization Uses'}
      {$region 'Castle State Creation'}
      {$endregion 'Castle State Creation'}
      

      The first pair delimits state units declaration in the uses clause, and may look like this:

      uses SysUtils,
        CastleWindow
        {$region 'Castle Initialization Uses'}
        // The content here may be automatically updated by CGE editor.
        , GameStateMenu
        , GameStatePlay
        {$endregion 'Castle Initialization Uses'};
      

      The second pair delimits state creation lines (typically in Application.OnInitialize call) and may look like:

      {$region 'Castle State Creation'}
      // The content here may be automatically updated by CGE editor.
      StatePlay := TStatePlay.Create(Application);
      StateMenu := TStateMenu.Create(Application);
      {$endregion 'Castle State Creation'}
      

      Of course all our templates have been updated to follow these conventions. All the examples will follow shortly.

  4. “Regenerate Program” menu item (command-line: castle-engine generate-program) now generates also castleautogenerated.pas file that does some useful things:

    This avoids the need to care about them in LPR or manual gameinitialize.pas code. This way there’s less “boilerplate” in your gameinitialize.pas.

    It also allows to put in gameinitialize.pas custom command-line parsing (previously it required to modify LPR file, making it not 100% easy to autogenerate).

    Our templates and examples have been updated to follow this. You can (but don’t have to!) update your existing projects to follow this too. Just generate standalone program by “castle-engine generate-program” (and do not edit LPR or LPI or castleautogenerated.pas, to be ready to call them again). Your project will continue to build by both Lazarus and build tool (that is also why auto-generated stuff is not hidden in some temporary directory — it needs to be available for running from Lazarus).

    The LPI file now includes all Pascal files found in the CastleEngineManifest.xml search paths into the project. This makes Lazarus behavior nicer out-of-the-box, it can navigate among all units (they are all in “Project Inspector”), it looks at all Pascal source code to know when to rebuild the project.

  5. When creating a new project, we ask for Main State Name. This makes the first state name configurable for “Empty” and “3D Model Viewer” templates.

I also have some small changes to mention, too small to deserve own news post:

  1. More useful “Basic” editor tab, it is no longer disjoint from “Layout”.

  2. Initial log output is now better, with a line like Platform: Android, OS: Android, CPU: arm (32-bit).

  3. Fixed src/library/ compilation.

Comments on the forum ➤

Multi-sampling (full-screen anti-aliasing) on iOS

Posted on

iOS anti-aliasing
iOS without multi-sampling requested (some anti-aliasing done anyway)
iOS with multi-sampling requested (more anti-aliasing done)
No multi-sampling (desktop)

You can now activate multi-sampling on iOS using Window.AntiAliasing := aa4SamplesFaster. You should set this before window is opened, which usually means it should be done in the initialization section of a unit like GameInitialize.

What values of AntiAliasing are actually meaningful?

Internally iOS supports only “none” or “4” multi-sampling values. So actually there are only 2 different states on iOS depending on Window.AntiAliasing:

  • aaNone, aa2Samples* -> means no anti-aliasing
  • aa4Samples* and higher options -> means 4x anti-aliasing

The suffix “faster” or “nicer” also doesn’t matter for anti-aliasing on iOS, e.g. aa4SamplesFaster and aa4SamplesNicer are equivalent. This suffix matters only on OpenGL with NV_multisample_filter_hint.

Testing

Unfortunately the log always says Current: 1 samples per pixel because it seems Apple didn’t bother to implement glGetInteger(GL_SAMPLES) correctly. It always returns 0 (so it would seem that no multi-sampling happens).

But if one looks at actual rendering, then yes, multi-sampling does make an effect!

Actually, it seems that iOS always does some multi-sampling, which I guess is just something they do on the high pixel resolutions on iOS (these are results of my tests on iPhone SE). But there’s definitely more multi-sampling when you request aa4SamplesFaster than if you leave it at aaNone. See the screenshots from iOS device with and without multi-sampling requested on the side of this post. They show an unlit box, which should produce very sharp edge without anti-aliasing (see desktop screenshot).

Comments on the forum ➤

Many new things: Various editor, glTF, physics, sprite sheets and other improvements. Upcoming more: tutorial, sprite sheet editor, particle system news.

Posted on

Castle Game Engine editor

We’re busy doing a lot of things 🙂

  1. The pull request with our own sprite sheet editor and format is in-progress. Thanks to Andrzej Kilijański!

  2. New tutorial is being finished: using CGE editor, from scratch to a complete game. Thanks to Eugene Loza!

  3. GPU-based particles in 2D and 3D. See forum posts about GPU-based 3D particle system for CGE (with editor), 2D particle system now supports GPU-based particles. Thanks to Trung Le (Kagamma)!

    Try it out already — I want to make dedicated posts about them, and also think about integrating into engine core in the future.

The new engine features available now as part of regular engine download:

  1. CGE editor: Directory operations: create, delete directory from the editor. Proper refresh (to show new dirs on the left, available in both panels, done automatically too when switching applications).

  2. CGE editor: Undo for properties changed by a dialog (thanks to Eugene Loza).

  3. CGE editor: Easier textual input of TCastleTransform.Scale, you can just type a single float (by Andrzej Kilijański and Michalis).

  4. CGE editor: Less alarming exception messages. Better behavior when opening invalid design files.

  5. CGE editor: Remembers window state and sizes (thanks to Eugene Loza).

  6. glTF: Support STEP interpolation in animations (you can try glTF-Sample-Models/2.0/InterpolationTest/ (from Khronos) to test).

  7. glTF: Important reading fix, in particular visible on some Kenney glTF models.

  8. Sprite sheets and images loaded to TCastleScene: by default do not force power-of-2 texture.

  9. Physics: gravity strength, very useful for 2D game when often 1 unit is not 1 meter (thanks to Andrzej Kilijański).

  10. Physics: capsule collider (thanks to Andrzej Kilijański).

  11. Transform feedback (TGLSLProgram.SetTransformFeedbackVaryings) with demo in examples/3d_rendering_processing/transform_feedback.lpr (thanks to Trung Le (Kagamma)).

  12. Theme images now use TCastlePersistentImage (thanks to Eugene Loza). Updated documentation about theme — the usage is now often simpler.

  13. Fixes to handlings URLs with anchors (by Andrzej Kilijański and Michalis).

Comments on the forum ➤

Many improvements: behaviors attached to TCastleTransform (a bit like MonoBehaviour), alphaMode and alphaCutoff from X3D 4.0 and glTF, Android services docs, loading/saving from TStream

Posted on

TCastleBillboard behavior
TCastleTransform speed test
  1. We introduce a new class TCastleBehavior which can be attached to any TCastleTransform to perform some job. You can create descendants of it (or use ready descendants of it in CGE) and override methods like Update.

    It’s a nice way to express some ideas. We right now feature TCastleBillboard and TCastleSoundSource build on top of this.

    The first demo is inside examples/creature_behaviors. Also our template “3D FPS Game” already uses it to define TEnemy class.

    If you come from Unity and are interested “what is the equivalent of MonoBehaviour in CGE” then the TCastleBehavior is now the best answer. Documented on CGE for Unity page.

    This is a work in progress!

    • First of all, editor can and will provide support to add and configure behaviors visually. It’s not a big deal, TCastleBehavior is just another TComponent descendant, our architecture of editor/serialization can handle it.

    • TCastleSoundSource can be even better, and it may become the most advised and easy way to setup sounds in CGE.

    • I’m working on TCastleMoveAttack (in CastleBehaviors unit) to provide out-of-the-box creature AI for games. And it will be a basis of new approach for creature AI in CGE, deprecating current CastleCreatures unit.

  2. LoadNode overload that takes a TStream with scene contents, and MimeType as a String.

  3. SaveNode, a better name for Save3D, with simpler API (Save3D has way too many overloads, and is now deprecated). With only 2 overloads, to save to URL or to TStream.

  4. TImageTextureNode utilities to load images from any TStream or TEncodedImage instance, without the need to load from any URL: LoadFromStream, LoadFromImage.

    This simplifies some use-cases of TImageTextureNode, where you don’t have an URL (supported by CGE downloader) but you have a ready TStream or TEncodedImage with image contents. An alternative approach in this case is to use TPixelTextureNode, but this is sometimes cumbersome, as 1. converting at runtime between TImageTextureNode/TPixelTextureNode is bothersome, 2. serializing TPixelTextureNode to file is very verbose (using X3D SFImage text syntax).

  5. I have extended X3D 4.0 to include alpha treatment parameters that correspond to glTF parameters: Appearance.alphaMode and alphaCutoff (in Pascal: TAppearanceNode.AlphaMode and TAppearanceNode.AlphaCutoff). So these are now handled in both X3D 4.0 and glTF in CGE. Testcases: in X3D in my x3d-tests, in glTF in glTF-Sample-Models.

  6. New examples/3d_rendering_processing/transform_speed_test/ – speed test of many TCastleTransform instances.

  7. Documentation how to implement new Android services.

    The above page is directed at Android services. For iOS, there is a shorter section here. But a lot of concepts are (deliberately) very similar between Android and iOS services.

Comments on the forum ➤

Castle Game Engine 7.0-alpha.1 release, view3dscene 4.0.0 release

Posted on

scene_1
1_gizmo2d-translate
steampunk_gltf
environment_light_various_gltf_sample_viewer_setups_0
Escape from the Universe - one of possible ending screens in Japanese
Screenshot of selection at 2018-07-29 05:15:01
vlcsnap-2018-06-16-09h57m46s961
Castle Game Engine - strategy game demo - hexagonal Tiled map
DamagedHelmet_0
third_person_camera_screen_3

We proudly present the first alpha pre-release of Castle Game Engine 7.0. It is time to break the long period of waiting since CGE 6.4!

We emphasize that it is a pre-release. We’re still working on a finished 7.0 release, where all the features are polished, all examples are reorganized to show the new approach, all of manual is updated to show editor usage etc. In the meantime, we feel (since a long time now) that what we have is fantastic, and a big step forward since the last CGE release.

If you prefer a video introduction, watch the video presentation embedded on our “Getting Started” page.

The most important new features are:

The more complete list of changes is here. Even that longer list is just a summary — just browse our news to know all the details.

Along with the new engine, we also release view3dscene 4.0.0 and castle-view-image 2.0.0. These tools are packaged within the main CGE download (they will be automaticaly invoked if you double-click from CGE editor on a 3D scene or image), but you can also download them separately.

  • New view3dscene 4.0.0 features include CGE improvements, like glTF support, X3D 4.0, Spine improvements, sprite sheets, animations panel (test animations, with cross-fading, simultaneous animations), dynamic batching and more. It also features a few new view3dscene options like “Edit -> Convert Inline to Group (pulls external content into this model)” and gamma correction configuration.

  • castle-view-image 2.0.0 features CGE improvements, like removal of dependency on libgtkglext and libGLU.

Comments on the forum ➤

Simplifications, optimizations, GTK backend suitable for testing OpenGLES too

Posted on

mobile/simple_3d_demo screenshot
  1. We had a few methods that needlessly traversed whole TCastleTransform hierarchy. Reworking them was an optimization and also an API simplification (IOW, a “no-brainer” 🙂 ). Changes:

    1. TCastleTransform.Press, TCastleTransform.Release are now only called when TCastleTransform.ListenPressRelease is true.

      The need to process keys in TCastleTransform is very seldom (we only had 2 use-cases for it in the engine, one is in soon-to-be-deprecated CastlePlayer, the other was for X3D key sensors which are not very useful for normal engine usage).

    2. TCastleTransform.CameraChanged, TCastleTransform.UpdateGeneratedTextures, TCastleTransform.VisibleChangeHere virtual methods removed (their use-case is now implemented as an internal mechanism, tailored to factual needs, not needing to be recursive).

    3. TCastleTransform.Dragging removed (not needed, a simple Boolean internal field that tracks “whether something is between PointingDevicePress and PointingDeviceRelease” is enough).

  2. CastleWindow GTK backend (default on Linux) can now initialize OpenGLES context using EGL. (Note that it was already possible with Xlib backend previously.)

    This allows to test OpenGLES rendering on desktops, just define symbol OpenGLES at compilation (e.g. by adding it to CastleEngineManifest.xml, or just tweak one line of src/base/castleconf.inc). And make sure you have OpenGLES installed (libgles2 package on Debian and similar).

  3. Updated documentation about CastleWindow backends.

  4. Optimized bounding box calculation for meshes (boxes are now a little less optimal, but much faster calculated; undefine FAST_MESH_BOUNDING_BOXES if you want to try again the old method).

  5. Optimized GeneratedCubeMap with update=NONE (should take zero time, was accidentally consuming some).

  6. Fixed LOD node behavior under transformation animation (testcase: navigation/lod_test.x3dv in demo-models).

Comments on the forum ➤

Demo of showing loading progress, WaitForRenderAndCall utility, new TCastleTouchNavigation

Posted on

zombie_fighter demo - loading
zombie_fighter demo
zombie_fighter demo
  1. We have new TUIState.WaitForRenderAndCall utility, especially useful to implement loading inside TUIState descendant.

  2. Our examples/user_interface/zombie_fighter features now a demo showing loading progress (as a descendant of TUIState, which is our advised approach for loading screens now).

  3. Whole examples/user_interface/zombie_fighter was remade to use editor.

  4. We have a new UI control, available from code and in editor: TCastleTouchNavigation.

    This shows controls that you can drag to navigate within a viewport. Thus it allows navigation in a TCastleViewport on touch devices. It is a “reboot” of previous TCastleWindowTouch use-case, now expressed as UI control that can have any size, can be attached to any viewport, and in general is consistent with the rest of CGE.

    In a typical usage scenario, you just add it as a child of TCastleViewport, set FullSize=true, set Viewport to the parent. Then control the touch interface. It is easiest to call MyTouchNavigation.AutoTouchInterface := true to let it be automatically assigned. Set MyTouchNavigation.AutoTouchInterface := ApplicationProperties.TouchDevice to let it be automatically assigned, but only on touch devices (that do not have regular keyboard / mouse).

    See TCastleTouchNavigation API docs for more info. An example is in examples/mobile/simple_3d_demo.

Comments on the forum ➤