Blog for Brian Richardson at GarageGames.com

A PIX debugging session

Brian Richardson — 2008-02-06T05:50:31+00:00

Here's an article I've been meaning to write for a little while. It's about PIX, the DirectX utility that ships with the DirectX SDK. It's a great utility for tracking down rendering issues. The point of this article isn't really to explain it in great detail, because it's easy to use. It's mostly to expose people to the tool and encourage you to check it out! This is a debugging session I did after tracking down a crash bug in dynamic cubemaps in the upcoming TGEA release. The crash bug was pretty easy to find. But when I fixed it, I got this result:

The "spider ball" in this image should be reflecting the tower it is next to, what gives? Let's use PIX to figure it out. First, to launch PIX, find it under DirectX Utilities under the DX SDK folder. You'll get a blank screen. Next, select File->New Experiment. Then for "Program Path", enter the path to your executable. Then, select the "A single-frame capture to Direct3D whenever F12 is pressed." radio button. Finally, hit the "Start Experiment". This will launch the app. The next step is to get your app to render your bug. In this example, I moved the camera so I was looking at the spider ball again and hit the F12 key. The game will pause while PIX records all of the DirectX API calls and state into a log file. Then quit. You'll end up with a screen like this:

The treeview in the lower left pane is a list of all DirectX calls made during the frame that was recorded. If you click on the render tab in the right pane PIX will show you the scene up to the API call selected in the left pane. You can learn a lot about how an app renders by just hitting the "D down" button and watching the scene draw step by step in the render pane.

It's cool to have all of this information at our fingertips, but it'd be cooler if we could filter it down to what we're interested in. By right-clicking on a pixel in the scene and selecting "Debug This Pixel" we can do just that.

This will replace the render view with a list of all of the API calls that changed the color of that pixel. It's a life story of that pixel for that frame. You can click on each of the links displayed to move the current selection in the treeview in the left hand pane to that API call.

In this next image, I just picked the first pixel that was black, which should get me to the API call I feel is generating the wrong image. It's event 2893.

Now we can examine the state of D3D at the time of this call. This is awesome stuff! Rendering with DirectX (and OpenGL) basically involves setting up a large state machine. The types of states are rendering states, textures, texture sampling states, shaders, shader constants, and the list goes on. If any one of these states is incorrect, you'll get rendering bugs. They can be hard to track down without a tool which allows one to examine the state of D3D. Often we have to do ad-hoc state checks by dumping textures to disk or querying the device and logging the state info out to a file. PIX provides the ability to check state without modifying your code. Getting back to my dynamic cubemap problem, the first question we must answer is: Is the dynamic cubemaptexture being rendered correctly? If it is being generated correctly, are we actually using it during the draw call? Let's find out! Double click on the blue hexadecimal address to the left of the API call in the treeview in the left hand pane. In this example, it's 0x056150D8. This will change the right hand pane to a view of the device. We can see a lot of state here. I want to look at the textures, so I choose "Pixel State" from the tabs and scroll down to the "Sampler" section. This section allows one to look at all of the current textures that are active during a draw call. Many bugs are just due to the wrong texture being bound, or no texture is bound at all!

To actually look at the texture, just double click on the blue hexadecimal address in the "texture" column. In the next picture, you can see the cubemap texture has data in it! This is good news, that means I can ignore all of the code that deals with generating the cubemap.

Next, I wanted to look at the pixel shader code that is used. Mostly because I forgot how the cubemap was working at the time. I wanted to see what other dependencies it might have: other textures, shader constants, etc. To do this, go back to the debugger frame that showed the history of the pixel and click on "Debug pixel (xx,xx)". This will bring up the pixel shader that was used.

Looking at the shader, it only samples the cubemap and doesn't rely on any shader constants. It's time to look at the vertex shader to see what it passes to the pixel shader. To do this, just select "Debug Vertex X" in the history view.

Looking at this dump really fast, I could see that it needed to have these vertex shader constants: $modelview @ position 0, $cubeTrans @ position 16, and $cubeEyePos @ position 19. Let's check the vertex shader constants and see if the data is good. To do this, select "Vertex State" from the tabs and scroll down to the vertex shader constants.

Oh crap! Look at positions 16-19, it's full of zeros. So the cubemap transform isn't getting set! I quickly searched the code to see what sets them up and found out that they'll only be set if the material has "dynamicCubemap" set to true! D'oh! I fixed the material and got the following screen:

That was literally my debugging session, it took about 5 minutes. It could have taken a lot longer if I didn't have the right tool. Hopefully, this was a good introduction to PIX. There are other uses for it: performance monitoring, resource usage, but this is what I use it for the most. I hope this article makes you reach for PIX the next time you have a rendering bug.

TGEA Batching Doc + randomness

Brian Richardson — 2007-08-18T23:05:43+00:00

So, a whole lot has changed for me in the past two years or so. I've moved to Portland, OR and bought a house. I've gotten engaged to my girlfriend of over 8 years. I've shipped a few pieces of software. The latest change is that I've joined the engine team here at GarageGames! It's definitely been a childhood dream of mine to work on games and game technology for a living. I'm getting chills when old songs (mostly old Front 242) are playing and I'm hacking on our next engine release. Reminds me of staying up too late as a kid trying to make .s3m music players in protected mode assembly. Also, reading Gamasutra and GG is work, not something I have to hide when I'm at work! ;) Everyone at GG has been really cool and it's a great place to be.

I've written a small article on TDN about the batching system used in TGEA. If you want to add a new object to TGEA, or add custom shaders you must know how this works and I think the article is a good overview to get you started.

Also, if you are doing any graphics programming with DirectX and are not using PIX you are going into a knife fight with a pointy stick. PIX has been a great tool for debugging silly graphic artifacts. It's told me twice that some textures were not getting set. It's also really good at showing you how your scene is being drawn. It's so good in fact, that for my required screenshot in a .plan, I'm going to post of screenshot of a scene in PIX!

As I keep on learning and creating new things, I'll try to write more articles explaining pieces of the engine and other fun stuff one can do.

Torque is a good playground!

Brian Richardson — 2006-01-13T07:51:40+00:00

So, a year and a half ago I was visiting Portland and read something on Slashdot about the Torque Game Engine. I had read about it a while ago, but never checked it. On a whim, I did. The idea of being a game developer suddently overwhelmed me and I decided to buy the engine and start hacking.

After a bit of time, I've released some resources, and I've worked on some projects.

Fastforward about a year and a half, I'm in Portland and now I've got a neat new job doing some DirectShow programming. It's not game programming yet, but I'm definitely moving in the right direction. I'm working on some projects that should turn into some released stuff!

With Torque getting more acceptance as a engine in gamedev circles, I think I'm in a pretty good position to meet my goal of being a fulltime game developer. I guess I'm just writing this for other people that might be thinking about using Torque to get into gamedev, it seems to be pushing me in the right direction!

Other randomness, I've released a little program that does super fast program launching. Check it out a let me know what you think!

Here's a little screenshot:

Also, check out PAGDIG if you're in the Portland area!

Wednesday Oct 26 20:09

Brian Richardson — 2005-10-26T20:09:09+00:00

IGC Wrapup, Breaking things, hire me!

Random update time kids! I had a good time at IGC! It was great to see all of the projects and get some of that energy again.

Mistakes I made this year were:

I guess this year I was a bit less social, so I met less new people. This is because I actually knew people this time! So I just hung out with them. I'll have to change that next year.

Not testing my stuff completely before comming down. This was due to time mostly. It was very dishearting to see someone launch my demo and it just flat out broke on them. Next year I'll have fully tested demos to install. But I did install something on the machines this year, which is a step higher than last year.

I've redone my website. I've decided to use it to sell myself as a contractor. If you have a paying project and are looking for some programming help, check me out. Also, if any of you could run through my portfolio page and let me know if anything is unclear or worded poorly. It was neat to assemble this page because it was nice to see almost everything I've done over the last year in one spot. Felt good after my disappointing IGC demos. ;) I recommend everyone do it!

I spent a day prototyping a concept I've called "Breakshit".

Everyone likes to break things, so why not write a game around that activity? I've got enough tech done to prototype gameplay now. So now I need to figure out a good goal to provide the smallest amount of structure neccessary for "fun". I've got a video of the breaking stuff here (xvid encoded). I based the "tech" on The Shape3DS resource (Thanks Matt!) so I can grab lots of free 3DS models to litter my landscape with and break them!

On the prototyping note, check out this article about rapid game prototyping, it is quite well written!

Saturday Sep 24 18:50

Brian Richardson — 2005-09-24T18:50:50+00:00

What I've been up to and what I'm planning to do:

I landed a nice job here in Portland, OR so I'm gonna be able to stay! That's quite a load of my mind. I've settled into a nice new rhythm. I've gotten a bunch of smaller projects done:

1. Port of fxFoliageReplicator from TGE to TSE for a bounty submission. I had a lot of fun doing this. All of the animation is done in the vertex/pixel shaders. It was intersting comming up with methods to turn features on and off with no branching. Mostly involved multiplication of things by 1 or 0, or by taking advantage of overflow and the min function.

2. Re-enable interior rendering modes in TSE for a bounty submission.

3. Some GuiFlash bug fixing, mini-enhancements. This will be released to the community at some point.

4. Some work on Josh Dallman's game: Shelled!

5. Also, I just submitted a new resource called: Stupid WheeledVehicle Tricks. This shows you how to modify the vehicles to drive on walls, and gives some code allowing a two wheeled vehicle.

I've also been doing some hardware hacking. After my laptop died for the final time, I decided to yank out the ATI Mobility Radeon 9600 chip and install it into my Speak and Spell. I can now play TGE/TSE based games on it (albeit, a bit slow). Here's a picture of it running a new build of
Shelled (in the surreal environments, gotta love em):

Plans for the future:
I'm going to clean up some of the projects I've messed around with and bring them to IGC with me. They won't be impressive, but at least I'll have something running on those machines, eh? Then maybe I'll start focusing my energy in on one project, but I'm not very worried about that right now.

I'm just gonna yoink this directly from Josh:

Lastly, for you Portland GarageGames members (and there are quite a few), check out the new Portland IGDA Chapter website which lists the next meet at Old Town Pizza on Oct 13th. PAGDIG stands for Portland Area Game Developer Interest Group.

I had fun just talking with other game dev people there and it seems like we could really get a scene going if we can grow this group a bit. So show up, eat pizza, you gotta eat that night anyways right?

Monday Jul 18 7:12

Brian Richardson — 2005-07-18T07:12:49+00:00

Move to Portland, GID Ghosts Entry, other silliness

Due to all kinds of "real world" things going on and some gamedev side projects I haven't gotten too much done on my own projects. This resource is the only public thing I've done recently. Some of this is due to my move from Washington, DC to Portland, OR. I love this town so far and I hope I'll be able to settle in with a job soon. (If anyone knows of any cool openings, please get in touch!)

So, now that I've gotten here, I've gotten back into gamedev work a little bit. I've been playing around with HLSL and Rendermonkey alot. I really want to get more into non-photorealistic rendering and doing weird games. So on that note, I decided to jump in and do a gid this weekend. Here's what the critics have to say:

Quote:

<TomB> its quite possibly the weirdest thing ive seen come out of a GID ever

Here's a screenshot:

It's called "Fade to Nothing". The premise behind the game is simple. Everytime you are hit, you become invisible for 5 seconds. As your health decreases, so does your opacity. This makes it harder for your opponents to hit you. This also opens up neat strategic possibilities. You could damage yourself, then run to a new hiding place while you are invisible. There are all kinds of neat gameplay possibilities. There's also a full screen "GHOOOOOSTVISION" shader effect to make seeing more annoying.

I'm hosting a dedicated server for a while, so you can download it here and join the action! There are a couple things to keep in mind. One: This currently requires a ps2.0 capable card. This is because I'm lazy. Two, there's a weird bug with the material mapping. When you join the server for the first time, the level will blink because the mappings have not taken effect. If you disconnect and reconnect, it's fine. Three, there are spelling and grammar errors on my title screen. I may or may not fix this in the future. ;)

Finally, here's a quick rundown of the dev:

1. Port starter.fps over to TSE. (This will hurt me later. ;)
2. Enable my GHOOOOOOOSTVISION shader.
3. Notice that setting alpha on shapebase objects is annoying. I implement a simple shader to get around that. (Minus the ugly sorting issues that I ignored.)
4. Fix network bug with my shader hack.
4.5: Start implementing "last man standing" mode. This would do a normal last man standing game, but you are still allowed to run around and shoot people after you're dead. You'd just be invisible, and you would do no damage, you would just throw them around. I thought this would be very fun! But I didn't feel like dealing with the "dead" state management.
5. Create a quick .MAP level. Used textures from Games Extract for the level. Rock on free textures!
6. Get annoyed because my material mapping isn't working. Matt Fairfax issues the smackdown and let's me know that the demoMaterial macro is reference demo. Why didn't I see that!?
7. Random cleanup

Wow, long plan! ;) I'm sure I missed something. Oh well.. I'm going to be looking into hatching/stippling style rendering soon. Other future plans are blurry right now.

Wednesday Mar 2 16:59

Brian Richardson — 2005-03-02T16:59:10+00:00

February turned out to be a much more productive month for me than January. Here's what I got done:

I passed my Game Mathematics class at the Game Institute. I signed up for this class back in '99 or so and never did anything with it. With my renewed excitement for game development, I decided to finish it up. It's a great refresher on the math I knew and introduced me to the math I needed to know.

I worked on the Flash GUI resource with Thomas Lund. That was quite fun. I fixed the viewport issues that it was having inside Torque. It's based on GameSWF and will just get cooler as GameSWF gets more ActionScript support.

I've also have been working with other people more. I'm helping Tom Feni with his Toons project. I'm working with Nate Watson on his project as well. I've got another one coming up also!

On the personal project front. I have made some progress on my game Fight Like A Girl. It aims to be Mike Tyson's Punchout for the ladies. Here's a current screenshot:

It's currently written in Flash. I'm pondering finding a Flash artist to animate the rest of the game. That seems to slow me down the most. I'm hoping to have a full version of the first fighter/level done very soon. Then I'll link it here and find out what I'm doing wrong so I don't make the same mistakes more than once.

The future of this game is a bit blurry. I want to have a Flash version because I want it to be extremely easy to get people to play it. My plan is to have a downloadable version as well, which would provide customization and other bells and whistles.

There are many options for this:

1. Use the Flash Projector/ActiveX control. Advantages are: Least amount of new work, runs everywhere easily. Disadvantages are: Runs slow, doesn't look "cool". I wanted to Target very low end machines with this. So the projector w/ GDI seemed like a good bet. But it runs really slow on my slow work machines, and I don't like it.

2. Use GameSWF/OpenGL. This raises the bar to OpenGL capable machines. I really wanted to have an extremely low bar for customers to hurdle. I could try to write a software renderer for gameswf. It is set up so you can replace the graphics and sound rendered with new modules. So this might not be too bad. It also doesn't currently support all of the ActionScript I need, so I'd also have to code that.

3. Use Torque2D. I could easily export the graphics with some code+GameSWF. Then recode my game logic in TorqueScript. If I'm already going to require OpenGL w/ GameSWF, then this route maybe the safest approach.

Any suggestions would be appriciated. Please keep in mind that I really want it to be easy for potential customers to give me their money! ;) That's why I'm leaning towards the Flash Projector or a new software renderer in GameSWF.

Thursday Aug 19 14:46

Brian Richardson — 2004-08-19T14:46:18+00:00

Fun device time!

My plans have changed a small bit. I've learned quite a bit about Torque in the past month or so. I was working on a racing shooter game ala Mario Kart. You can see some of the results of that learn in this resource.
[url]

But that got put on hold. I'm working on a small short project involving this VR Glove.
I've learned alot about Torque's input/event system and about the action map. Which links the input to the scripts. Watch this little video To see
the glove in action.

Future plans are to improve the glove interface. Then complete the rest of the project I'm working. Finally, I'm going to get back to work on my game.

I've had some issues with map making. But I've found lots of pieces of info about dif files scattered all over the place which have been helping me out. I'm thinking about consolidating them all together in one page to help other people.

Anyways, that's all folks.