Sorry your browser is not supported!

My game project contains a lot of animation and visual work.
And my target is the OUYA (Android 4.1, OpenGL ES 2.0) and the Raspberry Pi 3 and 4, but also Low-End-PCs

Genre of the game: Beat'm'Up Brawler like Streets of Rage 4.
Local Multiplayer, bunch of enemies, drawn backgrounds


What I tried to reduce memory ussage so far:

- using MP4 files. Works, but not for character animations,
because we could only stream one video at a time and
jumping to a timestamp is not instantly because of the keyframes, which have to be decoded before eventually

- Spriter animation files: we tried hart to use BrashMonkey Spriter PRO,
but 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
also in AppGameKit the Texture-Atlas is not supported, so that would mess with trying to handle the texture loading well to avoid memory issues

- Spine Pro 3.8.x, bought some assets to test. Missing Mesh-deformation. Also Spine V. 3.8.x is not nativly supported (http://de.esotericsoftware.com/spine-runtimes,
tried https://forum.thegamecreators.com/thread/221085
user re-player made in AppGameKit Tier 1. But a lot of work has to be done to be useable

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)
Spriter 1.x has also Mesh-deformation, but not the runtimes. So you still would have to export the deformed mesh animations as single frames. which is than "pointless", you rather would use After Effects and a puppet tool

Spriter 2, mesh-deformation

don't want to put more art videos here, you could look up, what Spine PRO or DragonBones PRO (also Creature, and maybe Spriter 2) can do with skeleton-animation + mesh-deformation.
also the puppet tool from After Effets use a technique like that. Mostly used for flag waving, capes, or smoke deformation. But also for 3D effects and face turning.


- Since Spine Pro is expensive and doesn't cost the same like in 2013, when I bought it, we also could have Dragon Bones
but that is not supported nativly at the moment and the community work is not active, I guess

- I also tried to convert the animations with creature.kestrelmoon.com Creature. It is less expensive then Spine PRO and offers some unquie features.
It also could produce FBX files. With simple animations that works. But using FBX files results in a non-2D-game-logic. All commands now for 3D objects and not for Sprites anymore.

- using Spritesheet with Texture Packer does work, but is still big in Memory
best option so far. doesn't really save memory, but could reduce the dimensions of the needed textures and result maybe in 20 to 30% less needed memory

- GIF animation files, don't work with any Sprite commands to make them transparent.
They also no real animations, even if they contain some. So all SpriteAnimation commands don't effect them at all
tried different ways to make one color transparent, doesn't work.
Found also a mistake in the help file: https://www.appgamekit.com/documentation/Reference/Image/SetImageTransparentColor.htm
Others tried it as well https://forum.thegamecreators.com/thread/225817
also playback issue with GIF files found here https://forum.thegamecreators.com/thread/226868

- tried to integrate BASIS Universal Texture compression in Tier 2 C++ last year, asked for help, ... (https://github.com/BinomialLLC/basis_universal)
2017: ATSC https://forum.thegamecreators.com/thread/220195
2018/2019: BASIS https://forum.thegamecreators.com/thread/223023
2019, C++: https://forum.thegamecreators.com/thread/225169

The idea is, to have a beautiful 2D animated game like Streets of Rage 4 or Cuphead


I am trying to realize indie games that not only have static images or "retro style" pixel graphics.

So here are the files, I tried to get working somehow

Gif: green background, GifT: Transparent, GifB: Black, gFELal.gif: Santa
My Spine try I made with my Drone_2020, it didn't load in AppGameKit nativly, and the community Spine 3.8.-JSON loader had visual artefacts.

As 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.
In fact using Compression Techniques (Zlib) is actually going to have a noticeable impact on both performance and potentially increase Memory Utilisation.

As 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.
What is going to happen, is you'll have an overhead for this happening.

Ideally, it would be better if AppGameKit just supported Compression Formats.
Such-as BC5, BC7, NV1, ATC, etc.
These aren't closed source., most have libraries freely available both from Vendors, trusted 3rd Parties and open 3rd Parties.

•

From an (AGK) Developer Standpoint., you're only REAL choice is to get creative.
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... as it's a very efficient approach.

Another 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).
As 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.
Given that I do believe that AppGameKit Compresses Images that are Stored (but not in usage) ... this should be a more efficient way of simply doing Classic 2D Animation.

Cuphead for example to support 4K and the "Hand Drawn" Style., actually makes very heavy usage of Tiled Resources.
It's an excellent Feature of Modern Graphics APIs., such-as DirectX 11 and OpenGL 4.x., but I'm not sure that AppGameKit fully supports this., as it doesn't even support the Full OpenGL 2.0 Specification; rather just the OpenGL ES 1.1 Subset.
As noted, I THINK that Texture Atlas' are a built-in Exception; but I'm not sure, as I don't tend to work with 2D... and I work with Mobile Platforms even less.

Another approach would be Frame Interpolation., where in you have Fewer Animation Frames; and you use a 3rd Party Library to Generate the Frames in-between.
This was actually a common approach between 95 - 05, not just for 2D but 3D as well... because it would allow you to have only a handful of Keyframes that could then be "Fleshed Out" In-Flight.

•

A lot of this would be unnecessary IF AppGameKit actually supported Vulkan properly., rather than merely having a Vulkan Interface for OpenGL ES 1.1
Personally I don't understand why TGC didn't stagger the Release Features.
It would've made more sense for:

AppGameKit v1 ("Classic") to support OpenGL ES 1.1
AppGameKit v2 ("Standrd") to support OpenGL ES 3.0
AppGameKit v3 ("Studio") to support Vulkan 1.0

And simply maintain all three., to provide said "Feature" Levels.

@Raven
https://github.com/BinomialLLC/basis_universal

That is what I was talking about, now for years. All engines support ETC1 / DXT or PVRTC in some way. I understan, while HTML5 and all mobile GPUs are on different support level and they need somehow a fallback, ...
but as a developer I want to choose, if I care about platforms that don't support any of these features.

The OUYA e.g has a Tegra 3 SoC from 2012. TWO TOUSEND TWELVE ...
and the OUYA nearly supports directX 9.x and OpenGL ES 2.0 with ETC1, but also DXT texture compression.
With BASIS transcoding it would be possible for AppGameKit to support multiple texture formats including 32 Bit uncompressed RGBA8888
we could have JPEG like small file sizes, but also a memory texture compression with about 8:1, wo a 4K x 4K texture would not use 64 MB uncompressed in memory, but only 8 MB.
Also Vulkan and 3D apps would profit from that. If you have 8 stages of textures with all kinds of textures like diffuse, normal, specular, and so on ...

I understand, why Game Maker Studio 1.x didn't supported MP4 playback back than, I also understud, why Game Maker Studio doesn't promote 3D things ...
but App Game Kit wanted to be the better Game Creation tool, I thought.

Game Maker Studio does not support JPEG and didn't supported MP3 and also had no support for Spriter. But they made some good moves with adding Flash Support, even when flash was dead, way? Because a SWF (ShockWaveFlash file) can have JPEGs and transparency and animations in it.
And they integrated Spine support. They knew, they needed all things great in 2D. So they have done it so great, that Unity3D and Unreal had to also integrate better 2D support. And I guess, Unity even changed its name.

So yeah, we have MP4 video playback, we have OGG support. That is great.

But for doing bigger projects with other companies or artists or in a team, it is complecated with only propper slow loading PNG support (or no transparency JPEG)

It is possible to make a game without that. But I guess, it would look like it is made in the 90's but for mobile. Even some Windows 95 games supported DirectX with compressed textures.
Or could playback some music containers like MOD / 669 / S3M / IT ..., I understand, that often game engines need something like BASS or FMOD and TGC wants not licences attached to games made with AGK.

That is great. That could be also the problem with Spine playback, the source is free to integrate, but if you would use it as a AppGameKit game developer, you would need to have a Spine license.
But they restrict themself, if no company could use there tools for bigger projects.

So I guess, I can create my animations and drawings and so on, and have to see, how I can get the animations later into the "game". Small file size, small memory foodprint are key, I guess. For performance and for download speeds.
On Google Play there was a long time a 100 MB per App limit. And not every game has to be 150 GBytes like they tend to be with Unreal or other 3D things these days, I guess

------------ from the BASIS GitHub -------------
Basis Universal Supercompressed GPU Texture Codec

Basis Universal is a "supercompressed" GPU texture compression system that outputs a highly compressed intermediate file format (.basis) that can be quickly transcoded to a very wide variety of GPU compressed and uncompressed pixel formats: ASTC 4x4 L/LA/RGB/RGBA, PVRTC1 4bpp RGB/RGBA, PVRTC2 RGB/RGBA, BC7 mode 6 RGB, BC7 mode 5 RGB/RGBA, BC1-5 RGB/RGBA/X/XY, ETC1 RGB, ETC2 RGBA, ATC RGB/RGBA, ETC2 EAC R11 and RG11, FXT1 RGB, and uncompressed raster image formats 8888/565/4444.

What I am trying to do the next month, maybe years:




To create all assets needed for something like that:




App Game Kit already has Tweens, and Box2D physics, and Sprite collisions ... it offers a lot. It also understands JSON somehow.
It also supports some blending modes. And it has a fast 2D Engine, where scaling and rotating is possible and also scrolling and in-out-zooming.

I can load PSD layers into App Game Kit with the help of a automated Script
https://github.com/EsotericSoftware/spine-scripts

Can read the JSON and PNG files and or JPEG files and also make instances and set there Blending modes.
Could also swop out PhotoShop-Layernames for some animations or enhance them via AppGameKit particle effects.

So I guess, with the combination of some of these skeleton2D tools, and support in AppGameKit and with the help of texture compression, it is possible to archieve great visual 2.5D results.

My Photoshop and the result in App Game Kit

from the Streets of Rage 4 video.

As I said., AppGameKit DOES NOT Support Hardware Compression... or at least that is to say it doesn't support any Formats that in turn support such.
Sure, you have PNG, GIF, JPEG... but these are Software Solutions., meaning they merely take up less Storage Space; once they're processed, well they all become identical 32bit RAW Images.

This is wholly different from say using a Direct Draw Surface (DDS) Texture in Dark BASIC Professional, where it could be stored in BC 1 - 5 Formats.
The Texture (Surface) would be held in it's Hardware Compressed Format, unless converted to be used in a Memblock; unfortunately a problem doing that is that Image Created from Memblocks would use A8R8G8B8 instead of BC1/BC3/BC5.
Though keep in mind, unlike AppGameKit which directly restricts you to R8G8B8A8., the DBP Memblocks were more or less just DirectX Buffers; so you could change the format and manually handle the Compression approach.

I've in the past attempted to work with the limited cImage Class (From the AppGameKit SDK) to add support for other Image Formats, which do support various things like Cube Maps, Volume Maps, Texture Arrays, MipMapping and Compression.
The problem is that in my tests... essentially whatever I tried to load would simply be overwritten or discarded in favour of something the AppGameKit Engine itself was doing; or worse said attribute of the class would be inaccessible for writing to.

Unless TGC changes this, or expands support themselves. The reality is, you simply won't be able to take advantage of Hardware Compression Formats., at least not in AGK.
There are no issues adding support for such for Dark BASIC Professional however.