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 🙂
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:
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).
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).
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).
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.
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!
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.
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:
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.
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.
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!
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:
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.
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.
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!
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.
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.
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 🙂
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.
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
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.
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.
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_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.
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 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.
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.
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.
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.
