izzy Posts: 23 Joined: 1st Apr, 2015 9:15pm Progress Sharing #37 Sat 7th Apr, 2018 8:35am By izzy We have worked a lot on animations. First of all, animations loading was awfully slow. Loading one complex creature with lot of animations and frames took 4-5 sec.Â Bearing in mind that each level has at least 3 different monsters, this was a big problem. Of course slow loading time was only on first monster encounter. After that creatures are stored in memory, and "loading time"Â ceases to exist. But from development point of view, it is annoying. I start the game for tens of times a day.So what causes the problem? The problem was that there is one textual file that describes each frame with various data like: location on texture atlas, frame ID etc. Reading textual files and parsing them was never a fast task. Actually, problem had several parts: All animations are stored in atlas textures. They are pow2 textures, and since I didn't wanted to store animations in one large textures, I have stored them in several 1024x1024 or 2048x20248 resolution textures (taking into account older cards here). Each monster have at least two atlas textures, and at mostly nine. Animation frames were stored in textual files for one animation to load I needed from 2 to 20 files to open and process Another problem was that sometimes animation was broken. For example while idle animation was played, some frames played were from absolutely different animation. This appeared once in awhile, and rarely enough to put it at the end of my bug list. I just presumed that it has to do something with component part of animation or bad export/processing of animation frames. Solution was to create one new graphical format with all data stored in one file. First of all I needed to created one nice Monster Viewer app for testing purposes. Secondly, I have redesigned component part of animation. Until now, all frames were separated components and all textures were also separated components. Now I use one component/creature. Component stores all necessary data, so now I need to fetch one component instead of thousands. This will bring some small general speedup in processing. Since I have already created one propriety format long time ago I decided to reuse it. With small fixes it was ready pretty fast. First test were fantastic. Instead 6sec load I have now loading time of 0.2sec. Created one batch script and encoded all files. Again, instead 300MB of data I am using now 80MB. I am not sure did I fixed broken animation, will see it during tests. During conversion I found a LOT of problems. Badly spelled animations, missing animations, unnecessary animations. Everything is fixed now. Unfortunately I didn't had a time to put all those changes into the game. That task will wait for the next week. Animations All animation of one creature are stored in only one file. Files are loading 1000% faster. Appropriate attack animation is triggered for every weapon. You slash with long sword, bash with hammers, pierce with spears (but it is possible to pierce with hammer which looks stupid, or one hand bash with two handed sword which looks awesome :) ) Enemies are now facing toward target of their attack bugfix: when enemy died, dying animation was played twice (All monsters die twice, sounds as some bad pulp fiction title) bugfix: when player died, he/she was stripped of cloth, and died naked. Now he/she dies dressed. New enemy: Dire Wolf New enemy: Death Wolf Redesigned enemy: Hell Hound Finished enemy: Bee Queen New animation: Spider's vicious bite New animation: Spider's web spit Finished enemy: Caustic bloat Finished enemy: Explosive bloat Finished enemy: Pit bloat Finished enemy: Snake With these enemies finished, we have: 98.15% enemies finished for first 5 levels. 77.29% enemies finished for next 5 levels. 28.9% enemies finished for levels range: 10-15. 5.6% enemies finished for levels range 15+. This is 52% enemy graphic done. While I have all models, I miss a lot of animation for them. Quality Changes A LOT of refactoring. For some strange reason my player class was named Denizen. For last 3 years. Now, when the class was stripped from it's exotic name, it is renamed to Player. Optimizing OpenGL. There were still some left overs of deprecated gl calls. Lot of code was moved to use glm. Reply You are not signed in. You need to sign in if you want to post.