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: 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.
Improvements to game logic:
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 :).castle_game_engine/examples/resource_animations/
in sources.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.Final code renames/refactoring:
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.
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.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.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).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.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!
CONSERVE_TRIANGLE_MEMORY
symbol.CastleWindowProgress
: Opacity
property, configurable colors, using UIFontSmall
when necessary, fixed to work with non-standard glViewport (like after typical TCastleViewport usage).ExclusiveEvents
= true, consistent with other TUIControl.CastleLog
output 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).