Development: great API for 2D games and UI, our engine in Debian, on the road to OpenGL ES, Orcs and Volcanoes game screenshots

September 15, 2013
Orcs and Volcanoes - intro screen
Orcs and Volcanoes
Orcs and Volcanoes
Orcs and Volcanoes
Orcs and Volcanoes
Orcs and Volcanoes
Octopus exported from Blender to KAnim.
Tooltips with rounded corners over partially-transparent buttons.
Custom image under selected item.
Custom image under selected item, 2.
view3dscene tooltips with rounded corners.
Message dialog with nice buttons.
New dialog look with a nice scrollbar and button.
New dialog look with a nice scrollbar and button.
  1. 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 :)

  2. 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 :)

  3. 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:

    • Renders 2D images as npot textures underneath (suitable for modern OpenGL and GLES, better with anti-aliasing).
    • 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:

    • Drawn using images, so much more configurable.
    • Normal buttons at the bottom (descendants of our TCastleButton), so it's natural to handle them with mouse.
    • Theme for slider and frame much better (somewhat based on GTK 2 theme "clearlooks", esp. the scrollbar).

    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:

    • Always use 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.
    • Since 4.2.0, it will be advised to use cleaner 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.
    • If you hope to keep your code portable to GLES2, of course be sure to avoid old OpenGL API. Immediate mode rendering cannot be used (use only VBO; usually, you should just use our TCastleScene for rendering all 3D, and TGLImage or TGLVideo2D for all 2D).

    Font API improved:

    • The advised font drawing call is now 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.
    • All font drawing can use blending for text (just pass text color with alpha < 1).

    Consistent TCastleColor usage. We now consistently use TVector4Single type to express a color, it's even aliased as TCastleColor.

    • We do not use TVector3Single (as we like having alpha available).
    • We do not use byte versions. There are numerous arguments in favor of using float-based color values (instead of byte-based): it allows for components > 1 (useful for physically-correct rendering and some shaders inputs), it is natural to smoothly interpolate (you can also use functions in 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).

    • Color constants as TVector4Single have simple names inside CastleColors, just "Yellow" instead of "Yellow4Single".
  4. Comfortable TAbstractGeometryNode.Solid, TAbstractGeometryNode.Convex.

  5. X3D and Kanim exporters for Blender updated to work with latest Blender 2.68a.