Given that I do believe that AppGameKit Compresses Images that are Stored (but not in usage). as it's a very efficient approach.Īnother would be to use a Texture Atlas., assuming I understand how it's implemented in AppGameKit correctly and it's their Variation of Tiled Resources (aka Virtual Texture).Īs this should mean that you can have all of the Animation Frames Stores in essentially a "Sprite Sheet"., then you simply swap out the "Current" Sprite Image with one from the Atlas. You approach of using a 3D -> 2D Marionette Rig, where the 2D Object is broken down into it's Animating Joints then Animated via a Skeleton is certainly a great way to reduce Memory Overhead. These aren't closed source., most have libraries freely available both from Vendors, trusted 3rd Parties and open 3rd Parties.įrom an (AGK) Developer Standpoint., you're only REAL choice is to get creative. Ideally, it would be better if AppGameKit just supported Compression Formats. What is going to happen, is you'll have an overhead for this happening. In fact using Compression Techniques (Zlib) is actually going to have a noticeable impact on both performance and potentially increase Memory Utilisation.Īs backwards as that might sound., the reality is because it has to be converted back to a Raw Format for Loading then AGK's Engine will recompress behind the scenes. The idea is, to have a beautiful 2D animated game like Streets of Rage 4 or CupheadĪs strange as this is going to sound, given that AppGameKit was designed primarily for Mobile Platforms is that it COMPLETELY lacks support for Compressed Formats, at least from a Developer / User Standpoint.
tried to integrate BASIS Universal Texture compression in Tier 2 C++ last year, asked for help. Tried different ways to make one color transparent, doesn't work.Īlso playback issue with GIF files found here
So all SpriteAnimation commands don't effect them at all They also no real animations, even if they contain some. GIF animation files, don't work with any Sprite commands to make them transparent. doesn't really save memory, but could reduce the dimensions of the needed textures and result maybe in 20 to 30% less needed memory using Spritesheet with Texture Packer does work, but is still big in Memoryīest option so far. All commands now for 3D objects and not for Sprites anymore. But using FBX files results in a non-2D-game-logic. It is less expensive then Spine PRO and offers some unquie features. I also tried to convert the animations with Creature. Since Spine Pro is expensive and doesn't cost the same like in 2013, when I bought it, we also could have Dragon Bonesīut that is not supported nativly at the moment and the community work is not active, I guess which is than "pointless", you rather would use After Effects and a puppet tool So you still would have to export the deformed mesh animations as single frames. Spriter 1.x has also Mesh-deformation, but not the runtimes. The reason, why mesh deformation is a must have for an artist to create great animations with any skeleton2D program (that is also why Spriter 2.x will have it, if it ever comes out, they tease it since 2018) But a lot of work has to be done to be useable User re-player made in AppGameKit Tier 1. Spine Pro 3.8.x, bought some assets to test. Spriter animation files: we tried hart to use BrashMonkey Spriter PRO,īut it has no Skeleton-Setup-Room like Spine so it is not useable for most artists, game industry uses it not as much as SpineĪlso in AppGameKit the Texture-Atlas is not supported, so that would mess with trying to handle the texture loading well to avoid memory issues Jumping to a timestamp is not instantly because of the keyframes, which have to be decoded before eventually Works, but not for character animations,īecause we could only stream one video at a time and What I tried to reduce memory ussage so far:
0 kommentar(er)
