All this has changed now however, as I've altered the grass to be both properly lit and to receive shadows correctly. The effect can be seen below.
Wednesday, June 08, 2011
Properly shaded foliage
Ember has a system for generating grass and other kind of foliage. It looks pretty good in most cases, but the shading of the grass has always been off. This is even more apparent when the time of day changes, as the grass doesn't change colour when the world does. In addition, the grass didn't receive any shadows, making it look strange when running in a higher graphics settings.
All this has changed now however, as I've altered the grass to be both properly lit and to receive shadows correctly. The effect can be seen below.
All this has changed now however, as I've altered the grass to be both properly lit and to receive shadows correctly. The effect can be seen below.
Tuesday, May 24, 2011
Ember 0.6.1 out of the door
I finally managed to get Ember 0.6.1 out of the door.
It seems to be common procedure for me to never be able to get the releases out in accordance to my plans, but this time it took even longer than would seem "normal".
The two main reasons for this were Windows and 32-bit architecture, both legacy systems (hurr hurr hurr).
I've always striven to make Ember cross platform. This can be seen in the components used and the way its internals are laid out. The main problem is that I'm not too fond of touching Windows unless I absolutely have to, and therefore the Windows releases have lagged behind the Linux ones. Fortunately for us a contributor in the Worldforge community, James Lovejoy, has been working on streamlining the process of building Ember for Windows, and with his help we were set on releasing a working Windows binary along with the 0.6.1 release.
It turned out however that some of the low level networking stuff we were doing in the Eris library didn't play to well with Windows. Ok, cue a rewrite in Eris by Alistair, some testing of that, and we got it fixed after a while.
The other issue was more subtle. I've added some mechanisms for making sure that Ember is running on a fixed fps rate (60 by default). This relies on getting and comparing millisecond timestamps from the OS. Problem here was that I was using the C++ "long" type, which on 64 bit machines (such as the one I'm developing on) is 64 bits, but on 32 bit machines is 32 bit. And 32 bits are too few, since the timestamps will then wrap around after something like a month's time. Not good. And this was of course something I didn't discover until I basically had already made the release and was testing our 32-bit precompiled binary out (we're now using AppImage since Autopackage is defunct).
Just some snags on the way, but enough to delay the release a little bit too long.
Currently we've just started up the coding part of Google Summer of Code. This year I'll be mentoring two students: Martin and Peter. They're already at work improving Ember, with some exciting weeks ahead of us all.
Oh, and here's a small movie showing how the Model Editor can be used.
It seems to be common procedure for me to never be able to get the releases out in accordance to my plans, but this time it took even longer than would seem "normal".
The two main reasons for this were Windows and 32-bit architecture, both legacy systems (hurr hurr hurr).
I've always striven to make Ember cross platform. This can be seen in the components used and the way its internals are laid out. The main problem is that I'm not too fond of touching Windows unless I absolutely have to, and therefore the Windows releases have lagged behind the Linux ones. Fortunately for us a contributor in the Worldforge community, James Lovejoy, has been working on streamlining the process of building Ember for Windows, and with his help we were set on releasing a working Windows binary along with the 0.6.1 release.
It turned out however that some of the low level networking stuff we were doing in the Eris library didn't play to well with Windows. Ok, cue a rewrite in Eris by Alistair, some testing of that, and we got it fixed after a while.
The other issue was more subtle. I've added some mechanisms for making sure that Ember is running on a fixed fps rate (60 by default). This relies on getting and comparing millisecond timestamps from the OS. Problem here was that I was using the C++ "long" type, which on 64 bit machines (such as the one I'm developing on) is 64 bits, but on 32 bit machines is 32 bit. And 32 bits are too few, since the timestamps will then wrap around after something like a month's time. Not good. And this was of course something I didn't discover until I basically had already made the release and was testing our 32-bit precompiled binary out (we're now using AppImage since Autopackage is defunct).
Just some snags on the way, but enough to delay the release a little bit too long.
Currently we've just started up the coding part of Google Summer of Code. This year I'll be mentoring two students: Martin and Peter. They're already at work improving Ember, with some exciting weeks ahead of us all.
Oh, and here's a small movie showing how the Model Editor can be used.
Sunday, March 20, 2011
Worldforge in Google Summer of Code 2011
Worldforge has been accepted into Google Summer of Code 2011!
We've had a remarkable experience with the program from before and are very excited about this opportunity. If you're a student which are interested in working on a cool Worldforge project during the summer, don't hesitate to visit our GSoC page. The sooner you start getting involved in the project the better, so don't be shy about making yourself heard on the mailing lists or irc.
Subscribe to:
Posts (Atom)