Ramble

I've been surprised by how much GPU power it takes to run a pixel shader over a scene. The 2-pass Gaussian blur I've been testing with pushes my laptop's GPU pretty hard (a Mobility FireGL V5200; not exactly an uber GPU). Initially I attributed the performance I was seeing to my code being inefficient, but after comparing performance with the post processing samples on the Creator's Club site (which I presume to be well formed) I don't think I'm doing anything "wrong" - I'm just a little bit brainwashed by the performance of modern CPUs.

A modern CPU (like an Intel core duo 2.0Ghz processor) can perform mathematical operations so fast as to be indistinguishable from magic. But I was forgetting that the modern GPU hasn't had as much time as the CPU to mature & advance as a technology. GPUs are fast, but they still have plenty of room to grow. In thinking my code was inefficient, in truth I was overestimating the ability of my laptop's GPU.

So the shader business is basically done. I've got a system of renderTargets built into the engine to handle arbitrary scene processing at arbitrary points in the parent/child hierarchy, which accomplishes the goal. Now all I need to do is steal my wife's 8800GTX out of her gaming rig and cram it into my laptop with a vice. Yea, that should work.

My job has me somewhat diverted from this blog, although, the stuff I'm tasked with at work is vicariously related. In my current project, a "mostly complete" version of this 2D engine is used to create an XNA application. But I'm a "regular" programmer, not a "game developer", and so the goal of this 2D engine is to create a really user-friendly, neato touch-screen interface in an attempt to delude all who use it into believing their job is not quite as boring and mundane as it is. Which is not such a bad thing to do for people, really.

This app at work likes to get real chummy with a SQL database to conduct important workly business. About a 3rd of this chummy relationship is facilitated through the DataAdapter.Fill method, mainly because I have a small ADO engine with some built in concurrency checking features etc which I'm reusing in the XNA app. What's particularly problematic about using DataAdapter.Fill with an XNA application is the fact that DataAdapter.Fill is a synchronous method: this means DataAdapter.Fill "blocks the calling thread" while it's grabbing data out of SQL. I'm no game industry veteran by any means, but I can guess blocking the main thread of a game probably ranks in the top 3 "worst design features of all time". While it just so happens I can get away with this over the LAN, deploying this app over a VPN is obviously not going to work.

So currently I'm devising an async system for DataAdapter.Fill and just basically making all the changes I have to make to get this done, it's a little extensive because I'm revamping an entire remote access system, just a little. To be honest it's something I've always known I should do, I just never had a real critical reason to do it. Kind of a hassle but certainly for the best.

But this relates partly to my 2D engine / game programming hobby in that I'll end up with a model whereby the game loop submits requests for remote data, then continues to render normally while it polls for the result to complete. I would assume this sort of model will be handy for a networking layer to a multiplayer game, like for sending requests to a game server or peer client and awaiting the response. So, mundane as it is, this sort of thing should prove reasonably useful in the future.