X_ITE is an open-source JavaScript library to display X3D (and a number of other formats) in a web browser, using WebGL. It was recently extended to import additional formats, and render them straight away or convert to X3D. The supported formats are now: X3D, VRML, glTF (GLB), OBJ, STL, and SVG.

There is an accompanying online converter to X3D and a command-line converter x3d-tidy that perform the conversion using X_ITE underneath.

In a way, this is similar to what we do in Castle Game Engine, where we also load everything (like glTF) to X3D nodes, give you an online converter and a command-line and GUI converter.

But there’s also a big added value: X_ITE supports SVG. SVG (scalable graphics, create it e.g. in Inkscape) gets converted into proper geometry in X3D, so it remains scalable and can be used as part of your 2D or 3D game in CGE! This is what I enjoy about being part of an ecosystem and open formats like X3D — we get new features “for free” thanks to cooperation with others.

Note that in the generated X3D file, all objects will be placed at the same depth, Z = 0, at least right now. You may have to fix it to avoid Z-fighting in case SVG layers overlap. For simple cases, it is possible to do this by just manually editing the X3D file in any text editor. Assigning meaningful names to your objects in SVG, e.g. using Inkscape “Object Properties”, also helps. I have done it with a non-trivial SVG file (our engine logo) and the manual effort was ~easy 🙂

See the result of my play in demo-models/svg. It shows how to fix Z, I also add a shader effect to discard pixels outside of a circle in the middle, to “cut off” stuff that should not be visible in a circular engine logo.

I encourage you to test the converter and explore X_ITE in general. Many thanks go to Holger Seelig for an amazing work on this!

This is probably not the most sexy graphic effect announcement :), but the lines and points are useful to visualize a lot of things.

We have improved our glTF support to properly import points, lines (lines, line strips, line loops), and their materials.

We have also improved our X3D nodes capabilities by introducing TIndexedLineSetNode.Mode and TLineSetNode.Mode. This allows to comfortably and efficiently define lines, line strips, line loops in X3D.

Thanks to recent rendering code improvements, we can finally request “core” profile on macOS, to get latest OpenGL version (4.1 in my case) instead of being stuck with legacy OpenGL 2.1 on mac.

We request now a modern context on mac, both with TCastleWindow and TCastleControl. This applies to all our software — CGE editor, view3dscene, all your applications you build with CGE.

You can use the new TCastleRenderUnlitMesh utility class to render unlit 3D objects easily. It has a nice API when you want to render a set of vertexes and then forget about them — sometimes this is easier than setting up the shapes in TCastleScene. It may be especially useful for rendering debug 3D geometry, in fact view3dscene is already using it for this purpose.

An example usage is in test_rendering_opengl_capabilities example, in unit gamemymesh.pas.

Moreover, thanks to this class (and some other improvements I’ll describe in subsequent posts) we have upgraded our shadow volumes code, making it simpler and working with mobile OpenGL ES, without losing any performance. You can test shadow volumes on OpenGLES e.g. using examples/viewport_and_scenes/shadows or by creating a new project from “3D FPS Game” template.

And while we’re at it, our shadow maps code was also fixed. It now works on OpenGLES in much the same way it does on desktop OpenGL.

Note: This is not the end of shadow maps upgrades. They are still not as straightforward to activate as they should be, and they don’t cast shadows on multiple scenes. More work on shadow maps is coming 🙂

First, a reminder that our DelphiCon presentation is in ~3 hours, 2:00 PM in Central Standard Time. See DelphiCon 2023 to register, you can also just watch the live stream on Embarcadero YouTube. I hope you will enjoy it! I will be of course present during the presentation, go ahead and fire questions at me:) See also more talk information here.

Second: Game Industry Conference recently published a recording of my presentation there, from October 2022. It’s just 30 minutes, and it’s really a very different talk from DelphiCon, I talk about the engine high-level decisions (like glTF, X3D), motivation, thoughts on making open-source game engines (declarative, evangelism). The slides from GIC presentation are also available. So, if you can’t wait to see me :), I encourage to watch GIC 2022 talk now:

I have a lot of pending news from recent engine developments (big refactor to rendering, lots of OpenGLES improvements, Tiled improvements) but for today, the most important thing:

Join Embarcadero DelphiCon 2023, an event celebrating 28 Years of Delphi, and listen to our talk “Getting Physical in Your Games with Castle Game Engine” on Thursday (February 16, 2:00 PM in Central Standard Time). As always be careful to recalculate timezones, personally I found it easiest to register and then add particular event to the calendar by clicking on the appropriate link, and then I can let my calendar software do all timezone calculations 🙂

You can also just watch the event on Embarcadero YouTube, they stream it live.

My talk focuses on new features coming in 7.0-alpha.3, with a special emphasis on physics. I spend a significant part of this talk doing funny things with physics :), there is also a nice overview of CGE usage for 3D in general, I also fall in love with a particular sound effect. My talk is prerecorded this time, and as such I can already spoil that it was impossible to fit everything into my 1-hour slot, and I will be releasing some “bonus” videos afterwards, if you can’t get enough of my rambling and will want more after DelphiCon 🙂

And while I show there everything in Delphi, since it’s DelphiCon, it is really all the same if you’re an FPC/Lazarus user!

My talk description:

Castle Game Engine is an open-source cross-platform 3D and 2D game engine. We’re aiming at a huge engine release “7.0” shortly after Delphicon 2023. As such, I’d like to show the latest juicy stuff we’ve been working on: physics, shadows, rendering huge maps, using engine as part of VCL or FMX form. The session will start with an introduction to using the engine with Delphi. Everyone interested in making games using Delphi is welcome!

While technically I’m busy on shadow-volumes-new branch (despite the name, it has spiraled into a number of generally useful rendering code refactors; rendering on both modern and ancient GPUs will benefit, as various things are improved and the code gets simpler too)…

…let me make a non-technical post 🙂

We really appreciate your donations and, going forward, this is ideally the way to fund the development of the engine, The main goal of donations is simply to cover the cost of people, so that they can work on the engine full-time, which in turn just translates to more features, faster. Right now we have 1/2 developer on a payroll (Andrzej Kilijański, paid from Michalis Kamburelis own pocket) and hiring him was a great decision — having Andrzej made a big difference, the engine progress in recent years owes much to his work. Imagine we can have 10x of that 🙂

Our recommended way to donate is a monthly subscription on Patreon. Patreon offers a number of traditional payment methods.

On top of making things easy, Patreon also offers a unique reward for donors: 4 physical sticker with CGE logo that you receive after 3 monthly donations at 10 USD tier. See the photo 🙂 They ship worldwide, I tested 🙂

But there are other options, always listed here. These include:

1. If crypto-currencies are your thing, you can donate using:

   Ethereum: send to this address: 0x0b0e37c7391C7268DEc9c0De63bA5A3b1B42baCe

   Bitcoin: send to this address: 1FuJkCsKpHLL3E5nCQ4Y99bFprYPytd9HN

2. GitHub Sponsors

3. Open Collective

Whichever option, whichever tier you choose — big thank you!

I’m serious about developing the engine, I’m serious about making something that enables you to develop great games with open-source software. We are doing it… wow, I just found the oldest news post from 2004. So 18+ years now. The engine is now old enough to drink and do other adult stuff 🙂 And you can see at our regular news, for so many years that we don’t stop and we don’t plan to stop. I hope you enjoy this journey and want to support us along the way. Financial funding is, in the long-term, something that allows to work on the engine just as a regular thing, with as much people and time we can afford. Your support really changes what we can achieve and how fast we can do it.

Enjoy creating games with Castle Game Engine!

To start the weekend, I added a new example to Castle Game Engine showing the navigation in games like “Eye of the Beholder”: moving on a grid, rotating by 90 degrees, crawling a dungeon with a group of heroes 🙂

The example is in examples/eye_of_beholder directory of engine sources. Just open with CGE editor and run. The level has been designed in Blender.

You can move and rotate using keys or by clicking on buttons (so it also works on mobile).

See the screenshots on the side — can you tell which one is the original “Eye of the Beholder” game and which is our example? 🙂

This post somewhat retracts yesterday’s post, because I had a busy sleepless night and fixed some issues with loading Tiled in TCastleScene that I mentioned yesterday 🙂 I did a significant refactor of how it works.

I’m proud to say that loading Tiled maps into TCastleScene is now our recommended approach to using Tiled maps. The big benefit of this approach is that you can place additional objects, like sprite sheets in TCastleScene, over the map easily (and specialized API to place/move units on map will appear soon too). TCastleTiledMapControl will soon be deprecated, in light of this.

The following improvements are done:

1. First of all, we have new example application examples/tiled/map_viewer_in_viewport where you can test everything I announce today. It is a simple Tiled map viewer, underneath loading Tiled map to TCastleScene.

   You can test that it is functionally just as good, if not better, than examples/tiled/map_viewer approach.

2. Huge optimization, by internally using a single draw call for all consecutive tiles using the same tileset. This allows to effortlessly support our test map 400×400 in examples/tiled/map_viewer_in_viewport/data/maps/desert_big.tmx with 100 FPS, at whatever zoom.

3. Support for all map types: Orthogonal, Isometric, IsometricStaggered, Hexagonal.

4. Correct support for all flip combinations (diagonal, horizontal, vertical).

5. Fixed layer Z ordering and offset application for all layer types.

6. Fixed origin (map left-bottom corner is now at 0,0).

7. Support for “Smooth Scaling Safe Border”, to fix rendering artifacts when using smooth scaling on tilesets without proper alpha bleeding.

8. I’m proud that my refactor actually made the code over 2x smaller and simpler 🙂 Line count dropped 1210 -> 510 for the x3dloadinternaltiledmap.pas unit.

If you like my sleepless nights’ work, please support us on Patreon 🙂

OK, this post title is probably too long 🙂 But I really want to announce a few related things, and talk about related plans. Bear with me, and read on if you’re developing 2D games using Castle Game Engine with something like a map underneath.

1. I’m happy to announce a very powerful and easy to use optimization for TDrawableImage rendering: almost automatic batching. The way it works is really simple: if your rendering code is mostly just a sequence of calls to TDrawableImage.Draw, then you can surround it with TDrawableImage.BatchingBegin and TDrawableImage.BatchingEnd calls (these are class methods) to achieve a significant speedup.

   Underneath, batching for TDrawableImage means that rendering many times the same image gets grouped into a single OpenGL(ES) draw call, and so it’s much faster. It works because GPU has great performance if you tell it to render million quads with a single draw call, while it’s quite inefficient if you use million draw calls to render one quad each.

   E.g. this code actually does just 2 draw calls now, not 200:

   TDrawableImage.BatchingBegin; for I := 0 to 99 do MyDrawableImage1.Draw(100, 10 * I); for I := 0 to 99 do MyDrawableImage2.Draw(100, 10 * I); TDrawableImage.BatchingEnd;

   TDrawableImage.BatchingBegin; for I := 0 to 99 do MyDrawableImage1.Draw(100, 10 * I); for I := 0 to 99 do MyDrawableImage2.Draw(100, 10 * I); TDrawableImage.BatchingEnd;

   This should be a great tool for people doing lots of image rendering.

2. Using the above batching, I have greatly optimized our 2D Tiled rendering control TCastleTiledMapControl, that now internally always activates this batching.

   As Tiled rendering uses TDrawableImage to render each tile, it benefits greatly from the new batching.

   Moreover, as another optimization, TCastleTiledMapControl no longer renders tiles that fall outside of its render rectangle. This rendering was useless, and it could cost significant time.

   I have also added a test map, examples/tiled/map_viewer/data/maps/desert_big.tmx, with 400×400 tiles, to demonstrate this optimization. Before optimization, it had 2.7 FPS on my system (yeah, less than 3 FPS…), clearly demonstrating that previous rendering was unoptimal. After adding batching, FPS increased to 24, and then avoiding rendering useless tiles gets us to nice 61 FPS. The FPS stay reasonable even at significant zoom out.

   You’re welcome to test it all yourself, just build and run examples/tiled/map_viewer/ yourself.

3. In parallel to improving our simple 2D drawing (TDrawableImage, TCastleTiledMapControl) we also pursue another way to render 2D things in Castle Game Engine: render your whole 2D world as a number of objects (like TCastleScene and TCastleImageTransform) in a viewport.

   The approach to put things in scenes and viewports is in general much more feature-rich. Scenes can have physics, they can easily render sprite sheet animations, they can be designed visually in CGE editor (see e.g. Platformer demo done in editor this way), they also work in 3D (so a lot of work and optimizations benefits both 3D and 2D games).

   This means that in general, we advise you to use scenes and viewports for 2D games. Our new project template “2D Game” shows this approach.

   That said, the approach of “scenes and viewports” is admittedly not as efficient as (much simpler internally) rendering using TDrawableImage, TCastleTiledMapControl. This is especially visible if you try to design a big map for 2D game. Both memory (because of our X3D nodes memory usage) and performance suffers (because our DynamicBatching cannot yet handle some cases, and it doesn’t batch across scenes, so it’s worse than TDrawableImage.BatchingBegin and TDrawableImage.BatchingEnd in case of maps).

   There’s no single best solution (yet) to this “dualism”. We work on optimizing our scenes and viewports, and until it is perfect — I hope you can enjoy 2 methods of rendering 2D stuff. They are documented on How to render 2D games manual page.

4. Pursuing the approach to render things using scenes, with many thanks to Matthias (from Free Pascal meets SDL) you can now load Tiled maps to TCastleScene. Simply point TCastleScene.URL to a Tiled map file (.tmx).

   This allows to render map inside a viewport, mix it with other viewport things (like scenes with sprite sheets) and use viewport camera (also at design-time) to pan and zoom the map. And you can even rotate map, even in 3D 🙂

   The loading is not yet efficient, and doesn’t account for some map types (like isometric or hex). So TCastleTiledMapControl remains our recommended approach to render Tiled maps for now — but at some point in the future using TCastleScene should be fully efficient and functional and then it will be advised as more feature-packed.

5. I have been playing with creating isometric games (without Tiled help) too.

   The result are new demos examples/isometric_game and examples/isometric_game_3d.

   They use TCastleViewport with items (like TCastleImageTransform and TCastleScene with sprite sheets) to express the map and objects on it.

   They show how it’s a feature-rich approach — e.g. isometric_game_3d has cool shadows 🙂

   It is possible that in the future we could have a built-in tiled editor in CGE. I still haven’t decided when is the right time to pursue this — for now, relying on Tiled is great, but a built-in tiled editor remains an interesting option.

6. Finally, the optimizations necessary for great performance when you use lots of small scenes and images to render maps are really in progress 🙂

   I’m now working on branch shadow-volumes-new that, despite the name, includes a few useful renderer refactors. In particular it changes the way our shape renderer needs to be initialized / finalized, opening the door for cross-scene batching.

Thanks for reading! This was a complicated post, as admittedly what we do may be a bit confusing — we do pursue (and even document) 2 approaches for 2D maps, and we improve them both. But we also have a preference which one should “win” in the future (viewport and scenes!) but it will take time to get there with full performance. I hope what we do is clearer now and that you will enjoy the journey 🙂

As always, please ask on our Discord or forum if anything is unclear.

And we appreciate supporting us on Patreon. We also opened the option to donate using Ethereum if crypto is your thing 🙂