Lost   Leave a comment

This entry should have been posted a week or two ago, but it got lost in my heap of drafts. Oops!

On Sunday the 18th I had to get up far too early. 9am! On a Sunday! When I’d not gone to bed until after 3! Boo. I chucked a cup of coffee (instant, even) down my throat before going to the town centre to get cash out and buy gift tags. Then home again, and finishing off cards and put the tags on some presents.

(I didn’t tag Long Lost Cousin’s family’s presents; I figured they’d be better able to divide them up than I would.)

My uncle and sister turned up slightly earlier than expected (barely an hour after they said they would), whilst I was making breakfast and a pot of coffee (the ground coffee needed using up. A lot of coffee was drunk on Sunday, but the espresso machine wasn’t turned on once). Once they’d gone (obligation fulfilled for another year, hurrah!) I sat down and enjoyed my buttered and jammed croissants, the rest of the day to myself.

Which meant: programming for my secret project!

The first task was optimisation, albeit important optimisation. Every time I loaded a certain type of object, it would create its own copy of its vertex shader. Inefficient, of course; every instance would be the same. Worse, that means creating every object calls the DirectX high-level shader language compiler. This becomes quite noticable when you try to create a thousand objects at once, hanging the program for several seconds.

Of course, this sounds like a stupid thing to do, but there is a reason: the DirectX device can be lost in various circumstances, which takes all its resources (textures, shaders and so on) with it. If that happens they need to be re-loaded, or it’ll crash.
All the objects have functionality where the engine automatically gets them to re-load their resources when it detects the device has gone away, hence them loading their own copy. Slow, but they didn’t have to worry about losing them.

Now, running in a fixed-sized window you shouldn’t ever lose your device, so I could just create the shader and pass a pointer for the objects to use. But everything else copes with device loss, and I didn’t want to build in too many hacks (at least until deadlines were more urgent), so set about writing a shader manager into the engine.

What it does is keep a record of the shader filename and objects in a vector, and gives anything that tries to access one its index if it exists, or creates it if not. So the pointer to the shader is only ever an array access away, which is fast, so it needn’t hold on to it – meaning the engine can delete and load them as necessary.

It doesn’t (and probably should) keep a reference count of shaders, so it can’t get rid of the records for any that are no longer used by any extant objects; it keeps at least the filenames (and, in practice, everything else) until the engine itself is deleted and the vector’s emptied. It could delete the actual shader objects, if it wanted, but it doesn’t at the moment. I doubt there would ever be a case where that would use up enough memory to care about; shaders aren’t big; but regardless, it’s a bridge to jump off another day.

I’m glad I belatedly learned about STL, or that would’ve been considerably more work, or less efficient, than it was. Happily, by the end of Sunday, the code was doing half the things I wanted it to do. And there were still two days left!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s