Sunday, January 29, 2012

IO, Memory, and Screenshot fun

This week was all about my system for managing the inputs and outputs from objects. I also set up a better method for managing the rendering of my sprocket objects. Sprockets are my engines components, for those unfamiliar with a component based architecture it favors building up objects with composition rather than a deep hierarchical chain. For rendering I've added a new object called a scene collector. The job of the scene collector is to collect any model objects from the components so that they can be checked for culling, assigned to the appropriate views, and any other scene management by the game. I also added a new Floating Text component which I used for testing out my node editor for EnergonIO( The name for my input/output system ). Here's a screenshot of the current node editor showing a connection between 3 different objects.


In order to test out my floating text I added a ToString output to my timer sprocket. This let me hook up my timer to my floating text so that I could see a change everytime the timer ticked by. This whole linkage also gave me a chance to test out my trigger volumes. So I hooked up the OnEnter of my trigger volume to the TriggerStart on the timer. Here's a shot of the player having just passed through the trigger volume, shown in the image as a (T) icon with a box. It triggered the timer which then sent its output to the floating text which is displaying the current timer from the timer.


One of the big problems I came across after testing my IO was that there wasn't a mechanism to properly handle what happens when an object gets despawned. This led to crashes because the trigger volume would try to call the onStart input of the timer which had already been despawned. So this meant I had to do something to disconnect the output from the input on the input destruction. Up until this point my IO system had been one way, the outputs knew about the inputs, but the inputs had no idea what output they belonged to. This wasn't a big issue I just added a register function to the input so the output could register itself with the input when it was hooking up. This way when the object the input belongs to gets despawned the input can tell the output that it no longer exists.
Another big change to the engine this week was the addition of variableInfos which are specific to protoforms. Protoforms are what I call the generic data structure which stores the creation information for my sprocket objects. I used these new protoform specific variableInfo's for storing the instance name for a protoform so that I could edit them in the protoform editor window. Here's a shot of the protoform editor window. Don't mind the kirby test art, he's going to be replaced by a penguin with a rocket pack.




The last thing I worked on for the week was a screenshot dumper for this blog. It's hooked up to F2, so whenever F2 gets pressed a screenshot gets dumped to the root folder composed of a prefix and the current time so that it always has a unique name. There seems to be some kind of issue with it though, it almost looks like it's off by a pixel or something. Some of the lines look thinner in the screen shots. Maybe an odd problem with the multisampling?

No comments:

Post a Comment