One of the on-going problems with Digital Spaces is when you start it the first time. You get a black screen. And you wait. And if you're observant, you'll notice the hard disk is churning. If you're not, you will think Digital Spaces has crashed. If you are loading an online space, you won't even get the hard disk churning. Eventually you see a single frame of GUI, with a Loading message in the middle of it, then you're in the Space and running.

So why does this happen? First you'll need to know something about how Digital Spaces works. The Core acts as a scheduler for each of the Components. Each of these components does the actual work. Commonly used Components are the SGManager, 3DVisuals_Ogre, GUI_CEGUI and UserInput_DirectInput. These are probably the bare minimum any space can use, with a really empty Space possibly not using the SGManager. Which Components are loaded is specified in the .space file. After loading a .space file, the Core loads each of the specified Components into memory, then instructs them in turn to initialize. The initialization function can indicate that it wasn't able to complete all its initialization, and should be called again. This behaviour is encouraged, for reasons I'm about to explain.

When Ogre initializes, it creates the blank window which any Digital Spaces user is familiar with. When the SGManager initializes, before todays update, it would instruct Ogre to load all the models needed to display the .scene file. While Ogre is being bombarded with requests to load models, it hasn't been told to render its window. The GUI isn't displayed until the Ogre display is rendered, resulting in a black screen that won't respond to anything.

What I've spent today and yesterday doing is reworking how the SGManager parses the .scene file. Previously, it was a recursive process that would drill down into the XML heirachy, and create SGObjects, that required models to load, as it found them. After a bit of reworking, the SGObject creation process doesn't need to load it's model right away, in every case. When possible, it will delay it.

What this means is now the SGManager can return from it's initialization without fully constructing all the SGObjects. This causes the Core to call all the Components initialization functions again. Ogre takes this change to render it's window, with the GUI now created and visible, before the SGManager creates the next SGObject on it's list, usually causing a model to load.

So while this doesn't remove the black screen of loading completely, it means it is much shorter, and users can now see a Loading message sooner. One of these days, I'll even put a progress bar on it. It does make the total loading time a little bit longer, due to the looping and additional rendering, but for the user the experience seems much faster, because they see something on the screen sooner. In fact, with the current loading box, the loading models are visible behind it, so in large enough scene, or a slow enough computer, the user may be able to see models popping into place.

My next planned optimization is to rework how the SGObjects track Representations that are self animating. An example of this is model bones. Currently, the SGObject interrogates it's Repr's 100 times a second, to make sure it's data is as up to date as possible. I'm thinking to make these updates lazier, so that SGObject's don't update their position/orientation/scale data until something asks them for it. While this means that technically at any point the SGManager will be out of step with the visible simulation, it won't matter, because as soon as any code inspects it, it will update itself.

But I think that will have to wait. I need to work on the ESS-STS125 project some more first. While I'm waiting for feedback from the alpha preview package I made up, I need to decide what I'll implement next, and get to it.

Today I've worked on Bruce Damers Nerves library. Bruce did a bunch of work on it over the last few days, seperating the display logic from the processing logic. It seemed to be largely a case of removing the tendrils MFC had worked into it. With a bit more tweaking, I was able to seperate the single application into a processing library (NervesLib) and front-end (NervesMFC, MFC being the library used to handle the windows UI). With a bit more work, I was able to create an alternate front-end (and remove the last tendrils of MFC integration). The new front end is a console based application (VervesConsole, very original). It doesn't do much, just starts up the "world" and cycles it 100 times, while displaying any log messages. It doesn't seem like much, but it proves the core parts of Nerves are alive and kicking in there.

Logically, all the information needed about it's internal state, to display a status diagram, should be available through public functions. Depending on what Bruce is up to, my next task will be either making Nerves internal state more readily accessible, or to re-implement the input/output functions, to allow me to feed and extract events in that are not based on windows events.

I also repackaged the ESS Space I prepared yesterday, when I found out I'd used an old script to make the installer. That's the problem with moving to a new work machine, you forget the little things you only use occasionally.

0.12.0 is now available. As aways, downloads are the installer, the source and the API documentation. There is also an online version of the API documentation.

0.12.0 is a significant change, with the removal of the deprecated 3DScenegraphManager API and the partial rewrite of the SGManager, which now requires unique names across all types of scene graph objects, and involved a slight change to the SGManager API.

Some of the scripts in the available demonstration spaces will fail. Updated copies will be uploaded soon.

After thinking about it, I decided this release should be 0.12.0 instead of 0.11.1 . It contained serious API changes (the removal of commonly used 3DScenegraphManager API) and broke compatibility with a lot of scripts. This means there was only one release in the 0.11 line, but I guess that happens sometimes.

Just to give you an idea, 0.11.0 was SVN revision 652, while 0.12.0 is SVN revision 695. I think that's the biggest jump between releases, ever.

This morning was spent attempting to fix a small issue with the blog software, which lead to scrapping the whole thing and just using the Joomla content mangement. I then added a RSS generator add-on, and a content comment add-on, and now have the same capability I had with the previous add-on, but no hard-coded assumptions about the site's software layout. Left-over's from the add-on's WordPress origins, I guess. I also added a link that subscribes you to the blog, through FeedBurner . While I could have linked you directly to the RSS generated by the site, FeedBurner does some sanity checking and beautification to the feed, as well as adding convenient buttons to subscribe using assorted content portals. Note that it does some magic based on your browsers/readers User-Agent, so if you run it through a web proxy, you might find yourself getting the wrong format.

On top of all this, I've been getting a lot of feedback from some-one new on the Digital Spaces scene. (Scene, .scene file, get it? A joke!) He has been providing a lot of feedback about the site, and how it presents to some-one who hasn't been closely involved with the project from its inception. Some of the feedback does make me groan, but it's all valid, even if sometimes the answer to "why is it like that" is "because that's how we thought it should be". Keep up the good work Alex! Expect to see changes around here as we reassess the site over the coming months.

I've added a poll on the forum,where I ask if people would rather stick with the good old reliable Zip formatfor API and Source packages, or would they rather the 7z format, with the approximately quater size archive files. Please let me know what you think.