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!

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

   • examples/network/asynchronous_download : does sample downloads asynchronously, so CGE events are processed, animations play, can be interrupted

   • examples/network/remote_logging : does sample POST requests.

   • examples/network/castle_download : command-line downloader, like a simple wget or curl.

   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.

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.

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.

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 🙂

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:

   • CastleOpenDocument implementation split into include files, much more maintainable now.

   • UInt32 / Int32 used everywhere, instead of LongWord / LongInt.

   • TCastleContainer.LoadSettings can be called without context initialized — this is easier in some use-cases, see e.g. Delphi+FMX/VCL examples.

   • TCastleEdit caret blinking improved (reset after text change, fix for AutoRedisplay=false).

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.

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 🙂

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.

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.