Solkraft Engine

Entities which require collision boxes/circles (Entities with Physics Property) now have a editor specific for just that.

Adding, removing or reshaping collisions boxes/circles

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.

Update on the SolKraft Level editor.

The Property Viewer was was the latest feature added to it.

It currently reads from an XML file, displays the data (which can be edited) and saves to another XML file.

  The implementation of Box2D is going along smoothly.

Physics Demo will show of the current state of the implementation

Today we have finished our small graphics demo program that we will be using in the presentation of milestone two. The purpose of this program was to asses how well the libraries that we chose to use for graphical functionality in the engine would interact with each other and if they would full fill the functionality that we require ow them.

The result of the testing have been very positive and we have settled on these external libraries:

GLFW-A lightweight utility library for OpenGL that we use for window management and input handling.

GLEW-An extensions library for OpenGL in windows.

GLM-A math library.

SOIL-A lightweight image handling library with functionality to load an image directly to a OpenGL texture.

Besides graphics we also added some very basic input for the little car you can see on the image to move.