Engine rename to "Castle Game Engine" soon, development news: some important fixes / improvements, many API improvements
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:
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".
"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).
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.
Engine improvements. Next engine version promises some work on engine API to make it simpler and leaner. Some of the larger developer-visible changes:
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.
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.