I thought I'd better post at least once more this year; and to liven things up a bit it's even Space Crusade related!
Well... not specifically Crusade related but building in the right direction. I'm still working on my reference counting memory manager though it is a little bit more now.
The short of it is that each object in the scene graph (provided by the memory manager) knows it's class and can query fields and methods on it. These can either be used directly from C++ or from a sort of scriptless language. C commands can be chained together to perform simple tasks without the task being written at compile time. I've only used this for image filtering but the possibilities are (as they say) endless.
Below is a screen shot of (a part of) a smart objects header. Notice that a smart object knows all the objects which reference it: pcFroms.
Most objects are rarely referenced by more than one or two objects and if this is the case then additional memory does NOT need to be allocated to track those references.
If more than four objects reference 'this' object then an array of pointers is allocated.
These reverse references are important because they can be used to calculate a path back to the root object. If a path cannot be found then the object is not forward referenced from any other object and it can be deleted.
Most importantly each object knows it's distance from the root node (as shown in the screen shot below) which makes finding a path to the root trivial.
In fact knowing the distance to the root enables whole object trees to be discared in better than O(log(n)) time - where n is the number of objects in the scene. This is - I think - faster than any garbage collector and because there is no garbage collection phase there are no nasty program pauses.
The thing I like most about this scheme of memory management is that when the last object referencing an object tree is deallocated then the entire tree can be deallocated. Importantly this means that the deallocating thread can deallocate the tree and the program can remain utterly single threaded!
Anyway, that's enough technical stuff... I've also posted a picture of my snazzy new UPS. Those still living in SA will know why a UPS is important now :(
Interestlingly it's only rated to 600 Watts but it's handling two 300W power supplies and two 100W monitors at half it's maximum rating. I was pleasantly surprised ;)
And that's enough of that.
Later!
Well... not specifically Crusade related but building in the right direction. I'm still working on my reference counting memory manager though it is a little bit more now.
The short of it is that each object in the scene graph (provided by the memory manager) knows it's class and can query fields and methods on it. These can either be used directly from C++ or from a sort of scriptless language. C commands can be chained together to perform simple tasks without the task being written at compile time. I've only used this for image filtering but the possibilities are (as they say) endless.
Below is a screen shot of (a part of) a smart objects header. Notice that a smart object knows all the objects which reference it: pcFroms.
Most objects are rarely referenced by more than one or two objects and if this is the case then additional memory does NOT need to be allocated to track those references.
If more than four objects reference 'this' object then an array of pointers is allocated.
These reverse references are important because they can be used to calculate a path back to the root object. If a path cannot be found then the object is not forward referenced from any other object and it can be deleted.
Most importantly each object knows it's distance from the root node (as shown in the screen shot below) which makes finding a path to the root trivial.
In fact knowing the distance to the root enables whole object trees to be discared in better than O(log(n)) time - where n is the number of objects in the scene. This is - I think - faster than any garbage collector and because there is no garbage collection phase there are no nasty program pauses.
The thing I like most about this scheme of memory management is that when the last object referencing an object tree is deallocated then the entire tree can be deallocated. Importantly this means that the deallocating thread can deallocate the tree and the program can remain utterly single threaded!
Anyway, that's enough technical stuff... I've also posted a picture of my snazzy new UPS. Those still living in SA will know why a UPS is important now :(
Interestlingly it's only rated to 600 Watts but it's handling two 300W power supplies and two 100W monitors at half it's maximum rating. I was pleasantly surprised ;)
And that's enough of that.
Later!
posted by Andrew at
5:10 am
|
3 comments
