[Proposal] Better multimedia formats.

[Nelvin]

I'd love to hear an actual reason with, maybe an explanation why and how something else works the same way, instead of just a phrase of opinion

[raidho36]

It's a sage conundrum: people who know this very well don't have the patience nor faith in humanity to explain all of that in simple terms to laymen, and people who are willing to do this don't have the necessary knowledge.

Instead, I'll present a tangential to the topic but core to the reason argument: it's an extra maintenance surface and an extra dependency for something that can already be done using existing methods.

[Nelvin]

Never mind ... life's to short for these nosense.

[Imagic]

WebP is not only about animation, especially since JPEG has been removed.

it's an extra maintenance surface and an extra dependency for something that can already be done using existing methods.

You're wrong. WebP has lossless/lossy alpha/color compression.
It's royalty-free. Its official implementation is BSD licenced. The API is simple.

I think people are getting too rhetorical about something like this. I will implement WebP for LÖVE because I know my next project will benefit from it, as a core format (to improve LÖVE) or as a library if it's rejected. I'm not interested in arguing, trying to convince people is pointless; I'm only sharing knowledge about those formats.

[slime]

Just to clarify, JPEG has not been removed from love and I have no intention of doing so, especially since the JPEG file loader is a single file header library (stb_image) so it has none of the usual problems library dependencies have.

We're looking at AV1 for video playback in the future, although I haven't 100% confirmed that. All the other video formats either have licensing issues or their build setup and/or binary size doesn't meet our standards.

I'm a bit ambivalent about webp support. I'm not convinced the format has a strong use case in games right now (tools for dealing with game animations tend to work with sprite sheets and don't tend to output webp), and in terms of what a shipping game would use, native compressed texture formats like DXT5 are generally much more useful than yet another intermediary format like webp. If it were already supported by stb_image I'd have no problem updating love's copy of that library to allow webp files to load, but as-is I'm not so sure about adding an extra dependency. If it actually ends up becoming ubiquitous in the future my opinion will probably change, though.

[Imagic]

JPEG has not been removed from love and I have no intention of doing so

The wiki is not up-to-date ? https://love2d.org/wiki/ImageFormat

Yes, AV1 is very interesting, especially with hardware optimizations.

If it actually ends up becoming ubiquitous in the future my opinion will probably change, though.

That is the reason for this topic and it is already in major web browsers. I'm really interested in doing a pull request to support WebP as a normal format at first, without thinking about animation. I can use WebP with the LuaJIT FFI, but I really think the format would be useful to other people using LÖVE.

How would you add the WebP dependency in the LÖVE build process ?

[zorg]

JPEG has not been removed from love and I have no intention of doing so

The wiki is not up-to-date ? https://love2d.org/wiki/ImageFormat

That might have been an accidental deletion due to these changelog messages on the 0.10.0 wiki page:

- Removed image loading support for all (non-compressed texture) file formats except for PNG, JPEG, TGA, and BMP.
- Removed JPEG encoding support from ImageData:encode.

Edit: Actually, those are the formats löve's capable of encoding, not formats it's able to decode. I also fail reading comprehension apparently.

[slime]

The wiki is not up-to-date ? https://love2d.org/wiki/ImageFormat

That is up to date, but I suppose that page on its own without context isn't very clear - that is specifically for formats supported by ImageData:encode, not for formats supported by love.graphics.newImage/love.image.newImageData.

If it actually ends up becoming ubiquitous in the future my opinion will probably change, though.

That is the reason for this topic and it is already in major web browsers.

To me, being supported by browsers isn't the same as being ubiquitous in terms of use. If the format is actually being used for real scenarios and those scenarios mean people will try to load webp images in love, then I'll be interested.

How would you add the WebP dependency in the LÖVE build process ?

If the dependency is out-of-tree:
For Windows you'd make it work with our cmake build system: https://github.com/love2d/megasource
For macOS you'd precompile a .framework dynamic library (with the correct folder structure and info.plist) and update love's xcode project to reference it like the other frameworks.
For iOS you'd do something similar to above but you'd precompile a static .a library instead of a dynamic library.
For Android you'd integrate it into the build system here: https://github.com/love2d/love-android
I'm not too familiar with Linux but you'd probably at least have to update some of the files here: https://github.com/love2d/love/tree/mas ... tform/unix

If the dependency is in-tree it's much simpler - the files just need to be put in love's libraries folder and referenced by the respective build systems. Single-file header libraries like stb_image don't even need the latter step, which is one reason why they're so appealing.

[Imagic]

Here is a pull request for a basic implementation, it may help.

It would be nice to have a wiki page listing all supported formats for decoding, if there isn't one.

[AuahDark]

To add, FLAC has been supported since 11.3, but FLAC encapsulated in Ogg is not, due to LOVE treat Ogg as Vorbis at the moment. To workaround that, you can rename the extension to something else like ".whatever" and LOVE will try to test every possible audio decoders instead.

That being said, I have plan to integrate Opus to LOVE. There was patches sent before and I think that can be used as base.