So it looks like Baywords is back up, which means all my old blog entries are viewable again, but now I gotta decide which blog to continue using. Unfortunately, Baywords doesn’t support importing or exporting blog entries, so I can’t merge them into one either way. Lame. Thanks for nothing, Baywords.

I guess I could manually copy each entry over since there were only a handful of them, anyway, but then they’d be all out of order and stuff and I’d have to manually update their timestamps. Rarghrarghrargh.

EDIT! I copied all my old entries over by hand. The image refs still all point to Baywords, which is sketch, but whatevs.

I posted this over on the TIGForums, but I thought it might be worth posting here, too. And if not, well at least I updated my devblog ever.

Ever have a time when a problem that you’ve assumed is difficult turns out to be so simple you feel stupid for not attempting to solve it sooner?

The problem was this: Given a constant gravity speed and a desired jump height (and assuming standard parabolic jump physics), compute an initial jump speed that will reach the desired height. For some reason this always seemed scary and I just never bothered to solve it. Instead, I’d just screw around with jump speeds until I got something that was close enough.

Turns out it’s actually pretty simple to solve (and if I had looked, it’s all over the internets, too). Set up the equation for the parabola, take its derivative to find the velocity over time, find the time where the velocity is zero (since this will be the peak of the jump), plug this back into the parabolic equation, and solve for the velocity. If anyone’s curious about the solution, it’s just:

// In arbitrary units, and assuming Gravity is a positive value
JumpSpeed = sqrt(2.0f * Gravity * JumpHeight);

Heh.

Here’s a reference screenshot of a Kirby game:

Here’s that same shot running through this CRT emulator I’ve been working on:

Now I just need a game to show off this tech.

There’s a new competition running on TIGSource at the moment. The theme is “A Game By Its Cover” — contestants find an image of a box or cart for a fictional game and develop an actual game inspired by it.

I’m running with this madness (found on Famicase 2010):

I’ve been wanting to put together some tech for displaying 2D sprite graphics with Direct3D, and this should get me moving on that.

I spent a few hours tonight and got this hotness working:

Yeah, so it doesn’t look like much, but it proves the tech. I’m just drawing directly to a dynamic texture each frame. This should give me a decent compromise between the power of working directly at the pixel level (as opposed to rendering sprites as quads) and the ability to play around with post-processing effects in a shader to get some old school scan lines and whatnot. I’m a little worried about the perf costs of locking and unlocking a texture every frame, but I’ll cross that bridge once I come to it. At the moment, I think the cost of blitting pixels to the locked buffer is going to be the tighter bottleneck.

I’ll be posting tech-related progress notes here and game-related notes on the forum entry over the next few weeks. Unless I forget.

After probably about a week of sleepless nights, I finally found an explanation for the input lag that I’m seeing in fullscreen with vsync enabled.

http://www.ogre3d.org/forums/viewtopic.php?f=5&t=50486

Apparently my CPU is idle a lot of the time, so I end up queueing up GPU commands for successive frames too far in advance. Or something. To be honest, that explanation doesn’t entirely make sense to me (for instance, why would it only affect fullscreen mode?), but if I just spin for a little while each frame, the lag goes away. Hrm.

For the past few nights, I’ve been banging my head against the wall trying to solve this problem. When I run in fullscreen mode with vsync enabled, I get a small but noticeable amount of input lag. (Well, there’s some latency on everything, really, but input is where it manifests itself most obviously.)

Tonight, I discovered that if I never set D3DPRESENT_PARAMETERS::Windowed to FALSE and just manually handle changing the display mode, moving the window, changing its style, and making it topmost, I get no input lag. Let Direct3D manage that stuff for me, and BAM, input lag.

I’m not really comfortable checking in this change. I don’t want to have to manage this stuff myself. It should just work to let D3D do it, and the fact that it isn’t working suggests to me that something else is wrong somewhere, but what?

Using a right-handed coordinate system is a totally valid option (and honestly, the mathematician in me would say, the only correct option). But if you’re using Direct3D, you shouldn’t ever use one because Direct3D will hate you and make your life miserable.

I just realized today that cube map samplers automatically assume that your coordinates are left-handed, and so far, my searching has turned up no information regarding any way to change this. That means that you’ll either need to waste precious instructions inverting coordinates in your shader, or else you’ll need to author your content to fit this assumption. The latter is clearly the better choice, but it complicates matters when your content is generated from your engine. Let’s say you want to render out the six sides of a cube map every frame to do some real-time reflections. Well, if you’re using a right-handed coordinate system, you’re going to have to mirror your view matrix, which means also inverting the winding order of your primitives. And that’s just a pain.

I added a bug report form to my engine. This can be called up from the console at any time, and it can also be displayed any time an unhandled exception occurs. Of course, this relies on user vigilance to keep me informed of outstanding issues, so to be safe, I also automatically generate and upload a minidump file when unhandled exceptions occur. The downside is that this means I have to compile with debug information, so there’s some non-trivial perf loss there, but if it helps me catch bugs, it’s worth it. I can always turn off these features in later builds (once any major bugs have presumably been fixed), and thanks to my handy timestamping feature, users will be informed of the new version.

Yay techmology!