Recent Comments

Archives

Categories

Meta

Links

Since the rendering part of the engine was more or less done (or at least done enough for this) at the beginning of the week we begun writing the AnimatedProperty class. It is a property that the user attaches to an entity that the user wants to be animated.

It functions by switching out the texture handle of the attached entity, making the render manager render the entity using a different image. It does this a regular intervals defined by the user in milliseconds. To load an animation into the engine the user has to specify the directory in which the animation’s frames are located, how many frames the animation contains and what filetype the images are saved in. When the images are loaded into the engine the texture handles are saved into a large std::vector containing all frames for all animations for that entity. The resulting start and stop indexes are saved into a custom “Animation” struct. Then the user can go ahead and send a “PlayAnimation” message to the entity and it will start animating whatever animation is set as “current animation”. The property will iterate through the frames std::vector between the indexes saved in the relevant Animation struct.

Implementing this was a smooth process with little issues. Since we wanted the animation system to be based on time instead of frame rate we had to make use of the EngineTimer class which we had written before. As we were testing we discovered some strange bugs in the EngineTimer class, but they were swiftly ironed out and AnimatedProperty is now as good as done, apart from it’s message system interface, which is placeholder until we have actually implemented the message system.

Two frames in our test environment, running on our engine. One press of the “D” key makes the entity move a step to the right and causes the animation to play. Input, rendering and animation are all done by the engine.

As for the StateManager and StateBase classes, we started implementing them a week or so ago, but had to stop about halfway through because the rest depended on other parts of the engine which were far from done at that time. This was a bit of a planning slip on our part and we took note to base our planning a bit more around dependencies in the future than we previously have. We swapped around a bit in the time-plan between the state-classes and a couple of other classes, but the rest of the plan remains unchanged.

All in all the engine is coming along nicely and things are going mostly according to plan.