Timer Trouble

Ugh, this new timer and interpolation thing is giving me troubles. Initially I wasn’t even interested in a new timer class. My timer class was working just fine. The problem is Nick’s new and improved interpolation class comes with requires a new and improved timer class.

Of course getting the new timer to not shatter the code that the rest of the game was using for a timer has been, problematic at best. And I haven’t even actually begun to start messing with the interpolation class yet.

Since I don’t see it as good practice to have two timer classes in a program I’m faced with one of two choices. Either rewrite the rest of the game elements that currently access my timer class to use the new timer class. Or, rewrite parts of the new timer class to accept the calls that are currently in the existing game.

The one good thing coming out of all of this is the educational value of it since I’m starting to get into delegates and lambda expressions which is new stuff to me.

Tweening...stuff

I'm happy to report the further animation and collision tests have turned out positive, so with the new classes in place it's time to move on to the next thing. And after throwing a dart at the wall...it appears working in an interpolation class (or tweening class) is the next thing to tackle.

This interpolation class will be a utility class that will handle things like fading the screens up and down, moving menu items across the screen and who knows what else. So it will be a very handy thing to have around both now and in the future...so, let's get it right.

To start off I've been reading a lot from Nick Gravelyn's blog. And lucky for me he has an interpolation class that will serve as my base point of learning. You think that would be easy then huh? Well it appears I've got some reading up to do before I get rolling with it since Nick's using delgates and lambda expressions to implement his classes.

So for now I've got to get a handle on these two new elements...so, back to reading.

New Animation System in Place

Initial tests indicate that I may have finally gotten the new animation system working properly...did I mention I'm not very good with math. Anyhow, as an added bonus it appears, believe it or not, that the collision system may be working as well. (I never saw that coming, but I'm not complaining.). But those are VERY initial tests in both cases.

So here's a brief history of the animation system throughout Deep Blue's development.

I. Square Sprites - The initial system was gleaned from the platformer demo in the Visual Studio Express Dev Library. It was the most specific, and limiting of all. It ONLY accounted for square sprite frames (with a 1:1 ratio) layed out in a horizontal line. While this may have worked perfectly and been very efficient for the platformer, you can imagine the limitations it put on sprite design.

II. Variable Ratio Sprites - So, the first thing I did was overload the method with an alternate version that accepted a frame width. I kept the sprites aligned in a horizontal row so that the frame height could be simply pulled from the sprite texture height.

That worked pretty well, except on the larger sprite animations which resulted in extremely long sprites (250 pixel wide frame * 30 frames = 7500 pixel wide sprite). And that just wasn't going to work. Even though it wasn't recommended, things animated pretty well....until the engine started checking for pixel collisions on a sprite of that size. It pretty much brought the game to 2 to 3 frames per second. So after posting and talking with the helpful crew on the XNA forums they suggested a basic rule that no sprite should be larger than 2048 in any dimension, and really, you should shoot for a 1024 max in most cases.

In order for that to happen...other than reducing all my larger animations to 3 frames....I had to lay out the frames in a square spritesheet.

III. Square Sprite Sheets - So my current solution is to lay out the frames in a 1:1 ratio sprite sheet with a max size of 2048 x 2048 pixels using a 1024 x 1024 texture when possible. After loooooooooots of broken math it appears to be working. So now I can have much more efficient sprite sheets and much better frame rates when lots of things are moving on the screen at once.

Each of the above variations was carried out by overloading the same Animation constructor so if I HAPPEN to have an animation that has 1:1 frames that is not over 2048 pixels in texture size I can create it easier than I can the custom square sprite sheet constructor.

All-in-all I'm pretty pleased with the results. It took a little longer than I'd hoped to figure it out, and I went through a bottle of Tylenol in the process but I'm glad to have it out of the way.

Let the Music begin.

It's a little early, but I did get my little music studio up and running. It's a little awkward at the moment. The distance between my computer keyboard and monitor and the digital piano is far enough to remind me how old I'm getting.

Eventually we'll plan on mounting a second monitor in front of the piano but for now it just makes recording things a little more interesting.

The good news, everything is in working order and it's fun to be recording again.

Recent Progress

Things have been moving along pretty well from the programming side. Recently, with a little guidance from "fr3shm4nt" on the XNA forums, I was able to get a HLSL shader working that included a lightmap for darkening the scene the deeper you dove. That was a pretty big step and I'll use some of the same techniques for the radial blast distortion when I get to that.

As things got darker deep underwater I also added the system in place for the bioluminecent glow of some of the enemies. So we should be set there.

I've also done a little tweeking to the treasure system to make it easier to read and apply, as well as cleaned up the animation system a little putting things in more logical places.

I'm still wrestling with the collision system, but refining the animation system was the first part to cleaning that up and getting it working properly.

On top of all the programming I've also been focusing in on the "Deep Blue" story. At this point it's looking pretty solid. The story has been a lot like painting...starting with big broad general strokes slowly refining and watching everything come together.

With all this focus on code and story it hit me recently that the one area that seems to be lagging behind is the art. Anyone else find that as ironic as I do? So anyhow...at some point soon I'll have to turn my attention back to the artistic side of things.

But that should be the easy part....right?

Deeper Blue

The concept of "Deep Blue" began as an underwater submarine game in fact the folder on my drive still bears the original name "Sub Attack". Blue waters with light rays dancing through the scenes. But after seeing a few videos on YouTube about the deep sea creatures I though it would be more interesting for it to take place much deeper in the ocean. And that's when things really started to develop from a creature/vehicle concept.

The only problem, and one that's been really getting to me recently, is the fact that 30,000 feet underwater looks much different than 500 feet underwater. Visibility becomes a major game play element. Even with some of the story elements of Deep Blue that would add a little more light to the scene, the environment would be much different at that depth.

I've decided to shoot for something inbetween reality and game...which seems to be a common approach so far...and go for a much darker environment the deeper you go.

To pull this off, I hope, I'll use a pixel shader to darken the value of the entire screen then use glow textures with an additive value to 'light up' the lights on the MANTA or the bioluminecent creatures of the deep. At least that's the theory.

So far the darkening part seems to be working pretty well, now I've just got add glowing light sources back in. The shader started out as a game component, much like the bloom shader I'm using. But I needed more control over the draw order so the UI and messaging wouldn't be effected by the darkening so I switched it to a class.

Some Days

Is it just me, or does it just seem impossible to program anything that works on some days. Other days things go smoothly, but days like today I can't seem to get my mind to kick into "program" mode.