Engine rename to "Castle Game Engine" soon, development news: some important fixes / improvements, many API improvements

August 22, 2011
view3dscene rendering tower with sunset sky
Humanoid model, captured with transparent background, replaced in GIMP with some texture and gradient
Collada 3D text logo (from collada.org/owl)
  1. First, the big news: Grand engine rename is coming! New name of the engine is planned to be

    "Castle Game Engine"

    (Short (Unix) name: castle-engine, with dash inside.)

    For two reasons, the current name of our engine, "Kambi VRML game engine", feels a little uncomfortable:

    1. Our focus, since quite some time, is on X3D. Yes, X3D is really just VRML 3.0 (even the X3D header shows that X3D versions start from 3). But people from the outside don't know about this, and may think that we support only some old standard from ~1997. So, at the very least, the "VRML" in the name should be replaced with VRML/X3D or just X3D.

      This was caused by history — the engine development started when VRML 1.0 (now ancient) was still useful (e.g. Blender had built-in VRML 1.0 exporter), and VRML 2 (97) was just gaining popularity.

      The problem isn't limited to engine name, unfortunately. Most important units and classes inside the engine start with "VRML" instead "X3D". Our SourceForge project name and URL has "vrml" inside. So the rename will be some organizational challenge, but I think that we just have to "bite the bullet".

    2. "Kambi" in the name, which is really just a shortcut of my last name, feels like this is too much of a personal project. One-man achievement. Which is, well, kind of true for now... :) But I really want to change it, and hope to get some more developers involved.

    Looking back, I should have just made more creative name than just slapping "Kambi" (my last name) + VRML (technology) + "Game Engine" :) For example, Ogre has a nice name, that also immediately suggests the engine icon — ogre's head, used also in many Ogre3D examples. I like it.

    We already have a nice engine icon that I like very much (this tower with tentacles and moon thing). It is connected to the fact that main view3dscene screenshot, used on various pages, depicts a tower (which, in turn, comes from a very, very old Blender model I made). Also, we made a game called "The Castle". So the new name "Castle Game Engine" seems sensible. No more "VRML" in the name, no more "Kambi" in the name. New name has nice connection with engine icon. When googling "castle game engine", we already hit our engine page (because of "The Castle" game).

    Nothing is set in stone yet, so if you have an idea for an even cooler name — please write e.g. on forum.

    The engine rename means also renaming many identifiers (as the idea is to get rid of VRML prefix), so this will be a large breakage of API compatibility.

    Note that the rename doesn't mean that we drop support for any VRML version (we still fully support VRML 1.0 and VRML 97 (aka VRML 2.0)). It also doesn't mean any major redesign of the engine architecture — just a lot of renames, and of course a usual, steady progress (see below for some new engine features implemented since last release). So, although new engine release will require changes in your code (if you're a developer making a game using our engine), it will be relatively trivial, just renames — no architectural refactoring. I will of course publish a list of important renames (of components and units), and don't hesitate to ask (for example through forum) if you have any questions.

    Of course, old URLs will continue to work for a long time. I'll set appropriate redirects wherever possible.

    We also take this opportunity to migrate to the new SourceForge project management Allura, aka SF 2.0. The new SourceForge project page is on https://sourceforge.net/p/castle-engine/ (although old-style URL http://sourceforge.net/projects/castle-engine/ also works). You can see there a Wiki (hopefully will work better than HostedApp MediaWiki), new "Discussion" forum (possibly we will use it, instead of PhpBB hosted forum).

  2. Important user-visible improvements in the engine and view3dscene:

    • Loading of many scenes is now ~2 times faster :), and is done immediately. That is because we fixed octree creation, it was mistakenly done twice, and the 2nd time was on-demand.
    • More image formats supported (without the need for installing any external program or library). We use excellent FPC fcl-image to load and save various image formats now. This improves reading of some formats (PCX, JPG), and introduces some new formats (GIF, TGA, XPM, PSD).

      Note that some formats, like PNG and DDS, are still read using our internal code (in case on PNG, this relies on libpng that is distributed with Windows binaries and present on all Unix installations). These formats already have good (optimized, and using full format features) reader inside our engine, so no need to change them.

      See glviewimage docs in SVN for a current list of supported image formats.

    • New view3dscene menu item to take a screenshot with transparent background, Display -> Screenshot To Image (Transparent Background). (Requested on forum).
    • Fixed "Edit -> Remove Selected Face" to allow using it repeatedly, and to work with IndexedTriangleSet.
    • Fixed "pure shader renderer" on shapes that have textures with full (not only 0/1) alpha channel. In some situations, they were mistakenly drawn with additional alpha test, and effectively some parts of them were invisible. This bug slipped in 3.10.0 release.
    • Collada importer improvements, this was mentioned in detail in previous news. Static stuff from Collada models is read almost fully.
  3. Engine improvements. Next engine version promises some work on engine API to make it simpler and leaner. Some of the larger developer-visible changes:

    • Generics everywhere! We have replaced all of our containers with clean FPC/Lazarus generics. We heavily use FGL.TFPGObjectList (classes list), our own TGenericStructList (as standard FGL doesn't work for records/vectors), and FGL.TFPGList (primitive types lists). We also use standard TFPList instead of TDynPointerArray, and TKamStringList (descendant of standard TStringList) for strings. Removed custom hacky templates objectslist.inc and dynarray.inc.
    • Object3DAsVRML is renamed to X3DLoad, with various X3DLoadInternal* helper units.
    • Various simplifications around (to KambiGLUtils, to VectorMath) to remove old $ifdef stuff needed for older FPC versions and such. We require now FPC >= 2.2.4 (there is really no sensible way to get our generics working with earlier FPC releases).
    • Under GLX (Unix), we can use new GLX >= 1.3 functions to init context, and we have a testing code to activate OpenGL >= 3.0 forward-compatible context. (Relevant patches to FPC also submitted).

      No, we generally don't fully work in 3.0 forward context yet, some deprecated features from GL < 3 are still used around, e.g. for fonts. But it's nice that we can actually check it now, and push forward.

    • Camera components in Lazarus package have now icons.
    • TBox3D and TQuaternion records remade into old-style object. Previous procedures Box3DXxx(Box, ...) have to be changed now to Box.Xxx(...). This results in nicer API, method names may be shorter and look cleaner.
    • T3DTranslated is free from OpenGL dependency, and moves to Base3D unit. This opens the door for T3DTransformed in the near future.
    • Removed tgAll and TransparentGroup, this was an unnecessary complication. We have now just Transparent:boolean, and our T3D.Render only renders only opaque or only transparent.
    • Notifications (GLNotifications, these messages "You picked up Potion Of Life" etc. you see in FPS games) were reimplemented. There are now TUIControl descendants, so can be used just like our other 2D controls. They are also visible on the Lazarus component palette now.
    • Examples rearranged. Many useless examples removed, many good examples visible better. Some new examples are being planned, to showcase some engine features. Also, lets_take_a_walk and rift may be moved inside engine examples.

      Outdated engine examples removed: direct_vrmlglscene_test_*, , dds_remove_small_mipmaps, md3tovrmlsequence, svn_to_grayscale, detect_alpha_simple_yes_no, demo_parseparameters, demo_textreader, test_menu_change_from_keyup, multi_texture_demo, test_platform_specific_utils example, shading_langs mode, lazarus/camera.