Talk about anything

Nerdzmasterz And, yeah, this is probably THE most active thread here, from what I can see.

2,500 posts!!! And the OP was a hit and run.

cybereality 2,500 posts!!!

Some of us just don't like Discord ^^

CLAYOoki I recall a similar conversation on this. The big answer I got was no. I can see from experience that pirates and hackers are dealt with in various ways.

You could try to keep all of the information on a server, or use a password, but neither of those methods are fool-proof. The server would probably be the best option, if one can afford it.

In my class Box I have this:

func setPopMessage(message : String = "Pop!"):
	_popMessage = message

but where I initialize my Box I'm not getting any auto-complete suggestions for the input:

	var box : Box = createBox(0,0,0)
	box.setPopMessage(NO SUGGESTIONS??? what am I doin wrong?)

Am I missing something?

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.

Does it make sense to use the QOI format?

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.

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/

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.

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

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.

cybereality I've never heard of that, and I doubt it is useful for anything (considering I've never heard of it).

https://en.wikipedia.org/wiki/QOI_(image_format)

I think it's mostly up to just how new it is. Seems like something with potential though, and open standards, IMO are always preferable.

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.

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.

Erich_L the material to be drawn on top of everything else

There is a Render Priority, but I think it only has an affect on transparent materials (lower numbers are rendered on top). You can also look under Flags for No Depth Test. This may be what you are looking for, though it usually ends with strange results.

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

It works for me:

Kojack
Seems the DDS custom mip map issue is that Godot assumes a specific number of mipmaps based on the resolution, while the format itself allows a different number of mipmaps. Mine had 7 mip maps, Godot was expecting 10.
It was created with the official Microsoft DirectX texture tool, I assume they know their own format.
Remaking it with the expected number lets it work.

The point of the test texture I have is each mip map is colour coded. For example first mip map is 512x512 solid red. Second is 256x256 solid green, etc. When you put it on a mesh, the colours you see represent which mip levels are being viewed. If you never see red on the mesh, it means 512x512 is a waste of resolution. (The new one I made is 13 mips with 4096x4096 at the top)

spacecloud woot! I can’t wait for this. It looks like 3.5 is getting pretty close too

I've got 110,911 dds files on my hard drive.
Lots of games use them. Nvidia and Microsoft make tools for them (like photoshop plugin and stand alone), every game engine (that I've used) supports them. But I guess non Windows developers might not have as much, since DDS (Direct Draw Surface) is pretty much a header then a raw dump of a Direct3D texture from memory. It may take a little more code to load them in OpenGL if you don't want to simply convert them to a simpler internal format in the loader.

Of course "right tool for the job" and all that.
Jpeg compresses well on disk, but is lossy, expands to raw in memory and doesn't support alpha channels.
PNG compresses ok-ish, is lossless and has alpha channels (and things like deep colour modes), but also raw in memory.
DDS can store ST3C style block compressed formats (the kind that stay compressed on the GPU), voxels and 6 face cube maps, plus less common formats (like RGBA4444).
GIF is paletted (stores pixels as an index into a palette of up to 256 colours, instead of as colours directly) and supports animation.
EXR for high dynamic range images.

Block compressed textures use RGB565 (16 bit colour) so can look crappy, depending on the texture. (Technically for most of the BC formats each 4x4 block is paletted, with a palette of 2 user specified RGB565 colours and 2 interpolated RGB888 colours between the user specified ones). Godot converts textures into block compressed format internally when you set a texture to VRAM compression.

From the Godot docs, the actual types stored in an exported project are going to be raw, webp, png or st3c/pvrtc. If you put a jpg in a project, and set it to lossy compressed mode in the importer, it will be stored as a webp.

I used to have my own format that was 192 bit colour (double precision float per channel) in a tiled format for handling massive images bigger than memory. Yeah, overkill for pre-2000 rendering, but it was fun.

Yeah, for sure. When I was using DDS it was with a custom DirectX11 engine I was writing. I did go with it, only because it worked best with the Microsoft APIs and I needed it for efficient cubemapping. But the tools were poor. I think there was a Photoshop Plug-In, but it hadn't been updated, or didn't work with the latest version of PS at the time, or something, can't recall exactly. I think there was a Microsoft tool I used.

When I switched to Vulkan, I was on Linux and kind of trying to get away from Microsoft, so I attempted with KTX, which is like the OpenGL version of DDS. It's actually a decent format, but the tools were not great. I think I had to use a command-line convertor or there was some random third party app. But I decided it was too much effort, so I just switched to using standard formats like JPG and did the mipmapping/cubemapping in code. So not the end of the world, but I would prefer if there was just standard support in apps like Photoshop, GIMP, etc. without using strange tools.

In any case, I think JPEG XL is the future. I know Godot supports WebP already, and they are quite similar in performance and file size, but I think JPEG XL has a lot of potential. Aside from the quality and file size (which is as good as WebP and far better than JPG/PNG) it also has transparency, high quality animation, and really high levels of depth, HDR, multiple layers, etc. You should read this blog post to see why it's probably the last image format we will ever need in our lifetime (disregarding stuff like holography or lightfields, I mean as a 2D image).

https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs

Just to show you one data point, a single image in JXL can be up to 1,073,741,823 x 1,073,741,824 with 4,100 24-bit channels. You could literally store an entire AAA PS5 game in 1 image. Granted, that's not a great idea for a lot of reasons, but you could.

Jpeg xl is definitely interesting, but it needs more support. Chrome won't show them by default (have to turn on a flag, why?) and Firefox only allows them in nightly builds, not the standard release.

QOI can handle 4,294,967,296 x 4,294,967,296 images.
(Although that would require something like 72 exabytes for 32bit colour without compression)

Kojack Jpeg xl is definitely interesting, but it needs more support.

Well yes. The spec was finalized in 2021, but even the reference implementation on Github is not finished. There is some beta support (mostly if you build source yourself, like for GIMP, Firefox, etc.) but I think this has more to do with the reference code not being stable. I would expect things will be rolled out later this year. And the spec is final, so people could write their own implementation or whatever. But it takes time. As I said, the spec wasn't finalized until October of last year. But seeing as it has HUGE benefits for web development, I expect the adoption to be quick. WebP is good, but I think being backed by Google made people wary, just like Apple's formats haven't gone far beyond Apple products, but JPEG XL is a standard and royalty-free with a BSD license.

Pixophir And for my project I need lossless compression, no fine print. Not 'visually' or 'mathematically' because what if epsilon is a large number ?

JPEG XL can do lossless, at 35% smaller than PNG. You can also store 32-bit floats in each channel, so it has way higher precision than most other image formats (unless you include working directly with GL/DX).