Well here’s an interesting thing that I haven’t gotten to the bottom of yet.

I was just recently putting together an entry for a game competition. Since I like to mess with shaders and other odd graphics card things, examples of that activity needed to be collected for the submission. Among them was a thing called the Cave Demo – basically the idea is that it was to be a game where you are exploring a procedurally generated cave, but unlike most such caves, this one has its generation parameters tweaked on the fly, causing it to shift around all crazy-like. Unfortunately, I’m not convinced that this was going to become a good game, so for the moment I’ve stopped working on it – it did result in some really cool -looking things though, at least to my tastes.

As it turns out, rendering a cave each frame is pretty easy – you render a bunch of stuff into a greyscale image, with the map representing some kind of density function, then by rendering with that image as your punchthrough texture you do a sort of automated Marching Squares thing, and bam, you’ve got a cave. You can render greyscale images into the cave buffer additively to get various effects like platforms appearing and disappearing, that kind of thing. It’s neat. From there it’s just a matter of interpreting the density map in a more complicated shader to generate a more impressive looking cave. Obviously this is a really ineffective explanation because how this was all done is maybe a blog post for another day.

Anyway, the key to this is that that’s actually not all that’s required if you want to have actual gameplay that interacts with the cave. This ever-changing cave will be needing functional collision detection, and for that, we need to get some or all of the cave buffer from video memory back into main memory so the CPU can deal with it. This can be annoying to set up, and it’s not the speediest operation in the world, but it’s doable and I did it and I was quite pleased with myself.

Fast forward to the other night, where I’m assembling a bunch of videos of stuff I’ve worked on to prove to people that I can make stuff. I fire up my trusty FRAPS and record what I presume to be some rad footage. I open it up in Media Player Classic and am confronted with something way way less rad than I was expecting. Rather than capturing what was actually on the screen, FRAPS has captured the contents of the cave buffer – a weird-looking blurry image about a quarter the size of the video frame, and wholly unsuitable for entering into a competition of any kind.

This was pretty soon before the competition was going to close, so I didn’t really have time to do much about it other than use a camera to film the footage and hope the resulting low quality doesn’t offend people too much. I did manage to figure out that the act of getting stuff back from the video memory to the main memory was what was doing me in. I discovered this using the time-honoured debugging technique of commenting that bit out and seeing if it fixed the problem. So that gives me something to go on, although it didn’t actually help at the time because of course getting rid of all the game’s collision detection kind of broke things. When I do figure out what’s really going on here and if there’s a way to get around it, I’ll update this post with more helpful advice.

In the meantime, don’t make the same mistake I did! There are things that can trip FRAPS up.