This week, the game “Direção Defensiva” was presented at a government conference. As I said in an old post, this game was developed to help people driving better as the player have to obey the traffic rules like stop at traffic light,  don’t exceed the road’s speed limit, and so on. At the same time, the player have make some delivers at a given time, wich is subtracted each time he disobeys the traffic’s rule.

In the conference, people could play the game using a wheel’s joystick, wich gave more immersion for the player. The game was a sucess in the conference and always there was people waiting for playing it. Also, the game got attention for some jornalists that published some post in newspapers and on the TV.

People trying the game

The Journalist

Me testing the game also

 In this case, extracting the color components could be done using the following code:

int pixel = texture[i];
int r = ( ( pixel << 24 ) & 0xFF);
int g = ( ( pixel << 16 ) & 0xFF);
int b = ( ( pixel << 8 ) & 0xFF);

But, for my surprise, the components are retrieved in the inverse order. After looking for why this problem occur and also found others looking for it, as here, I found out the problem. In the code above, I was using integer type. In the Intel architecture, little endian is used, so the most significative bytes are allocated in the end. This is why we get the color components in the inverse order, even requiring some predefined order.

To outline this problem, I changed the type from integer to CUDA’s uchar4, solving the problem as bit ordering are applyed only in 16-, 32- and 64 bit word. After this change in the code, I was able to get the color components in the right order.

[1] Cass Everitt. 2001.  ”Interactive Order-Independent Transparency”.

[2] Trapp, Matthias and D”ollner, J”urgen. 2008.  Real-Time Volumetric Tests Using Layered Depth Images.

[3] Liu, Fang and Huang, Meng-Cheng and Liu, Xue-Hui and Wu, En-Hua. 2009. “Efficient Depth Peeling via Bucket Sort”.

In the next days, we will be working on the AI of the cars e pedestrian of the city. Whenever possible, I will discuss techniques that were used in the game development process. Below, there’s a video of the game (in Portuguese) for those interested to see it.

Wait for more news!

[YouTube]http://www.youtube.com/watch?v=KS__0i7cN20[/YouTube]

At SBGames I presented a tutorial about using the Unity3D engine for making games. It was a very good presentation and attracted a lot of people for the tutorial. Unfortunatly, only 100 minutes was given for the presentation so only the basic concepts was covered about it.

Another research that I presented there was about using XNA and CUDA for prototyping physical worlds. As this research was only accepted as a short paper, I had only one minute to preset it. So, I made a video of about one minute trying to show my research. The video is in Portuguese and is shown below.

[kaltura-widget wid="oyyh8hucnw" width="400" height="365" addpermission="" editpermission="" /]

[flv:http://josericardojunior.com/wp-content/uploads/2009/10/FastTrack.flv 320 240]

There was no imposition on what tools used for develop them but here, in Niteroi – RJ, the tool thas was adopt for developing the game was XNA. This could help local judges to measure the games developed here.

In the begginning we saw a video of the contest organizers and attended to a local keynote about game design, which was very important to situate people that that is impossible to develop a complex game in 48 hours.

After that, the theme was announced: “As long we have each other, we will never run out of trouble”. Additionally, the maximum game play time could not be greater than 5 minutes and one of the following adjectives needed to be presented in the design: busy, travelling and tiny.

With this insane theme, our team that was formed by a leader programmer (me), a programmer (Andre Brandão) and a graphics artist (Jorge Lopes) started to think how to make a game with this theme. A lot of ideas came in but that was either very complex or did not fill the theme.

The Game

After about 6 hour of thought, we reached a game ideia that was not too complex, fun and was in conform with the theme.

The game is about a woman that wants to get married. For this, she needs to pursuit a man in a given time, which is more faster than she and he can wrap in the level boundaries. To help her with this hard work, she can throws various objects in the level, trying to block his passage. Below is some screenshots of the game:

Previously, I had developed a framework in XNA for 2D games, handling collision events, animated menus, scene manager, sound and things like that. This was very helpful to have the game finished in the right time as we could concentrate mainly in the game that we are developing.

Results

At the end of the event, each team had to present the game developed, was it almost finished or not, for local judges. Some teams make very nice games while others, unfortunatelly did not accomplish it in this short period of time.

After all presentations, we reach the third place in all the games developed! To a game developed in this short period of time, we were very pleased with this as we developed a game that is simple, fun and have a great game play factor behind. Some photos of the hole event can be seen here as some other reports about the event.

Future Works

As future works, we plan porting it to web using Adobe Flash, enabling people to play it without the needs of installation. More levels will be added to it and a score mark will be implemented, saving the best time a person win the game in all levels.

First of all, we need the texture that will be projected:
texture gDiffuse;

After that, we need to create a sampler. Here there is a trick. The CLAMP mode needs to be used for all adrress. This is because, sometimes, as we will see, the texture coordinate generated can be greater than 1.0.
sampler2D gDiffuseSampler = sampler_state {
Texture = <gDiffuse>;
MagFilter = Linear;
MinFilter = Linear;
AddressU = CLAMP;
AddressV = CLAMP;
AddressW = CLAMP;
};

Here is view matrix that will do the texture projection.
float4x4 projectorView;

And this is our normal camera matrix, composed by the Word, View and Projection.
float4x4 WorldViewProj;

To facilitate, I created some structs to store the information that will be needed by the shader effect.
struct VSIn
{
float4 position : POSITION0;
float4 texcoord0 : TEXCOORD0;
};

struct VSOut
{
float4 position : POSITION0;
float4 texcoord0 : TEXCOORD0;
};

Here is our main vertex shader. Let’s see how it works:

VSOut mainVS(VSIn input){

First, we create our struct to store the end result computed by the vertex shader.
VSOut output;

In this line, we compute the texture coordinate. We can see here that, to do this, we get the position and multiply by the projectorView, which is a matrix composed of a world, view and a projection but of some other point of view that can be another camera, as is the case of this example. After this multiplication, we said that the position is in homogenius clip space. Points outside the field of view of this projector view will not be rendered, or in other words, will not have texture coordinates.
output.texcoord0 = mul(float4(input.position.xyz, 1.0), projectorView);

Here we compute normally the projected position of this position.
output.position = mul(float4(input.position.xyz, 1.0), WorldViewProj);

And finally return these information
return output;
}

Now let’s see the Fragment Shader.

float4 mainPS(VSOut input) : COLOR {

First of all, we are making a division of all components of texture coordinates by w. It’s is necessary because, as I said before, we are in homogenius clip space. This space is used to do clipping but here we do not need this. So, to get the real position of this vertex we have to make this division. After that we are in normalized clip space. That is, our vertex can go from -1.0 to 1.0. Vertex outside of this range are not showed. Here we have a problem: texture coordinates only can go from 0.0 to 1.0. To solve this, we multiply it by 0.5 and add 0.5. This will do the job.
float4 texcoord = input.texcoord0;
texcoord.x = ((texcoord.x / texcoord.w) * 0.5 ) + 0.5;
texcoord.y = ((texcoord.y / texcoord.w) * -0.5 ) + 0.5;
texcoord.z = ((texcoord.z / texcoord.w) * 0.5 ) + 0.5;
texcoord.w = (texcoord.w / texcoord.w);

Next, we get the texel from the texture normally.
float4 tex = tex2D(gDiffuseSampler, texcoord);

And finally here we return the color. Here there’s another trick. As we are using clamp mode, texture coordinates outside the range from 0.0 to 1.0 will have its color matched to the border of the texture. So, what I did here is make the border of the image transparent, or alfa equals to 0. After that I multiply the texel color from the texture with it’s alpha and added the color of my plane, which in this case is white.
return float4(tex.r * tex.a + (1.0 * (1 – tex.a)),
tex.g + (1.0 * (1 – tex.a)),
tex.b + (1.0 * (1 – tex.a)), 1.0);
}

And is it. Below is an image of this shader applied in a plane using my engine that I’m making in XNA. Here, I used a camera with different field of view. Instead of a plane, it can be applied in whatever object you want.

In this shader, I tried to use the tex2Dproj which takes the texture coordinates in homogeneous coordinate space but it doesn’t work for me. If anyone get it’s working please, let me know.

Any comment or question, don’t hesitate to write me.

Today I’m posting some photos of SBGames, a Brazilian conference about games, computer graphics and related topics. This year, I presented a short paper about NPC behaviors compositing.

It’s only for now. As soon as possible, I will discuss my short paper about NPC behavior composition here.