More insane adventures in DirectX. I’ve been trying, before actually porting the engine code en mass, to get some foundation stuff off the ground, to make sure all the facilities I want are available. How was I to know that something as simple as capturing the screen to a jpeg would be such a problem?

In the old asylum code, I didn’t bother trying to write my own image routines, I had already written a bmp and gif reader and writer in the past, and that was quite enough for me. I used a library called BMGLib, which had some general purpose image manipulation routines. I had a rather hiddeous API route to take to get there though. I had to get a device context, through my CDX wrapper, to the DirectDraw surface, and copy it into an HBITMAP. BMGLib could then build an image in it’s own format from the HBITMAP and then save it out. I also used this to make the screen desaturate, by bringing the surface into a BMG image structure, using the API call (which was still faster than my method, dammit) and then copying it back. It wasn’t a critical operation to have super fast, and it sufficed.

Alas, with the Direct3D surface, I couldn’t use this method so well, not that I tried it at first, it was a penultimate ditch effort to get a desaturation effect working at all. The problem was that virtually any information I could get on getting a grayscale in DirectX was to either have a second set of textures that were desaturated (useless for me, and a waste of space) or to use a fragment shader (didn’t want to do that since I wanted to keep this thing as simple as possible, who would feel sympathy for a 2D game that didn’t run because their graphics card wasn’t good enough, I’m trying to make it as portable as possible)

One last method was presented, which was using what I beleive is called a fixed function, which is a sort of pseudo pipeline program, except it’s sort of pre-limited by the functions it offers, and was a forerunner before the shaders took over the scene. The information I found suggested setting it up so that it performed a dot product with the texture and a predefined constant such that the result would be the correct desaturated version of the colour. It didn’t use the straight up average of the colour intensities, since apparently the eye responds to colours more or less than others at the same intensity. Regardless, the thing didn’t work, I kept getting an image that was waaaaay to dark, like the contrast was turned up. I fudged the numbers a lot until finally getting something that looked decent.

Now the problem is that I need some way to use this to convert an image (ie: texture) from colour to grayscale for the save/load screen I’ve been thinking of, which was easy the old way, but now I’ll have to come up with some cockamaney render to texture method to convert to black and white so I have 2 copies of the image. Writing out a black and white version of the image alongside the other one is silly and not worth considering.

Which brings me back to writing out textures at all… at first, just a simple screenShot method, writing out to PNG, failed with no output. Odd, the docs said that was a valid format, oh well, let’s try Jpeg. Hey, that worked, let’s look at the picture… okay, it seems it only wrote a third of the image out before giving up, the rest is garbage, and the dimensions of the image appear to be transposed. Turns out the only thing that worked was BMP writing, why did they even bother?

A check showed my DirectX SDK was quite old, like from 2002 or something, but still, the function was valid for Jpeg, the implementation was broken, oh well, time to download hundreds of megs of SDK and hope it doesn’t break anything. I decided not to uninstall the other one, against the wisdom of Microsoft, since I knew that the new DirectX had gotten rid of DirectShow and shoved it off in the Platform SDK which I A) didn’t want to download and B) knew that the one I had worked just fine. Getting the new DirectX stuff working with the old DirectShow actually went off without a hitch.

So I had some basics done, but didn’t feel like porting over yet, maybe now that I’ve got more power, better IDE (VS.NET 2002 (all I got) instead of VC6’s) and know the code a little better, maybe I’ll add in some stuff the old engine never had. I started with zlib, which with a wrapper I got off of that book I talked about in my last entry, integrated fairly seemlessly. I tried compiling the library myself, but it was useless (that kinda stuff never seems to work for me) but it had precompiled static libs and dll’s as well, and they worked fine, so now I can store my resources in zips to make things a little more efficient and nice looking.

I’ve also just recently, and barely, brought Lua into the mix. Lua is a scriping language that I first had to deal with in Graphics class, it was actually quite useful, easy to extend, but still bewildering, and nearly all the documentation I can find is about writing for the scripting language, rather than integrating it into your own code (which is sorta the point, but whatever).

I tried a bunch of different ways to compile the source to libraries, then using existing project files to compile it, then using precompiled libs, and nothing worked. Finally I just brought in all the code into my own project and that seemed to work, and that’s the way it will be until I figure this out. It means longer clean builds, but it will at least allow me to experiment. Oh, and it also caused an Internal Compiler Error which seemed to be related to the use of precompiled headers, so I’ve turned them off for the moment.

I had my own scriping ‘language’ for the old asylum code, it worked well enough, and my infix math parser worked surprisingly well, but I’d prefer something a little more stable. I’ve spent time in the past tracking down a bug that turned out to be a problem in my own script runner.

So I’ve got infrastructure going, I should have a demo available in five or six years.