Summer of Code T-Shirt Arrives

· by Steve · Read in about 3 min · (572 Words)

Shame it’s not summer anymore of course 😉 But it’s nice to have a momento of the Summer of Code anyway. Over the weekend a mentor summit was held at Google HQ, which I unfortunately couldn’t attend because of my existing bookings and the fact that it takes in excess of 14 hours each way. Still, 2 representatives from the Ogre project were due to go (reimpell and xavier), hope to hear from them how it went soon.

I’m still picking through code resolving threading issues, over the weekend it was mainly the scripting classes so that resource groups could be initialised in a background thread. Since some of the parser classes tend to keep some parse state, and I didn’t want to lock on this state since it’s completely contained and independent, it required using what Java would call a ThreadLocal, ie thread-specific storage such that each thread has its own personal instances of the parser classes. boost::thread_specific_ptr stepped into the role nicely and some macro trickery makes it all transparent (and not dependent on Boost, even though it’s a super lib) if you’re not using threading. In some cases I managed to eliminate the required state so I didn’t have to use this, but in some cases it’s unavoidable.

Pretty soon I’ll have finished all the low-level safety stuff and can concentrate on the higher level functionality. It’s mostly there already but I’m wondering whether I need to include some functionality to make Resource users tolerant of background loaded resources. I mean, most of the time if you’re loading resources in the background, it’s because you want to create new objects / world geometry chunks which are dependent on them, and you’ll typically queue the load (in a ‘choke point’ if possible) and wait for the background resource ticket to come back as complete before triggering the creation of whatever dependent instances you wanted. I suppose it’s possible that in a less organised system you might want to try to create the dependent objects up-front, and detect resources which are marked as delayed loaded and do something ‘safe’ until the resources are loaded. The issue comes when the resources don’t actually exist at all yet, because it gets a bit messy - you have to find somewhere to hang the flag that says the resource is delay loaded. Whilst originally I was including this kind of approach in the design, it’s got a lot of gotchas and I’m wondering if it’s actually that useful anyway. People who are going to be using background loading are on the more ‘serious’ end of the user community and should probably know better - that they need to organise the background loading & unloading of resources carefully.

However, it would probably be useful to have some kind of policy / placeholder class which can deal with some common requirements, like being a placeholder for one or more instances of something (perhaps a billboard, a simple geometric shape, etc), then when at a certain distance, trigger a load operation and call back something when done to create the more complex resource, to automate the more typical task of swapping in resources based on distance. Although, again this works better in groups (of objects and resources) rather than individually, especially since many resources are shared among many objects - you only need one thing managing the loading. More thought needed, suggestions from potential users are welcome.