Those who know me know I used to do quite abit of development in c# using Microsoft’s XNA platform.

Well I like to check back in every now and then with some of the big players in the community to see what’s going on.

One of those players is Catalin Zima, who is famous for producing many great shader and effect samples.

One of Catalin’s reccent project particularly caught my eye however as I had tried to tackle the same problem several years ago when I was in my final year of university. That is, Dynamic 2D Shadows Calculated on the GPU (http://mikecann.co.uk/university-projects/shadowshader-in-rendermonkey/)

Catalin’s approach to the problem is far more elegant that my brute force iterative approach. He uses a clever technique of distorting the desired casting image about the light in such a way as not to require iterative pixel lookups.

If you are interested in the more details in the technique I encourage you to check it out over on Catalin’s blog: http://www.catalinzima.com/2010/07/my-technique-for-the-shader-based-dynamic-2d-shadows/

http://www.mikecann.co.uk/?p=163
httpvh://www.youtube.com/watch?v=vxrg1YavBIg

http://www.mikecann.co.uk/?p=169
httpvh://www.youtube.com/watch?v=3wdIiCCAb9U

I have another reason for these old re-posts, something a little more flash orientated.. Stay tuned for more info

One project I have been working on for a while (in my spare time at work and in the evenings at home) is a new version of PlaceEd. PlaceEd is a small app used by people at work who need to design levels with objects and paths in them.

The reason for making this new version was because the original was starting to show its age and after several modifications to customise it to certain projects it has become unreliable. A second version (PlaceEd2) was half coded by one of the other employees at rockpool though they ran out of time and didn’t complete it.

So that’s where I come in, and I wrote from scratch a new app and called it PlaceEd 3 (even though there wasn’t really a fully released version of PlaceEd 2).

PlaceEd3 lets the user create a new project. This project can have levels added to it. Each level can have a certain number of layers. Layers can be either one large image or a tileset and tileset data. The user can then create objects and give them variables that can either be static (global to all objects of that type) or they can be local which means each object has its own value for that variable. Objects can then be placed on the level and moved and dragged about. Paths can also be placed on the level, this is useful for games that need to script specific movement sequences.

Once a level has been designed it can then be exported as a single binary file that is easily compressed and a java source file that gives a demonstration of how to load the binary data file.

The whole app is written in C# using WeifenLuo docking panels. For the rendering of the level I have integrated an XNA 2.0 panel for speed it gives.

When i got home i tested out my theroy and the results can be seen below. Its pretty obvious that its not perfect but as i say it was just me messing.

Oh BTW grant kot has been working on his polluted planet some more, and its starting to look quite impressive now its over in XNA: link1, link2

I started this time from some work done by the CUDA team over at NVidia. As im running windows Vista i couldnt get CUDA to work so i read through the source and adapted it to my needs.

As you can see from the video below its better than my last attempt but still not perfect, it also still runs on  the CPU on a single core and has had no optomisations applied to it.

Hopefully tho i can build on this to make it better.

So i have decided to have a go at implementing it myself in XNA.

So here it is, my first attempt at it. Currently the algorithm is very rough as you can see from the video there are still some problems that cause the particle to behave a little… umm.. erratic

Hopefully with abit more time and effort ill get it sorted. At the moment there are 5000 interacting particle on one CPU, hopefully i will beable to push that figue up soon and take advantage of my quad-core system

Well its that time again. XNA 2.0 has been released and with it a new Dream Build Play competition.

As a warm up to the competition Microsoft have launched a smaller contest named Silicon Minds. The central idea behind this contest is to encourage A.I. in games and as such 60% of the marks will be given to the quality of the AI in the game a further 20% given to how fun the game is and a final 20% given to the polish of the game.

I have been wracking my brain trying to think of a good project to do for this contest, some of the ideas i came up with were:

• Bee Swarm Game
• Dynamic FPS Difficulty
• Particle Flocking
• Learning Geometry Wars
• Predictive Multiplayer
• Adaptive Level Design
• DNA Designer
• Design a Positronic Brain

In the end i decided that due to how short the competition is (ends jan 27th) and my lack of any A.I. experience I would stick with what I have learnt in the past and develop on that. So using the work i have done on LieroXNA so far im planning on writing an A.I. for a deformable 2d landscape.

Sorry i cant say any more at this stage but stay tuned and ill update in the near future.

The way the terrains work has changed a few times over the course of development of the project for various reasons mostly related to the incompatabilities of the 360 and my previous methods. I wont go into those previous methods here but if anyone reading this has any questions dont hesitate to ask in a comment or email me. I would also like to say this may not be the most efficient method as I was only getting the terrains up as a proof of concept first then was planning on refining later.

Before i can explain how the terrain is deformed i must first talk about how the terrain is composed. There are currently three layers to the level, an indestuctable layer, a destructable layer and a background layer.

 There is also a "destroyed mask" that is used to create areas at the start that have already been destroyed. This is mainly used so that you dont have to burrow for ages at the start to get to your opposition. Combined together you end up with the final result below.

 Each texture layer at the moment is 2048×2048 (which is the maximum texture resolution the 360 supports) and is in the format Color (8bpp). The indestructable and the destructable layer are then sent to the GPU for use in rendering and particle collisions by the GPU particle system.

Objects such as players and weapons that are updated by the CPU however cannot perform collision checks on a texture that is on the GPU (without calling getData() which causes read-back which is horribly slow). So the destructable and the instructable layers are duplicated in the initial load of the level and saved as a large two dimensional array of Colors on the CPU.

You may ask why waste memory by storing the full Color component on the CPU when only a single bit is required per pixel to determaine if the terrain is solid or not. The reason for this is that by storing the full color component exploded particles can become the colour of the terrain that they exploded from rather than all of them being the same color.

When an explosion occurs a few things need to take place to make the terrain deform correctly. A hole of the correct size must be cut away from the Texture on the GPU so that the particles react correctly to the deformed terrain, also this new hole must be mirrored in the collision data on the CPU so that the player doesnt collide with things they think are destroyed terrain.

Another 2048×2048 "explosion map" texture is used to handle the deformation of the GPU texture. A series of explosion masks have been created that represent each explosion size:

 When an explosion occurs it is added to a list of other explosions that have occured that frame. When the render of the level is called the list of explosions that have happened that frame are iterated through and rendered to the 2048×2048 "explosion map" map texture in the correct world location that the explosion occured. This "explosion map" is then passed to a texture render shader which using render targets updates the terrain texture:

float4 PixelShader(float2 texCoord : TEXCOORD0) : COLOR0
{

    float4 outCol = float4(1,0,0,0);
    float4 explosinCol = tex2D(ExplosionSampler, texCoord);
    if (explosinCol.x!=0)
    {
        outCol = tex2D(TextureSampler, texCoord);
    }

    float4 indestr = tex2D(IndestructableSampler, texCoord);
    if (indestr.w!=0){ outCol = indestr;  }
    
    return outCol;
}

Note how the shader takes into account the indestructable layer so that the explosion doest destroy parts of the indestructable level.

The CPU collision data ‘texture’ is updated at the time of the explosion. When game loads each explosion mask is duplicated on the CPU much in the same way the indestructable and the destructable layers are. When an explosion occurs each pixel in the CPU explosion mask is compared against the CPU destructable layer and depending if the pixel is "indestructable" or not the pixel is set to be destroyed.

If you remember from back at the start I talked about the "Destroyed Mask" but didnt explain how it destroyed the terrain. Well it basically acts as a large explosion mask. At the init of the level the Destroyed Mask is rendered to the "explosion map" giving it an initial destroyed appearence. The same is applied to the CPU.

And thats about it for how the terrain deformation works in the project at the moment. As i said i played around with many differnt ways of doing it including negative rendering and methods that dont involve using a 2048×2048 temporary buffer texture but for now this is the method that it uses.

I have been spending the majority of my time getting it to run on the 360. I ran into many problems, the majority of which were due to the different ways render targets work on the 360 and the fact that you cant use 128bit floating point textures (Vector4 textures).

Ill be going into more depth on the problems i faced on the 360 in a different post. But what i can say is that it works almost perfectly on the 360 now and im very happy with it.

For now you can see a new video of the engine with some fancy bloom effects added

+ Added a destroyed layer to the game which is just the initial map but darker.
+ Added a shadow to the foreground to give it a more 3D appearence.
+ Added an indestructable layer, so that maps can have abit of structure even after a long battle.
+ Added the ability to zoom in and out. This was a big one and took most of last weekend to sort out.
+ Added player spawning.
+ Added the ability to control the player with the 360 controller.
+ Started to add other gameplay features such as player jumps, crosshair, weapon switching things and others.

Anyways you can see all these new features in action in the video below. Again, you can download a higher quality one if you wish: [download#1]

<