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.)
Animation blending means that the transition between animations is smooth. Without animation blending, the old animation instantly stops and the new animation plays. With animation blending, there is a short time during which the old animation “fades out” (it’s applied with decreasing strength) and the new animation “fades in” (analogously, it’s applied with increasing strength).
The movie below shows this technique in action in new Castle Game Engine. Notice how animation changes are sharp when TransitionDuration is zero, but they are smooth when TransitionDuration is larger. This is especially visible when switching between “Idle” and “Attack” animations on the 3D knight model.
This feature was implemented thanks to Castle Game Engine supporters on Patreon, in particular thanks to Robert Daniel Murphy who wished for it. Thank you! Please support me to see more cool features 🙂
We have a new demo examples/play_animation/ to test the PlayAnimation method, including Loop, Forward and TransitionDuration.
Additional cool features of our animation blending
Note that animation blending happens even when you restart the same animation. We show this in the movie by restarting the “Walk” animation — note that “old Walk” blends smoothly into “new, restarted Walk” when Transition is non-zero.
Animation blending works for any field that can be linearly interpolated. So it works for animating translations, rotations, coordinate sets and everything else. It works for mesh deformations, or bone animations produced by Spine. It works for 3D or 2D.
Caveats (aka “things that, sadly, do not work yet”)
For now, the animation blending doesn’t work for animations defined by castle-anim-frames (which you probably use to export animations from Blender). Fixing this requires improving the castle-anim-frames loading a bit.
Background: Animation blending only works when the same mesh is used by all animation frames, but in case of castle-anim-frames we cheat a little and we have many (precalculated) copies of the mesh. This was supposed to be fixed one day anyway, to decrease memory usage (see the TODO here). It turns out that this fix is also needed to enable animation blending.
For now, there is no way to define TransitionDuration for animations run by our TCreature system (using resource.xml) files. The resources animations (like TCreature) are done a little differently, without directly calling PlayAnimation, and they require a bit different code to make use of animation blending.
Both of these will be fixed one day (AD 1 is a work for ~2 days, AD 2 is a work for ~0.5 day). Let me know if any of this is critical for your project, and I’ll try to make it rather sooner than later! 🙂
Castle Game Engine is using X3D as our scene graph. This means that we have a huge number of nodes (like Transform, Shape, IndexedFaceSet) that are nicely documented in the X3D standard. And you use these nodes throughout the engine (by loading files, like X3D files, or constructing the scene using these nodes from Pascal code — see example here or (2D) here).
As our engine grows, and we get more features, I also propose some extensions to X3D, to add more features both to X3D and to Castle Game Engine. I decided to summarize them in the wiki:
Some of these proposals are already implemented in Castle Game Engine (e.g. CommonSurfaceShader, consistent RGB texture treatment, shadows). Some are planned (e.g. PBR, and binary meshes using glTF integration). All the comments are always welcome!
We also talk about these things on x3d-public mailing list, and I encourage everyone to join. If you have an opinion how X3D should look like (in the context of Castle Game Engine usage, or not!), or if you wonder how to do something using X3D — this is the list 🙂
Our website has moved: It is now on https://castle-engine.io/ . Our own server (in Los Angeles), our own domain. This makes our website independent from SourceForge. And it opens the door for some cool new features (online 3D models converter, screenshot generator, notifications from WordPress).
Our most important downloads (engine, view3dscene) have also moved, to be independent from SourceForge. They are now hosted on GitHub. This makes downloading smoother (no more SourceForge “download redirect” page). BTW, did you know we have a permanent link to the latest CGE download: https://castle-engine.io/latest.zip.
Important fixes:
Mouse look handling on Windows 10 has been fixed.
Fix for Windows Intel GPUs version <= 8: use fixed-function pipeline.
The drawing_toy example (examples/mobile) uses now fast TGLImage.DrawFrom for drawing.
New TCastle2DSceneManager, with more consistent Transparent (default false, just like TCastleSceneManager, and making TCastle2DControl opaque by default).
I have some more cool news to share, stay tuned! 🙂
Let us introduce a new mobile application based fully on Castle Game Engine. It’s a mobile version of our view3Dscene. Basically, it opens scenes in supported 3D formats, and lets user to walk / explore them, navigate through viewpoints and take screenshots. It also includes some demo scenes. As it should be a regular mobile app, not a game, we had to add many new GUI-related features into the engine.
New features available in the engine, added because view3dscene-mobile needed them:
Examine camera uses new gesture recognizer to detect pinch-to-zoom and two-finger panning gestures. The panning was possible only with the white round touch control before, so we can get rid of it for Examine camera now.
We handle screen DPI setting to scale UI on Android and iOS and present properly sized controls to the user. App works both on tablets and phones in both landscape and portrait modes. The Window.Dpi is now correct on both Android and iOS.
New controls: SwitchControl represents variable with on-off state (i.e. a touch-friendly checkbox), and powerful TableView control that has been designed to provide easy way to present dynamic lists with accompanying images or custom controls. It has similar interface as the native iOS UITableView or Android ListView.
Option to have the operating system status bar on (with carrier name, clock, battery status). Games usually hide it, which is also the default in our engine, but it may be useful for regular app to leave on. It also applies to the bottom bar with software buttons on Android. To use this in your own applications, set fullscreen_immersive=”false” in CastleEngineManifest.xml and design your UI to leave space at the top following Container.StatusBarHeight.
As view3Dscene is an app to view all supported 3D file formats, apps made with Castle Game Engine can now define the file extension associations for Android and iOS in their manifests. See view3dscene-mobile CastleEngineManifest.xml for an example how to define file associations in your own applications.
This post was written mostly by Jan Adamec, who is developing view3dscene-mobile since November 2017. My thousand thanks go to him, both for working on view3dscene-mobile and for implementing many missing necessary features in the engine!
You can now easily play the animation backward, passing the Forward = false parameter to PlayAnimation. Internally, X3D TimeSensor node is enhanced with a new field TimeSensor.fractionIncreasing.
String is now always UTF-8, just like in Lazarus LCL. This changes the treatment of localized (non-English) characters inside AnsiString (the default string). The engine now behaves just like Lazarus (LCL), regardless if you use TCastleControl (with LCL) or TCastleWindow (without LCL), and treats all strings as containing UTF-8 characters. This change is done in CastleUtils initialization code. Advantages:
consistency with Lazarus, that already does the same.
We now support Spine paths. They are converted to NURBS curves internally, and you can display them or use them from code to do anything you like (e.g. animate camera or some character along the path). See Spine support in Castle Game Engine for notes.
view3dscene has new menu items in the “Edit” section: “Hide Selected Shape”, “Reveal All Hidden Shapes”
Fixes:
We now treat Intel GPU on Windows with driver version >= 9 more like a normal GPU: assume they can make cubemaps, and generate mipmaps. See here.
Fix compiling with CodeTyphon FPC. Thanks to Benedikt Magnus!
Note that Michalis still advices to use normal FPC and Lazarus with Castle Game Engine, not CodeTyphon. I simply trust more in FPC and Lazarus developers, they care about making open-source Pascal code in a proper way, and with good quality.
We’re proud to announce Castle Game Engine 6.4 release! Castle Game Engine is a free, open-source game engine written in Object Pascal. We support both 3D and 2D games. We are cross-platform (desktop, Android, iOS — with the help of our own build tool and scalable user-interface components). The complete list of the engine features is here, so go ahead and download it and try!
Jan Adamec is working on a mobile view3dscene — a viewer for X3D, VRML, and all the other formats supported by Castle Game Engine (Collada, 3DS, MD3, STL, Spine JSON…) for Android and iOS. He also implemented various new CGE features in this release — thousand thanks!
New powerful TCastleTransform class is introduced. This allows to transform scenes (TCastleScene instances) in a comfortable way. It is also the ancestor of TCastleScene, so you can now e.g. trivially move the TCastleScene by just doing Scene.Translation := Scene.Translation + Vector3(1, 2, 3);.
Together with the new engine, we also release view3dscene 3.18.0 — our 3D and 2D model browser, and glViewImage 1.8.0 — our image browser. These tools are useful when working with the engine (to quickly check how does the engine handle given model or image), but are also perfectly useful on their own, to view or even post-process your files.
At this moment, I also want to ask you to support the engine development on Patreon. This support really helps me, and is very appreciated. Various 6.4 features (like physics integration!) would not happen without this.
If you have not yet seen my plans for 2018, read them — I have a plan that should make our engine the best engine ever 🙂 In short: editor component (to get standalone editor, like Unity3d, and to get editing inside Lazarus/Delphi, like GLScene, and to get runtime inspection/editing of the game world), Delphi compatibility, glTF and PBR, and looking closely at WebAssembly and pas2js.
rift (fixed_camera_game) example was completely reimplemented. It now uses TUIState, has muuuch simpler code, and is portable to mobile (Android, iOS).
Terrain example reimplemented, has now much more functions (like adjusting shader parameters) and better defaults (some taken from wyrd-forest), and is portable to mobile too (Android, iOS).
sandbox (now just “isometric_game”) code improved (although it still uses a very simple approach to rendering) and it can compile to mobile (although input still relies on a keyboard).
Sound buffer improvements and fixes: TSoundBuffer is a class now (although it should be invisible to you, as it’s automatically managed by the sound engine). And it correctly “survives” if the application was paused / resumed on Android. So you can safely do Buffer := SoundEngine.LoadBuffer(‘sound.wav’) in Application.OnInitialize and then play this buffer at any time later.
In preparations for releasing Escape from the Universe on iOS, I have implemented a number of new “services” on iOS. They allow to integrate your games easily with various iOS frameworks.
Send analytics to Google Analytics or Game Analytics. Both are excellent and free analytics platforms for mobile games. You can gather a lot of data about how people are installing and playing your game. They both provide a number of statistics out-of-the-box, and in addition you can send a number of custom events (clicks, level progress, timings etc.), and in addition the in-app-purchases are automatically logged (so you can see when and who purchases things). Oh, and the Pascal API to handle it is trivial, and works also on Android: use TAnalytics in CastleAnalytics unit.
Basic integration with Facebook SDK. This provides yet another analytics, this time integrated with a Facebook application. It can also be used to login to Facebook within your game. More integration with Facebook may be implemented on top of this in the future.
