Development: engine 4.0.0 release in a few days, many improvements this month
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:
New very important example program is available in engine source code:
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.
Improvements to game logic:
TWalkAttackCreature.Enemymethod. 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 :).
RenderDebugCaptionsmechanisms (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.Pickedmethod 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").
TexturePropertiesmechanism 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.xmlmust 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.
Final code renames/refactoring:
CastleXxxnames. 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
Castleprefix, some not. Now all unit names have
Castleprefix (the only exception being
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.
DefaultXxxglobal 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.
resource.xmlfile refers to the resource class (maybe it's creature resource, maybe item resource and so on), and creates resource instance.
TCreatureResourceis derived from
TItemResourceis derived from
KeysMouse) types are no longer aliased in
CastleWindowunit. This was unmaintainable, and wasn't available in Lazarus
CastleControl. Simply add
CastleKeysMouseto your uses clause if you use any identifier from it.
bump_mappingexample dir, not useful for engine; and
bump_mappingwas actually removed from engine core, as not useful anymore, it's now in obscure_castle_engine_demos_and_tools repo).
Other engine improvements:
CastleImagessupports resizing images with bilinear interpolation.
riBilinear. Default is still
riNearest, so fast (and ugly) like before.
CastleWindowProgress, when it needs to scale progress background image, requests
riBilinearinterpolation. glViewImage allows to test both resizing methods.
TOutlineFontare classes, with Data field and some methods. This way utilities from
font2pascalutility 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!
Opacityproperty, configurable colors, using
UIFontSmallwhen necessary, fixed to work with non-standard glViewport (like after typical TCastleViewport usage).
ExclusiveEvents= true, consistent with other TUIControl.
CastleLogoutput stream is configurable.
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).