aqnuep

I agree that this is a much needed feature. It would be great to get support for it as it imposes severe limitations on the usability of the launch.json for...

> Will it help to bracket these includes and any other write-related code in ktx_wrapper with#if KTX_FEATURE_WRITE? For some reason I cannot reply on this comment, so replying here: what...

@MarkCallow, this is still WIP as I still have to update the auto-generated files and their scripts to include `/* clang-format off */` in order to avoid auto-formatting them, and...

@MarkCallow, I did not yet get feedback from you about the proposed code formatting conventions applied in this branch. Should I maybe create a separate PR first that just moves...

> I remain somewhat concerned that formatting is done as a workflow rather than via a clean filter run when files are commited. I have to think more about potential...

Note: the reason the entire rgIsaDisassemblyView.cpp is marked as changed is because it contained inconsistent line endings previously.

> My concept is that KTXwriterScParams contains the options needed to recreate the file so I expected to see, e.g. In my interpretation KTXwriterScParams should only contain the parameters of...

@MarkCallow, @lexaknyazev, I believe that the consensus was that `ktx encode` is not supposed to deal with GPU BC compression, but only with actual supercompressions. I know this PR proposes...

Thanks for the clarifications, @MarkCallow. This just caught me by surprise as I accidentally stumbled upon it. I don't have a good name for this either, but since this changes...

> I'll look as soon as I've had lunch to see whether that 0.5 offset you mentioned is still there and what's causing it. It's simply what we used when...