Site Sections

Friday, August 17, 2007

Tile Texture Shader

Blah... so I am packing to go down state tomorrow, and I am bummed because I missed the chance to get some Oyster Eggs in KOL with one of my characters. So to make myself feel better I thought I would write a little tutorial today.

What we are going to cover is how to add tiling attributes for a texture shader. I figured out how to do this a few weeks ago when I was playing around in my engine (it's really not all that hard). I was trying to build interior walls like they use in the Unreal engine but I couldn't figure out a good way of building the subtraction space model they use in their editor... well needless to say, Unreal also has the ability to dynamically set texture location and scaling in its editor. I of course think this is very important when you want to line up textures and build walls that are longer than your texture is wide. So lets begin:

Here I have a basic texture shader:


float4x4 WorldViewProject;
sampler TextureSampler;

struct VS_INPUT {
float4 Position : POSITION0;
float2 Texcoord : TEXCOORD0;
};

struct VS_OUTPUT {
float4 Position : POSITION0;
float2 Texcoord : TEXCOORD0;
};

VS_OUTPUT Transform(VS_INPUT Input) {
VS_OUTPUT Output;

Output.Position = mul(Input.Position, WorldViewProject);
Output.Texcoord = Input.Texcoord;

return Output;
}

struct PS_INPUT {
float2 Texcoord : TEXCOORD0;
};

float4 Texture(PS_INPUT Input) : COLOR0 {
return tex2D(TextureSampler, Input.Texcoord);
};

technique TransformTexture {
pass P0 {
VertexShader = compile vs_3_0 Transform();
PixelShader = compile ps_3_0 Texture();
}
}



The concept here is very simple, take in the world-view-projection matrix and the texture sampler, and map them to the vertex texture positions. Then in the pixel shader we simply sample our texture for the appropriate color value and output that color. I have purposefully neglected to add any lighting to this shader for simplicity sake.

Here is a quad that I created that uses the simple version:



So now we want to provide the ability to offset the texture position and to be able to scale the texture for tiling purposes. We will add the following attributes to the top of the shader file so they are accessible from our code:



float TextureScaleX;
float TextureScaleY;
float TextureOffsetX;
float TextureOffsetY;



These values are going to be used in factors. This will make the math really simple, you will just have to remember how the math is done and everything will work out really easy when trying to set up your image. Now we will change our Texture function to perform the scaling and the texture offset. It looks like this:



float4 Texture(PS_INPUT Input) : COLOR0 {

float2 ScaledTexcoord = Input.Texcoord;
ScaledTexcoord.x *= TextureScaleX;
ScaledTexcoord.y *= TextureScaleY;
ScaledTexcoord.x += TextureOffsetX;
ScaledTexcoord.y += TextureOffsetY;
return tex2D(TextureSampler, ScaledTexcoord);
};



And there we have it. Our shader now can accept scaling and offset factors, for example all we would have to do to tile a quads texture to 2x2 tiles, would be to set the shaders x, y scale factors to 2 and we would have 4 copies of the texture displayed on the quad. Say we wanted to shift a texture over by 50% so the textures started tiling at the center of the image in the upper left corner, all we have to do is set the TextureOffset x, y to .5 and we get the result shown below.

Tuesday, August 7, 2007

The Woes of C...

I really dislike C, not because it is complex or that I do not understand it. It's not even so much that it is a functional language over a OOP (Object Oriented Programming) language, although that is frustrating. I just hate the libraries that have been developed for it. I dunno... maybe I am just stuck using really obnoxious libraries (specifically National Instruments LabWindows). Utility functions should be intuitive and they should be flexible, C functions that I've had to work with (although I haven't used many different libraries) are just cumbersome, take too many variables and are just all around bulky.

My other beef with C is local variable initialization, I hate having to define loop variables at the top of my function instead of in the loop declaration. I just don't understand why they couldn't write the compiler to declare stack variables while parsing the entire function, even if they had to parse the function twice.

I miss working in C++ :(

Monday, August 6, 2007

KOL Downtime and an XNA Book Review

So its 11:30 pm again... I hate when KOL goes down. It makes me very sad. I wonder what they do every night that requires the server to go down. I wonder if it just takes too much server time to update everyone's adventures. Any who... I went bowling tonight so I didn't get a chance to work on my game today but I did read some of the new XNA Game Studio Creator's Guide by Stephen Cawood and Pat McGee.

Here is my opinion so far: I don't know how long ago they wrote the book but it seems like there are better ways to handle some of the stuff they are doing, I wonder if they wrote it after the refresh. Maybe it is just my pet peeve that they use underscores in method names or what but their coding style is so far atrocious. Also they use Quake II models for animations, I haven't gotten to that part of the book yet (I am on chapter 4 so far as I just got the book Saturday - Shaders WOOT!) I am hoping that the chapter on the Quake animations will give me some insight on how to make Maya animations work in XNA since I am using the .X exporter for my models. Also it seems like there might be some good info on some geometry and Quaternion I might be able to use for camera controls and better character/obstacle control. I did notice though that the collision detection section was lacking in any sort of complex vertex collision on meshes. :(

I'm crossing my fingers...

Ill write more of a formal review once I have finished the book. I am disappointed that I can already tell that this book is simply too basic for what I want to do with my engine. Oh well... at least it will make some interesting reading for a few days.

Languages... when you know too many

This morning I was working on my game since for some odd reason I woke up 2 hours before I had to work. The funny thing is that I have just started using C# at the same time I started using XNA. Of course I work in C, C++ and Visual Basic for work and Michigan Tech teaches Java as its primary course language (among some others for special classes, such as LISP, Prolog, Veralog, Matlab, Fortran, etc...). It has been really easy to pick up C# as it is almost syntactically the same as C++, mixed in with a few things from Java. Granted it has its own things unique to the new .Net platform such as the "Using" keyword for things other than import libraries, the ever interesting partial classes, and a few other things I'm not all that familiar with yet, such as attribute tags and the new Getter/Setter syntax (I'm old school, I like method names with get and set in them).

The point I was getting at though, was that this morning I was trying to extend a class for the items from the HMModel class that was developed from the Hazy Mind site and I kept trying to use the super() call to the parent constructor. I did an F1 search and it even came up as a keyword to call the parent class for constructor calling and method access. Well it didn't work and I kept getting exceptions. Seems the correct use is to call base() in the initialization list like C++... Thats where knowing too many languages can cause you problems.

Sunday, August 5, 2007

Quaternion

So today I was working on Indy Game and I was trying to get the slerping working (fun flybys - Check out the Hazy Mind site for more info) for the turning of the camera when going through doors. Anyways... Yea, Michigan Tech is not exactly the best school in the world for graphics. See, I didn't hear about Quaternions until just recently (actually until I read the Hazy Mind site myself). I've taken graphics courses and although they were not very good, they were all in OpenGL but not in the sense of learning OpenGL, but to instead learn the basics of rasterization, line/point theory, phong shading, and stuff like that... I mean we didn't even get into any model file formats, or level design or anything of real use when developing game engines.

Enough ranting... The reason I am writing this is because today when I was trying to get the slerping working I kept having this problem with my camera over-rotating. It would rotate to almost the place I wanted it but not quite right. It always seemed like it over shot its target axis that I thought I was defining in my Quaternion that I was passing as a target rotation to the Slerp function in my engine.

Here was my code:


HMCameraManager.ActiveCamera.Slerp(HMCameraManager.ActiveCamera.Rotation *
new Quaternion(0, 1, 0, 1), .45f, SlerpType.Revolve);


The idea here was that I was attempting to have the camera "Slerp" 90 degrees to re-adjust the camera for when a player went through a door. I am hoping that this gives the player a real chance to see that the world they are in is really in fact a 3D world even though they are restricted to a 2D plane of movement (except for the doors of course). Well it seems that I don't really understand Quaternions all that well... the X, Y, Z components are not the directly related to which axis to rotate to. Well, after about 4-5 hours of tinkering and a lot of trial and error, I fixed my problem, it really was quite simple and I hate that it took me so long.

Here was my fix - Don't laugh (ok, you can laugh a little):

HMCameraManager.ActiveCamera.Slerp(HMCameraManager.ActiveCamera.Rotation
* Quaternion.CreateFromAxisAngle(new Vector3(0, -1, 0),
MathHelper.ToRadians(90)), .45f, SlerpType.Revolve);

You can see here that my change involved a little more calculation to create a Quaternion that I know for a fact is a 90 degree rotation. Makes things a little simpler in my mind, even if it does look a little sloppier. If anyone else has a better suggestion, please feel free to let me know.

Saturday, August 4, 2007

Indy Game I

So for the past couple of weeks, I have started development of my first XNA title. Initial development has gone into constructing the basic implementation of an engine. Current features include an OctTree for object culling, Skybox, object rendering, shader support, post shader processing, 2D HUD GUI manager (there will be a tutorial up here later once I get this working %100), and the beginnings of an input manager for both keyboard and 360 controllers.

The concept is being worked out and revolves around the premise of an indy game developer who was sucked into his own game, it is incomplete and he must beat the game to get back out. My idea is to develop the game as a sudo-2D environment using 3D models fixed on a rail.

The largest problem I have had so far involves camera functionality. The basis of the engine spawns from the Hazy Mind engine site (thanks Michael Schuld for the starting point and very useful information) but the code is quickly becoming heavily modified as the hazy mind engine is not really structured well for large scale projects.

Further updates will be added here later as I start generating screen shots, and better engine code for level generation and collision detection. I am really happy with how much XNA does simplify things. I haven't worked with it enough yet to fully understand how it supports other things such as animations imported from Maya but I am hoping to get into that stuff very soon as I will need animations for my characters.

Check back soon for more updates...

The Kingdom

I love Kingdom of Loathing, everyone should play it. The concept is truly original and the technology is so simple I am surprised there is that much content. Its amazing what a simple design can produce with a tight feature set.

If you haven't played KOL yet, check it out here

Don't forget greasemonkey plugins for firefox and the KOL Wiki

New Blog

This new blog is for development information on game projects currently in development by myself. This is the first post to put something up until i get some more time to put more information on.