Development: great API for 2D games and UI, our engine in Debian, on the road to OpenGL ES, Orcs and Volcanoes game screenshots
Great news for Debian users: Castle Game Engine package is available inside official Debian repositories. Version 4.0.1 is already available in the testing release, and version 4.1.1 is in unstable (on the way to testing). Installing Castle Game Engine in Debian, with documentation and Lazarus integration, is now as trivial as installing standard FPC units :)
On the side of this post you see screenshots from "Orcs and Volcanoes", a game Michalis did 2 weekends ago at Ten Square Games "gamejam" :) This is a roguelike with pixelart graphics, with some 3D twists and real-time action. For a weekend project (literally 36 hours of programming, no sleep) I think the result is quite cool, the game actually works and is playable :) Of course, it uses our engine for everything.
Almost all graphics from the "Badass Heroes" game. Used with permission, but they are not freely redistributable, so I can't share the game publicly... Anyway, feast your eyes on the screenshots :)
A lot of engine API improvements done in the recent weeks, in particular around 2D controls and images. Most of that is caused by the desire to port complete engine to OpenGL ES, and have Android/iOS version.
The nice side-effect is that the 2D API is now generally much better. Frankly, if you want to make a pure 2D game, Castle Game Engine is now an excellent choice :) Drawing 2D images and animations is now very flexible. Details:
TGLImage
(our class to render images as 2D, for GUI and 2D games) much improved:
TGLImage.Draw
can display image stretched (if ScalingPossible, OpenGL bilinear filtering will stretch it nicely).
TGLImage.Draw3x3
can display image stretched intelligently, preserving corners and sides. These functions are the basis for implementing 2D GUI, e.g. TGLImage.Draw3x3
is used for all TCastleButton
states, which makes it also easier to theme (e.g. it's now possible to make rounded corners without any fuss, just make transparent corners in the texture). All CastleControls
are now drawn using TGLImage
.
TGLImage
drawing automatically uses alpha test or alpha blending, depending on alpha channel in the loaded image. You can always change TGLImage.Alpha
to explicitly force specific alpha treatment. You can also change TCastleImageControl.AlphaChannel
.
TCastleTheme
is now a configurable collection of images (with nice defaults).
Tutorial about 2D controls
contains various examples about new TGLImage
and Theme.Draw
usage.
Dialog boxes (CastleMessages
unit) improved:
More 2D controls:
TCastleLabel
(like Font.PrintStringsBox
, but nicely wrapped in a class).
TCastleDialog
(to make modal or non-modal dialog boxes, with scrollbars, buttons etc).
TCastleProgressBar
(display progress bar as TUIControl
, regardless if you use CastleWindow
or CastleControl
).
Because of the move to new TGLImage API and the rest of GLES2 changes, small compatibility breakage may happen at 4.2.0 release. This concerns you if you do direct OpenGL calls or use low-level tricks from CastleGLUtils. Things to take into account to have a smooth upgrade to 4.2.0:
SetWindowPos
, never directly use glRasterPos*
functions. In general, forget about raster position — this concept is gone in GLES2 and modern OpenGL. Use only SetWindowPos
to affect initial text position for TGLBitmapFont
and TGLImage
, this works in both engine 4.1.1 and in SVN (future 4.2.0). It is only for 2D, and is not affected by modelview matrix state.
TGLBitmapFont.Print(X,Y,Color,string)
and TGLImage.Draw(X,Y)
instead of SetWindowPos
. But SetWindowPos
will also work, to allow you to write code in the existing 4.1.1 API that will also work smoothly in engine >= 4.2.0.
TCastleScene
for rendering all 3D, and TGLImage
or TGLVideo2D
for all 2D).
Font API improved:
Print(X,Y,Color)
. Other versions are deprecated, as they lead to messy code — it's not nice to manage global state in WindowPos
, it's not nice to manage global color in CurrentColor
.
Consistent TCastleColor
usage. We now consistently use TVector4Single
type to express a color, it's even aliased as TCastleColor
.
CastleColors
to interpolate in HSV space), it is easier to express constants.
The only advantage of using byte-based colors is that this is what you get from RGB 32-bit color images, and you can compare it for exact equality. But this isn't universal anyway (there are images with float colors, like RGBE). When dealing with TRGBImage
or TRGBAlphaImage
you can still use byte-based colors and eventually convert using Vector4Single() and Vector4Byte() both ways (in practice 8-bit and 16-bit values will be expressed precisely as Single too).
Comfortable TAbstractGeometryNode.Solid, TAbstractGeometryNode.Convex.
X3D and Kanim exporters for Blender updated to work with latest Blender 2.68a.