We already posted about our new upcoming game “The Unholy Society”. Some more background:
Our little indie game studio “Cat-astrophe Games”, making games using “Castle Game Engine”, has just signed a contract with a great Polish publisher “Fat Dog Games”. That means that we have someone who will pay our bills while we develop games using “Castle Game Engine” !
And this means that I, as of today, can work 100% of my time on “Castle Game Engine” and games using it (“The Unholy Society”, and also “Escape from the Universe” for iOS soon). Many things will happen, in more-or-less this order:
Expect some iOS improvements in November, for “Escape from the Universe” for iOS.
Expect Delphi compatibility in CGE. I know I did not post about it lately, but it is still the main feature of the upcoming CGE 6.4. release! More plans about CGE are listed here — I “live by this list” since a long time, trying to prioritize my life to achieve these engine features.
Expect various engine improvements caused by “The Unholy Society”: Steam integration. Spine support improvements (animated meshes, shearing, probably Bezier curves). And I will make (probably as a separate project on GitHub) a Yarn dialogue reader and player (Yarn dialogue was used e.g. in a fantastic “Night In The Woods” game).
Engine improvements that happened lately:
(Work in progress) We have a new class
TCastleTransform, that unifies and simplifies previous classes
T3DCustomTransform. It is also the ancestor of
TCastleScene, so finally you can just do
Scene.Translation : ...without the need to wrapp the
There are still some bits in-progress here. I’ll write more when it’s finished.
Improvements to setting X3D fields comfortably:
SetXxxon various TMFNode classes, e.g.
Partially workarounded Lazarus CodeTools problems with new generics. Unfortunately, Lazarus CodeTools do not handle Delphi generics OK, yet. So Generics.Collections cause problems. Also CastleUtils unit on FPC 3.0.x causes problems (but not with FPC 3.1.1.)
Sound engine sources are now updated better (without the need for TCastleSceneManager).
Lazarus packages always use inline now (it was disabled for some time). So things will be faster.
TCastlePrecalculatedAnimationwas removed from the engine. It was deprecated before 6.0 release. Simply use
TCastleSceneto play *.castle-anim-frames or *.kanim files.
1. Adding new renderer to the engine
I sometimes get questions “Will there be another renderer available in the Castle Game Engine?”. My answer was always this: “Yes! Contributions for this are most welcome. It is just not my own priority now, because the current renderer (using OpenGL / OpenGLES) works great, and it works on all platforms.”
To make it easy for everyone to actually start experimenting with a new renderer, I wrote a simple example code that shows how you can start a new renderer. Just fill the
TCastleSceneVulkan.Render and test on any 3D model 🙂
And if you have something (even just a start!) ready, don’t forget to post about it on our forum (bonus points if you will already show a CGE fork on GitHub where it can be tested). This will make Michalis extremely happy and it will avoid duplicating the work 🙂
2. OpenGLES: suggestions for new contributors
If you know your way around 3D coding, and you’re looking for interesting tasks to implement in the engine, please take a look at our OpenGL ES (Android and iOS) TODOs. This page describes 6 features that are implemented in OpenGL, but are not (yet!) implemented in the OpenGLES version.
Some of these tasks are “relatively easy (and fun!) with high reward“. You can make a cool graphic effect working on Android and iOS. The groundwork is already done (since it’s a feature already working for OpenGL), and your job is to adjust the code to work also on OpenGLES. E.g. you can activate shadow volumes on OpenGLES just by changing the current fixed-function shadow volume rendering to use shaders (the desktop OpenGL rendering will be upgraded by this too, of course — we don’t need a fixed-function implementation of shadow volumes at all).
3. Renderer improvements implemented lately
- Gouraud shading in the shader pipeline now honors
ccwfield correctly. The Gouraud shading performs one-sided lighting, and now you can control which side receives the lighting using the
ccwfield, see the link for details.
- 2D rendering (
DrawPrimitive) since some time uses shaders by default on desktop OpenGL.
- Occlusion query (
Scene.Attributes.UseOcclusionQuery) does not use the fixed-function pipeline anymore.
Castle Game Engine is now integrated with the Apple Game Center on iOS! The new TGameService class handles both Google Play Games (on Android) and Apple Game Center (on iOS) with a common API.
A working example is within the
examples/2d_dragon_spine_game/, in particular see the Game.pas that implements the game logic and achievements.
Also, CastleMessaging unit was ported to iOS (this is used by various Android/iOS services), and various other “infrastructure” changes were made to enable implementing “services” nicely on iOS.
I have just finished a large rework of our rendering code 🙂 This unifies desktop (OpenGL) and mobile (OpenGLES) shader rendering better, and brings many new rendering features:
You can now choose between Gouraud or Phong shading, on both OpenGLES (mobile) or OpenGL (desktop). Our shaders support all combinations. By default we do Gouraud shading, but you can switch to Phong for the whole scene by
Scene.Attributes.PhongShading := trueor only for a particular shape using
Shape.Shading := shPhong. See also the X3D Shape.shading field.
Bump mapping (even steep parallax bump mapping with self-shadowing), specular maps and other CommonSurfaceShader features are now fully available on OpenGLES (mobile platforms).
You can set global
falseon desktops, to force absolutely all rendering to go through shaders, without any fixed-function calls. This makes our desktop rendering 100% based on shaders, instead of the previous mix of shaders and fixed-function operations. This will be the default (on modern GPUs) soon, and you’re welcome to test it now. You can also test it using view3dscene, just pass command-line option
Update: TODO: We still use fixed-function commands for shadow volume rendering and occlusion query features. This will be fixed (along with some OpenGLES upgrades), but until then: using these features will make your application call fixed-function commands, regardless of the
EnableFixedFunctionflag. Contributions to fix it rather sooner than later and most welcome! These are easy, local problems, they just need a dedicated person to handle them!
P.S. See also a simple example how to build a scene with custom shaders (X3D ComposedShader node), on display_box_custom_shaders.lpr.
Lots of new things for developers! 🙂
Improvements for iOS application building:
Additional attributes in CastleEngineManifest.xml for iOS: team identifier, overriding qualified name and version for iOS, specifying
Loading music from OggVorbis (using Tremolo customized for iOS).
Compilation fixes (workarounds for some FPC problems) to work in release mode.
Fixed touch up (mouse up) event. Test multi-touch with our drawing_toy example.
Fixed Android building from Windows.
Large camera API simplification:
TUniversalCameraclass is now gone. Change the navigation type using the new SceneManager.NavigationType property.
Details: I came to a realization that the
TUniversalCameraclass is a needless complication. We now expose
So now you can do
SceneManager.NavigationType := ntWalk;
instead of the previous (ugly):
(SceneManager.RequiredCamera as TUniversalCamera).NavigationType := ntWalk;
And instead of
SceneManager.Camera := SceneManager.CreateDefaultCamera; (SceneManager.Camera as TUniversalCamera).NavigationType := ntWalk; (SceneManager.Camera as TUniversalCamera).Walk.MoveSpeed := 10;
now you can do
SceneManager.WalkCamera.MoveSpeed := 10;
This is much simpler, right? 🙂 It’s also safer, without these ugly typecasts.
More new stuff!
And, in case you missed our announcements from 2 weeks ago, our engine is now integrated with an amazing Kraft Physics Engine by Benjamin ‘BeRo’ Rosseaux.
The manual page about physics in Castle Game Engine should be helpful.
The code to do this is 100% open-source, you can view it on GitHub here: physics_2d_game_sopwith (the main code is in “game.pas” unit).
Also, we now have a manual page describing how to use physics in Castle Game Engine.
This work was sponsored by Castle Game Engine supporters on Patreon. If you want to help in the engine development, please support me on Patreon! Thank you!
New physics classes (TRigidBody, TCollider and descendants) are now part of the Castle Game Engine core.
To use this yourself, see the T3DTransform.RigidBody property, and the TRigidBody and TCollider descendants documentation.
The example code on https://github.com/castle-engine/castle-engine/tree/master/examples/physics/physics_3d_demo should also help 🙂
We have mesh collider, to perform collisions with a scene mesh.
The mesh collider was beautifully trivial to implement. I honestly didn’t expect it to be so easy to code. Lots of kudos go to Benjamin ‘BeRo’ Rosseaux for creating the wonderful Kraft Physics Engine!
This was implemented thanks to the supporters of Castle Game Engine on Patreon. If you like what I do, please support Castle Game Engine on Patreon!
First results of Castle Game Engine integration with Kraft Physics Engine! 🙂
Kraft Physics Engine by amazing Benjamin ‘BeRo’ Rosseaux. Open-source, clean Object Pascal code, portable (Delphi, FPC, including FPC on Android and iOS).
I want to extend this a bit, and will post more details (on Castle Game Engine news/blog) soon. For now just enjoy the video 🙂
The physics fun was sponsored by Castle Game Engine supporters on Patreon. If you want to help in the engine development, please support me on Patreon!
As a little break from the work on Delphi compatibility, I added some new features to the engine 🙂
KTX (Khronos Texture format) support throughout the engine. See the details about KTX features supported. KTX format is in many ways an alternative to DDS, with a clean specification, supporting the same features (GPU compression, 2D and 3D textures…). The KTX Khronos page has links to various tools that can create KTX files.
Support nvcompress for automatic compressing of textures for GPU.
nvcompressis part of the NVidia Texture Tools. It is cross-platform (Windows, Linux…), free and open source. On Debian and derivatives (like Ubuntu) you can install it simply by
apt-get install libnvtt-bin. Thanks to Eugene Loza for advicing it!
nvcompresswill be automatically used underneath when you call
castle-engine auto-generate-texturesin your project. This requires using our build tool to manage your game project.
Our fps_demo shows how to easily get texture compression in your games. See the material_properties.xml in fps_game for how to trivially compress your textures to DXT1 and DXT5. See material_properties.xml and texture compression documentation for more information.
There was also an important fix to using this approach for textures referenced from X3D.
Useful helpers for X3D building, to easily create and modify X3D graph:
- New methods
RemoveChildrenfor grouping nodes (like TTransformNode, TGroupNode).
- New methods
CreateTransformfor geometry nodes (like TBoxNode, TIndexedFaceSetNode).
- Also on geometry nodes:
TexCoordand some more are now simple properties.
SetXxxmethods available to set various multiple-value (array) fields. Use them like this:
Coord.SetPoint([Vector3(...), Vector3(...)]); IndexedFaceSet.SetCoordIndex([0, 1, 2]); Inline.SetUrl(['my_file.x3d']);
These look much better than
Coord.FdPoint.Items.Assign([Vector3(...), Vector3(...)]); Coord.FdPoint.Changed;
and they always cause an appropriate update (they automatically will call
Changedfor you, and send the new value using X3D events).
This is all part of my ongoing effort to enable you to operate on X3D graph more comfortably, without accessing “somewhat-internal” fields instances in FdXxx (like FdChildren, FdCoord…).
- New methods
- Improved and simplified lets_take_a_walk example (examples/3d_sound_game/).
Intensive work on the engine Delphi compatibility is ongoing 🙂
We can now actually compile and run in Delphi (10.2) a simple console demo using our “base” units. Vectors, matrices, colors, rectangles, time measuring, logging, a lot of string and class and other utilities… it’s all working in Delphi. This is the demo code.
In parallel, I’m fixing the syntax of all the code to compile in “FPC Delphi test mode”, this is providing a nice baseline to later compile in the actual Delphi. On this front, I almost finished porting everything non-visual (I’m finishing the X3DNodes unit, which is a huge unit that depends on almost everything non-visual in the engine). So, we’re close 🙂
The “FPC Delphi test mode” means that we use FPC, but in Delphi mode, and disable macros, and disable operators like += etc. And I can run on Linux too, which is comfortable for me 🙂 So it’s like “make FPC behave as much as Delphi”. Any changes required at this stage would be required by Delphi too. To use it, you can set environment variable
CASTLE_ENGINE_TEST_DELPHI_MODEto “true” before running the build tool.
Units cleanup was done along the way. I rearranged some units, to remove some uncomfortable dependencies (when too many units are inter-dependent on each other). In effect, we now have a “files” unit group that includes units from old group “net” + units dealing with files. More details in the units map in the wiki.
Spine (2D animations format) improvements:
- When animating in Spine using Bezier curves (translations or rotations), the resulting movement in our engine is now exactly what you see in Spine.
- Animating the scale in Spine is now fixed (it was accidentally changing the order of layers).
DDS (image file format) improvements: support reading DX10 + DXGI_FORMAT_R8G8B8A8_UNORM case (produced e.g. by PowerVR Texture Tools when converting RGBA image to DDS).
In a spur of the moment, I wrote a short page about “What are range and overflow checks (and errors) in Pascal” 🙂
TDebug3Dclass is a new simple approach to visualize debug things attached to 3D objects.