Warning Deprecated

This blog is complete and all future posts are at my new site jrepp.com.

Render targets, multipass glow buffers and more

I've been trying to solidify the look of the shmup game and learning a lot more about how XNA (dx) interacts with HLSL. I have some issues still to work out but I'm almost done with the visual tweaks. One issue you'll run into quick is having to match your depth stencil buffer to your render target. There are also some issues with texel/pixel alignment (texels align in center, pixels align in the upper left). I did have some glowing bullet trails going for a bit which was nice and I'll hopefully have more progress to report soon.

Some other neat features that I've added gameplay wise are tracking missles and the start of a pretty full featured particle system. The tracking missles and bullets have been refactored to use the same particle system.

On another note, I got my old domain back jrepp.com and am pretty much finished with the migration of my recent content, links etc. I don't have all the old stuff from the previous jrepp.com (sources, cocoabb, arcane programming docs) but I'll be digging it up out of the archives to get things cool again. I also plan on writing a few short postmortum articles about XNA development when I hit my stopping point.

My kids are both really into playing the game right now. The key mechanics for them are the "star fox roll" and the debug camera. On a side note this months Retro Gamer has a couple good articles, one of which is about the making of Star Fox which is really a good read.

Holdem: Bug fixing career mode, UI tweaks

I fixed a bunch of bugs in holdem last night. I got career mode working really well, both continue career and new career. I moved a bunch of the player game save logic out into it's own class called 'SaveData'. This aggregates the player basic information as well as extended stats. It uses a binary format with a version header tag to ensure consistency. I was smart about deserialization this time to avoid the unaligned memory read problem that I ran into with the pack file index.

On the UI side I cleaned up the main menu so continue career only shows up when you have a save game. From the in game options menu when you cash out or save and quit it does a nice transition back to the game and then either fades out to career or play now or shows the currently slightly broken quit confirmation.

I would love to get one more art pass over all the menus and background stuff. I may just experiment with altering the existing menu background to make it more color blend friendly and change to a larger font. I want the UI to feel very tangible and inviting.

XNA Shmup Update

More progress as of late on the xna based shmup concept. All of the gameplay mentioned in the previous post has been implemented. Some of it is not quite 'fun' yet. The attack pod makes things entirely too one-sided and most of the weapons need to be tweaked.

Before ragging on the game any more I've gotten a bunch of neat things working. There's a few big things that currently don't exist in the XNA beta that will bite you as soon as you start to scratch the surface of the framework:

• No support for model loading or animation
• No support for fonts or UI

So I was pretty much okay with both of these not being there in the beta and just waiting for them to show up in a final version. Well the first thing I stumbled upon was the ZiggyWare XNA font generator and associated rendering code. This was super easy to throw into the code, it took me less than an hour to get the fonts support into the scene graph.

I then spent another hour and wrote a very small but usable UI/menuing system. When the debug camera is not enabled the left trigger brings up the menu. You use the DPAD to navigate the menu (A button also opens submenus). Certain items can have 'tweakables' attached to them which can be either a float, vector3 or vector4 value type. The tweakable fields (3 or 4 for vectors) can be selected using the shoulder buttons. The right analog stick adjusts the value in the field and an update event is sent to an attach IEventTarget object. I use eventing all over the engine already for animations, game logic etc. The one tweakable I have now for example is the LightDir tweakable which is wired to an UpdateLightDirection event on the scene. In the first picture you can see the specular highlights on the water (please excuse cheazy really bad shader code). You can tweak the lighting with the controller to get the desired effect.


So then that brings me to the issue of the model loading, which I was also content to let be and just use the standard cubes. I remembered that I had some old 3DS loader code laying around and porting C++ to C# is pretty darn easy IMO so I spent a few hours and ported the 3ds code. There were a few wierd things to work out in the translation but the C++ code was written with some nice abstractions so it went very smootly.

So now I've got some free 3ds models from the web running around in the engine with some more interesting lighting and it's actually looking a little bit more decent at this point. The next two shots are just of a free 3ds model I found that is composed of about 16 mesh chunks and has custom basic materials (no textures). To handle the materials I created a MeshMaterialGroup object that accepts the material with face indexes from the loader and resolves the faces into prim indexes. When you call Mesh.SubmitPrimitives() it looks to see if it has any material groups and if so it submits them in order instead of sumbitting the entire prim batch for the whole mesh.

Close ups of 3ds model:

XNA Shmup

So for anyone who cares and hasn't heard me rant about what I wanted to do with the XNA stuff I'll just explain it now. Ryan inspired me to go in the direction of a shmup, I have wanted to do one for a long time but this new framework seems ideally suited to a game like this. There isn't any particular art style or theme set atm so I'm just laying out some really basic shmup gameplay elements that are pretty much 'required' to have a respectable game. One of the key ideas though is to completely leverage the 360 controller. I want to have a very natural action mapping to the controller that makes sense and gives you more control than simply shoot and move.

A few concepts that I am borrowing for the GD are:

• Roll defense from starfox
• Polarized attack for the enemies ala ikaruga (radiant silvergun), the difference here is that ground targets must be bombed, squigies must be railed with mass driver weapons and conventially shielded enemies require beam weapons.
• All weapons are effective against all enemies but certain weaons are much more effective. This technique is vital to survival.
• Ability to equip a small pod that can has limited controlled and it's own set of upgrades.
• Clip/reload system for mass drivers/bombs, energy system for beam weapons. Ammo is plentiful but must actually be collected and you cannot hold the fire button the whole time.
  
  
  Here's a screenshot debugging one of the triggers for a mob spawn and the new bullet system:
  
  
  
  Again, not very impressive looking (it looks better in action) but I'll just layout a few of the things that are working now.
  
  
• Follow camera
• Scene trigger system that can fire proximity events
• Mob controller with spawn/death management (hooked to trigger system)
• Mob action scripting pcodes with time driven events (Fire, Rotate, Change properties etc)
• Random terrain generator

I'm not trying to do a fully polished game currently. Just something that starts up allows you to play through a random level with increasing difficulty and records your high score. I will probably implement a few different types of weapons as well.

I don't know if I want to finish it all in one shot.. I have to get back to some other stuff.. really ;)

XNA: Yes I'm a bit addicted now

This stuff is really nice. I'm actually a bit addicted to the whole thing. I finally got some shader issues sorted out. I have a few very basic shaders right now, one that renders color coded normals for debugging purposes and one that does a single directional light and diffuse shading. I picked up a good shader book and a new 20" LCD yesterday when I was hanging out with Mike. Here's a spinning cube inside a procedural landscape.

Migrating Outlook Express to a Mac

So Lindsey is now migrating to a mac (Mac Mini) and I found the process of migrating her email to be relatively easy. First you get this program called dbconv and run it on all the dbx files in \Documents and Settings\UserName\Application Data\Identies\{BIG-GUID}\Microsoft\Outlook Express

dbxconv *.dbx

Copy all the mbox files to a windows file share.

On the mac in the finder 'Connect to Server (OpenApple-K)' enter the address:

smb://your.server.address

Import them in Mail.app.

Once the mailboxes are imported you export the contacts to a CSV file in outlook. Paste them into: Csv2Vcard and save the output to a vcf file.

Import it into Address Book as Vcards.

XNA rainbow mesh

Well it's certainly not much to look at. I haven't put too much time into getting things pretty yet but I have ported a bunch of game engine concepts from rampart already. I've got a simple scene system with multiple vertex/pixel shader support and runtime switching between shaders. An animation system is hooked up to the avatar with event callbacks. Multiplayer support with actions wired into avatar. Debug mode with flying camera and ability to control scene rendering parameters (pictured wireframe mode). Oh and sound effect events.

The shader in the screenshot is the simple ffshader.fx that is shown as an example in the XNA docs. I have another shader that I put together off the template in NVIDIA's FX Composer. You can toggle between the two and there is a dynamic effect binding system that binds scene/object parameters automatically for the selected effect.

And yes the rainbow terrain mesh is super fruity!

The XNA docs overall are very good but they don't go very deep. I had to dig a bit deeper to discover how to handle the effect files more generic than in the examples which simply loaded a vertex shader function.

Essentially what I have is an scene effect object per .fx file. They derive from an abstract class with the following members:

OnEffectLoaded() -- called after the effect is loaded to get handles to the various parameters.

BindSceneParameters() -- called once per scene render to bind global scene parameters.

BindSceneObjectParameters() -- called once per scene object to bind local object parameters.

This is handy for switching effects on the fly.

I'll post some more XNA shader stuff later.