Comment on this post ➤
To finish the week of many annoucements, here are 3 more engine features added lately.
BTW, I also wrote a wiki page documenting common properties to “make rendering prettier”. Check it out:)
New engine features:
Scene.Attributes.SeparateDiffuseTexture allows to get a prettier lighting behavior. The textures (in
CommonSurfaceShader.diffuseTexture) will then really affect only the diffuse lighting term. This is generally better and prettier (specular highlights are then brighter), and it’s also more correct (according to X3D spec). But note that it is only possible in Phong shading (when
Scene.Attributes.PhongShading is also
true), and it makes rendering a little more expensive (for now).
In view3dscene (see view3dscene from snapshots) you can use menu item View -> Separate Diffuse Texture (When Phong Shading) in addition to View -> Phong Shading on Everything. By default it is false, to be compatible with previous look, and also because it’s more consistent with Gouraud shading behavior. (And the Gouraud shading is default, in turn, for speed.)
Client and server classes for implementing TCP client/server communication in Castle Game Engine games are available. See the unit CastleClientServer, and the demos in examples/tcp_connection. Thanks go to Benedikt Magnus for implementing this!
You can now instantly disable/enable physics by setting SceneManager.Items.EnablePhysics to false/true.
Comment on this post ➤
Since a long time, you can automatically generate compressed and/or downscaled textures versions using our build tool.
This process is now smarter. Instead of detecting which files to update looking at file modifications times, it now looks at file contents (using fast MD5 checksums), and automatically creates/updates a
castle_engine_auto_generated.xml file. The
castle_engine_auto_generated.xml is automatically created and maintained in your
data/ directory when you call
We plan to extend this feature even more, to store more information inside the automatically-maintained
castle_engine_auto_generated.xml. In the future, this file can be used to:
- Track the size of the texture. This allows to avoid trying to load non-square compressed texture on iOS, which is not possible — thanks to weird Apple limitations. Currently we just avoid using any auto-generated compressed textures on iOS.
- Track the DXT* version generated, for the case when we automatically choose the best DXT* version depending on the image alpha channel. This would complete a currently unfinished-and-undocumented feature of
<format name="DXT_AutoDetect" /> in
Comment on this post ➤
You can now comfortably localize (translate) your game.
Two approaches are possible:
- Use our own localization class from the CastleLocalization unit. It can read from a number of translation formats (XML, JSON, CSV, GetText MO). It can translate user-interface controls, like TCastleLabel. The demo is inside examples/localization/custom/.
For advanced users, the system allows to aid in localizing your custom classes too (see OnUpdateLocalization) and to add your own translation formats (see FileLoader).
Thousand thanks go to Benedikt Magnus for developing this!
Use the standard GetText unit from FPC. You use GetText formats for translating (PO, MO), utilizing tools like PoEdit. The resourcestrings are translated automatically. The demo is inside examples/localization/gettext/.
The engine uses resourcestrings for some internally-generated messages (and it will use them more), so these can be translated too.
In both cases, you can use a cross-platform CastleSystemLanguage unit that tells you the preferred user language.
Note that, while both approaches (GetText, our own) provide some infrastructure to aid you in translating (resourcestrings, special handling for UI controls), you can also translate things “explicitly” in both cases. Using the TMOFile.Translate(‘my_id’) in GetText, or Localization.Items[‘my_id’] in CastleLocalization.
So both systems are really flexible, and should fill all your needs 🙂
A related feature is also new TInputPressRelease.KeyString. This expresses key press as a string with UTF-8 encoding, and allows us to accept input of international characters across Castle Game Engine (for example in TCastleEdit). Many thanks go to Eugene Loza for this!
Comment on this post (1 comment now) ➤
I have a large backlog of new Castle Game Engine improvements to announce 🙂 Let me try to make it up, by making a new announcement more-or-less daily for the following week. Remember that everything I describe is available to you right now: simply use the Castle Game Engine version from GitHub (6.5).
We start with the improvements to our PlayAnimation method. It is the primary way to run animations using Castle Game Engine (documented in the manual).
- New overloaded
PlayAnimation version with TPlayAnimationParameters, that allows to specify:
PlayAnimation(AnimationName: string, Loop: boolean) version. This replaces (deprecates) older overload with
"Looping: TPlayAnimationLooping" parameter — the TPlayAnimationLooping did not really prove to be of much use, so it’s simpler to just specify Loop as a boolean.
I have also written a large documentation “How to animate things using X3D”. This may be useful for developers that want to understand how the X3D nodes are used for animations. The
PlayAnimation method, under the hood, uses the X3D nodes.
Comment on this post ➤
We’re proud to present Connect4, a free game for Android published by Benedikt Magnus and LanIstAn today!
The game is using Castle Game Engine, with our 2D user-interface rendering, and includes music, localization (English, Polish, German, Spain), and networking support. You can plan against a computer, or against a friend over the network. I believe this is the first game with networked play done using CGE.
I really like this part of developing Castle Game Engine — seeing how others are using it to create the coolest things. Congratulations and thank you!
We also have a ton of new features added to Castle Game Engine lately. In particular, thanks to Benedikt Magnus we now have:
And I’ll be posting more about the new CGE features later.
Comment on this post (4 comments now) ➤
We are now officially Embarcadero Technology Partner!
What this means, in simple terms, is that Michalis has full access to the latest Delphi version, with all the Delphi platforms (including Android and iOS), for free.
This should be great news for everyone waiting on Castle Game Engine + Delphi compatibility:) We have no more excuses now, Castle Game Engine will have to work perfectly with Delphi!
Thanks go to Embarcadero, and in particular Jim McKeeth, for making this possible.
(P.S. I curse myself for making this announcement on the one day of the year when everyone else is making jokes 🙂 Yes, this is very real, and is happening! Our supported compilers and IDEs page is already updated about it.)