Development: engine 4.0.0 release in a few days, many improvements this month

January 17, 2013
FPS game screen
FPS game screen
FPS game screen
FPS game screen
FPS game screen
FPS game screen
FPS game screen
FPS game screen
FPS game screen
FPS game screen
Debug 3D information

Many final improvements done to the engine, to make the next 4.0.0 release really polished for developers. Below is a list of new SVN features (implemented since last news, mostly within the last 3 weeks).

Engine 4.0.0 release is almost ready, what remains is finishing the new tutorials. BTW, I got into habit of posting a little smaller (and more frequent) notes about engine development on our Google+ page, so you're welcome to follow us there.

Latest improvements to the engine:

  1. New very important example program is available in engine source code: fps_game.

    It is a simple demo, with a lot of comments in code, of a fully-working FPS game. We have level, creatures, items (medkit and weapon), inventory, player can be hurt and die, player can shoot and kill the creatures, bump mapping, move limit, sectors/waypoints (for AI), buttons, notifications, custom viewport, sounds, sky, water, footsteps and a lot of comments.

    P.S. Various game data (knight, textures, sounds) are from opengameart.org, countless thanks go to it's many contributors. Details what is from where are inside AUTHORS.txt files in sources. Only level and items were modeled by Michalis from scratch.

  2. Improvements to game logic:

    • Creature enemy is now configurable by overriding TWalkAttackCreature.Enemy method. The default implementation chooses the central player as the enemy (if the player is not dead yet), but you can override it to implement something more sophisticated (like creature vs creature fighting, teams etc. — not everything is tested there yet, but it all should be doable now, so go wild :).
    • New methods to define creature/items (all resources) animations are available. You can load animation from kanim, or from multiple VRML/X3D files (one VRML/X3D for each animation), or from a single VRML/X3D file (in which case the file will have to contain different TimeSensor to activate each animation). Description how it works is inside DRAFT.modeling_tutorial.txt for now. Example of all 3 methods to define animations are inside castle_game_engine/examples/resource_animations/ in sources.
    • Many improvements to our RenderDebug3D and RenderDebugCaptions mechanisms (you can see them e.g. in fps_game demo): respect Orientation (work with games with either +Y or +Z up), sphere is displayed better, caption is multi-line and contains "enemy distance" info.
    • TItem.Picked method can be overridden to configure what happens when you pick item. Example code in fps_game shows how to make an item that is consumed on pickup (aka "power-up").
    • TextureProperties mechanism was enhanced into MaterialProperties, that can describe much more things. In the future, we can add there more stuff about material/texture that cannot be comfortably expressed in Blender, but that is conceptually tied to material/texture. For now, the main addition is that you can define bump mapping by normal_map properties there. The hack in our Blender exporter (to autodetect xxx_normalmap textures) will possibly be removed at some point (as it has no future, it's dirty).
    • player.xml must be now loaded explicitly by Player.LoadFromFile (we try to never load the file from some hardcoded location without you requesting it). Also, all player properties have now sensible defaults, so in simple cases there's no need to use this file at all.
  3. Final code renames/refactoring:

    • A lot of unit renames, to bring all units to CastleXxx names. I admit it was a mistake trying to have non-prefixed unit names in engine 3.0.0. After some time, many unit names had to be prefixed anyway, and this created inconsistent naming — some unit names had Castle prefix, some not. Now all unit names have Castle prefix (the only exception being X3DXxx units).

      It means that when upgrading your project from engine 3 to 4, you'll have to do appropriate renames in the "uses" clause of your units. Compiler will tell you where :) I also prepared a list of renames in doc/naming_engine_4.0.txt file.

    • Many DefaultXxx global constants moved to constants inside classes, to not pollute namespaces with a lot of constants that are usually useful only as default value for corresponding property Xxx.
    • All creature/items "kinds" renamed to "resources". Previously, terms "kinds" and "resources" were used to refer to the same thing, which could create confusion. Now it's simple: resource.xml file refers to the resource class (maybe it's creature resource, maybe item resource and so on), and creates resource instance. TCreatureResource is derived from T3DResource (as TCreature derives from T3D). TItemResource is derived from T3DResource, like TItemOnLevel derives from T3D.
    • CastleKeysMouse (formerly KeysMouse) types are no longer aliased in CastleWindow unit. This was unmaintainable, and wasn't available in Lazarus CastleControl. Simply add CastleKeysMouse to your uses clause if you use any identifier from it.
    • Removed units: VideosCache (merged into CastleVideos), Rectangles (merged to CastleOnScreenMenu), BezierCurve (merged to CastleCurves), NormalizationCubeMap (moved to bump_mapping example dir, not useful for engine; and bump_mapping was actually removed from engine core, as not useful anymore, it's now in obscure_castle_engine_demos_and_tools repo).
  4. Other engine improvements:

    • CastleImages supports resizing images with bilinear interpolation. TCastleImage.Resize and TCastleImage.MakeResized take Interpolation parameter, riNearest or riBilinear. Default is still riNearest, so fast (and ugly) like before. CastleWindowProgress, when it needs to scale progress background image, requests riBilinear interpolation. glViewImage allows to test both resizing methods.
    • Fonts: Huge refactoring of font units and types.
      • We now have 4 units: CastleOutlineFonts, CastleBitmapFonts, CastleGLOutlineFonts, CastleGLBitmapFonts.
      • TBitmapFont and TOutlineFont are classes, with Data field and some methods. This way utilities from CastleOutlineFonts become methods.
      • font2pascal utility added, this is a very old Windows-only utility to convert fonts into our bitmap/outline font structures. It awaits eagerly to be reimplemented using freetype, contributions for this are most welcome!
    • Memory optimization for models with many nodes (esp. using heavily prototypes), by about 10%, and another 10% possible if you define CONSERVE_TRIANGLE_MEMORY symbol.
    • Improvements to CastleWindowProgress: Opacity property, configurable colors, using UIFontSmall when necessary, fixed to work with non-standard glViewport (like after typical TCastleViewport usage).
    • "Home" key in Examine mode goes to initial viewpoint (configurable by VRML/X3D Viewpoint or SetInitialView in code), instead of always going to viewpoint with +Y up. This should be universally more useful and more natural than previous behavior.
    • Fixes to viewports for ATI on Linux (one bug of Mesa, one bug of fglrx, see BuggyDepth32 and BuggySwapNonStandardViewport in CastleGLVersion).
    • Examine camera has ExclusiveEvents = true, consistent with other TUIControl.
    • CastleLog output stream is configurable.
  5. The caustics demo (you seen a movie of this in earlier news) is now committed to our demo models. Many thanks to Victor Amat! I hope to use these ideas to make such water available out-of-the-box for all games using our engine (right now you will have to adjust shaders for your specific case).