JpegXL bitmaps support?

Did you think about adding this bitmap format?

I appreciate, CGE is not about demo-scene, but still it is darn-impressive.

Install GitHub - zamfofex/jxl-crx: browser extension to display JPEG XL images
Then check JPEG XL Art paying attention to file sizes.

They forgot to put “Rubin golden vase 1” immediately to the www-page, despite i reported to them in discord 2 weeks ago, and that is a shame, it feels a most impressive 81-bytes art i saw)

There is some shady story about Microsoft retroactively acquiring patent for some modification for one Polish invention, though. Still, the technology itself looks impressive, whatever lawers would do to it.

As for adding JPEG XL Art : I do not have plans to support it, as it is not common enough for now.

If you’d like to have it supported, my simplest recommendation is to extend Vampyre Imaging Library ( https://imaginglib.sourceforge.io/ , GitHub - galfar/imaginglib: Object Pascal image loading, saving and manipulation library. ) to support it. If the support is cross-platform, for all platforms and compilers interesting to CGE (so FPC and Delphi, on Windows, Linux, other Unixes like FreeBSD, Android, iOS…, on x86_64, i386, Arm 32-bit and 64-bit)… then we’d just use it in CGE.

P.S. Note: There has been ChatGPT-generated spam in this thread today. It is removed now, though some of us may have seen it in email anyway. Please ignore it naturally :slight_smile:

There has been ChatGPT-generated spam in this thread today

Yeah, and you also week ago merged quite a patch from another dev, i though it was him initially :slight_smile:
The chatbot, i have to admit, was really good in extracting abstracts and repeating points :slight_smile:

my simplest recommendation is to extend Vampyre Imaging Library

That’s a viable route, indeed.

it is not common enough for now

Why should it matter? You are not making some image browser, you are making a library for a sealed, hermetic applications. The only thing that does matter is if it provides for better games, or not.

X3D is also not very consumer-oriented tech, so what? it suits you and you use it.

Made me remember about features like “smart linker” oif Turbo PAscal or “shaking the tree” in JS world.
Is there a point of having the whole Vampyre pushed to mobile phones over mobile network, if only few of the formats would be used? IOW, could maybe CGE generate a bundle, subset of Vampyre reduced to exactly the assets formats provided for the game?..

It matters, since a file format that isn’t “commonly used” implies that surrounding software (image processing applications, libraries) is also harder to find. Even if the format would be used only internally, it would still matter for engine devs, even if engine users would not see it directly. So “commonly used” is closely connected to “useful to make better games”.

But indeed, my rejection “not commonly used” was too terse. This is just one of the factors, not the only one. To expand:

  • I do not see JpegXL proving something drastically different than what Jpeg 2000 or lossy WebP are exploring. And what, albeit less efficient and older (but oh so popular) good old JPG already did.

    And they both have more popularity than JpegXL from what I can see. And we don’t support them (though Vampyre has Jpeg 2000 support, but not cross-platform and cross-compiler enough). In practice, supporting JPG was enough.

  • JpegXL doesn’t bring any game-changing benefit for a game engine, or more generally 3D applications or GPU-intensitive applications.

    This is in contrast e.g. to DDS or KTX image formats, that we support, even though their popularity is slim compared to e.g. PNG or JPEG. Because DDS or KTX have important features for our use-case (GPU compression, ability to specify cubemaps, mipmaps, texture arrays, 3D textures…). We’ll also support KTX2 for this reason. They also make sense for this reason to be used even internally ( Auto-generated compressed and scaled textures | Creating Game Data | Castle Game Engine relies on DDS / KTX. )

    From what I can tell, JpegXL would need to be completely “unpacked”, much like JPG, to upload it to GPU. In this sense it is not “game changer” compared to existing JPG support.

  • The comparison with X3D is… interesting, because it is actually a real problem for us that X3D didn’t get more popularity.

    It would be much better if X3D was as popular as glTF, and have as great support in all software (like Blender) or ecosystem (like Sketchfab) as glTF has.

    But there is a factor than “saves” X3D in our case: X3D is a great definition for in-memory nodes to define what you want to draw. glTF doesn’t fullfill this case (it exposes much more limited concepts, it would not be enough for us without lots of extensions).

    So we have both, X3D and glTF, and we want perfect support for both. But, just saying, this isn’t really painless :slight_smile: It would certainly be easier it we could have all the benefits in one 3D format, that is both popular, and has a complete graph of all the concepts we find useful. Of course world is never so perfect :slight_smile:

2 Likes