More animiation WiP, almost draw an animation state properly
As it turned out, this may have been a little too optimistic of a message. It does look better though:
Commit 8f113c93
Tag: c++
Commit f9cd3f9c
make blend indices and weights available in the model vertex shader
This brings the animation data to the renderer for the first time. Let’s just say there is some room for improvement:
Commit 984b2ed8
Further flesh out the model/animation loading
This adds the Transformation class which is mostly a wrapper around GLM operations at this point.
Commit 406fbe7c
First iteration of the animation loading/parsing, WiP
This also loads the bone and and frame data, as well as the first iteration of generating transformation matrices out of them.
Please note that none of that data is currently being used by the renderer yet.
Commit 020afb17
Make the model loader work with models that contain animations (WiP). Remove redundant code.
This simply loads some of the animation data (e.g. blend weights), but does not do anything with it yet.
Commit a37eea7d
Replace wavefront models (obj) with IQM ones
Re-export all the existing models in the new format.
Commit acb9e9a0
Add support for the IQM model format (WiP)
This is the beginning of the long journey to get animations going, which the model format used so far does not support at all. Say hello to IQM, the Inter Quake Model Format.
Before animations will work though, make sure to support rendering the models in their static/default state, which is exactly what this commit does.
Check out what it looked like right before, when it was almost working:
Commit 96125d39
Add bed object (without functionality yet)
Comes as advertised, it does not do anything yet, but it looks nice:
Commit aba39e82
– add new job messaging mechanism that allows the job to return messages to the object manager
– add first message type that allows objects to transform themselves
– fix bug in the renderer that crashed when creating and removing the number of models resulting in the same number
– added more gameplay logic (starvation and death)
This is rather substantial as it adds the notion of “job messages”, that allows Python scripts to make changes asynchronously. The only message type currently supported is the “change object” message, which essentially transforms the object sending the message. This change needs to happen asynchronously for obvious reasons, as replacing the object requires a complete removal of the existing object, including the script instance, before it gets replaced by a completely new object in the same location.
On a more superficial levels, this adds a bit more game play, if you want to call it that. Yay!
Commit b4e17439
– add the gravestone object
– decrease the HP if there is no food left
– slowly increase the HP if there is food left
– add new object category so as to not list certain objects in the menu
Does exactly that. Also, finally there is some sort of consequence to not go with the one existing game play element: make sure to feed your characters!