Monday, September 29, 2008

Diverse

The last couple of weeks I've been working on many different parts of Ember without. I've started looking into how to get it compiled on OSX, which seems to require some reading up on the OSX build system first. I've also began work on building the latest Ember release for win32. I was hoping that someone else would have picked up the torch, using the win32-dependency package I provided, but so far none has appeared. I'm thinking that there's bound to be some issues with getting openal integrated, but other than that only Mercator has been updated, so it shouldn't be too hard.

I spent some days delving through the code which handles terrain after I found that the terrain was broken when on worlds with non-square sized. The cause of this was improper conversion between the Ogre coord system and the WF coord system. The problem is that the former is screen centric while the latter is world centric. That means that every time we translate any coord between them we need to convert it. However, if we somewhere misses to do this translation, or we're confusing the two, problems will appear. In this case the code was expecting WF style coords, but got Ogre style ones.
A preventive measure that can be taken to avoid these kind of problems in the future would be to more clearly mark what kind of cood type is expected at any place by requiring that whenever possible 2d or 3d structs are used instead of separate values.
It's much more clear what
getHeight(WFMath::Point<2> position)
expects than
getHeight(float xPosition, float yPosition)

Another area I've done some work in is the entity creator. It's now much more easy to work with thanks to the addition of randomized orientation and default values. The former helps a lot when you quickly want to place a large number of entities in the world, as demonstrated in this video.

This video also shows how easily the terrain can be altered. At the start of the video the world is completely empty, with just a flat terrain. Everything that's altered is altered live on the server, so any other client logged in at the same time would see the exact same changes.

The entity creator is getting more and more useful for each day. It can now be used for quickly creating all kinds of more complex structures, such as the enclosure demonstrated here.

The entity types used here aren't part of stock cyphesis yet though.

I've also recorded a little longer stroll through the world. For some reasons however there's quite a lot of stutter, which I think is caused by the massive IO requirements of the video recording app (GLC). When running through the world without any recoding going on I don't get any stutters. It nonetheless shows of some of the richness in the world. The world as seen here is also not the stock world, instead containing some additions I've done on my local box. I'm not sure how this large amount of entities would work on a slower machine.

Tuesday, September 02, 2008

Sound integration

The work with integrating the GSoC projects into the Ember trunk have continued. I've now merged the Sound Manager changes that Romulo have provided into the main trunk. In the process I had to do some alterations to the code though. While the code provided by Romulo worked and did indeed play sounds it made some assumptions that made it not so suitable for the very dynamic nature of the entity world. Since we can't know beforehand what kind of entities that we need to show, and must be able to dispose of and create new entities as we move through the world we must make sure to provide good resource handling. The changes I made to the way the SoundService works have much to do with how sound sources and buffers are allocated and handled. I've worked with the assumption that not too many sounds will be playing at any time, and that once a sound has finished playing it should be deallocated.
The original code also worked with the assumption that all sounds allocated from ogg files were "streaming" sounds, while all sounds allocated from wav files were "static" sounds (i.e. where the whole sound could be kept in memory). However, the notion of "streaming" and "static" only relates to how large the sound buffer is, not how it's stored (in ogg or wav). Any sound that is too large should be streamed, which means that it should be read from disk in increments. And any sound that is very small could be kept in memory, making it "static".
As I've reworked the SoundService I've temporarily disabled the support for loading ogg sounds, as the implementation needs to be able to handle data recieved from the Ogre resource system. It should however return as I sort out the code.

With the sound support now in Ember trunk I'll start looking at polishing up the code and updating the media for a 0.5.4 release pretty soon.