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.

Christmas with the Ember

The last couple of weeks have been really hectic, as it's always before the end of the year. With not much free time work on Ember has suffered, but I've now finally gotten a stable release of 0.5.1, just in time for the holidays. This release adds a lot of new features, chief amongst them a much nicer interface with inventory and status widgets. As always there's a lot of bug fixes and improvements in almost all areas of Ember. Here's as small list of some of the improvements:

• totally refactored ingame chat system with better performance and functionality
• support for both Lua 5.0 and 5.1
• a new icon system
• a new inventory system with drag and drop equipment
• status widgets for both the avatar and current targets
• update of all materials, with support for normal and shader maps for most entities
• refactored terrain system with support for both shader and fixed pipeline functionality
  

After the 0.5.0 release earlier this year I wanted to do a 0.5.1 release pretty close to it, but for various reasons it didn't happen, and the release comes almost a full haft year after the previous one. The main reason is that I want to release really stable code without any regressions and strange graphic glitches. The problem with this is however that it's really hard to test out all of the various graphical cards when I'm the only one that works on the codebase, and I only really have one development box with a Nvidia card. Previously this has led me to disable the shader terrain rendering, since I found out at release time that it didn't work with ATI cards.
This can't work in the long run, and I'm looking at trying to better embrace the "release early, release often" motto, even if it means that some releases will bring regressions with them. Since I'm the only developer I'm really dependent on good bug reporting from end users. Lately I've been seeing some increased activity on the Launchpad bug tracker, which is really great, since it's just the kind of input I need from the users.
So I will try to get a release of 0.5.2 out not too soon, even if that release might break something. I'm also looking at perhaps using the Google BreakPad for even better crash reporting.

The new release of Ember also uses a lot of Jayr's new materials with support for normal and specular maps for most surfaces. This looks really good and hold great promises for the future as I move to include a better foliage rendering mechanism into Ember (after all, the mason world is an outdoors world, so natural foliage rendering seems almost like a requirement). It also brings the used media up to 90~ Mb.

With future versions of Ember we need to refactor the media system so that world developers can specify their own media repositories in a better way. Currently Ember gets all its media from one place and places it statically in ~/.ember/ember-media-0.5.1. However, we would like to let each world provide its own media if so desired, so that when you connect to one server you might download (through wfut) media specific to just that server.

For this release I haven't had time to set up a Windows build environment and provide a working windows binary. If anyone else feel better suited for this task I would greatly appreciate it, else I will do this myself after the holidays.