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 ➀

Merry Christmas, some summaries and API improvements

Posted on

Castle Game Engine Christmas postcard
Castle Game Engine Christmas postcard
Castle Game Engine Christmas postcard

As we get near the end of 2023, I want to simply thank everyone who supports Castle Game Engine in whatever way — on Patreon, by making games, by code contributions, by feedback, or just by simply being here and looking what we’re doing πŸ™‚

The end of this year was a bit busy for me, admittedly, and I didn’t achieve yet some of our big goals I hoped for 2023 (like 7.0 release, or even 7.0-alpha3, or Delphi/Linux finish, or review of some very important PRs like Steam, new navigation components, Tiled improvements). But I hope to get there, there’s still one more week! πŸ™‚ And we did a lot already, making the engine both more functional and also easier to use in many departments. See all things we added for 7.0-alpha3. We also have lots of new up-to-date training material, starting from “Bad way to play chess” 2 tutorial articles, though many manual updates, Pascal learning materials and finally slides and examples from all conferences I attended in 2023. I hope you enjoy this steady progress.

Onward with a description of most important recent API updates:

  • Undeprecated and made read-only TCastleTransform.RigidBody. This is just a shortcut for Transform.FindBehavior(TCastleRigidBody).

  • Temporary but important TCastleTransform.InternalMovesPhysicsBodies — workaround for some cases when using physics, and moving parent object from code whilst children objects have physics rigid bodies.

  • New TCastleComponentFactory — load a serialized component and instantiate multiple times.

  • New ComponentClone — deep-copy (clone) any component.

  • Some long-deprecated CastleSoundEngine API removed (or moved to private, so not accessible): SoundEngine.Sound, SoundEngine.Sound3D, SoundEngine.PlaySound, SoundEngine.LoadBuffer, SoundEngine.FreeBuffer.

    Since a long time, we have better alternatives: play sound using TCastleSound, TCastlePlayingSound, TCastleSoundSource, TSoundEngine.Play. See the sound engine documentation. These new classes provide much improvement (are easier to use from code, and are possible to setup in editor too).

    If you have any questions how to upgrade old API usage, consult above manual, and talk to us! A short map:

    SoundEngine.Sound can most usually be just replaced with SoundEngine.Play

    SoundEngine.Sound3d replacement is more involved, you need to use TCastleSoundSource attached to some TCastleTransform.

That’s it for today, but I hope to have bigger news very soon — hopefully still in 2023 πŸ™‚ Have a good Christmas, holidays, and a happy New Year everyone!

And since this was a year of AI boom, enjoy 3 AI-generated CGE + Christmas themed postcards attached to this news post πŸ™‚

Comments on the forum ➀

Castle Game Engine on PineTab2, Linux tablet from PINE64

Posted on

Castle Game Engine on PineTab2
Castle Game Engine on PineTab2 - occlusion_query example
Castle Game Engine on PineTab2 - terrain example
Castle Game Engine on PineTab2 - platformer example
Castle Game Engine on PineTab2 - platformer example

Last week, I got my PineTab2 tablet, made by the PINE64 community. In a way, it’s an early Christmas gift I bought for myself πŸ™‚ It’s a tablet running Linux on 64-bit Arm. My hope was to have something that can be a tablet (light device, can do tasks for which touchscreen input is comfortable enough, like read things and watch movies) but also can be a laptop (do e.g. coding, as it features a fully-functional Linux and a keyboard with touchpad). It took some tinkering, but I have to say my hope was fulfilled and I love it πŸ™‚

It’s still a low-end device, by which I mean that it’s not very fast and when I have a choice — working on a regular modern PC / laptop is just faster. But it’s also not terribly slow. It is much more powerful than e.g. a Raspberry Pi 4 (e.g. examples/platformer runs on PineTab2 with ~30 FPS, which is playable; on Raspberry Pi 4, I could run it, but it wasn’t really playable). The device is fast enough to even use KDE Plasma by default (Though I’m a GNOME guy, I’m bound to install there familiar GNOME 3 or XFCE at some point; but for now I enjoy KDE, it’s an interesting change for me).

You can install there FPC, Lazarus, VS Code, and finally our Castle Game Engine and have fun making games. The default OS on PineTab2 is DanctNIX, which is Arch Linux ARM, and in practice it features most of software you would find on a regular Arch Linux, both from official packages and AUR.

Technically, it is just Linux on a 64-bit Arm CPU (known also as Aarch64).

You can guess where this is leading: The official Linux/Aarch64 downloads of Castle Game Engine “just work” on PineTab2. Enjoy!

There are no special instructions, just download, unzip and run bin/castle-editor inside, as on other platforms. Remember to also install FPC (Free Pascal Compiler), see below

FPC on PineTab2

While you can install FPC from the packages (sudo pacman -S fpc), you may experience linking problems with FPC 3.2.2. They result in errors with messages like undefined reference to__libc_csu_init’`.

When that happens, my advise is to install FPC 3.2.3 (from the fixes_3_2 FPC branch). I am testing now on FPC 3.2.3 + Lazarus IDE from recent main branch. I used my install_fpc_lazarus script for easy setup.

Castle Game Engine in AUR

About CGE package in AUR: While it should work in the future, first the FPC built into DanctNIX has to be upgraded (see above — FPC 3.2.2 will have problems at linking). Then we should update the castle-engine-git package to just add aarch64 architecture and it will rock, allowing you to install CGE on it by just yay -S castle-engine-git.

Editor binaries: GTK2 or Qt5

The CGE editor on Lonux comes with 2 binaries since some time: castle-editor (GTK 2) and castle-editor-qt5 (Qt5). To run the latter, you have to install qt5pas (sudo pacman -S qt5pas) but it does have occasional crashes, looks like some LCL Qt5 widgetset problems. I advise using castle-editor for now.

PinePhone, PineBook Pro

In theory, this support should extend as well to other PINE64 products using Arm64, like Pinebook Pro and PinePhone. They all “just run Linux on Arm64” so in principle should work.

I’m pretty confident that it will work on Pinebook Pro without any issues. I would assume it would be just an upgraded experience compared to PineTab2 in terms of performance, but without touchscreen.

I’m super-curious about PinePhone πŸ™‚ If anyone has PinePhone, and wants to test can we install FPC and CGE there, let me know. I can help if you want, e.g. we can meet online and test it together.

Before you buy PineTab2

In case this post encourages you to actually buy PineTab2 tablet, please take into consideration:

  1. I am enthusiastic about this tablet, and I’m also a Linux fanboy πŸ™‚ I actually enjoyed testing 3 different OSes on this (DanctNIX, Ubuntu Touch, Rhino Linux) to see what works best. I enjoyed testing browsers to see what has best support for the touch screen, performance, and can play DRM content. I enjoyed playing with WiFi (while the laptop has a WiFi card, DanctNIX doesn’t feature a working WiFi driver, and the simplest recommendation is to use a WiFi dongle; Ubuntu Touch has a working WiFi driver, but comes with different issues around touchpad).

  2. Make your own decision if you will enjoy above tinkering too πŸ™‚

  3. See PineTab2 wiki and reviews like Pine64 PineTab 2 unboxing and review by Ivon Huang, After 3 months of daily-driving tPineTab 2, ARM Linux tablet, I love but also hate it.

  4. If you want a fast and fully-functional tablet that “just works” then a modern Android tablet or iPad may suit you better. (Though PineTab2 supports Waydroid so you can run Android tabs, but with performance hit.)

    And if you want a fully-functional laptop that “just works”, than a regular laptop may be better πŸ™‚ PineTab2 wasn’t even supposed to be a laptop (for this, see Pinebook Pro). I just decided to test can it fulfill the role of a laptop, for some work, for me.

Comments on the forum ➀

Two cars – example game with placeholder graphics, to play and extend into your own

Posted on

Two cars example game - editor

Since we had much talk on Monday about mobile development on our Discord, it is most suitable that I’m publishing today a toy we’ve made with my daughter this weekend in our Castle Game Engine πŸ™‚

It’s a simple game we’ve designed for (and tested on) an Android tablet, but it is really a cross-platform toy, works on desktop or any mobile, any size.

The concept is simple: 2 cars, ride forward into infinity, avoiding the obstacles on the road. Deliberately with placeholder graphics and very basic logic — play with it, extend it, make it into your own toy! The README of the game summarizes the current features and possible extension ideas.

I actually have a bit modified private version, with my daughter we started to make our own graphics — some images are photos of real-life toys, some combine random things we found on the Internet. Consider the placeholder graphics in that project as an invitation to make your own experiments!

To get it, just download the latest version of the engine and open the example in examples/mobile/two_cars/ subdirectory.

Comments on the forum ➀

Raspberry Pi 64-bit downloads officially available

Posted on

screenshot 2023-12-03 01-24-02 fullscreen
screenshot 2023-12-03 01-25-50 fullscreen
screenshot 2023-12-03 01-34-12 fullscreen
screenshot 2023-12-03 01-34-56 fullscreen
screenshot 2023-12-03 01-58-01 fullscreen
screenshot 2023-12-03 01-58-18 fullscreen
screenshot 2023-12-03 01-58-55 fullscreen

With big thanks to Simon Booth (Peardox), who provided the necessary machine to be mercilessly used by our Jenkins, our downloads now feature a ready binaries for Raspberry Pi 64-bit OSes.

This is a fully-functional and tested engine version. Get the engine, install FPC, and you’re ready to design and build games on your cool device!

To install FPC, you can install it from Raspberry Pi packages (sudo apt install fpc) or you can build FPC yourself. In the latter case, be sure to not use the latest stable version, 3.2.2, due to known issues. Instead, use 3.2.3 (fixes_3_2 branch of FPC) or latest FPC 3.3.1. You can build FPC yourself e.g. using fpcupdeluxe or a script like this.

The builds have been tested on Raspberry Pi version 4. They should support this or later Raspberry Pi OS versions, so they should be compatible with Raspberry Pi version 5 as well (though we have not yet been able to actually confirm it — give us a shout if you have Raspberry Pi OS 5 and have tested it!). The same goes for existing 32-bit Raspberry Pi engine downloads.

Comments on the forum ➀

Two new articles to learn Castle Game Engine and a fun toy to play: “Bad way to play chess”, aka “3D physics fun”

Posted on

Bad Chess - physics acting
Bad Chess - selecting a piece
Bad Chess - editor

I’m proud to publicly show two articles I recently wrote to teach Castle Game Engine!

They assume zero initial knowledge and they show the most important pieces of our engine. As such, I highly recommend reading these articles, whether you’re a newcomer or an experienced developer familiar with the engine. Read them here:

  1. Part 1: Castle Game Engine installation, editor, designing a 3D world, views, testing physics. (PDF version: 22 pages)

  2. Part 2: Coding using Pascal and Castle Game Engine API, behaviors, selection and hover, reusing a design of a 3D object. (PDF version: 33 pages)

The articles guide you through creation of a simple fun application — the titular “bad way to play chess”. If you want to play a ready game, download and install it from here (ready binaries for Linux and Windows). If you want to get the source code, clone the GitHub repository at https://github.com/castle-engine/bad-chess/.

All the techniques shown in the article are recommended ways to use the engine, they are proven to be comfortable and flexible for a wide range of games, and we work on keeping them optimal. The article and examples are suitable for both FPC and Delphi developers.

The articles have already been published in the Blaise Pascal Magazine. Also our supporters on Patreon have received an early preview of both articles. If you like our engine and these articles, we really appreciate if you can support us on Patreon!

Comments on the forum ➀