Enjoy a new example in our engine: examples/space_shooter. Features:

• Space ship (click anywhere on the screen, or use arrows, to move it).

• Background (drawn efficiently as one quad, with texture repeating to infinity).

• Rockets (fired by the player’s cannons). Each rocker has a collider and can detect when it hit an enemy. Rocket can be “armed” (destroys enemies) or “not” (just a ball that bounces off enemies).

• Enemies, played by the Mighty Rotating Rocks! They just move slowly towards the player. You can shoot them to destroy.

Technically:

• The player is just a TCastleScene inside a TCastleViewport, with input events handled in TViewMain.

• Using TCastleComponentFactory to create rockets and rocks. Each of them is defined by a reusable design.

• Using behaviors to define various behaviors of rocks and rockets.

• Using physics to handle collisions between rockets and rocks.

• Special component TTilingBackground to draw a background that (seems to) repeat to infinity. This is a reworked version of an old example background_tiling.

1. Next week, the Dev Days of Summer 2024 organized by Embarcadero starts!

   As you can guess, I’m in :), and you can watch the latest and greatest talk presenting Castle Game Engine on August 21th. The talk should make sense for all engine users, new and old — as usual I start with general engine overview, but then I go crazy and just develop a complete working game, live. I show using the editor and Pascal code (Delphi, though everything is really applicable just the same for FPC, and resulting project is compatible with both FPC and Delphi). I go through views, scenes, physics, behaviors, component factory, timers and more.

   I have finished recording the talk just this week (here’s a sneak preview of the project). During and after the talk I will of course be also available for live Q & A.

2. You can also catch me live, in person at FPC and Lazarus event in Cologne (Köln), Germany in October 2024. The event is on 10-11th October, my talk is scheduled for Friday, 11th October.

   In my talk I want to cover everything, from the game idea, through implementation using our engine, to the final deployment in Steam and Android (Google Play). I have a very intensive plan 🙂

   If you’re interested and have questions, please use the contact information at the bottom of this page. Detlef Overbeek will answer everything and help you get there.

3. Finally (with a good timing, just for those who cannot wait to see me 🙂 ) — my presentation from ITDevCon last year was recently published:

Be seeing you!

Tl;dr of this: download the latest Castle Game Engine and everything will be perfect! (or, at least: better!)

Remember that we follow continuous integration and delivery (right now using GitHub Actions) to continually release new version of the engine, 7.0-alpha.snapshot, after every commit that passes a number of automatic tests. So everything we say in these news posts is available right now in our downloads.

Recent important bugfixes:

1. Fixed frustum culling of shapes in scaled scenes.

   If you had TCastleScene with some scale, and TCastleSceneCore.PreciseCollisions, and observed disappearing shapes when rotating the camera — this is fixed now.

2. Fixed gizmos (lights, cameras) size (in editor) when they are within a scaled parent. By accident, previously the size was unreliable, could be too large for non-first child.

3. Fixed renaming components in editor on Linux / FreeBSD.

   We had a critical issue for quite some time in our editor on Linux / FreeBSD (all platforms using GTK2): occasionally, renaming components using the hierarchy tree (clicking there or using F2) was crashing. The problem was ~random, with some people experiencing it regularly, some never. 

   We have tracked the problem down to an 8-years-old Lazarus issue. Possibly, the issue was unaddressed for so long because, why the analysis of the problem was correct, the reproduction steps there were a bit difficult. Well, we have uncovered how to reproduce it easier, by editing in tree view 🙂 “Bumping” it in the Lazarus bugtracker resulted in super-quick fix from Lazarus developers — big thanks to Juha Manninen!

   If you use our official downloads, just grab the latest version and forget about it. We build using our Docker images which have Lazarus version properly patched.

   If you build Lazarus yourself, make sure to apply the relevant patch manually, as described here. Or just use latest Lazarus from “main” branch, which has this fix included.

4. Fixed crash at opening the project on macOS.

   See this merge request for details. Thanks for quick response of Lazarus devs, a version of this fix was quickly applied to Lazarus (main and fixes_3_0 branches). So just use Lazarus >= 3.5 if you build editor yourself.

5. Fixed editor packaged in our downloads on macOS. This was a silly mistake in our packing scripts, we packaged an editor for macOS, but then later script command was accidentally removing it 🙂

Note: There’s one more (really important) bugfix done lately to the lights attenuation. This will deserve a separate blog post to explain what happened. Stay tuned for future news.

Screenshot: Aston Martin Valkyrie-DVA by chiwei from Sketchfab. Traditionally, when I don’t have any special screenshot to illustrate the post, I search Sketchfab, download the model as glTF and show it rendered by our engine. This is one of the models in response to search string “bug fix” — due to same words in the description, though author of the model probably never thought someone will search Sketchfab for these words 🙂

Hi all! Today we announce a number of improvements for mobile (Android, iOS) development. They’ve been done while testing:

• Recently announced Castle Model Viewer on Android, see news.

• Updated Game Services Demo on Google Play.

• Updated Darkest Before the Dawn. A really old game developed using Castle Game Engine. Updated – no ads, use latest engine, released again on Google Play! Historically, this is the first game made for Android using Castle Game Engine, in 2013.

( Missed anything? See all Castle Game Engine applications on Google Play. )

Onward to engine improvements around the mobile:

1. TCastleContainer.SafeBorder — new property, working on both iOS and Android, exposing the safe area on screen edges where you should not draw anything important/clickable, because the system itself may draw important/clickable stuff on top of your application there.

   For example the system clock/battery/network state take space on top. The software home/back buttons may be on the bottom. Notch are present on some phones which obscure some part of some edge. See Android docs for display cutouts, and here how these displays look like. There are a few terms more-or-less interchangeable for this: safe area, insets, display cutouts on Android, status bar/bottom bar on iOS.

   Usually these are non-zero at top and bottom, but TCastleContainer.SafeBorder allows us to expose safe areas on potentially any screen side. Underlying API on Android actually gets all 4 sides. (Current code on iOS only queries for top safe area now, but we can improve it.)

   We also exposed TCastleContainer.OnSafeBorderChanged to notify about safe area changes. This is important, as applications dynamically switch orientation and/or enter/exit immersive fullscreen modes. So to support TCastleContainer.SafeBorder perfectly, make sure to react to TCastleContainer.OnSafeBorderChanged events.

   Our inspector (F8 on desktop, hold 3 fingers for 1 second on mobile) also shows them, as red bars.

   They behave OK with switchable orientations (portrait, landscape), phones and tablets and all supported Android versions, and it doesn’t break our behavior on fullscreen_immersive. This was some work to test 🙂

   How to actually support them — you need to move / enlarge your UI, to leave an extra space at the respective screen edges. You can move your UI (TCastleUserInterface.Translation), you can enlarge it (TCastleUserInterface.Height), you can use UI borders (TCastleUserInterface.Border), you can use padding available on some controls, you can also just add a solid-colored rectangle just for the sake of these insets. There’s no “automatic” answer, as you see — what to do depends on what UI you display. You can take a look what Castle Model Viewer for mobile does.

2. We have a new UI scaling method usEncloseReferenceSizeAutoOrientation. It is very similar to usEncloseReferenceSize, but automatically “flips” the reference width/height based on whether the current window sizes indicate portrait or landscape orientation. This means that UI controls have the same physical (real) size as your application orientation changes at runtime (e.g. because you support both portrait and landscape, and user just rotated the device).

   Designing for it is a bit more work. You have to account for both modes, portrait and landscape, as they result in different reference sizes. Your UI must fit sensibly in both cases.

   It is used by Castle Model Viewer for mobile so you can test it out and see how it works.

3. Gestures done with 2 fingers (on mobile) to zoom (pinch) and move (pan) with TCastleExamineNavigation have been quite improved. The code was simplified, the gestures now “kick in” instantly and they switch between pinch / pan dynamically, so you can effectively do both pinch and pan without releasing your fingers. This results in UX that feels much better to user.

   Again Castle Model Viewer for mobile is an example how it works. Run it and use 2 fingers e.g. on sample cat model to zoom/move it.

4. photo_service on Android was reimplemented to use modern approach on new Android devices and place the images reliably such that they appear in default “Photos” application.

   Using it is really trivial, just call TPhotoService.StoreImage. The full code (from castle-model-viewer-mobile) is:

   procedure TViewDisplayScene.ClickScreenshot(Sender: TObject); var Image: TRGBImage; ImageUrl: String; begin .. Image := Container.SaveScreen; try ImageUrl := FileNameAutoInc(ApplicationConfig('screenshots/'), 'screenshot_%d.png'); SaveImage(Image, ImageUrl); TPhotoService.StoreImage(ImageUrl); finally FreeAndNil(Image) end; ... end;

   procedure TViewDisplayScene.ClickScreenshot(Sender: TObject); var Image: TRGBImage; ImageUrl: String; begin .. Image := Container.SaveScreen; try ImageUrl := FileNameAutoInc(ApplicationConfig('screenshots/'), 'screenshot_%d.png'); SaveImage(Image, ImageUrl); TPhotoService.StoreImage(ImageUrl); finally FreeAndNil(Image) end; ... end;

5. We fixed saving files, when the subdirectory of the target file doesn’t exist. Our handler for saving to file:/ protocol now creates directory automatically.

   This makes sense for our engine, because we don’t want you to care about need for ForceDirectories and similar calls, because we don’t want you to usually care whether the protocol you use is file:/ or something else. We also don’t want you to depend on whether ApplicationConfig returns URL with file:/ protocol or something else (like future planned castle-config:/...). We also want constructions like SaveImage(..., ApplicationConfig('some_subdirectory/') + 'yet_another_subdirectory/foo.png'); to work automatically.

   A sample application is test_config_subdir.

6. We improved our Android documentation page (again — this seems to be most often updated documentation page of our website in 2024, maybe aside from roadmap 🙂 ). Simplified, and clearly recommends Android Studio. We work hard to make the Android process very simple and documented. At this point, installing Android Studio (not only Android command-line tools) is the best approach, IMHO — it has Java version that always works, has GUI-friendly access to emulators, mirroring, accepting licenses…

7. We improved our Android FAQ about emulator usage.

8. We improved our Android services list, to list all services and clearly specify which services are usually added automatically to the project.

That’s all, for this news announcement! We have a ton of new stuff, brace yourselves for more news 🙂 If you like this, we appreciate your support on Patreon, or other financial support , or other contributions. Reposting / resharing the news about our engine to interested people / places is in particular always appreciated!

Announcing a variety of documentation and website improvements:

1. For starters, we prepared slides highlighting Castle Game Engine features and plans. These are a nice summary of what we do and why. Just 11 slides, deliberately a short presentation. I very recommend to read and share it with everyone who may be interested in our engine!

   It has been prepared for Nicholas Polys to present our engine at SIGGRAPH 2024 highlights.

2. We have a big new section about “Baking Lighting” in our Blender documentation. This is a very powerful Blender feature, and it naturally works great in combination with our engine. We hope that this documentation helps you use it (there are a few “tricky” things to click during the process). It is accompanied with screenshots and sample model using it, in demo-models/blender/baking_lighting.

3. Inspired by a topic on our Discord, I added a section Variant records and related concepts to our modern Object Pascal introduction.

   It describes 3 Pascal features, all with examples:

   1. Variant records (example)

   2. Variant type (example)

   3. array of const and TVarRec (example)

4. We added a search box to our documentation, relying on DuckDuckGo (a privacy-friendly search engine that I use, instead of Google, for many years now, and don’t look back 🙂 ). It’s a simple search box that you can find at the bottom of the left sidebar on any page within the “Documentation” section. It searches everything in our domain that was indexed — docs, API reference, and even forum.

5. We updated and simplified our page about X3D. We tried to make it more streamlined and focus on important things (it’s an open standard and we use X3D nodes for everything). We hope this is simpler to digest than the previous version, which was complicated, at some points needlessly (e.g. most people by now probably don’t care about VRML).

6. We improved our roadmap, clearly distinguishing what we plan to do for 7.0.

7. A shout out to Reddit users: did you know we have a place to talk about Castle Game Engine on Reddit? Join there and feel welcome to talk about the engine. Eugene Loza reposts our news there, you can jump-in and comment on any news, or just start a new topic about anything you’d like.

We’re proud to officially release today Castle Model Viewer for Android!

Get it now from Google Play.

It’s a free 3D and 2D model viewer that supports all Castle Game Engine model formats: glTF, X3D, VRML, Spine JSON, sprite sheets, MD3, Wavefront OBJ, 3DS, STL, Collada, and more. It also allows to open a ZIP file that contains a single model and associated media (like textures, sounds etc.).

The viewer includes a few demo models built-in, but naturally you can also open your own model files. The important thing to remember is that models must be self-contained — we explain exactly what this means in the documentation, but the short version is: you will probably want to pack model with textures into ZIP.

Features:

• You can change navigation type (walk, fly, examine, 2D),

• jump between viewpoints,

• play chosen animations,

• save a screenshot,

• display scene statistics (triangle, vertex count) and more.

• Overall, we included the features from our desktop viewer that have been most useful, and adapted them to the mobile UI.

Have fun! If you find it useful, please support us on Patreon or a number of other ways.

The viewer is free, open-source, and has no ads or tracking naturally. Enjoy open 3D standards!

If you have any feedback, you know where to find me 🙂 Report bugs as GitHub issues. Oh, and if you like it — we’ll appreciate a 5.0 rating on Google Play 🙂

Big thanks for developing initial version of this application (originally known as view3dscene-mobile) to Jan Adamec, long-time contributor to our engine, also author of e.g. Room Arranger. It took us a lot of time before making a public release but here it finally is! Thank you!

1. We have released our Platformer game on Google Play! It’s a full-featured 2D platformer game, with sources available inside the engine, in examples/platformer subdirectory.

   The Platformer release on itch.io has also been upgraded. The new platformer version features a helpful dialog showing how to control the game on mobile, and pause view improvements (dimmed background, consistent Escape key on desktop, pause button on mobile).

2. New menu item in editor to debug input behavior: “Run -> Run Parameters -> Pretend Touch Device”. Accompanied by a command-line parameter --pretend-touch-device.

3. Extended our touch input documentation: more about TCastleTouchNavigation, mentioned compilation symbols, example using ApplicationProperties.TouchDevice.

4. Fixed the check when setting “Android SDK Location” from the editor, because the latest Android SDK may not have tools subdirectory.

5. Fixed stopping (from editor) an application running on Android from Unix. Previously, it always left adb logcat process in the background, and made a warning about incorrect child id. Now it properly kills adb logcat.

6. We bumped the Android target API to 34 (Android 14) to match the upcoming Google Play requirements.

We work intensively on the engine! Here’s a list of smaller engine improvements / fixes done recently. (For bigger improvements, see all the recent news — we have a lot of new stuff.)

1. New simple API in our CastleUnicode unit: TCastleStringIterator, UnicodeCharToString, UnicodeCharToReadableString, StringWithHtmlEntities. All with auto-tests. All following our general rule that when used with FPC, we follow default Lazarus conventions: String is AnsiString and it holds UTF-8; when used with Delphi, we follow default Delphi conventions: String is UnicodeString and it holds UTF-16.

2. We’ve made important fix to our VS Code extension last month: we now pass engine path properly to the LSP when the engine path has been configured as VS Code extension setting.

   Previously, our VS Code extension only worked if you had set CASTLE_ENGINE_PATH environment variable… which was not our intention, this was just a bug. To be clear, we work a lot to not require regular users from ever setting CASTLE_ENGINE_PATH environment variable (or any other environment variable, for that matter, like PATH). Because setting environment variables, in a way that is applied to all applications run in any way (also e.g. GUI applications not run from a shell), and on all operating systems (Windows, Linux/FreeBSD, macOS)… is not that trivial, as experience shows.

3. I wrote a small page documenting how overloading Pascal works, with or without the oveload keyword.

4. Optimized DPROJ size when your project has huge number of data files (we still need to list them all, for Delphi non-Windows targets, see Data files deployment (applies to all non-Windows platforms with Delphi), but the DPROJ shouldn’t be that big anymore).

5. New example examples/user_interface/screen_resolution_change showing how to use Application.TryVideoChange to change the monitor physical resolution. Along with a README that warns when it may not be the best idea 🙂 Using UI scaling is our first recommendation to make a game that adjusts to arbitrary user screen size.

6. You can now drag and drop Tiled maps on the viewport.

7. Docker image upgrades:

   • Updated Compressonator version in the image.

   • Updated FPC and Lazarus “latest” versions, see here for latest GIT hashes from FPC / Lazarus GitLab repos.

   • Updated GitHub CLI version.

   • Added git-lfs to checkout large repos (in case of GitHub Actions, they are checked out inside Docker image, unlike in case of Jenkins).

   • Fixed updating all Docker images hosted on GitHub in addition to Docker Hub

   • Repo is now castle-engine/castle-engine-docker (less sexy but more obvious name for previous “castle-engine/castle-engine-cloud-builds-tools”) 🙂

8. We now warn if it seems you mix 2 engine versions.

   The mix means that it seems the tools you call (in particular build tool, also called by editor) are accompanied by one engine version, but you use CASTLE_ENGINE_PATH environment variable to force a different engine location. This is a strong indicator that you have a mistake in your setup (maybe you forgot you have a CASTLE_ENGINE_PATH pointing to some old engine version) and can lead to various weird problems (since given build tool expects a given engine layout). Now you will get a clear message about it, like

   “$CASTLE_ENGINE_PATH environment variable points to a different directory than the one detected from the executable path: “…” vs “…”. This may be a mistake, possibly you have two (different) engine versions installed. Please check your environment, likely remove one of the engine versions or undefine CASTLE_ENGINE_PATH to not point to the engine that shall be unused.

   To be clear. you can have multiple engine versions on your machine. Just be sure to always use the tools (like build tool) from the same engine version from which you use sources (and build tool data).

   To avoid confusion, if you are unsure, we generally advise to not use CASTLE_ENGINE_PATH (as a central variable pointing to “current” engine) and do not put CGE tools on PATH. The less “central” settings you have -> the less things you have to maintain 🙂 If you don’t have any environment variable like CASTLE_ENGINE_PATH, but just run “bin/castle-editor”, it will correctly pick up the tools (including build tool) from the same engine directory. There are exceptions when CASTLE_ENGINE_PATH is useful, but you need to know what you’re doing :), in particular you need to remember that it’s another place where you indicated “where is the engine” and you will have to update it, if you decide to juggle engine versions.

9. Nothing done: We have been testing switching FPC optimization in release builds from -O2 or -O3. Sadly, it creates bugs in Aarch64, so we reverted back to -O2.

I don’t have a perfect image to illustrate this post. Attaching a screenshot showing how to display a cat with a jetpack instead :), because we can.

Do you like what we do? We appreciate your support on Patreon!

If a project is compiled in debug mode you can enter an Inspector at any time by pressing F8 or (useful on mobile) holding 3 fingers anywhere on the screen for at least 1 second.

The Inspector, first introduced in this video, is a tool to debug your game as it is running. It features an editor-like interface, to inspect your hierarchy and components, view logs, profile (measure speed) and other important tools. Recent news item alreday talked about “Monitor and Auto-Reload Data” checkbox.

We continue to extend this with more features, to make debugging and experimenting with your game as it is running more powerful.

1. The biggest feature here is that you can manipulate boolean properties as checkboxes. For example, just click on the TCastleUserInterface.Exists or TCastleTransform.Exists to toggle whether something exists (is visible and collidable). Toggle TCastleImageTransform.SmoothScaling to tell if an image is pixel-art or not. And so on.

   TODO: We want to extend it to allow editing all properties at runtime, not just booleans. This improvement should come very soon, editing properties as strings is a natural extension of this idea. And naturally this is pushing us more and more into idea “implement editor using CGE UI”, something that we already committed to doing, but it’s going to take some time.

2. Pretty hierarchy rendering (no more “-” suffixes).

3. Display user interface and viewport stats (draw calls).

4. Checkbox to toggle UI batching. Select “More” and then “User Interface Batching”.

   Note: you can also toggle viewport batching, just select the viewport and toggle TCastleViewport.DynamicBatching property as a checkbox.

A natural warning: This is a debug feature that may break some assumptions in your code. If your Pascal code assumed that it controls the TCastleTransform.Exists value (which is a perfectly valid assumption, it is true when your game is actually used by normal people!) then you can break this assumption. That’s also why the release game builds naturally don’t enable the inspector. You can control whether the inspector is possible adjusting the TCastleContainer.InputInspector configuration — e.g. you can make inspector always disabled, or always enabled, or enabled using some other key combination.

To be enabled by default only in debug mode, inspector relies on specific project configuration set up in new project and updated by “Code -> Regenerate Project”. More specifically, the call ApplicationProperties.InitializeDebug; in CastleAutoGenerated.pas unit makes the inspector available (using F8 or 3 fingers). See also our recent post about “Code -> Regenerate Project”.

We added to Castle Game Engine capability to read 16-bit and higher precision image formats. This is useful for precise terrains (where you want to store heightmaps with more precision than 8-bit) or any other data that you may want to process (in shaders or using Pascal code) where 0..255 range (8-bit integer, i.e. byte) is not enough.

Overall, this is a collection of inter-connected features and developments. We hope you enjoy our long news announcements :), here goes:

1. First of all, grab the demo test-high-precision-terrains: Test loading terrains from 16-bit and higher precision image formats. It’s in a separate repository (not in CGE main repo) because it necessarily has quite large data files.

   Just explore it, in editor and also run it, to see what this all means.

2. We have implemented a full set of 4 float-based image formats:

   1. TGrayscaleFloatImage,
   2. TGrayscaleAlphaFloatImage,
   3. TRGBFloatImage,
   4. TRGBAlphaFloatImage.

   All these float-based image formats are now uploaded to GPU as float textures, thus can be used to process this data on GPU in shaders. That is, we don’t “lose” the extra precision anywhere on the way from disk to the GPU.

   For example, new Castle Image Viewer loads and displays the 16-bit PNGs, or float-based KTX, or 16/32-bit TIFFs, as float images. You can confirm it by loading such image and observing that Castle Image Viewer status bar shows it has a TXxxFloatImage class.

3. 16-bit PNG images can be loaded to 4 float-based image formats mentioned above. (Previously, they have been loaded to 8-bit image formats, losing precision.)

   There’s nothing you need to do to enable it. The 16-bit PNGs are just loaded to new image formats now, and everything should just work better.

   This happens both when PNG images are read using LibPng (our default PNG handling, giving us great PNG loading performance) and Vampyre Imaging Library (as a fallback).

   In both cases, we now read all images from PNG test suite perfectly, without any precision lost. We have included some images from that test suite into CGE auto-tests to ensure it stays this way.

4. Float-based KTX images can be loaded to 4 float-based image formats mentioned above. This is great if you really need max precision. KTX contains float values, we read float values, there’s no conversion at all — everything is simple, fast, and using floats.

   Note: throughout this announcement, “float” means the 32-bit floating point type called float in C and Single in Pascal. All image libraries, including Vampyre and CGE, call it “float”. Do not confuse this with Pascal Float type defined in the Math unit, which is the most precise floating-point format and not that useful for cross-platform applications since it means something different on different platforms.

   I found test KTX float images in KTX software, more precisely inside the astc-encoder tests (look in HDR-RGB and HDR-RGBA subdirs for suffix 32.ktx).

   These test images are also included now in CGE auto-tests (tests/data/ktx/floats) to ensure they are loaded correctly forever.

5. Likewise, 16/32-bit TIFF images can be loaded to float-based image formats mentioned above.

   Note that TIFF reading capability is not enabled by default in CGE. You have to enable TIFF support in your application and distribute the TIFF library (libtiff) with your application. We have documented it better now:

   • Read details about TIFF and JPEG 2000 support – why it is disabled by default, and how to enable it. This document also describes how to build and use libtiff.so.5 necessary to make it work on Linux, and what happens on other platforms.

   • Castle Image Viewer branch extra-image-formats is a working example doing it. You can compile this to get castle-image-viewer with TIFF and JPEG 2000 support. It includes the libtiff.so.5 precompiled, ready to use.

   Test TIFFs are in the test-high-precision-terrains demo mentioned above, see data/test_tiff.

6. TCastleTerrainImage uses TGrayscaleFloatImage to read terrain data from images. This means that it always operates on float precision, and you will enjoy extra precision if you image contains it — that is, if you use 16-bit PNG, or float-based KTX, or 16/32-bit TIFF.

7. Our Castle Image Viewer (test the snapshot version) also got some improvements along the way:

   • Refactored old long code into a few nice units.

   • Previous “Image information” modal dialog is removed…

   • … Because we have a new status text. Toggable with F1. Looking similar to Castle Model Viewer status text — deliberately. Displays lots of useful image information.

   • The “Images” menu is properly updated when opening the image with directory using “o”.

   • The files loaded from the directory are sorted.

   Overall, you can now browse a directory with images and quickly see their format, sizes etc. This is available on both master and extra-image-formats branches of castle-image-viewer.

   For quickly checking a lot of file formats/sizes, remember you can also use CGE existing utility image_identify. Great to check from command-line a number of images. Combine with Unix find to scan a whole directory, recursively, and output image information. Inspired by ImageMagick’s identify.

8. Note: saving float-based images is a TODO. It is documented in the roadmap. As always, ping me if you need it.

Credits

Big thanks go to Erik Johnson for supporting Castle Game Engine development, both on Patreon and by actually using the engine to develop new projects, and providing a ton of useful feedback on our forum! See the forum thread that initiated this.

The sample data has been provided by:

• Landscape Height Maps – great detailed terrains, including 16-bit PNG images.

• Topographical Earth Tutorials for the big 16-bit TIFF image.

Engine features described in this post done by Michalis — thanks to your support.