Traps and explanations when comparing non-integer types (floating-point, fixed-point) using Pascal

Posted on

Floating castle from https://sketchfab.com/3d-models/floating-castle-1e157bab3a4042eb834ca07d73aa28ce by Shahriar Shahrabi

Recently I got a very nice question about comparing non-integer values in Pascal (thank you to Jacek Mulawka!).

The core of the question was: Does the condition below (if) evaluate to true or false, and why?

MyVar := 0.1;
if MyVar = 0.1 then
  Writeln('Yes, MyVar equals 0.1')
else
  Writeln('No, MyVar does not equal 0.1');

I created a testcase for this (compiles with both FPC and Delphi) and I provided a lengthy explanation what happens and why in this repository:

How does comparing “MyVar = 0.1” work for different types?

As you can read there, it’s actually quite complex what happens, and depends on both the type, and compiler, and “platform” (“platform” is a term I tend to use to mean “combination of operating system and the processor, OS / CPU”). The short version of the conclusion is: use Math.SameValue to compare non-integers, but I explain much more details (and justified exceptions to this simplified conclusion) in the linked repo, so please read it 🙂

I hope that this overview is helpful to everyone dealing with floats, in Pascal or otherwise 🙂

P.S. The screen attached to this post continues our tradition “if you don’t have anything relevant to show, post something pretty rendered using our engine”. This is a floating castle from Sketchfab created by Shahriar Shahrabi and rendered in our Castle Model Viewer.

Comments on the forum ➤

In progress: web target, IFC, mORMot sample

Posted on

Web target - initial logs
IFC example
mORMot and Castle Game Engine
mORMot and Castle Game Engine

This post contains a relatively unimpressive screenshot that actually shows a very important achievement 🙂

Things we are working on right now in Castle Game Engine:

  1. Web target.

    Yes, it means what you think 🙂 Just recompile any Castle Game Engine project to run in a modern WWW browser! No plugins of course, it’s using JS + WebAssembly, it just works.

    What we have: We have a CGE branch with build tool that can execute castle-engine compile --target=web and then castle-engine run --target=web to:

    • build a wrapper using Pas2js,

    • then build your game using FPC for WebAssembly,

    • generate skeleton HTML file with <canvas> element,

    • run a HTTP server (just compileserver from pas2js, on port 3000),

    • run a WWW browser to open http://localhost:3000/ and execute Pas2js-generated JavaScript that in turn runs the WebAssembly code.

    • The WebAssembly code initializes log (you will see typical CGE log messages in both the browser console and in HTML content), and then opens TCastleWindow with a special WebAssembly backend…

    • …and, nothing more yet 🙂 TODO: We fail at the moment we want to use glGetString. Next steps are known, we need to use WebGL from WebAssembly, and the way to do this seems to use TJSWebGL2RenderingContext from job_web. Stay tuned!

    More information (what we have, what we plan) on the dedicated web target docs.

  2. IFC (Industry Foundation Classes) format support.

    It’s “another 3D model format”, ISO standard, that we support. It defines useful concepts for architecture, construction and engineering use-cases. It cooperates with some known applications in the domain, like Revit, ArchiCAD, BonsaiBIM in Blender, FreeCAD and many others. It defines concepts useful for building real-world stuff — the things defined are not only displayed in 3D, they may also have plans, they may have costs, scheduling and other metadata useful for real people making it.

    It’s also quite special — we provide dedicated API for it, using IFC classes, to load (or build from scratch), save and modify IFC models.

    A lot of basics work already. The IFC models can be loaded, modified and saved. We have examples/ifc that shows this.

    TODO: We work on making it now “as complete as possible (though without CSG and NURBS)”.

  3. Collaborative editing of 3D world using Castle Game Engine and mORMot2.

    This is a new example using our engine and mORMot 2.

    It shows already how you can modify and render a 3D world using our engine, and send the world information to a server made usign mORMot 2. The server synchronizes world state to a database on disk.

    TODO: The missing feature is “collaborative editing” promised there. Right now actually changes from other users are not synchronized as I envisioned.

Have fun with Castle Game Engine! And if you like what we do — please support us!

Comments on the forum ➤

Using ARM runner to automatically build releases for Raspberry Pi using GitHub Actions

Posted on

Castle Game Engine editor on Raspberry Pi
Castle Game Engine editor on Raspberry Pi

This is a small infrastructure change for us, but you can also follow this for your own projects, if you already use GitHub Actions to build your applications.

For some time, we have been using self-hosted real Raspberry Pi machines to build our releases (of Castle Game Engine, Castle Model Viewer and PasDoc) for Raspberry Pi. This includes 32-bit Raspberry Pi (with support also for older OS version, based on Debian bullseye) and 64-bit Raspberry Pi (with support for OS versions >= based on Debian bookworm).

However I was doing tests to see can we use GitHub-hosted Linux runners (thus, available for free, and maintained for us) to build our releases for Raspberry Pi. The idea is to run Raspberry Pi in a virtual machine (not only do cross-compilation to it) to be able to also run tests on it.

Turns out there’s a ready ARM runner GitHub Action that does exactly this. Examples of using this for Pascal applications:

We have switched all our projects to building Raspberry Pi releases using this approach now.

Comments on the forum ➤

VS Code extension updates, Pascal LSP updates (for VS Code and other editors)

Posted on

VS Code code completion
VS Code symbols in file
VS Code symbols in workspace
VS Code running Castle Game Engine task

Recently we did some updates to our VS Code extension for Castle Game Engine and the Pascal LSP.

  1. VS Code extension now uses the FPC path you set for more things. Namely, the build tool (which is executed when you press “Compile” from VS Code) will reliably use this FPC. This means that there’s no need to have FPC on $PATH anymore to use CGE from VS Code. Just configure FPC location in VS Code and everything should “just work”.

    Further notes:

    • Direct link to the extension in the marketplace.

    • We actively develop our VS Code extension, see the changelog for all details. I (Michalis) use it during all my work on the engine nowadays, so I really need it to be good and handle code in various stages of “in progress” 🙂

    • Reminder: The extension is useful for development of any Pascal projects, whether using Castle Game Engine or not. Pascal syntax highlighting and code completion (provided by LSP) work regardless of the Castle Game Engine. Only the “Compile”, “Run” features rely on CGE project (CastleEngineManifest.xml).

  2. Our Pascal LSP (pasls binary present in engine downloads) also got updates. It now better reports errors, capturing all possible Pascal parsing errors and returning useful error messages for them — with filename, line and column number. The idea is that, when working, you naturally sometimes have a code that isn’t (yet!) correct, so the code tools sometimes cannot provide their services (completing, jumping to definition etc.). In such case it’s important that you get useful errors, why is your current code wrong.

Comments on the forum ➤

Website upgraded to the latest Bootstrap with a few tweaks to the look and functionality, planning bigger redesign

Posted on

Castle Game Engine webpage redesign by Adrianna Matejek

Our website looks a bit different all around since last week 🙂

  • We have upgraded the underlying Bootstrap (which serves as the base for our look) from version 3 (rather ancient at this point) to the latest 5.3.

  • We took this opportunity to make some small improvements:

    • dark-themed navigational bar,

    • navigational bar properly collapsing on mobile (or just narrow window sizes),

    • search box in the navigation bar,

    • simpler “Donate” button leading to streamlined Donate page,

    • from the main page we have a link “Video Tutorial” to our presentation from Dev Days of Summer 2024.

  • In some cases (like link colors and font), we decided to follow the new Bootstrap defaults.

This is a preparation for a bigger website redesign. What we have now, thanks to using the latest Bootstrap 5.3 and thanks to being simple (generally following Bootstrap conventions, with only minor customizations) should lend itself nicely to bigger redesign.

What bigger redesign, you ask? 🙂 Well, we’ve been planning a website redesign for some time now, to make it both more impressive and communicate our intentions better. Attaching to this post a cool main page redesign from Adrianna Matejek. This is something which we want to eventually reach!

Comments on the forum ➤

Steam Integration

Posted on

Steam Achievements in The Unholy Society game
Steam UI for Achievements
Steam Achievement Test

We’re proud to present ready Steam integration in Castle Game Engine!

Features:

  • Use Steam API to
    • Control achievements (list, get, set state).
    • Get some information (country, language, VR mode, Steam Deck, whether some DLC is installed).
  • Works on all supported platforms: Windows, Linux, macOS.
  • Works with all supported compilers: FPC, Delphi.
  • Ready Pascal unit CastleSteam.
  • Ready example in the engine sources: examples/steam.
  • We have put deliberate effort into solving some technical things in a clean way: the integration doesn’t need any “wrapper” Steam library (you only need Steam DLL/SO from Valve, not anything additional), the integration code is clean and cross-platform (in particular, we use SteamAPI_ManualDispatch_GetNextCallback and friends – no assembler, no hacks to simulate C++ VMT in order to receive callbacks). This implies that our integration should “just work” on any platform supported by Steam, forever, reliably.
  • We have further plans related to this. The most immediate: release Castle Game Engine on Steam! We are finishing setting up our Steam page. Next: add more features from Steam API, like support joysticks using Steam (allows to handle any joystick type, and user can customize the handling in Steam) and Steam Deck-specific API (e.g. activate on-screen keyboard on Steam Deck).

Everything is documented on our Steam documentation page. It has also been mentioned on slides in 2 recent conferences — see Cologne FPC/Lazarus Meeting 2024 slides, Delphi Programmer’s Meeting (Polish) 2024 slides.

This big work has been largely done by the late Eugene Loza.

If you like what we do, we appreciate your donations.

Comments on the forum ➤

Fixes and optimizations: Shadow Volumes Optimizations, Shadow Maps Refactor, Nintendo Switch updates, important fixes

Posted on

LCL TCastleControl
Pirates - at Dev Days Summer 2024!
Pirates demo with shadows
  1. We’ve made a big optimization to processing of large worlds (which means: many TCastleTransform in a viewport), that in particular benefits cases when you use shadow volumes.

    This changes how an important rendering code works. We now make 1 pass to collect all the shapes, and reuse results of this pass a few times — 2x without shadow volumes (because we render opaque and then transparent objects), 4x for shadow volumes (was 5x before the optimization, but I managed to completely remove one). This means that “traversing transformations” (which matters for large worlds) is 2x-5x faster now.

    This matters for a number of applications, in particular it is impactful for applications using shadow volumes and non-trivial amount of scenes: pirates demo for Dev Days of Summery 2024 or games like DSRally from DiDi.

    For some technical details, see notes in the GitHub issue and notes about AddRenderEvent (how to make custom rendering code now).

    (This was done over a month ago, but I finally got to announcing it: ) ).

  2. We made a big refactor to the shadow maps processing.

    The immediate benefits are: much simpler code (using shadow maps is no longer entangled with texture coordinate generation in ProjectedTextureCoordinate) and fixes for some cases, like using shadow maps and occlusion texture.

    The more long-term benefits: This opens the door to finally improve shadow maps to work cross-scene and be trivial to activate from editor. The way forward is now clear: remove the TShape.InternalShadowMaps, pass the shadow maps when rendering, thus enabling the shadow maps from one scene to another.

  3. Small inspector rendering optimizations, and FrameProfiler shows now also rendering time spent in DrawPrimitive2D and TDrawableImage.

  4. Nintendo Switch version updated.

    While we cannot publicly share much details, the overview is simple: the very latest version of the engine is available and tested for Nintendo Switch, using the latest software stack for developing games from Nintendo). We also added “Run -> Platform -> Nintendo Switch” to the editor menu, so building can be done from GUI.

  5. Improvement: In the design mode (that is, in editor), we always have precise collisions. You no longer need to worry to toggle TCastleSceneCore.PreciseCollisions just to select things in the editor.

  6. Fix: Important fix has been pushed for physics. If you modify a transformation of TCastleTransform that has children TCastleTransform, and these children have physics behaviors (colliders, rigid body) then it’s automatically OK now.

  7. Fix: Saved JSONs are a bit shorter. No need to write JSON object for a vector / color with default value.

  8. Fix: Container.MousePosition during Motion events could be wrong due to recent Motion events collecting. It’s OK now. This also fixes mdRotate option of the TCastleWalkNavigation.

  9. Fix: Billboards in multiple viewports are now rendered OK. This also fixes lights gizmos in editor, when using camera preview. This also fixes lights gizmos in editor in terrain demo blinking.

  10. Improvements: examples/lazarus/model_3d_viewer for various UI improvements.

  11. Improvements: default .gitignore for new projects is improved to ignore some files produced by Delphi.

Comments on the forum ➤

Video: Advanced Castle Game Engine: forms, 3D generation, shaders, customizing editor

Posted on

TCastleControl on Delphi FMX form

A recording from my presentation in 2023 is now available on YouTube. This talk is titled “Advanced Castle Game Engine: forms, 3D generation, shaders, customization” and I presented it at ITDevCon conference in Rome almost exactly 1 year ago. I go through important CGE features:

  1. You can put engine rendering on Delphi FMX form.
  2. You can create and modify X3D nodes using Pascal, to build or modify 3D models — e.g. to display something from external sources (e.g. some machinery state) or to procedurally generate worlds.
  3. Compositing shaders using shader effects — original and powerful way to write shader code in our engine.
  4. Registering custom components in the editor — a gateway to extending what you can do in the CGE editor.

More:

Enjoy, and if you like it please support us on Patreon!

Comments on the forum ➤

Demo game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack. Early Preview of TCastleMoveAttack merged. Slides from conference last week

Posted on

FPS game demo - skeleton
FPS game demo - level design
FPS game demo - level design in Blender
FPS game demo - level design
FPS game demo - level design
FPS game demo - props from Sketchfab
FPS game demo - props from Sketchfab
FPS game demo - win

Today’s news is a combo of new things 🙂 I am back from 1.5 weeks of conferencing (first in Germany then in Poland). I have fresh energy, new demo and slides for you to enjoy!

  1. First of all, I have merged to CGE master branch an initial design of TCastleMoveAttack component that allows to easily define a creature AI. The idea is to attach this behavior to any TCastleTransform and make it behave like a typical FPS games enemy — it will walk toward (configurable) enemy, it will make a short range attack, it will run away from enemy when low on health etc.

    It cooperates with the TCastleLiving behavior that represents something that has hit points and can be dead / destroyed. You will typically add TCastleLiving to each enemy (otherwise enemy is indestructible) and to the player (camera or avatar, depending on if you make a 1s-person or 3rd-person view).

    It is configurable what is the enemy for each TCastleMoveAttack — they can track and attack any TCastleLiving. So they can attack the player, or fight with each other — lots of fun possibilities!

    There are some important TODOs remaining to be finished in this regard, so I emphasize that the way this component works will change (in particular, the movement will change to follow physics). Do not use it yet for bigger projects — though you can certainly use it already to have some fun 🙂 I also emphasize that this is not the only way to make enemies logic in Castle Game Engine — you can always code your own logic, creating new behaviors (see e.g. “3D FPS Game” template for a starting point).

    The existing documentation for now is in API reference of CastleLivingBehaviors unit and you can take a look what the examples do:

  2. Enjoy the new demo project mentioned above from “Zlot Programistów Delphi”: Demo game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack.

    It’s a complete game with level designed using Blender, level props from Sketchfab, enemies from Quaternius, enemy logic using TCastleMoveAttack and TCastleLiving. The game code shows simple things like game “win” (you “win” the game when you reach a certain invisible box in the level), game “lost” (when player’s life drops to zero), walking with mouse look, shooting at enemies.

    The example is naturally compatible with both FPC/Lazarus and Delphi.

  3. Finally, the slides from my presentation at “Zlot Programistów Delphi” 2024 are available.

    Note that they are in Polish, as the event is mostly in Polish. If you have trouble translating anything, and want to learn it, just let me know 🙂 Some of the topics overlap with slides I used for my Cologne lecture so you can find some explanation there too.

Comments on the forum ➤

Slides from my presentation in Köln (Cologne, Germany) today, spoilers about some new engine features

Posted on

Photo from Cologne -- does this tower remind you something? :)
TCastleMoveAttack

I’ve done a presentation about our engine at FPC & Lazarus meeting today in Köln, and I think it went really well. I had more time than usual, so after an introduction to the engine, I could go in more depth about some recently added features, including:

  • TCastleComponentFactory (with some cool improvements announced last here, demo usage in examples/space_shooter.)

  • Our new Steam integration. More about it in a dedicated news post coming soon!

  • Our new (work in progress, but already cool) TCastleMoveAttack component, providing out-of-the-box working creatures AI (so they can walk toward a configurable enemy, attack, run scared, die… typical “FPS-game enemy” logic in a ready tweakable component). See also our roadmap about it. It’s not yet finished, but it does work (on a walk-attack-behavior branch, see new examples/creature_behaviors version there). I showed some initial fun and promising results — see the slides below for screenshots!

The slides from the talk are available here. They are also embedded below:

Comments on the forum ➤