I was thinking of adding animation to a game as an intro using GIF at first, but then I noticed that it doesn't look well. Searching on Google reveals that there used to be animated PNG, but there haven't been any news about it since 2011.

Are there any updates about APNG? Are we ever going to stay stuck to GIF? Just pondering.

Not sure about APNG but the new kid on the block webP supports animations.

https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp

Maybe you were exaggerating with 2011 ... the project on Kickstarter:

https://www.kickstarter.com/projects/374397522/apngasm-foss-animated-png-tools-and-apng-standardi/posts

at least has a Feb. 2014 update and they sound confident that Browsers will support the format ...

Due to work on apngasm new patches are going out to browsers and hopefully we'll be seeing full APNG support not just in FireFox but also naively in WebKit browsers and Chrome.

naively ...

Probably that is still no guaranty that the format will be widespread ... ever, but it is something newer than 2011 with some people interested in progress ...

(Not too fond of the name, though ...)

... the tools might already be usable for your purposes!?

No, I am just pondering on newer animation image standards.

some of this is what led me initially to creating a lot of my "BTIC" stuff:

GIF isn't very good IMO (256 colors is not so good, weak compression), though does have browser support (may be relevant);

M-JPEG was ok, and I had extended it with more features, but still was moderately expensive to decode, as well as steep size/quality issues;

APNG and similar didn't seem to be catching on, and file-sizes would likely be fairly steep for longer sequences (video-like use-cases);

conventional video codecs have a fairly high decoding overhead and don't really support a feature-set which is optimal for animated textures (no native support for alpha channels, though VP8/WebM supports an alpha channel at the expense of decoding speed);

...

so, I created a format (*1) mostly specialized for animated textures, focusing initially on decoding directly to DXT1/DXT5, but later expanded to try to get better quality from BC7 and BC6H while keeping DXTn. in contrast, typical video codecs are designed primarily for YUV or RGB output, and decoding to DXTn or BC7 would require an explicit re-encoding stage, with considerable speed cost, or shimming in a block-transcoder at a lower level, which adds hair and may only be a modest gain over transcoding indirectly from YUV output. a secondary cost is that with these formats it may require some analysis to encode into DXTn or BCn blocks, limiting quality and harming decode speed.

interestingly, it also works passably as a video codec (*2), and seems to work pretty well for real-time video capture (lower CPU cost and smaller files than Lagarith, better quality and smaller files than MS-CRAM, ...).

typically, I am using AVI as the container, basically just using AVIs as textures in my engine (which may or may not have sound, if sound is present it is streamed into the engine's mixer and may be used as a sound-source for mixer channels, where the name of the AVI is given as the sound-effect name). (it can also be used in other programs via a VfW driver).

so, sort-of partway between being an animated GIF, an AVI, and a DDS.

though, it hasn't really caught on in my case for static textures, as its BC7 output quality is still "weak" vs other options (a slow-encoder to BC7, which can support partitioned-blocks / ...), prompting a strategy of basically sticking with a JPEG-variant, and caching converted textures in a Deflate-compressed DDS-like format (errm, actually a lazy/hacked BMP variant with BC7 image data...). TBD: better solution.

*1: actually, I iterated over a bunch of different designs, but one of them held up a lot better in-general, being able to have high decode speeds, being passable in other areas, and being hacked on to improve its image quality. the basic design is descended from Apple RPZA (AKA: QuickTime Video), but has since diverged considerably (it is now essentially a state-machine with the available block-formats depending on the current state).

*2: size/quality is worse than XviD or H264, but compares favorably with more conventional (but more closely related) VQ video formats (such as RoQ, RPZA, or Cinepak). mostly this is due to a mix of encoder-fiddly, supporting various schemes to encode blocks, and the use of an LZ77+Huffman backend (modest speed cost, but significant size/quality improvements over raw bytes).

decode speed is somewhat higher than more conventional codecs.

so, yeah, good for animated textures, and for a number of concurrent video streams not killing the framefrate...

nevermind if on/off working on all this ate up around 6 months in my case...

Are you doing this for a HTML/browser game, or something else?

Are you doing this for a HTML/browser game, or something else?

Something else.