(15/03/2015 03:42 AM)ZiNgA BuRgA Wrote:  I don't have a PS3, so what I can do about it is a bit limited.
It depends.  This is a hobby project which I haven't touched for a number of years, so can't remember a lot of it.  I'm also a lot busier these days than I was back then.
Regardless, please feel free to put your ideas/suggestions forward.  If it interests me, I may look into it.

Good enought, are just some small details like new language codes, a couple of problems with the custom config file of gimconv, and things like that, the most interesting that maybe motivates you a bit are related with vsmx format but i prefer to talk about it in another message, thanks :)

(15/03/2015 03:42 AM)ZiNgA BuRgA Wrote:  Note that GIM «> PNG conversion can be lossy.  If you're trying to guess settings, it's better to use GimConv to convert GIM to GIM with your settings (eg "gimconv in.gim -o out.gim [settings]").

Nice trick, i didnt imagined it and i was using a GIM--»PNG--»GIM conversion that works pretty fine if the original GIM was made by using format --image_format rgba8888
From 245 images that are inside explore_plugin_full.rco from PS3 4.70 firmware, around 200 passed this test (exact MD5 hash after rebuilding GIM--»PNG--»GIM)
The others are the problematic ones and as yoou say it seems related with the DXT conversions that are lossy, it seems is not posible to create a DXT exactly like the original
But by making a GIM--»GIM conversion the DXT is not modifyed, this allows for a perfect match after rebuilding, nice method, better than what i was doing

The options needed for the image @SonyBlack and me was looking for are:
--format_style psp
--format_endian big
--image_format dxt5

As simple as that... being very stricts, this list of options does the same:

--format_style psp
--format_endian big
--image_format dxt5
--pixel_channel default
--pixel_alpha default
The other values set to "default" completes the list of posible options related with pixel info (and also overrides any posible value preconfigured in the gimconv.cfg)

My problem is i was trying to reorder the pixel data by looking at the hexeditor after making a lossy GIM--»PNG--»GIM conversion, and in some way i was in the good road when i was messing with the --pixel_alpha 255... these zeroes at the left columns are related to alpha, by using 255 it seems lot of them appeared at left columns, but if you look at my previous message the column most at the left is telling exactly the value for the alpha (255 = 0xFF in my test)
But what really fills all the columns at left with zeroes is the value "default" that should be considered a different value than the others in the range of 0-255 (this effect of lot of zeroes was just a coincidence in my lossy png by the way, the only one that really stores the alpha info is the column most at left)
With the 24 posible combinations of the rgba channels for --pixel_channel rgba and his variations works in the same way... the total of options is 25 because the results of "default" is different than the others 24 (i tested all them, 25 different in total)

Hard to explain i guess, but what i mean is these "defaults" are critical for the results and are part of what defines this specific GIM format

(This post was last modified: 17/03/2015 03:31 AM by sandungas.)