Hi mike

I have read your blog several times now over the last few months(about LieroXNA) and thought i should just let you know i find your LieroXNA project very interesting
very impressive work with those particles aswell, very nice work
infact… not to long ago i was in the IRC channel #XNA and people was talking about “that XNA liero game with all the particles” so apparently you have made an impression on the world hehe

but the last post seems to be from 2007, are you still working on the project?

Also, One thing that makes me very interested in Liero and XNA related projects is the fact that i am my self working on a Liero3D game in XNA, if you are interested you can find info about it here:
http://liero3d.blogspot.com/

PS: Sorry about my bad spelling (Dyslexia)

take care
/Michael

——- and my reply: ——–

Well the result of this is I have been digging around and have found “some” old source code, its not complete, but over the coming weeks im going to take a look at it and see if I can get it in a state where I can post it up here, it would be a shame to let this one rot.

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.

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]

<

Firstly I worked on setting up a framework for weapons that allows them to be described by an external xml. This should reduce the effort involved in creating new weapons in the future. Taking a quick look at the XML that describes the rocket weapon you can see its straight forward but also pretty powerful:

<?xml version="1.0" encoding="utf-8" ?>

<weapon name="Rocket" type="projectile">
    <properties>
        <texture>rocket</texture>
        <trail>smoke</trail>
    </properties>

    <events>
        <onTerrainCollide>
            <spawn type="explosion" size="64"  where="this" velocity="this" />
            <spawn type="shrapnel" quantity="10"  where="this" velocity="this" />
            <die/>
        </onTerrainCollide>
    </events>
</weapon>

In addition I have been working on adding forces into the game. It took abit of tweaking but now explosions have a force which repels particles around it, you can see this in action in the video below. I have also added a "vortex" special weapon that sucks particles towards it which then swirl around until the vortex implodes expelling all the particles.

The size of the world has now been expanded and a simple camera has been added. Previously the intention was the world was to be split into multiple tiles of 1024×768 textures but i have now decided against that due to the level of complexity involved and gone for a system that uses one large texture (2048×2048 currently) instead. I have also changed the texture so its a little less "programmer art" as I was getting some stick for that

There is still alot of work to be done but im happy with the way it looks at the moment. You will have to excuse the video quality below, flash isnt the best compression for alot of fast moving small particles.

If you want to see a larger less compressed video (35meg) you can download it HERE.

+ Particles now represent the pixel they exploded from. i.e. if the terrain was green the particle is green, if it was blue the particle is blue etc.
+ Particles are now more white (hot) depending on how fast and how old they are.
+ Particles now explode in a circular direction and less randomly (looks more like an explosion).
+ Particles now have a direction from which they are exploded, at the moment is just current mouse position – last mouse position but in the future this will be used to blow particles away from a high energy collision.
+ Particles now react to the player. I realised that instead of just passing in the terrain texture to the particle update routine i could pass the entire back buffer allowing the player and any other objects in the scene to have particle reactions, yey!
+ Particles now have a bit of alpha blending to make them look a little less in focus, not sure if this works well, let me know

Well after digging around abit, I discovered that it was the same problem I encountered before when I released my 1,000,000 particles demo a few months ago. The problem is that ATi dont include the ability to use Vertex Textures in their graphics hardware (the core technology allowing me to get many particles on the screen). I knew the solution from previous work was to use ATi’s alternative Renter To Vertex Buffer (R2VB) unfortunately I could not find anyone else that had done this in XNA before which led me to the suspicion that it wasnt possible. I posted on the XNA forum about this, you can see the replies here.

Anyways to cut a long story short I have not been able to implement R2VB for ATi cards but I have instead done the next best thing which is to implement a CPU particle system instead. This means that people with realy old cards (or like my work machine without a card atall) or people with ATi cards they can still play the game and still have particles, just not as many (200-400k on nVidia, 10-50k on CPU).

Also something I implemented over the weekend was this fancy console which, makes life alot easier for me when developing, isnt it nice

So the new project is designed to be alot smaller than the last and should give a more immediate sense of achievement. The project is going to be a clone of the popular game Liero but for XNA (so xbox eventualy). For those that havent played it, its a real-time 2D action game (basically worms without the turn based tedium).

So far im just playing around with getting the core of the engine up and running. The original Liero and its successive clones were all done in C/C++. In those languages you have the ability to pixel blit, that is write directly to the back buffer one pixel at a time. In XNA/C# however you dont have that ability, so you have to do some funky stuff with shaders. The advantage of doing it this way however is that GPU particles that have physics (can bounce around the level) should fall out of the code nicely allowing for large numbers of particles.

Anyways, as I said its just a beginning for now. So far I have a level rendered with a terrain map, an explosion map (renders explosions to the texture each frame if any occurred) and a collision map which allows objects to collide. With the left mouse button you can blow holes in the terrain which in turn updates the collision map allowing the worm to move around more of the level.