Another thing I realized while writing docs, having to always put the
{}, {} things there is silly, and in many cases we need just one, not
all of them.
Because (after I read a bunch of articles on this) it can actually be
understood easier that way -- the now-documented snippet shows that in
practice. Also expanded the constructor and usage docs a bit.
I originally had this API there but then threw it away because it
encouraged inefficient use. However now it's really handy when writing
tests, so I guess I'll keep it.
Usually the validation layers should be expected to catch this, but in
this case we omit the pNext structure chain before it has a chance to be
caught by the layer, so the assert is needed.
I got a bit confused by the code, seeing it again after a few weeks, so
better explain the original intent to avoid getting confused again in
the future.
And remove the one case where storing the wrapper *really* isn't needed
right now.
Yes, I had to make the enum mapping table in the previous commit because
I didn't remember anymore if I exposed this already or not. The API
surface is *huge*.
A forgotten leftover from the initial RenderPass design. These used to
be created right at construction, but I eventually changed that to be
only done explicitly via a getter.
Originally I wanted to save people typing and provide "reasonable
defaults" for the image layout, however shortly after I realized I can't
express even the simplest case in the Vulkan Triangle example with
those.
Furthermore the case of having default load/store operations are so
rare that it isn't worth an extra API which tricks the user into
thinking the clear/discard operations are meant to be done somewhere
else. I realized this because it was actually harder to explain these in
a second step than introducing them right from the beginning.
Finally, because there's so many different structures to fill, the
implicit constructors weren't a good idea either, as it again tricked
users to think just PixelFormat or just an index is the parameter, with
nothing else, and then left them wondering where all the other important
params go. Same with {} used instead AttachmentLoadOperation::Load /
AttachmentStoreOperation::Store, unnecessary confusion there so don't
even suggest that.
Apparently "pixel size" could have meant "image size in pixels" as well.
Additionally also clarify what image size means, since it might be
unclear especially for the block-compressed images.
An unqualified link to Extensions.h will, guess what -- pick the last
Extension.h header that Doxygen came across. So in this case
Magnum/Vk/Extensions.h. With no warning or any other hint that something
MAYBE could be wrong. FFS.
Except for formats like ETC, which do have the actual size in their
name, these are just confusing -- the compression is more like 565 than
a byte in some cases and it just doesn't give any useful information.