Read the rest of the coverage here.
Pages
-
Blogroll
Archive
-
|
GDC Europe 2010 Coverage
August 17th, 2010 by Bas |
 |
|
GDC Europe 2010 Coverage – Day 1
August 15th, 2010 by Bas |
|
We, the entire team behind the FireFly engine, decided to go the Game Developers Conference Europe this year. There are loads of cool sessions to go to and learn some very good techniques from the professionals in the game industry. Especially things like multicore programming, DirectX 11 and DirectCompute are topics we would like to learn about.
Today the day finally arrived to go to Köln and enjoy the wonders of this conference. This is the first time for me to go to a such a conference. I will blog here every day to tell you what I have seen and learned.
Marries and I took a train in the morning and Emiel would arrive later in the afternoon. At 10:11 we stepped aboard the ICE International 133 heading for Frankfurt. It was a three and a half hour ride during which we played some games (like card games, not computer games..) and made some pictures.
When we finally arrived in Köln it was raining cats and dogs. From the train station we were supposed to take another train to get to our hotel, but we decided to walk so we could also do some sightseeing. The first thing we did was buy two umbrellas which at the end of the day turned out the be a very good investment. We went to see the Cologne Cathedral.
When we got to the hotel there was a slight mix-up. We reserved a 2 person room with an extra bed but when we got there we got a room without an extra bed. We asked the guy that gave us the room but he barely spoke a word Deutsch let alone English. We tried to tell him we needed three beds but instead he put us in a huge ass three person room. Just to be sure that we didn’t have to pay for the bigger room we tried to ask the guy again. He couldn’t make heads or tails of what we tried to tell him so he rang his boss and gave us the phone. We agreed that we could stay in the 3 person room today and we would talk it over the next day. Fine by us, this room is way nicer than the 2 person room.
At 3:00 the exposition of the GDC opened so we (still just Marries and me) went to take a look. We first got our conference badges which I thought alone was already awesome, we also got a bag with some flyers and other crap. When we went up to the next floor where the conference actually takes place, our eyes immediately caught the CryEngine 3 stand where they demoed Crysis 2 in 3D. Well before I tell you how it was I have to tell you something about what my impression was of 3D gaming. I have seen a few 3D movies in theater and some of them, especially the ones with fast moving imagery always gave me a headache. I thought that 3D gaming, especially First Person Shooter games would make me sick. Another more technical aspect is that since you will have to render the scene twice (once for every eye) your framerate will be halved.
Well Crytek has developed a technique that performs a postprocessing pass to fake 3D rendering from a single framebuffer. They didn’t want to give us any details since there will be speaker session about this topic on Tuesday but they did tell us that is was a relatively cheap effect with about the same running time as SSAO. The problem we came up with was that sometimes you left eye can see other things than your right eye. Especially when an object is very close.
Crytek showed us in-game footage of Crysis 2 in 3D and I was literally shocked how beautiful it was. There were no artifacts or anything that gave away that the technique was actually a ‘fake’. Before I put on the 3D glasses I was looking at the 2D version of Crysis 2 and thought by my self that it looked pretty amazing. However when I witnessed the beauty of 3D I found the flat 2D looking images of the game horribly fake. My conclusion: 3D games are awesome. We also got a CryEngine 3 t-shirt which I am wearing right now. 
O, Crytek also has this visual node based gameplay editor, it was awesome (see the picture 
).
We also visited an Intel stand where they were marketing some Intel tools for game development. One of these tools was Intel Graphics Performance Analyzer. I have to tell you that I used this tool once before because a bug in PIX caused me from not being able to debug a shader. I gave Intels tool a try but quickly threw it away because it isn’t able to debug shaders (probably because its a profiler not a debugger). Well today someone from Intel showed us a few things that are possible with Intel Graphic Performance Analyzer. He showed us a few things that are actually quite useful to me so I will probably be using it more often in the future. We also spoke with a few other people of Intel who loaded us with goodies; a tshirt, 3 dvd’s with software, 2 GB usb stick, lots of flyers, blocknotes and a bag. I guess they don’t see a lot of students.
After the expo we had a very good meal at a Subway, where Marries ate his first Subway cookie which he absolutely loved.
Those were actually my highlights of today, o yeah except for Marries meeting a Hellgast (see the picture). Blog you tomorrow. 
|
The Singleton Pattern
June 11th, 2010 by Bas |
|
I have seen many implementations of the singleton pattern all with their advantages and disadvantages. In this post I will describe how we implemented the singleton pattern in C++ for FireFly engine 1.0 and 2.0. The example code present in this post does not compile out of the box and is only meant to illustrate ideas.
The singleton pattern is a design pattern that makes sure that there is only one instantiation of a given object. This is particularly useful if there is a single object that performs actions for the entire system.
I actually think that this pattern is bad code practice but we use it nonetheless. The reason why I think it is bad is because from a design point of view there is no easy way to find what code actually uses the singleton since the singleton is part of the global state. The object is exposed everywhere in the code so it could be used everywhere.
Even though the singleton pattern could be seen as an anti pattern it has it uses. If there were no singletons, developers would have to pass the object around which, for object that are used a lot, is a pain in the ass.
Ok so for implementation details.
The first and simplest way is using a static function that returns the address to a static local variable:
class A {
public:
static A *GetInstance() {
static A instance;
return &instance;
}
}
This is a simple and elegant method but it gives you absolutely no control over when and how the singleton instance is instantiated and destroyed. A more robust way is to instantiate the singleton once and delete it when we are done with it. One way to achieve this is like so:
class B {
private:
static B *singleton;
public:
B() {
assert( singleton == 0 );
singleton = this;
}
~B() { singleton = 0; }
static B *GetInstance() { return singleton; }
}
With this method we have to explicitly instantiate B and we have to delete the class when we are done with it. However it gives us much more control over the entire process. However using this method involves a lot of code duplication. The singleton setup code is the same for every singleton class. We tackled this by defining macros that take care of declaration, implementation, construction and destruction.
class C {
__DeclareSingleton(C)
public:
C() {
__ConstructSingleton;
}
~C() {
__DestructSingleton;
}
}
The code in the example above is a lot more flexible. The defines remove the code duplication of the second example almost completely but not entirely. Fortunately there is another method that is described in Game Programming Gems 1. It involves a template class that wraps the singleton stuff. To make a class a singleton all one would have to do is derive from this template class like so:
class D : Singleton<D> {
}
This approach requires no additional effort from the programmer, it removes code duplication and we can implement the singleton class anyway we want. Lets take a look at the implementation of this singleton class:
template<class T>
class Singleton {
private:
static T *instance;
public:
Singleton() {
assert( instance == 0 );
int offset = (intptr_t)(T*)1 - (intptr_t)(Singleton*)(T*)1;
instance = (T*)((intptr_t)this+offset);
}
virtual ~Singleton() {
instance = 0;
}
static T *GetInstance() {
return instance;
}
}
The constructor looks very scary but does in fact nothing more than retrieving a pointer to T from the this pointer. This is only possible under the assumption that T is a subclass of the Singleton<T> class. What happens is that it first figures out the relative address of the derived class T and then stores the result in the instance pointer. The derived class could be deriving from more than just our Singleton<T> class, in which case the this pointer from our derived class might be different from the Singleton’s this. The solution is to take a nonexistent object at address 0×1 in memory, cast it to both types, and see what the difference is. The difference is the offset from the Singleton<T> to the derived class T. I just love the things you can do in C++!
Of course you can implement more methods than just the GetInstance method like for instance a method that returns a reference to the singleton or a method that checks it the singleton has been instantiated. All of these methods are trivial to implement. And because it is a separate class you can implement anything you like without having to modify code anywhere else.
So to conclude, I am very happy about our implementation of the singleton (anti-)pattern.
|
Time for screenies
May 27th, 2010 by Bas |
|
I created some in-game screenshots of the engine me and my friend have been working on for the last few months. We wrote the engine to compare different lighting methods. We also wrote a paper about it which will be published here in a few weeks. In the mean time you can enjoy these screenshots which are all taken in-game at framerates around 300.
|
Complete IPhone breakdown
May 2nd, 2010 by Bas |
|
The day before queensday I dropped my IPhone when I took it out of my pocket. It dropped half a meter straight on the stone street. When I picked it up I didn’t think there would be a problem. I mean it fell 2.5 meters from a bunk bed a few months back and there was nothing wrong with it. Not even a scratch! This time however I didn’t get so lucky. The image on the right pretty much shows the current state of my IPhone. The glass-plate is completely shattered. Fortunately it still works like a charm except you may end up with a few glass splinters when sliding your finger over the screen. 
I called T-Mobile (with my IPhone) to ask how much it would cost to repair the broken glass. The guy on the other end of the line didn’t know for sure but what he could tell me was that it would cost me over 200 euros! However after a quick google I found a shop called MacRepair that does the job for 120 euros.
So today I send my IPhone, via mail, of on its adventure. Since I am now currently very much immobile I turned to skype which I have actually always running but which I never use. I called my parents and even had my first video call ever!
According to MacRepair I can expect my IPhone to be returned on Friday. Lets just hope I can live that long without my precious. 