My presentation of engine mobile features at PascalCafe 2024 has inspired me to polish more our mobile features. There’s something cool coming soon (ups, did I just leak a link to early release only for the bravest testers? yes!).

For today, let me announce a few significant documentation updates around our engine:

1. Our Android documentation has been improved. I also added some screenshots from Android Studio, and this documentation now more explicitly recommends to just install Android Studio (not only Android command-line tools).

   Whole Android Studio is a larger download, but it is just worth it, in our latest tests. Even if you want to develop only CGE / Pascal applications for Android (not using Java or Kotlin), and you have already a favorite IDE (like VS Code, Lazarus, Delphi)… Android Studio is still very useful. It allows to easily install Android SDK (along with accepting Google licenses), allows to use Android virtual machines or mirror real Android device plugged over USB on your PC (very useful!), also contains already the proper Java version.

2. There’s a new documentation page Expose scene elements, like children transformations as TCastleScene children. It documents features, current and planned, of TCastleSceneCore.ExposeTransforms. It is a bit different from most of CGE manual, in the sense that in most of CGE manual, I generally document what engine features already exist and rock. In case of this page, while TCastleSceneCore.ExposeTransforms already exists (and rocks 🙂 ), this manual page also describes some plans about how it will rock even more in the future! I consider TCastleSceneCore.ExposeTransforms an important mechanism to enable a few use-cases in CGE.

3. I improved a bit networking manual chapter, in particular emphasized clearly that TCastleDownload can be used to communicate with backends over HTTP REST and documented the case of known memory leaks with Indy.

4. Our detecting memory leaks documentation is now more compiler-agnostic, spelling out available solutions in both FPC and Delphi.

5. I consolidated various slide shows about Castle Game Engine on slideshare.net. These come from various conferences where I spoke about CGE.

That’s not the end 🙂 I also wanted to point your attention to some wiki resources about Pascal I wrote in 2023. You can treat them as somewhat “companion” information to our Modern Object Pascal Introduction for Programmers book — maybe not good enough / not precise enough to be included in the book, but may be useful information / advise for all developers using modern Pascal:

1. Always use FreeAndNil

2. How to solve EAccessViolation error in Pascal

3. What are range and overflow checks (and errors) in Pascal

Happy reading everyone! 🙂 Do you like to read? Or maybe you prefer to make games? 🙂 Or both? Please support us on Patreon!

We’ve made a number of improvements to our CastleClientServer unit and the associated examples in examples/network/tcp_connection. The CastleClientServer allows to use a “classic” TCP/IP server/client architecture to communicate in Castle Game Engine applications. It relies on Indy — FPC developers will need to download it.

The examples in examples in examples/network/tcp_connection show a simple client and server that can exchange messages, as strings, reliably. The server and client(s) may run on any system (desktop, mobile) as long as they are reachable over the network — e.g. make sure you have the firewall properly configured on the server device.

Improvements done:

1. Big upgrade to the client/server samples in examples in examples/network/tcp_connection. UI is now designed using editor. Code is simpler and follows CGE conventions (all relevant code inside a view, TViewMain). We added buttons to stop server/disconnect the client, to test this flow. We show current state, including IsConnected.

2. Fixed CastleClientServer to be able to send messages with international characters (beyond ASCII).

3. Fixed IsConnected value for both server and client on Android — it was broken, now it’s good. As a consequence, also fixed sending messages from Android clients.

4. Fixed clean client disconnection/destruction on desktops (Linux, Windows, actually anything non-Android).

We’ve also tested various scenarios, including

• Android and Windows: Communication in both directions works. Both can be server and client(s).

• Android and Linux: Communication in both directions works. Both can be server and client(s).

Note that our engine is not committed to any particular networking solution. We use URLs and we have TCastleDownload for HTTP(S) requests, but that’s it for “core” engine features. We leave it open how you can make multi-player games, we just show you various examples — using Indy client/server discussed above, using RNL (see our demo not-quake), and we plan Nakama integration. See the networking manual chapter for an overview.

My presentation from International Pascal Congress in Salamanca, 2023 titled “Developing games and graphic visualizations in Pascal”, has just been published on YouTube (also embedded below)!

I encourage to watch it, I think it turned out quite nicely 🙂 It is a bit different from my usual presentations — it’s not only about Castle Game Engine (though I did feature our engine), I talked in general about rendering, about features a good game engine should have (IMHO!), about low-level and high-level Pascal rendering libraries, about Apus Game Engine (by Ivan Polyacov) and Benjamin Rosseaux (PasGLTF, PasVulkan, Kraft, RNL…) work. I just had an hour to talk about everything — so necessarily I go over many topics quite fast, but I hope you will enjoy the ride 🙂

Slides from this talk are available here since a long time, along with my positive notes from the conference. See conferences page.

Watch the talk:

I had a great time at Pascal Cafe conference today!

I made a presentation introducing Castle Game Engine and then discussing some details about mobile (Android and iOS) development with CGE.

You can watch:

1. Presentation slides

2. Sample application (for slides “Physics and Coding” section)

We have a new example examples/viewport_and_scenes/mesh_update that may be quite useful to many developers. It shows two approaches to update a mesh at runtime. This has a lot applications — e.g. you may want to animate / deform the mesh following some algorithm or allow for some user interactions or game events to change the mesh.

Quoting from the example README:

This example demonstrates how to dynamically (as often as possible, to reflect e.g. time passing by) update the mesh of a 3D object, while still being efficient. There are 2 approaches:

1. Call TCoordinateNode.SetPoint as often as you want, e.g. from view’s Update method.

   In this example, every TViewMain.Update increases Time and then calls TViewMain.UpdateCoordinateNode. The TViewMain.UpdateCoordinateNode updates the coordinates of the 3D object, the Time affects the waves shape.

   The point here is that TCoordinateNode.SetPoint is very efficient. It only updates the necessary rendering resource (VBO contents in OpenGL) and doesn’t do any unnecessary work (doesn’t rebuild anything, doesn’t recreate any resource from scratch).

2. Use shaders. You can use our shader effects to add a vertex shader that changes the position of each vertex right when it’s supposed to be displayed.

   The advantage is that this is even faster because the Pascal code does almost nothing — we just pass the new Time value to the shader. The per-vertex calculation is done by GPU, and GPUs are ridiculously fast at this.

   On one test system:

   • The first approach (TCoordinateNode.SetPoint) was able to handle 100 x 100 grid with 60 FPS. But once grid size increased to 200 x 200 it dropped to 18 FPS (in debug) or 38 FPS (in release).

     Note that changing the height calculation (to avoid Sin in Pascal) does not significantly change these measurements. The Sin, and in general how the H is calculated in Pascal, is not a bottleneck.

   • And the shader approach could handle 1000 x 1000 grid with 60 FPS. At 2000 x 2000 grid it dropped to 20 FPS. So, it’s 100x more performant, if you look at the number of triangles it can handle while still maintaining 60 FPS!

     Note that changing the height calculation (to avoid sin in GLSL) does not significantly change this. Neither does debug vs release build (which makes sense, since the speed of Pascal code cannot be the bottleneck here).

   Note: For stress-testing, consider setting initial CheckboxShader.Checked in design to true, to start with more performing version immediately.

   The disadvantage is that Castle Game Engine is not aware of the calculated vertex positions (they remain only on GPU). So e.g. any raycasts or other collision queries will treat this mesh as if it was in the original position (flat plane in this example).

   An additional potential disadvantage is that you need to learn shading language, more specifically OpenGL Shading Language (GLSL). There’s a small piece of GLSL code in data/animate_mesh.vs.

I encourage you to experiment with this example and try to stress-test it. It should handle very large values of GridWidth and GridHeight.

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!

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!

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!

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!

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!