Simple User Interface Batching

Posted on

User interface batching

We have implemented a simple approach to user interface batching to improve performance of UI rendering:

  • You can easily activate it by Container.UserInterfaceBatching := true. See TCastleContainer.UserInterfaceBatching API docs.

  • We also added a way to observe whether/how much do you gain. Look at class variable TDrawableImage.Statistics information. In particular use TDrawableImage.Statistics.ToString, or TDrawableImage.Statistics.DrawCalls, TDrawableImage.Statistics.ImageDraws. Display them in any way (e.g. on some label).

  • There’s simple example examples/user_interface/ui_batching/ that shows how to use it. It also shows how it decreases draw calls from 57 to 21.

  • The TCastleContainer.UserInterfaceBatching docs do try to “manage the expectations” and outline what to expect from it.

    The existing algorithm is simple. It can be beneficial — it’s nice if you have lots of TCastleLabel or TCastleImageControl with same image, rendered one after another.

    But it can also be pretty worthless. This approach helps with rendering some easy arrangements of UIs, where underneath we render a subset of the same image many times. It will not help if we keep changing images, e.g. when rendering buttons’ backgrounds and captions.

    Moreover, note that usual applications do not have a bottleneck at UI draw calls rendering. Probably, stuff like 3D and 2D game world is your main concern, not UI, and not UI draw calls 🙂 Remember to optimize smartly, where it matters.

Try it out, let us know how it performs in your project!

Do you like what we do? Please support us on Patreon!

Comments on the forum ➤

iOS: fixes, improvements, docs

Posted on

Example application on real iOS
Example application on real iOS

The gist of this post is simple: if you have a mac and iOS (iPhone, iPad) device, go ahead and deploy your application to iOS, using latest engine and following our documentation!

This week we’ve tested building Castle Game Engine applications on iOS with latest macOS 14.4 (Sonoma), with latest Xcode 15.3, on Apple M2 (Aarch64) CPU.

As a result:

  • We did a few small fixes and improvements to the build tool. The iOS applications should again build out-of-the-box from any CGE project.

  • We followed with updates to documentation how to build for iOS.

  • We also retested distributing iOS applications for testing using TestFairy (using one of our iOS services). It’s a third-party commercial service (but free for start), but really valuable in my experience, esp. if you work with only remote mac machine.

  • Moreover making a “debug” build of CGE application on iOS will no longer crash.

    Details: fpcupdeluxe (and maybe other ways of installing FPC?) puts in the default fpc.cfg instructions to activate -Ct (Stack Checking) when DEBUG is defined. For some reason, it crashes on iOS. Our workaround just disables it (passing “-Ct-” on the command-line) as you likely don’t need it anyway.

Do you like what we do? Please support us on Patreon!

Comments on the forum ➤

Register for Pascal Cafe in IJsselstein (Netherlands) on April 6th (Saturday)

Posted on

"Escape from the Universe" game - in editor, and running on real phone

I will give a talk about our Castle Game Engine at International Pascal Cafe, on April 6th (Saturday), in ~3 weeks from today. The 1-day event features talks from well-known people in FPC, pas2js and Lazarus ecosystem, including Michael Van Canneyt and Mattias Gaertner, so I’m really excited to join! You’re welcome to register (note that the price is smaller if you register before 1st April).

My talk (~1 hour) will start with general overview of our engine (editor and code) and then we’ll explore more in-depth developing for Android, talking about some mobile/Android-specific features. Here’s a bit more detailed plan:

  1. First part of the presentation will be a quick introduction to the engine. We’ll design a simple 3D world in the engine editor, and write code to perform funny actions when users interact with the world.

  2. Then I’ll show our ability to easily recompile your game to Android. I’ll present a few features interesting from the point of view of mobile development: multi-touch handling, UI scaling, and using services for analytics, vibrations and game achievements.

See you there!

Comments on the forum ➤

Play “Gem Islands” made using Castle Game Engine

Posted on

"Gem Islands"
"Gem Islands"
"Gem Islands"
"Gem Islands"
"Gem Islands"

I love doing these news posts — it’s great to see how our engine is actually used to build games and worlds we can explore.

Looking for a game to play over the weekend? Gem Islands is a medieval knight adventure game in the third-person view. There are 5 islands, different weapons (short and long range), items, minimap and lots of things to explore. The source code is available too! Head over to the game site at itch.io to read the proper description and download the game for free. If you’d like to post a comment, you can also use the existing forum thread about the game. Enjoy!

Game by Didisoft.

P.S. Pssst — do you develop a project using Castle Game Engine? I am really happy to be able to post about your projects, whether “very in-progress” or “finished” or anything in-between. It makes me (Michalis) very happy — because this is ultimately the purpose of Castle Game Engine, to allow us to do pretty things that we enjoy. It also shows everyone what the engine is capable of, which is another bonus point. Everyone: feel invited to post about your project(s) in the “Show Your Projects” section on the forum or similar channel on our Discord. Show us screenshots, tell us about your experience with CGE (good things? bad things? anything on roadmap you’d like to see sooner?), give us downloads (only if you want)… Thank you!

Comments on the forum ➤

New VS Code extension to integrate with Castle Game Engine perfectly — build, run, debug CGE projects, use Pascal with code completion and highlighting

Posted on

VS Code code completion
VS Code symbols in workspace
VS Code symbols in file

We are proud to announce new Castle Game Engine VS Code extension! We have put a lot of work into it in recent months, to make sure VS Code users can very comfortably work on Castle Game Engine projects.

You can build, run, debug CGE projects, you have Pascal syntax highlighting and code completion. We’ve made all the features with the mindset the defaults should work out-of-the-box (as much as possible) for people who just download CGE, but can be tweaked for custom needs. You literally need to set only 1 value in the extension settings — “Engine Path” — to enjoy the full functionality.

The extension page in the marketplace already lists all the features, and our VS Code documentation has been updated with all the necessary details. Moreover, Andrzej Kilijański (who is also the lead developer of this feature) has prepared a demonstration video showing the extension installation and usage:

Please try out the extension, report any issues, and rate us in VS Code marketplace!

If you have already followed our recommended VS Code configuration in the past, you will notice these improvements:

  • As mentioned above, more things “just work out-of-the-box”. The process to configure is easier. Including e.g. support for bundled FPC (with CGE).

  • You can use Ctrl + T to jump to workspace symbols. Use “Engine Developer Mode” to even jump to engine routines too!

  • You can use Ctrl + Shift + O to jump to symbols in the current file.

  • We fixed the LSP pasls to make creating new empty Pascal file in VS Code work OK, i.e. code completion will “kick in” as it should.

  • We fixed the LSP pasls to not show a lot of messages when we search for identifiers by holding Ctrl. In such case, it is normal that most identifiers don’t exist — as you can easily hover over comments, keywords etc.

  • You can uninstall the VS Code extension we recommended in the past, “Pascal Language Server” VS Code extension from Ryan Joseph now, if you use new CGE extension. If you’ll keep both extensions installed, you will get duplicate completions (from both extensions), duplicate entries in Ctrl + T etc.

Have fun and if you like this please support us on Patreon!

Comments on the forum ➤

Linux fully supported with Delphi

Posted on

play_animation demo with Castle Game Engine on Delphi/Linux
TCastleControl on FMX form with Castle Game Engine on Delphi/Linux
Downloads with Castle Game Engine on Delphi/Linux
Automatic Castle Game Engine tests on Delphi/Linux

We are proud to announce that Castle Game Engine supports now the Linux platform with the Delphi compiler! You can now deploy your Delphi games to Windows and Linux with the same code-base.

This blog post describes various details, but really the recap is short: it just works and we have extensive documentation about Delphi + Linux specific things. Go ahead, download the latest CGE and try it out 🙂

Details about what happened:

  1. Well, 410 commits happened 🙂 And I initially thought this (making CGE work with Delphi/Linux) will take me a few hours to do. Then I thought it will take me a few days. It ended up taking me almost 4 months (although I was doing many other CGE tasks in parallel to this). Let this be a lesson of humility for all devs who dare make optimistic estimates!

  2. Both TCastleWindow and TCastleControl applications work perfectly with Delphi for Linux.

  3. All TCastleWindow examples work on Delphi/Linux. Explore the examples in CGE examples/ subdirectory and build and run on Linux with Delphi.

    All TCastleControl examples using FMX (FireMonkey) work on Delphi/Linux. This includes examples/delphi/fmx/, examples/delphi/fmx_play_animation/.

    examples/delphi/fmx_play_animation/ is actually a new example. Cross-platform 3D model viewer and animation player using Castle Game Engine components (TCastleControl, TCastleScene) and FireMonkey.

  4. The page about TCastleControl in FMX applications stays up-to-date and relevant for Delphi/Linux.

  5. Downloads (web requests) using TCastleDownload work too on Delphi/Linux. You can test them by

    Our code using TNetHttpClient on Delphi was much improved. It supports now various HTTP methods (including POST with POST form data). The code for aborting downloads in progress was also improved to behave cleanly and not cause crashes.

    It also got some Linux-specific fixes to work around Delphi issues. In particular, we handle redirects manually on that platform, as we cannot rely on TNetHttpClient.HandleRedirects on Linux.

    All in all, it was quite non-trivial to make it always work, but now it does 🙂 It can be interrupted, it can send GET and POST and others, it can redirect, it can download files of unknown size, it can download URL like http://castle-engine.io/latest.zip.

  6. Under the hood, the TCastleWindow and TCastleControl for Delphi on non-Windows are actually shared more than in FPC: they both rely on a common TFmxOpenGLUtility class responsible for some platform-specific work, in particular to initialize OpenGL context inside an FMX window.

    Moreover, under the hood, TCastleWindow relies on CASTLE_WINDOW_FORM which is a new name for a generalized old CASTLE_WINDOW_LCL. It makes TCastleWindow actually use FMX and the above-mentioned TFmxOpenGLUtility.

  7. This makes our code much more cross-platform in case of Delphi. Doing Delphi/Android or Delphi/iOS after this should be a breeze. But I’m not going to do any estimates, in light of the first point on this list 🙂

  8. All 407 automatic tests, exercising some edge-cases (also with window sizes and multiple contexts) pass on Delphi/Linux. You can run them yourself, just compile and run the project in tests/ just like any other CGE project.

  9. Underneath, the code to initialize contexts got some upgrades. The glX and EGL context management has been refactored to separate units and extending them is easier.

    EGL initialization has been separated from OpenGLES.

    Finally, we can use EGL (on any platform) to initialize both OpenGL and OpenGLES. Our Delphi/Linux port relies on it: both TCastleWindow and TCastleControl underneath use

    • a window created by FMXLinux,
    • with a GTK3 widget,
    • with OpenGL(ES) context initialized using EGL.
  10. Our file filters are easier exposed for Delphi: TFileFilterList has now methods TFileFilterList.LclFmxFilters, TFileFilterList.LclFmxFiltersFromString (suitable for both LCL and FMX) and we have CastleFmxUtils unit with utilities to place CGE filtes in FMX open/save dialogs.

  11. Our package checking application was much extended and it now checks also Delphi packages for correctness.

    This makes it easier to design good packages for Delphi — that include 100% of units, and that are disjoint where they should.

    This also means we can change the files included in packages with confidence. Both DPK and DPROJ of packages are checked, and we make sure they include all files they should (scanning actual CGE files), with proper relative paths, and nothing more.

    If you’re interested in code, see our check_packages utility code. While it’s an internal CGE tool, it is possible it could be useful for other projects as well. The tool can be compiled with both FPC and Delphi (and regardless of the compiler, it can check both Lazarus and Delphi packages). See the README for instructions how to adjust it for your own purposes.

  12. Simple shell tests (mostly some grep calls) in cge_shell_tests also check now that Delphi packages are correct, in particular that VCL or FMX dependencies don’t happen in packages where they shouldn’t.

Note: Embarcadero had a server outage recently. Everything should be back online for users with Delphi 12 or Delphi 11.3. See Embarcadero blog, GetIt Update for Delphi 12, GetIt Update for Delphi 11.3. If you experience problems using GetIt to get FMXLinux, please consult the above articles.

Comments on the forum ➤

New Delphi packages organization and “Tools->Castle Game Engine” menu in Delphi IDE

Posted on

Delphi IDE Castle Game Engine menu
Castle Game Engine 3D in Delphi FMX form
Castle Game Engine 3D in Delphi VCL form
  1. Our Delphi packages have been reorganized to better support all the platforms supported with Delphi (Windows, Linux — watch out for the next news post!). The new Delphi packages are:

    • castle_engine.bpl with the base engine units. Not dependent on VCL, not dependent on FMX, not using TCastleWindow.

    • castle_engine_vcl.bpl with the engine code dependent on VCL (Windows-only). In particular it registers TCastleControl component you can drop on a VCL form.

    • castle_engine_fmx.bpl with the engine code dependent on FMX (cross-platform). In particular it registers TCastleControl component you can drop on an FMX form.

    • castle_engine_window.bpl with TCastleWindow class and friends. It is a key to use TCastleWindow in your own applications, which is a great approach when you want to create a typical game using CGE, with everything (including UI) designed using CGE.

    • castle_engine_design.bpl contains additional design-time features for CGE components. In particular, the new menu we talk about lower in this news post.

    Follow the installation instructions for the new Delphi packages.

    We also have more internal (mostly for engine devs) details about the packages in the repository.

  2. A connected new feature is that Installing our Delphi packages, aside from registering the TCastleControl for FMX and VCL, also adds to Delphi a new menu items in the “Tools -> Castle Game Engine” submenu. These provide some useful integration between CGE and Delphi IDE:

    • You can open CGE editor on the current project.

    • You can add CGE paths globally to the Delphi IDE using the menu item “Configure Delphi to Use Engine”.

      We advise this, as a simplest way to have CGE units available for all your projects. It extends the “Library Path” for all the platforms you have, adding there source directories for all CGE units. This way CGE source code is available to all your projects, and CGE units will be compiled and linked with your projects that use any CastleXxx units.

      After using it (and restarting Delphi IDE!) you can inspect what it did by looking at “Tools -> Options -> Language -> Delphi -> Library -> Library Path”.

      There’s a corresponding menu item to revert this configuration change, if you want.

    • You can add CGE paths to the current project, platform, and config (debug / release). This is alternative to using “Configure Delphi to Use Engine”, less advised, but makes sense if you really want to avoid changing your Delphi settings.

      See the docs for more details.

    • Necessary DLLs will be automatically deployed alongside your EXE file, if you build a project with CastleEngineManifest.xml from Delphi IDE. These DLLs follow the declared <dependencies> of your project along with some auto-detected dependencies (e.g. we automatically deploy OpenAL DLLs if your project includes sound files in data).

    • You can set CGE root path (this is used by above commands — to know where CGE sources are, where CGE editor is). Note that this CGE path stays only in Delphi IDE — we deliberately do not set some system environment variable or other config (read by other tools) to keep things simple (by being independent), at least for start.

    • Finally, we feature easy links to CGE documentation, API reference and Patreon.

    We recommend all Delphi users to follow the Delphi packages installation procedure, install the packages and use the “Set Engine Path…” and “Configure Delphi to Use Engine” menu items.

    Note that this work may allow us to remove a deprecated feature from our auto-generated DPROJ files (done if you set up the project using CGE editor). Right now, the DPROJ contains the paths to all CGE units, absolute — so they only work on your machine, and are not good for sharing your project in a version control system. We plan to simply stop adding these paths to new projects in the upcoming future. The idea is that all Delphi developers who use CGE should just use “Configure Delphi to Use Engine” on their machine, once.

  3. If you are interested in developing Delphi IDE extensions, you may find it useful to also take a look at our test project Delphi IDE design-time features tests. This is a small, independent of CGE, piece of Pascal code demonstrating how to extend Delphi IDE — adding new menu items, changing project and global options. We used it as a “test bed” to develop the CGE integration, and it may be useful for you too.

Comments on the forum ➤

New slim Docker images

Posted on

Castle Game Engine and Docker

We feature a set of Docker images that contain a ready Linux machine with Castle Game Engine and all our important dependencies: FPC (cross-compilers for most important platforms — Linux/x86_64, Windows/x86_64, Windows/i386, Android/Arm, Android/Aarch64), Lazarus, Android SDK, various texture tools. They are useful to build applications using CGE, both interactively and from various continuous integration/delivery software, like GitHub Actions, GitLab CI, Jenkins.

Their main documentation is our Docker usage documentation and our Docker image at Docker hub.

We have reorganized our Docker images recently. We no longer serve big Docker images with all supported FPC versions. Instead, the Docker images now provide a single FPC version (like latest stable — 3.2.2 now) and alternative Docker images provide alternative FPC versions.

The main practical reason behind this was that GitHub tightens their requirements for the disk space allowed for (free) GitHub Actions jobs. We have been “on the edge” with regards to their allowed disk usage, because our previous Docker images have been quite large, which was mainly caused by multiple FPC/Lazarus installations inside (each one with units for multiple platforms). And most people do not need these alternative FPC versions, we just recommend to use latest FPC stable. So it seems simpler to split the Docker images into more, smaller ones.

New Docker image names:

  • cge-none : our tools, including latest stable FPC (3.2.2 now), without CGE.

  • cge-stable : like cge-none, with added latest CGE stable, 7.0-alpha.2 now.

  • cge-unstable : like cge-none, with added latest CGE unstable, latest CGE GitHub commit that passed automated checks.

  • cge-none-fpc300 : like cge-none, but FPC 3.0.0.

  • cge-none-fpc331 : like cge-none, but FPC 3.3.1, recent FPC version from FPC GitLab “main” branch.

This article describing BuildKit features to have multiple variants in a single Dockerfile was immensely useful to make this work.

As always, you can take a look at our Docker setup scripts. The resulting images are on Docker hub.

Comments on the forum ➤

So many contributions: Providing data for HTTP PUT requests, fast toggling Tiled layers visibility, improved C++ library API, XML API for colors in hex, build tool info, FreeBSD fixes

Posted on

Castle Game Engine on FreeBSD 14

Michalis was busy last week reviewing and merging many Pull Requests to our engine. Thank you everyone for your contributions, and your patience with me (sometimes when I’m busy finishing some other work in CGE, that takes priority, and PRs wait a bit), and keep it coming!

In particular:

  1. We now support providing input data (as a stream) for HTTP requests (like PUT, or POST when TCastleDownload.HttpPostData is not enough), thanks to Vlad (phomm). Use the TCastleDownload.HttpRequestBody and see at examples/network/put_data/put_data.dpr.

  2. We now support fast toggling of Tiled layers visibility thanks to Dennis Spreen. Simple example is part of map_viewer example, just set Boolean like TiledMap.Data.Layers[0].Exists := .... This is the exact method with example code.

    For future plans, see our “New API for Tiled layers” section in the roadmap.

  3. Our deprecated library (for C, C++ applications that want to utilize CGE to display 3D models in any application) was extended to allow configuring input shortcuts thanks to Jan Adamec.

  4. Our XML utilities have been improved to support reading and writing colors as hex values thanks to Eugene Loza.

    There is another big PR from Eugene incoming: Steam support! And more from Eugene: distance field fonts, Bootstrap upgrade, screen effects + blending…

  5. Our build tool can now return more information: FPC paths, project paths thanks to Andrzej Kilijański. This is initial part of our upcoming big feature for VS Code users.

    There’s more from Andrzej as well: new navigation components, optimization for mouse move events, Android improvements…

And finally, we have also fixed CGE on FreeBSD and tested it with latest FreeBSD 14 version. We did it by fixing CastleGL, our dglOpenGL fork, to support FreeBSD. Thanks to Bartosz Jarzyna for reporting!

Thank you everyone for contributing. I hope you enjoy working with our game engine, and please keep it coming, we have big plans to be the best open-source game engine ever! See our roadmap to get inspired. Our features list wants to grow 🙂

Comments on the forum (2) ➤

January news: Ticoban, editor dragging, CastleGL based on dglOpenGL, tester improvements, Pascal custom RTTI attributes, more

Posted on

fps_game demo

Hi all! Our news have been quiet lately, let me fix this by a big list of recent developments 🙂

The list below is not really complete, we have some big thing (for Delphi people) already merged to CGE, but we’ll wait with announcing it until Delphi GetIt servers are fully back online. And we have another big thing (for VS Code people) almost finished. Stay patient 🙂

Onward with what we have to announce today:

  1. Ticoban, a 3D Sokoban version made using Castle Game Engine, is available now for free. Go check it out! By Rafael Campos.

  2. Editor now allows to drag multiple components in the hierarchy so you can more easily rearrange your components.

  3. Throughout CGE, we now use CastleGL unit to access the OpenGL API.

    This is a minimal fork of dglOpenGL, originally done by Sascha Willems and Delphi OpenGL Community (DGL). Our fork makes it compatible with all CGE compilers and platforms by using our CastleDynLib unit under the hood. E.g. it adds Delphi/Linux compatibility.

    We use it in CGE for all compilers (FPC and Delphi) and all platforms using desktop OpenGL (Linux, FreeBSD, macOS, Windows, …).

    This makes things simpler — so we just have 2 units, and both are in CGE: CastleGL (desktop OpenGL) and CastleGLES (OpenGLES). So code can just do {$ifdef OpenGLES} CastleGLES, {$else} CastleGL, {$endif}.

    And dglOpenGL is much better base than built-in things in FPC or Delphi.

    • FPC has GL, GLExt, but their extension querying was not useful with modern OpenGL (was using deprecated, and removed in core, glGetString(GL_EXTENSIONS) instead of glGetStringi(GL_EXTENSIONS, i)).

    • Delphi has OpenGL, OpenGLExt units but only for Windows.

    • They both miss some things, e.g. WGL routines to initialize modern context on Windows.

    We have been able to simplify some CGE code, esp. around WGL or dealing with GLExt issues, thanks to migrating to dglOpenGL. You can read more about my thoughts in #334.

  4. We’ve made a few CGE tester improvements and simplifications:

    • --no-window-create command-line option.

      Removed NO_WINDOW_SYSTEM define, no more IsConsoleMode check. The new --no-window-create option is better both for usage and development.

    • –filter command-line option, for both GUI and console testing, to filter tests by a wildcard.

    • Reliable reporting of both unhnandled exceptions and assertions’ failures, on both GUI and console.

    • Removed old FPCUnit-specific code. It was confusing now, without much benefit. We have completely own testing framework, though still heavily inspired by FPCUnit.

    • Cleaner compilation output (ignore deprecation warnings — tests knowingly use deprecated things, to test that deprecated stuff also works).

  5. There have been some internal refactors to make relevant code easier:

  6. TCastleContainer has now TCastleContainer.PixelsWidth / TCastleContainer.PixelsHeight and Width / Height are deprecated.

    Goal: to make it more clear that PixelsWidth / PixelsHeight are the actual size of the container. The existing Width / Height was a bit confusing.

    We have TCastleContainer.UnscaledWidth / TCastleContainer.UnscaledHeight to get the size of the container when you think with UI scaling. They should be renamed to Width / Height in the future, so they’ll get new more intuitive meaning.

  7. Now that Extended RTTI has been merged in FPC, we look with renewed interest at using some newer RTTI features in CGE.

    In particular, we have experimented some time ago with some ideas how we could use Pascal custom RTTI attributes. If both FPC and Delphi will have equal implementation, we really benefit a lot, we could add simpler API for publishing vectors, exposing test methods, exposing methods to be available as editor actions, etc.

Comments on the forum ➤