There is nothing to suggest. message is a String, it can be anything you want to type in. The Pop! is just a default parameter that is assigned if the method call is empty.

    I've never heard of that, and I doubt it is useful for anything (considering I've never heard of it). JPG and PNG are already more than fine. In any case, GPUs use their own texture compression, so the file format you use (like JPG) is only for getting it into the editor. Once your game is running on your computer or on a phone, the GPU uses it's own optimized format so it doesn't actually matter.

      Neither knew it. https://qoiformat.org/ Why do I think of fish ? :-)

      Use a format that suits you most. I am a fan of PNG for simple images and height map stuff, also because one can make an image in a few lines of code with libpng.

      But of course it depends on what you need it for. One stumbles over all kind of formats for all kinds of purposes.

      JPEG XL is interesting. That will (most likely) be the next industry standard image format (to replace JPEG, PNG, and GIF), so it would make more sense to support that, rather than random formats that will never work with anything. JPEG XL supports high quality lossy and lossless images (with much better quality and file size), transparency, animation, and a whole ton more. Once it is standard, there will likely not need to be any use for JPG/PNG/GIF for a long while.

      https://chromeunboxed.com/jxl-jpeg-xl-new-image-file-type-chrome/

      Do you know if there is a compressed format on the CPU side where one can still address single pixels ?

      Edit: wow, JXL claims 30% better lossless compression than PNG, impressive. Also for 16bit gray scale ? Will risk an eye. There's an implementation here https://github.com/libjxl/libjxl, but it isn't in the Debian repositories yet.

      Editedit: It's also rather fat, an allrounder, compared to PNG. But then again, if you want to store a lot of data and have a chance for 30% less demand on space for storage and traffic ...

      I haven't been able to build the source yet. It's still not 100% final, so it's in constant flux. However the release page on Github has an older .deb file that does work. It at least lets you view the images, I'm trying to convert some stuff now. It's from last year, but it's good enough to test the quality and file size. Support is still not ready (as I said, it's barely final) but there is a GIMP plugin and Chrome just added support.

        cybereality I've never heard of that, and I doubt it is useful for anything (considering I've never heard of it). JPG and PNG are already more than fine.

        I had not heard about this format, too, so I was surprised. It's kind of claimed to be a "faster PNG".

        cybereality I couldn't get the command-line tools working, but I used this website. https://jpegxl.io/

        Your browser does not support JPEG XL.😞

              Tomcat Your browser does not support JPEG XL.😞

              Yes, like I said, it's very early. I don't expect support to be out until later this year in a stable release. You can kind of get it working with beta software, like I did, but it's not totally there. But in a few months I expect it will start rolling out. It's honestly going to be pretty big. We get better quality at much lower file size (if you look at the test I did, it's like 25% of the size at the same visual quality). Plus high quality high frame rate animation, that will be much better than GIF. And transparency of compressed images, which is not possible right now (especially important on the web). I'd say within 1 year, it will be the industry standard.

                Krita doesn't work with the new format yet.

                Though this release adds support for the new JPEG-XL format, which supports animation, exporting and importing animations in this format gives incorrect results. A fix is pending.

                But XnViewMP and GIMP know about it.

                I get artifacts when saving from .jpg:

                Megalomaniak open standards, IMO are always preferable.

                Yes, I agree, but with something like an image format, I think wide compatibility may win out. In any case JPEG XL is BSD License and royalty free, so I don't see any issue there.

                  The DDS format can be a handy one. Not only does it store many different GPU pixel formats, but it can do block compressed (the various GPU compressed texture formats), cube maps, voxels and custom mip maps.

                  I might need to do some source digging though, Godot's docs claim to handle loading custom mip maps from DDS files, but it fails on a DDS I've been using since the Ogre3D days.

                  The interesting thing about QOI for me is the claimed 20-50 times encoding performance vs png. Being able to quickly encode a lossless image for things like frame capture could be useful.
                  Plus the fact that the entire reference implementation is a single 669 line C header (a third of which is documentation) with no dependencies means it looks damn easy to integrate into small projects or rewrite directly in other languages.

                    Actually, now that I read the website it does look pretty cool. At least for like hobby projects, I'm not sure how useful it would be for production or anything serious. From what I can see, the advantage is in the encoding time, which is pretty impressive. Mostly this is not an issue, but I guess for rendering image sequences that could be useful. Though the file size is slightly more than PNG. So it terms of game development, I'm not sure it matters much. Unless you are batch converting all the assets in a game, exporting a single PNG, even at 4K res, only takes a few seconds. Plus, there would need to be a lot more tooling for exporters and importers and all kinds of stuff. So I don't think it will be that popular, outside of hobby stuff.

                    What do you guys think of early access paid tutorial?

                    Basically, the tutorial covers the basic gameplay, UI, and SFX & Music, but the advanced gameplay is still work-in-progress and will be uploaded later.

                    Yeah, that could work. You could always release like the first video on YouTube for free, and then have paid access on your own site.

                      cybereality

                      Yeah, that's what I think.

                      I have this tutorial that I want to upload on Udemy, but the advanced stuff is taking too long. So I thought "Just upload the basic stuff, the advanced stuff comes later."

                      Maybe I should stay quiet about the advanced stuff. I can make it a surprise for the students.

                        Check out wingfox. It's mostly for artists, but they have some programming stuff too. The way it works is you can start a course and raise funds (even with like 1 video) and then you have to post a new video every week until it's finished. But the customers pay the full price. Granted, it's pretty high end, so I'm not sure everyone is accepted, but it might be worth checking out.

                        https://www.wingfox.com/c/8609

                        cybereality Usually when the editor knows the class type it gives you hints for what the func input parameters are.

                        On another note, does anyone know the name of the material parameter that allows the material to be drawn on top of everything else? I have been looking for quite some time, it's eluding me.