Grass

The last weeks have been really productive for Ember. I've closed most of the bugs reported in the bug tracker and also managed to add some new features. One that I've been needing for some time was a teleport function for admin mode. Previously when you were logged in as admin you had to move just as a regular person, which could take some time when you wanted to go to a different area of the map. But now there's a nifty "teleport here" option available when you click on the world, which will instantly transport you to the clicked location. It was very easy to implement, no more than 30 minutes work.
Another thing that has been bugging me for a while was that when you entered and exited building your orientation would be messed up. I initially assumed that there was something wrong with how the server sent updates to the client, but after some thorough testing I found that it was solely a client issue. The problem was that when the user controls the avatar and walks through the world, Ember ignores orientation and position updates sent for the avatar. This is to avoid the issue on lagging connections where the avatar continuously will snap back to a previous position, as sent from the server. When the avatar stops moving it will be adjusted to the data sent from the server however.
The problem here was then when the avatar moves into a house and changes it's container, it needs to be have it's orientation updated relative to the orientation of the new container. And this new orientation is correctly sent from the server, however not as I incorrectly assumed in the onLocationChanged event, but in the subsequent onMoved event. But if the user is moving the avatar Ember ignores the onMoved event and the old orientation will be used instead, resulting in the avatar looking in the completely wrong direction. The solution was to change the functionality so that the onMoved event would be honoured by Ember for the avatar even when the user was moving it, if it occurred right after a onLocationChanged event. This fixed the problem, something which I think has been in Ember for some years now.

A new feature I've been working on this week is support for a better foliage system. I've so far used a home grown system which uses static geometry, but it has some problems and I didn't want to put much effort into it since there are other third party components for Ogre which does it all much better. Especially the Paged Geometry plugin shows real promise. So the last couple of days I've worked on integrating that into Ember, throwing out my own solution. It's a very good library, excellent in both design and documentation. So far I've had no problems getting it integrated, but I think I need to do some alterations to it in order to support the demands of Ember, especially the dynamic nature of the terrain. So far I've focused on getting the grass to work, but the idea is to also use if for the trees and other objects that are both numerous and fairly static. This will hopefully bring the ability to display really vast forests.

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.

Windows, yeah that's fun

After spending the holidays away from almost all things Ember I'm back again. I did manage to do a little Ember work since it turned out that the .package file I uploaded to Sourceforge had become corrupt: that's what you get for claiming it from the upload pool before it has finished uploading. Wasn't harder than reuploading though.
There's been some really promising work done over Christmas however mainly by Alex Torkhov who have contributed greatly to the project through mainly the Launchpad. Our hope was that the Launchpad would make the project more transparent and provide a more technical forum for bug reports and suggestions, and it makes me happy to see that it's being used in that way.
Also, there's been some nice additions to the wiki by Alabandit, mainly concerning an introductory guide to Ember, something I've never had time to do.
All in all some promising new additions.

When I did the 0.5.1 release I only had time to do a precompiled version for Linux. I was hoping that someone could be able to help me with creating a precompiled win32 binary, but in the end I have to roll up my sleeves and do it myself. It's not a pretty job. But I've made a promise that I won't do any further Ember development until there's a binary version available for those using Windows.
Previously I've used MSVC for compilation, but it means I constantly have to hack the wf libs Ember just to make it compile. So instead I'm working on getting a fully working build environment set up in Windows through MSYS. It's getting there, but it slow as hell. Just running configure can take up to 10 minutes. I don't know what's making it so slow, and I have no interest in trying to hunt it down, as long as it works. But then there's all kinds of wonderful stuff, such as Windows case-insensitive naming system, as well as the inability to separate data from file system location ("This file is locked by another process." Yes, but would it be too hard to tell me which process is locking it?). And so on. It's just a tedious work.

And I have so many ideas for what I want to do next in Ember, but all of that will have to wait until I've conquered Windows.