Some header files from ancient Source SDK code, that include .xtf file header information and various other info on .xtf (check _XBOX defines, and also XTF lines):
Currently I am able to to convert .xtf to .dds using gssmt (linked in the xentax forum, it's the last post), and then I am able to convert .dds to .xtf by hex editing the .dds, replacing the first bytes from an original .xtf file. This obviously has issues, as there's no room for any changes (like resolution and such)
The memory leak in question is the generation of new data for the resizing of the image data, but instead of getting rid of the old data, it sets a new memory address without clearing the old one first. This is also UB as the image data is not VTFLib's to mutate, it should be copied and disposed of at the end.
Error report:
See the end of this message for details on invoking \njust-in-time (JIT) debugging instead of this dialog box.\n\n************** Exception Text *************\nSystem.PlatformNotSupportedException: Operation is not supported on this platform.
at VTFEdit.CVTFEdit.SetVTFFile (VTFLib.CVTFFile VTFFile) [0x006d8] in <5171360439d041378fa6d6fbba48e202>:0
at VTFEdit.CVTFEdit.Import (System.String[] sFileNames) [0x00291] in <5171360439d041378fa6d6fbba48e202>:0
at VTFEdit.CVTFEdit.btnImport_Click (System.Object sender, System.EventArgs e) [0x0001a] in <5171360439d041378fa6d6fbba48e202>:0
at System.Windows.Forms.MenuItem.OnClick (System.EventArgs e) [0x00078] in :0
at System.Windows.Forms.MenuItem+MenuItemData.Execute () [0x0000b] in :0
at System.Windows.Forms.Command.Invoke () [0x0001c] in :0
at System.Windows.Forms.Command.DispatchID (System.Int32 id) [0x00014] in :0
at System.Windows.Forms.Control.WmCommand (System.Windows.Forms.Message& m) [0x00021] in :0
at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00357] in :0
at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00043] in :0
at System.Windows.Forms.ContainerControl.WndProc (System.Windows.Forms.Message& m) [0x0001a] in :0
at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message& m) [0x00318] in :0
at VTFEdit.CVTFEdit.WndProc (System.Windows.Forms.Message& e) [0x00032] in <5171360439d041378fa6d6fbba48e202>:0
at System.Windows.Forms.Control+ControlNativeWindow.OnMessage (System.Windows.Forms.Message& m) [0x00001] in :0
at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x000b3] in :0
at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message& m) [0x00025] in :0
nvDXT is a legacy library compiled with an older version of Visual Studio. Due to "breaking changes" introduced in Visual Studio 2015 there are a large number of errors that occur when trying to link it.
These needs to be fixed or, more practically, the legacy nvDXT library needs to be replaced.
The DDS file format supports all of the same image formats as VTF (plus more), so there should be an option when importing a DDS file to retain source format or something along those lines (as long as the source DDS uses a compatible format and is a power of 2). Such an option would copy the image data and any mipmaps over to a VTF file (and create thumbnails, info resources, etc. if the user requests), while avoiding introducing green tint to DXTn or BGR565 textures and other lossy conversion issues.
Additionally, there could be an option to export as DDS, using the same image format as the source VTF.
I'm pretty sure this would be possible; while I am not familiar with the nitty gritty, I'd imagine that the image data itself can just be copied over, since both file formats encode the image using little endian with the same image formats designed for the GPU.
VTFEdit and VTFCmd expect an old version of DevIL which is no longer available. Newer versions have vastly changed codewise and don't work as a direct drop-in replacement.
VTFEdit and VTFCmd need to be updated to either use a newer version of DevIL or switch to a different image input/output library.