Fake Snowflake Shadow

Some time ago I was walking at night in a dense snow fall. I won't talk about my mood, but I was walking alone, nobody was around and I had some time to think, or rather to observe what was happening around. I was really excited about the shadows that where casted by snowflakes. They were dancing everywhere around, like small spiders running through the snow. Something beautiful, honestly. Of course, I mean shadows that are casted by something like street lamp. Now the problem is - how to simulate them? Of course we can cast each shadow accurately. But there are some obvious problems, and when I say problem I mean performance. I think I don't have to explain what problems are connected to shadowing complex particle system with multiple lights (just imagine the deferred shading with all those particles outside buffers, problems with transparency, or FR with multiple pass particle drawing, crazy). And also, there is some possibility, that you render your flakes (or even more possibly - rain) as post process. Sure! It is possible to do it in a straight way, but we wouldn't be game developers if we wouldn't look for some fakes ;) So how can we add some fancy shadows on the snow, that will look like drunk spiders? As you can expect, I'm not going to talk about any physically accurate solution. Look at the image first.

The upper part of the image is a 2D ortho projection of the world, the Source is our street lamp, green line is the ground. The lower part is meant to be the top-down view. As you can see, when the snowflake is close to the lamp (high), it's shadow is casted far from the center of the lamp cone, and it's movement dx1 is quite big. Then, when the snowflake falls and is close to the ground, it's movement dx2 decreases and position get's closer to the center. The situation shown here is utopia, because the flake falls straight down, with const speed. But, what it shows is that the shadow will be tending towards cone center with decreasing speed. This is a very important observation. Now, let's look at the right side. The snow is falling by some trajectory and in successive time periods it is located in P0, P1, P2 and P3 positions. The rule is quite the same, its shadow in time (T0-T3) tends towards cone center with decreasing speed, but we have to remember that this speed will not decrease monotonically, but will be varying. There even may be a situation, when T(n) is farther from cone center than T(n-1). When we look from top at the problem, we also have to add some variation in the other axis (due to air drag, the flake doesn't move straight), we can assume that shadow moves over some simple spline, directed towards S' (cone center) and with variably decreasing speed. The Lambda area is some small area around S', where shadows tend to dissapear (i think that making them bigger and more transparent would look good). You have to include this Lambda area if you don't want your shadows to dissapear suddenly. That's what I've observed in nature - flakes don't go towards strict cone center, but towards some area, because the light bulb isn't a point, but a volume.

Ok, I think that the idea is simple and obvious, so now - how can we simulate this? There are many possibilities, like:

• Particle system used only for shadows
• Post process stage shadowing
• Animated textures (even on low-end hardware, but I won't call any exact names ;P) with texture projection
• etc.

What you can take from this note is the general behaviour of snowflakes. Their movement is partly predictable (or at least its schema), and by reproducing it you can achieve some eye-candy scene.

2 Fast 4 GNOMZ

This is the second game in Gnomia world, look at the first one. While GNOMZ was a multiplayer game, 2 Fast 4 GNOMZ is an exclusively single player game, just like the previous one - made by QubicGames for WiiWare service. This time our goal is to run through the world of Gnomia to find a woman and, of course, collect socks. There are four characters that you can morph into, that's why there is '4' in the title. The game is quite indie in style and is strongly related to Bit.Trip Runner and Super Meat Boy in a matter of difficulty. Our goal was to create a game that is really a challenge, only for hardcore, oldschool gamers. My role at 2F4G was project management and lead programming. There were 11 people working on this title development, including programming, visuals and audio.

GNOMZ on the market

I can proudly say, that my youngest child - GNOMZ, was finally published on WiiWare, USA. Read more at gnomzthegame.com. You can also buy the game, visit nintendo.com

I can also say, that Gnomia is such an inquiring world, that we are allready working on another title that is going to be placed there. This has been already announced on nintendolife.com by Michał Dys, our PR fella ;)

With or without GPU, that is the question...

This post just represents my thoughts about how people get into some hi-tec trap. They know how to create some eye candy effects, like fish eye or chromatic aberration with GPU shader with 5 lines of code or less - that's cool. But when it comes to a situation when people don't have those shaders for their support, they get confused and say "that's impossible, you can not create such effects without modern GPU" and that's bullshit. A good example is the platform, that I'm currently working on - Wii. I can not say anything more technical about this platform due to some legal rights, but I can say (and everybody know it) that it's rather a low-end hardware. Let's get back to those effects that I've mentioned. You can create some approximation (simple fake, but that's what graphics are all about, ain't it?) using simple linear texture filtering - just create a grid of quads with regular mapping and distort their positions in some manner. With fish eye - just create radial distortion with strength proportional to distance from center of the grid. It looks quite good and is extremely cheap both in performance and implementation.Chromatic aberration - draw red channel on such grid with horizontal distortion with some strength, then green one with 2/3 of this strength and blue one with 1/3, mix them using additive blending et voila!

As a conclusion - this can be really simple, just don't ever think that something is possible only on new GPUs or CPUs or whatever, stay open-minded :) I think that this is quite what low end hardware demoscene is all about.

Class method as template parameter

I had an interesting problem that can be solved using a little bit tricky C++ code. Imagine a singleton that holds some pointer to a class that has many methods with identical params, but different purposes. Now, imagine you're creating some wrapper for this class in some other class (the first one was a ID3D11Device in my case, so I didn't modify it) and your code is also identical, despite this single method call. You can obviously copy paste this problem, creating n-times more lines of code. But this is an ugly solution, so below I paste the nice one. Class A is the ID3D11Device, class B is my wrapper. In my case fun1 was enough (i knew A type while implementing this), but because i find this useful - i paste code for case with unknown A type. Of course in practice, fun1 and fun2 would be big functions with this single call embedded somewhere deep.

struct A {
void a(int param) { std::cout << "a " << param << std::endl; }
void b(int param) { std::cout << "b " << param << std::endl; }
};


struct B {
template< void (A::*F)(int) >
void fun1() {
A* a = new A; // obtain A, this may be singleton or anything else
(a->*F)(1);
delete a;
}


template< typename T, void (T::*F)(int) >
void fun2(T* t) {
(t->*F)(2);
}
};


int main() {
B b;
b.fun1< &A::a >();
b.fun1< &A::b >();


A a;
b.fun2< A,&A::a >(&a);
b.fun2< A, &A::b >(&a);


return 0;
}

The only aspect that may need some explanation at the moment is how to pass ID3D11Device method marked with STDMETHODCALLTYPE as template parameter. Notice, that STDMETHODCALLTYPE is just a macro for __stdcall. We can pass this additional keyword using syntax like:

template< HRESULT (__stdcall ID3D11Device::*CreateShader)(const void*, SIZE_T, ID3D11ClassLinkage*, ID3D11VertexShader**) >
bool load_(const char* filename) {
...
}

Ok, now for the real example - the code will be a little bit more tricky, because we have to use derived template param as param for functions used as template params, blah, compliacted - look at the code :)

template< typename ShaderType >
class Shader {
protected:
ShaderType* shader;
public:
Shader() {
shader = NULL;
}


virtual ~Shader() {
if(shader) {
shader->Release();
}
}


template< HRESULT (__stdcall ID3D11Device::*CreateShader)(const void*, SIZE_T, ID3D11ClassLinkage*, ShaderType**) >
bool load_(const char* filename, const char* entryPoint, const char* shaderModel) {
...
}


template< void (__stdcall ID3D11DeviceContext::*SetShader)(ShaderType*, ID3D11ClassInstance* const*, UINT) >
void bind_() {
...
}
};


class VertexShader : public Shader< ID3D11VertexShader > {
public:
__forceinline bool load(const char* filename) {
return load_< &ID3D11Device::CreateVertexShader >(filename, "mainVS", "vs_4_0");
}


__forceinline void bind() {
bind_< &ID3D11DeviceContext::VSSetShader >();
}
};


class PixelShader : public Shader< ID3D11PixelShader > {
...
};


class GeometryShader : public Shader< ID3D11GeometryShader > {
...
};


class DomainShader : public Shader< ID3D11DomainShader > {
...
};


class HullShader : public Shader< ID3D11HullShader > {
...
};


class ComputeShader : public Shader< ID3D11ComputeShader > {
...
};

Of course you may decide to make load and bind virtuals, and to pack them into some kind of manager - this is just a design decision, whether you want to automate use of those classes. In such case design would get a little bit more complicated. My load is virtual, bind isn't. Additionally, VertexShader is strongly coupled with VertexLayout (ID3D11InputLayout), which is created while loading, so my structure looks something like this:

GNOMZ the game

GNOMZ is a WiiWare multiplayer hot seat action platformer developed by QubicGames. I worked over this project as lead programmer and project manager since january till august 2011. You can read more about this game on GnomzTheGame.com. I also wrote some paper about implementing AI in GNOMZ, you can read it here.

Reviews:

• "I would say that Gnomz is an excellent multiplayer game"
www.gev.com

Smart Traffic Signs

Recently, I've been traveling more than 4k km by car, and I had some time to think about stuff not connected with gamedev. In Germany I've noticed a strange sign - speed limit depending on slipperiness of the road surface. It was strange, because there were no precautions if weather is ok, so you can go 300km/h if your car can, and in case of rain you can go only 80km/h, so it's quite discrete. And than the idea came - why not measure the state of the road and show the speed limit in electronic form. For example in dense rain - 80km/h, in snow - 50km/h, in light rain - 120km/h and so on. We kept going, and on the bridge there was a sign - in case of wind, 100km/h or something like this. The idea is even better here - just measure wind speed and show appropriate limits. The method is great because the sign can measure a lot of parameters at a time, and using some heuristics it can show the speed limit, or some other information. What other info? For example - imagine a sign showing a pedestrian crossing. If you go at night you usually can't see anything, so slowing down is the only option, but even going 50km/h is too much if someone enters the crossing. The solution is simple - show some additional info, that there is someone near the crossing, so that the driver knows that he has to stop, not only slow down. It's not easy to implement, but in my opinion it's not impossible. Smart signs can also take into consideration some other stuff, like traffic - read this. In my opinion, the method has almost no limits, and would really improve safety on roads. The only question is, will politics spend money on our safety? I don't think so, they need money for PR :)

Let's go further - the speed limit also depends on the car, for example big truck should have much bigger limits. Why not implement traffic signs... in cars? Imagine a display that shows you the limit, or in extreme it can even automatically limit your speed. The idea can be really simple - all traffic signs have some transmitters attached, that broadcast restrictions at some place (some norm would be required). Receivers collect those broadcast, and analyze them, for example taking into consideration mass of the car, state of it's tires and so on. But for now this is rather science fiction, because all cars would have to implement this. Maybe it's a good moment to start such revolution, this depends on motorization brands. Remember, that such a solution doesn't have to mean that we remove all "classic" signs - they can stay, we can just add some new features to them.