ZDoom

I said before: texture animations on sprites cause so many secondary problems that I won't consider them.

At bare minimum if nothing else in case APNG isn't worth implementing, it could be recommended to use it as one way to see how animation could play out and that being timing of each frame.

Though APNG could be taken as an example for GZDoom to have dedicated animated PNG format compatible with GZDoom that has own provisions along compiler and decompiler instead of trying to adapt GZDoom to APNG.

In case that several images are expected to have same frame time / delay then reference frame time once and proceed evenly play out each frame.

Another frame time / delay reference in case there are additional images with different frame time / delay value.

An intepreter implemented into GZDoom core engine and this kind of custom format has bare minimum instead of APNG that has frame time / delay for each image despite if all had same frame time / delay.

66ms image image image image 99ms image image image 122ms image image image image (random example)

So when an NPC enter X state then it flips through images for that X state until Y state takes effect then images of Y are flipped through in a loop until another action is taken and so forth.

Instead of having 4 lines of code for one action that references that action each time for each frame of animation the frame time / delay along image allocated for each frame of animation.

For GZDoom game engine to be aware of such format, perhaps have extension of DAPNG with addition of DA being Doom Animated.

The only way I could see APNG being useful is if GZDoom could automatically extract the animation sequence and timing info from it automatically. If you still need to define the individual frame info with [wiki]ANIMDEFS[/wiki] or something, it would essentially just be a harder-to-use archive of PNGs that you have to do more work with (compiling the APNG itself together with its frame timing info, then define the animation's frame timing info for GZDoom). If GZDoom could automatically animate it given the file's animation info, I could probably see some use there with making the animation in tools handling the format and GZDoom doing The Right Thing with it automatically, but if not I don't see the benefit of a single APNG vs a directory of PNGs as the latter will be easier to handle during development, less error prone (updating the APNG in your editor but neglecting ANIMDEFS for GZDoom, for example), and no big downsides for the final product.

[quote="Graf Zahl"]Animated textures run at screen refresh rate, you can specify fractional tics.[/quote]
In [wiki]ANIMDEFS[/wiki]? Interesting.

Tics aren't very intuitive, though, so it'd be nice to be able to use milliseconds. E.g. instead of "pic 1 tics 5", "pic 1 ms 140" perhaps.

Animated textures run at screen refresh rate, you can specify fractional tics. Of course if you try to play a 120 fps animation on a 60 Hz monitor you'll only see each second frame

[quote="Graf Zahl"]Using APNG for texture animations would be fine - same for using animated GIFs there.[/quote]

Would this mean we could get animated textures that run faster than 35 tics a second, or would that still be a limitation?

[quote="Graf Zahl"]It's smaller, but that's really it.[/quote]
That was my guess as to what it might offer - presumably it does optimisations such as only recording differences between frames etc.

I also fairly quickly came to the conclusion that, these days, with several mods weighing in at a few hundred MB, or sloppily containing many (mostly unused) textures from multiple shovelwared texture packs, or huge music files etc, that the few KB saved by some of the animations being optimised together into apngs (in the very few mods likely to use them) would not be hugely important.

Ultimately, as I said, it's not my call and wouldn't cause me any work but I'm also just not seeing any meaningful advantage of having apng support over what we already have. More than that, making them and including them would involve additional steps, as well as still having to include them appropriately in GZDoom mods (I.e. Still having to do at least some of the steps needed to get pngs into a mod). :shrug:

Graf, if you implement APNG and then GZDoom and Raze are merged.

You could call it then Dukedoom? Get it? Dukedom.

Edit; A joke.

[quote="Enjay"] So, what does the format offer that we don't already have?[/quote]

It's smaller, but that's really it.

[quote="venividivici"]Enjay.

Issue with your reply that it hinges too much on how popular or unpopular APNG is as image format which is irrelevant because at its core APNG is series of PNG images with metadata that dictates sequence and timeframe of those.

Debate should not be on popularity as it should be on fuctionality of format and use case.[/quote]

Not too surprisingly, I disagree. ;) The popularity of the format is important because the popularity of it relates directly to how well supported it is by editing tools. As your links have demonstrated, it is supported by plug-ins for programs and quirky little tools designed specifically for apng and nothing else. Therefore, very few, if any, "normal" editing tools support it out of the box and the format consequently has less appeal. Its lack of popularity drives this (and in a circular way, is probably also driven by this). So its popularity is important because it has a direct impact on the accessibility of the format to people who want to create them.

As for the advantages that you list for the format, those are all really advantages of the png format. The compiling of the actual apng into a consolidated series of pngs is all fine and dandy, but I don't really see any real advantage over doing that versus using GZDoom's built-in and established functionality. So my question is really, what does apng bring to the table? If it is just that it means you can string a series if pngs together in an animation, well, we can already do that in GZDoom by defining the animation in a way that is analogous to what you do in the apng tools that you linked to. In other words, I can't really see the value of the format in the context if GZDoom because it doesn't seem to bring anything new to the table except for a quirky, poorly supported format that requires additional tools and steps to make (and unmake).

If it does bring something new to the table, something that can't already be done with GZDoom and pngs (and all the other formats it supports - which can even be intermixed within an animation if you really want) I'm not seeing it. So, what does the format offer that we don't already have?

Just one thing here:

Duke Nukem 3D supports animated textures for sprites - and this is a major pain in the ass for robustly determining what the sprite is actually displaying - which is very important for things like adding dynamic lights, voxels or models.

So I am very reluctant to add similar facilities to GZDoom.
Using APNG for texture animations would be fine - same for using animated GIFs there.

What is internally executed doesn't absolve magically the overhead of the layer above it that I refer to as another point being is quality of life improvement by reducing need to copy paste code. Each letter and space between such adds a byte.

GardRun1 Tics 8 <- 14 bytes then 56 bytes if 4 frames of animation

What I propose would cut that more than half. Far more if like some Doom mods have weapon animations that have 15 or even 30 frames of animation such as for reload.

That syntax being more flexible has a cost of overhead.

Asesprite is a commercial tool and trial version is useless, people make 3D models and animations in Blender then convert them to format of game engine they want to use it. Someone can use Piskel to make several PNGs in sequence, export them then use APNG Assembler or if all in one there is RealWorld Paint, all threee free.

You don't seem to be listening to the counterpoints that it wouldn't really have any of the advantages you've ascribed to it... "one line of code for frame" - that's still going to be happening internally. There's got to be some sort of loop inside that executes. The code still exists, it doesn't just happen magically. As for convenience... DECORATE/Zscript already supports simply doing a syntax of "BLAH ABCDEF 8" for displaying a number of frames in sequence, which is far more flexible than a fixed animated image would be.

From an authoring standpoint, [i]maybe[/i] it would be more useful, except, as stated, not many tools really seem to support APNG very much. But a number of tools support discrete image sequences (see Aseprite for one with robust support for this)

Enjay.

Issue with your reply that it hinges too much on how popular or unpopular APNG is as image format which is irrelevant because at its core APNG is series of PNG images with metadata that dictates sequence and timeframe of those.

Debate should not be on popularity as it should be on fuctionality of format and use case.

GIF is limited to 8 bit color and transparency that is also only complete while APNG is 24 bit for both while transparency can be partial/graded along no framerate limitation.

https://www.ionos.com/digitalguide/websites/web-design/what-is-apng/

Comparing GIF to APNG is like equivalent of someone comparing NES to N64 since you again mention GIF. SMK and AVI do not support transparency, former is 8 bit and latter can be 32 bit and can support audio.

Difference between PNG and APNG is that latter has multiple PNG images with additional chunks in single file. Chunk that indicates animation and has multiple images, chunk for frame time and chunk for image data for each image in animation.

https://wiki.mozilla.org/APNG_Specification

GIF and SMK aren't worthy of consideration while AVI would be limited to pre-rendered cutscenes while something like APNG could be used in role of showing pre-rendered cutscenes along being potential to be used in game for textures and sprites.

[quote="Rachael"][quote="venividivici"]GZDoom doesn't support GIF and supports PNG thus supporting APNG makes more sense as it is series of PNG images.[/quote]
It just simply is not as simple as that. But how can I expect to reason with you if you fail to see something as fundamental as this? :blergh:[/quote]

I don't expect it to be simple, but it certainly is simpler to support APNG than GIF.

If nothing else then you Rache or Graf or someone else may be inspired by APNG to create animated PNG format suited for GZDoom.

I am a layman, but looking arounds forums and various wiki that I am questioning sanity such as that for each frame individualy its stated 8 tics.

In that situation should it only be referenced at beginning and interpreted that it switches to next image every 8 tics in order until it reaches the last one? Or better first text references number of tics and each image in file is a number coresponding to a tic.

0 is first image and then every other image has different number such as image with 8 is show when 8th tic is reached until next one replaces once ticking reaches corresponding number of it.

If GZDoom was to support APNG equivalent format then for example name it perhaps SPA = Single Package Animation.

Run.SPA animation has 4 frames then first number for example is 47 then 0, 15, 31 and 47.

I am a layman so tell me if that makes any sense to you or not at all.

[quote="venividivici"]GZDoom doesn't support GIF and supports PNG thus supporting APNG makes more sense as it is series of PNG images.[/quote]
It just simply is not as simple as that. But how can I expect to reason with you if you fail to see something as fundamental as this? :blergh: