Catching up

I spent some time getting the Ember win32 binary done. Previously I've done it in MSVC and had to employ all manners of hacks to the code in order to get it to compile, but this time I wanted to do it with GCC (no need for code alteration) and in MSYS (no need to create separate projects for all components since the standard autotools setup will work).
Though I managed to get a couple of components built in MSYS I in the end had to settle for a hodge podge of msys, Code Blocks and precompiled libraries. Turns out it's not too easy to build stuff the *NIX way on Windows, shockingly enough!
In the end I got a working Ember binary which is now released. The good news is that now that I've got a build environment set up on Windows the next release should be much easier to squeeze out.

Now that I've got that done I've moved on the working on actual Ember features again. There's been some really great activity on the Launchpad with nice bug reports being filed. Before I start on some serious new features in Ember I'm thinking that I should at least get the new bugs fixed. Most of them are quite easy to handle, but there's a couple of problems with the way the icons are handled. One is that when switching between full screen and the desktop on Windows the icons will get messed up. This is quite straight forward, since the way the icons are done is that they are rendered and then blitted to a larger GPU texture. That way we can keep the number of render state changes down and make it a little quicker. The downside is that it's all happening on the GPU, and when switching back to the desktop the GPU releases all of its resources, and expects them to be restored by the app when the user switches back. There's however no such functionality in Ember for repopulating the texture, thus it ends up with uninitialized data. This is not that big a deal since there are a couple of ways to solve this: either by always keeping an in memory copy of the texture, or by repopulating it when requested.

The other problem is that our blit function won't work on GPU's that don't support Frame Buffer Objects. This is a little bit harder to tackle. The main problem is that rendering happends asynchronous. The app sends render ops to the GPU which queues them and then process them in order. So normally the GPU is a couple of frames behind the main app. However, this means that once we make our call from Ember to render the icon view, we might have to wait a couple of frames until it actually gets rendered. Now, right after we've rendered our icon we then want to blit it to our main icon texture. On cards which supports FBO the blit operation is just another render op, so it will be put on the render queue and happen after the rendering has taken place.
But on cards that don't support FBOs Ogre has to fake this by copying the data itself. And this is where there's a problem, since if we try to copy the data right after we've issued the render call the GPU will most probably not have had time to perform the render, and we'll end up with garbage data (which is exactly what happens).
So the solution is to implement a mechanism where we render the icon, wait a couple of frames and then blit it, thus making sure that the icon actually is rendered. I'm working on such a solution currently and it's looking promising. I've had to alter the structure of the icon rendering framework a little, but thankfully it's quite modular so it's no large alteration.

One thing that I really need to take care of it updating the example world of Mason. Mainly to make it use all of Jayr's new media. He's been adding a lot of really high quality media, which unfortunately isn't shown since the default Mason world haven't been updated with new entities. Both me and Al are quite busy adding new features to the code, so neither have had time to do this, and I was hoping that someone else in the project would be willing to go over it.
Another thing that needs altering is the layout of the world. Ember really likes large vistas with none too sharp height differences, since the LOD will then work best. Unfortunately the current world is pretty much the exact opposite: a small world with steep mountains. If we could move the mountain away quite a distance and make the elevation not as steep I think the world would both look and perform much better.