Threaded Mode | Linear Mode

sandungas · 09/03/2015 08:12 PM

Thanks to you for your help and your tools that are epic and gave lot of people lot of hours of fun and even made some people addicted to console underground scene like me :)
Im not native english, basically i would like to see an example of how to use the --gimconv-flags option, not sure if i was able to explain my problem but i will use another example more simple
Im using .bat files, all my .bat are in the same folder than rcomagegui, there is also a test.rco and a "test" folder at his side

First i make a dump, all is extracted in the "test" folder, and the images are passed to gimconv to make the gim--»png conversion

Code:

echo off
md ".\test"
Rcomage\rcomage.exe dump ".\test.rco" ".\test\test.xml" --resdir ".\test" --gimconv-cmd ".\GimConv\GimConv.exe" --conv-gim png
pause

This extraction works fine, then i open the rcoxml file (main rco descriptor) to remove most of the contents (because this is just a test is faster this way, only has 1 image)

Code:

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- This XML representation of an RCO structure was generated by Rcomage v1.1.1 -->
<RcoFile UMDFlag="0" rcomageXmlVer="1.1" type="ps3" minFirmwareVer="unknownId0x130">
	<MainTree name="explore_plugin">
		<ImageTree>
			<Image name="item_tex_plain_folder" src=".\test\item_tex_plain_folder.png" format="gim" compression="zlib" unknownByte="0" />
		</ImageTree>
		<TextTree>
			<TextLang src=".\test\English.xml" language="English" format="utf16" />
		</TextTree>
		<ObjectTree>
			<Page name="expage_explore_bg" unknownInt0="0x1110000" onInit="nothing" onCancel="nothing" onContextMenu="nothing" onActivate="nothing"></Page>
		</ObjectTree>
	</MainTree>
</RcoFile>

And then the rebuilding is where im having problems
If i use this command it gives me an error, the png--»gim conversion fails (as expected because is not able to locate gimconv.exe)
The point of this test is to verify if the resource paths from the rcoxml are detected fine (otherway it would split errors about not able to locate the files... there are not path errors so i guess the paths in the rcoxml are fine)

Code:

echo off
Rcomage\rcomage.exe compile ".\test\test.xml" ".\test_rebuilt.rco"
pause

Spoiler for and this is the error:

In this example to make the png--»gim conversion i specify the location of gimconv, and i also specify the gimconv flags (without any flag)
The only purpose is to see if the tool splits an error related with gimconv.exe (it doesn't, so i guess the way im using --gimconv-cmd is fine)

Code:

echo off
Rcomage\rcomage.exe compile ".\test\test.xml" ".\test_rebuilt.rco" --gimconv-cmd ".\gimconv\gimconv.exe" --gimconv-flags
pause

Spoiler for and this is the error:

In the next example i specify --gimconv-flags... with only one flag (ps3) to simplyfy things
There is no error, it seems like the tool stopped working, and im not sure if is because the name im using for the flags, i mean... i have no idea if this ps3 needs to be specifyed as ps3, -ps3, --ps3, "ps3", "-ps3", "--ps3", etc... there are too much variations

Code:

echo off
Rcomage\rcomage.exe compile ".\test\test.xml" ".\test_rebuilt.rco" --gimconv-cmd ".\gimconv\gimconv.exe" --gimconv-flags ps3
pause

Spoiler for and this is the error:

In the example before i just used the flag ps3 but my problem is bigger because i need to use several gim settings, and in the format that appears in the gimconv.cfg (because i think is the most flexible way to specify gim settings, and some options doesn't have a "label" like ps3 has), more specifically the settings i need to use are this 3 ones that seems to be the "standard" for around 80% of the gim's inside ps3 rco's
--format_style psp
--format_endian big
--pixel_order normal
So how i add all these gim settings ? If i try something like this the error is the same than in the example before

Code:

echo off
Rcomage\rcomage.exe compile ".\test\test.xml" ".\test_rebuilt.rco" --gimconv-cmd ".\gimconv\gimconv.exe" --gimconv-flags "--format_style psp --format_endian big --pixel_order normal"
pause

I think i just need to see an example of how to use this gimconv-flag from command line, this can help a lot but maybe im commiting some mistake in the way im trying to rebuild it ?

By the way, i know this method to rebuild an rco with a massive png--»gim image conversion (where the gim settings affects all images) is not accurate enought and in most cases will result in a broken rco. I don't know for PSP... but for PS3 is not accurate enought to use it as the "standard rebuild method" because inside PS3 rco's there are gim's that was created with different setings (as you and mugi was discussing here, and i could verify too http://endlessparadigm.com/forum/showthr...pid350611)
But i would like to make it work this way because im documenting the usage of rcomage and gimconv (and other stuff related) in a ps3 wiki and i need a working example of how to pass gim settings from rcomage---to--»gimconv

ZiNgA BuRgA · 11/03/2015 12:00 AM

Thanks a lot for posting all the info (really helps as I can follow what you're trying to do) :)

Your usage is correct, however, it looks like there's a bug which causes rcomage to crash in your situation (only happens with PS3 RCOs with a supplied gimconv-flags param).
This is my fault, so I'll make a fix for this.

By default, if you don't specify gimconv-flags on a PS3 RCO, it will supply the "-ps3" flag to Gimconv. If you do specify gimconv-flags, it's supposed to add that to the "-ps3" flag.

(09/03/2015 08:12 PM)sandungas Wrote: There is no error, it seems like the tool stopped working, and im not sure if is because the name im using for the flags, i mean... i have no idea if this ps3 needs to be specifyed as ps3, -ps3, --ps3, "ps3", "-ps3", "--ps3", etc... there are too much variations

Parsing is done by the shell (cmd.exe, not by rcomage), so ps3 and "ps3" are identical. The " character is only required if there's a space in the argument.

As this is sent directly on the command line, -ps3 or "-ps3" would be correct, as it's what Gimconv accepts (but due to the bug, rcomage crashes instead).
But also, since rcomage appends "-ps3" automatically, it's best not to ever specify this flag.

(09/03/2015 08:12 PM)sandungas Wrote: i need a working example of how to pass gim settings from rcomage---to--»gimconv

Thanks for your efforts and contributions, by the way!

ZiNgA BuRgA · 11/03/2015 04:37 AM

Here's a version with the aforementioned bug fixed.
Hopefully this works for you!

sandungas · 12/03/2015 12:15 AM

Nice, in rcomage-dev-v1.1.2 the gim settings are passed correctly to gimconv when compiling ps3 rco's Madwin

My old windows xp x32 complained about 2 missing dll's the first time i tryed to use rcomage-dev-v1.1.2 (previous versions doesn't), i googled them in one of these dll pages and placed inside rcomage folder and it solved the problem, here are the ones that proved working for me https://www.sendspace.com/file/bkw2m6

This concludes my oddisey with gimconv flags, for some reason in all the tests i made i never imagined this could be a bug (i feel a bit blind for not realizing something was not working and could be a bug, so i could report it here as a posible bug instead of my long messages with questions and brainstormings) but im also happy a bug was fixed

I used 3 batch files to automatize the tests with the gimconv flags, the .zip contains the 3 .bat files and explore_plugin_full.rco from PS3 official firmware 4.70 (in case someone wants to take a peek at the newest ps3 rco's ;)
https://www.sendspace.com/file/tohpxo
What the .bat's does is explained inside the next spoiler for not overloadiing the thread, i guess someone could find the .bat's usefull as an example of use or to modify them to automatize other experiments

Spoiler:

To run all the process first copy the 3 .bat and the .rco at the side of rcomagegui.exe, then run the .bat's in order by double clicking with the mouse in them (wait for each of them to finish before clicking the next one)

gimconv flags test1 (dump_to_png).bat
Makes a directory, and dumps the rco contents all together in a common folder, the images are passed to gimconv to make the gim--»png conversion

Code:

echo off
md ".\PS3 470 explore_plugin_full"
Rcomage\rcomage.exe dump ".\PS3 470 explore_plugin_full.rco" ".\PS3 470 explore_plugin_full\explore_plugin_full.xml" --resdir ".\PS3 470 explore_plugin_full" --gimconv-cmd ".\GimConv\GimConv.exe" --conv-gim png
pause

gimconv flags test2 (compile_from_png).bat
It does 2 rco compilations passing different gim settings to gimconv
first compilation gim flags: --format_style psp --format_endian big
second compilation gim flags: --format_style ps3 --format_endian little --image_format dxt5

Code:

echo off
Rcomage\rcomage.exe compile ".\PS3 470 explore_plugin_full\explore_plugin_full.xml" ".\PS3 470 explore_plugin_full (psp_big_default).rco" --gimconv-cmd ".\gimconv\gimconv.exe" --gimconv-flags "--format_style psp --format_endian big"
Rcomage\rcomage.exe compile ".\PS3 470 explore_plugin_full\explore_plugin_full.xml" ".\PS3 470 explore_plugin_full (ps3_little_dxt5).rco" --gimconv-cmd ".\gimconv\gimconv.exe" --gimconv-flags "--format_style ps3 --format_endian little --image_format dxt5"
pause

gimconv flags test3 (dump_raw).bat
It makes 2 directories and does 2 rco extractions in raw format (no gimconv flags used so is posible to see how the gims was build in previous step)

Code:

echo off
md ".\PS3 470 explore_plugin_full (psp_big_default)"
Rcomage\rcomage.exe dump ".\PS3 470 explore_plugin_full (psp_big_default).rco" ".\PS3 470 explore_plugin_full (psp_big_default)\explore_plugin_full.xml" --resdir ".\PS3 470 explore_plugin_full (psp_big_default)"
md ".\PS3 470 explore_plugin_full (ps3_little_dxt5)"
Rcomage\rcomage.exe dump ".\PS3 470 explore_plugin_full (ps3_little_dxt5).rco" ".\PS3 470 explore_plugin_full (ps3_little_dxt5)\explore_plugin_full.xml" --resdir ".\PS3 470 explore_plugin_full (ps3_little_dxt5)"
pause

Now is posible to see if the gim flags was applyed correctlly in step 2 (at compiling time)... by looking in a hexeditor at the gim headers of any of the gim files created in step 3

A GIM from the first frankenstein:
.GIM can be readed from left to right (so format_endian big has been applyed correctly)
Label PSP present (so format_style psp has been applyed correctly)
The pixel data starting at 0x80 (because this is the pixel data, right?) follows the image_format default (because was not specifyed, so is correct too)

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 02 05 F0 00 00 00 10 00 00 00 10  .......ð........
00000020  00 03 00 00 00 02 05 E0 00 00 00 10 00 00 00 10  .......à........
00000030  00 04 00 00 00 02 05 D0 00 02 05 D0 00 00 00 10  .......Ð...Ð....
00000040  00 30 00 00 00 03 00 01 00 B2 00 B2 00 20 00 10  .0.......².². ..
00000050  00 08 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 02 05 C0 00 00 00 00 00 01 00 01 00 03 00 01  ...À............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00  ÿÿÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ.
00000090  FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00  ÿÿÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ.
000000A0  FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00  ÿÿÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ.
000000B0  FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00  ÿÿÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ.

The same GIM from the second frankenstein:
MIG. characters are reversed (so format_endian little has been applyed correctly)
Label PSP is not present (so format_style ps3 has been applyed correctly)
The pixel data starting at 0x80 (because this is the pixel data, right?) follows the image_format dxt5 (correct too)

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  4D 49 47 2E 30 30 2E 31 00 00 00 00 00 00 00 00  MIG.00.1........
00000010  02 00 00 00 00 7F 00 00 10 00 00 00 10 00 00 00  ................
00000020  03 00 00 00 F0 7E 00 00 10 00 00 00 10 00 00 00  ....ð~..........
00000030  04 00 00 00 E0 7E 00 00 E0 7E 00 00 10 00 00 00  ....à~..à~......
00000040  30 00 00 00 0A 00 00 00 B2 00 B2 00 08 00 04 00  0.......².².....
00000050  04 00 02 00 00 00 00 00 30 00 00 00 40 00 00 00  ........0...@...
00000060  D0 7E 00 00 00 00 00 00 01 00 01 00 03 00 01 00  Ð~..............
00000070  40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  @...............
00000080  00 00 00 00 FF FF FF FF 49 92 24 49 92 24 FF 00  ....ÿÿÿÿI’$I’$ÿ.
00000090  00 00 00 00 FF FF FF FF 49 92 24 49 92 24 FF 00  ....ÿÿÿÿI’$I’$ÿ.
000000A0  00 00 00 00 FF FF FF FF 49 92 24 49 92 24 FF 00  ....ÿÿÿÿI’$I’$ÿ.
000000B0  00 00 00 00 FF FF FF FF 49 92 24 49 92 24 FF 00  ....ÿÿÿÿI’$I’$ÿ.

Now i realize you are still interested in releasing new rcomage versions would you like to hear some suggestions for the new version ?
I have a good amount of things i would like to talk with you in relationship with info that was published in http://www.psdevwiki.com/ps3/Main_Page (is because some people like me uses this wiki as a shared work log), also because i know you have been always interested in documenting some stuff like rcoxml structure, etc.. so is also an invitation for anyone in this forum to use this wiki for publishing info, if you have some specific need like restructuring/renaming/erasing/etc pages or some idea to create more pages just ask and wee will prepare it for you
Is a PS3 wiki so everything related with PS3 has a place in there, sadly wee don't have a PSP wiki but PSP and PS3 shares lot of things and file formats in common, specially the wiki pages that appears in this template under "XMB" and under "Containers" sections, some of them are closelly related with rcomage: http://www.psdevwiki.com/ps3/Template:File_Formats

So yeah, i have lot of things more interesting to talk about with you incase you are interested (if not, or none of you don't want to involve is ok, no problem, and if you prefer to move the talk to other thread just tell me)

SonyBlack · 13/03/2015 07:07 PM

guys.. i know this is a old stuff but i need help.. im customizing my xmb and im really done look here http://imgur.com/a/c5Je4#0 its rebug fw.. so but i can't figure out 1 thing.. i want to edit the tex_psn.gim of the xmb_ingame.rco.. everytime i edit the png file and convert back to gim and then repack to rco i get all time blank psn icon on ingame.. anyone of you proz now a solution? please.. im busy with this long time.. can't figure it out.. :( sorry for my english.. its not my main language..

sandungas · 13/03/2015 08:19 PM

(13/03/2015 07:07 PM)SonyBlack Wrote: guys.. i know this is a old stuff but i need help.. im customizing my xmb and im really done look here http://imgur.com/a/c5Je4#0 its rebug fw.. so but i can't figure out 1 thing.. i want to edit the tex_psn.gim of the xmb_ingame.rco.. everytime i edit the png file and convert back to gim and then repack to rco i get all time blank psn icon on ingame.. anyone of you proz now a solution? please.. im busy with this long time.. can't figure it out.. :( sorry for my english.. its not my main language..

I guess you are used to gimconv.exe command line usage (if not, you need to practise a bit and test a lot) because is needed to make this .gim conversion individually before rebuilding the .rco
I had no time to look at the contents of this .rco from ps3 firmware 4.70 yet... but i think you are right, this icon has a "rare" gim format (compatible with ps3, but not the standard gim format that most of the other images uses)

I think is a -dxt5 variant as far ive heard (and maybe alpha with a value of 255)... but i can't tell by myself, i didnt took a look at it yet, if im suggesting this gim setings is because it looks there are other .gim's inside ps3 rco's that uses them

The identification of .gim formats consists basically in comparisons of the original .gim VS the rebuild .gim tests (in a hexeditor first, and then a hash comparison)
So it can help if you provide a download link with the original .gim because this makes things easyer for others to take a look (specially for zinga burga that can help you much better than me, and maybe he finds the correct gim setings at the first try)

Edit:
Not sure if i was explicit enought...
The tex_psn.gim inside explore_plugin_full.rco uses this gim settings (im 100% sure are correct):
--format_style psp
--format_endian big
--pixel_order normal
These are the settings i consider "standard" for ps3 gims (because most of them was build this way)

But... the tex_psn.gim inside xmb_ingame.rco (same image, same name, but inside another .rco) uses another gim settings:
--format_style psp
--format_endian big
--unknown...
--unknown...
--unknown...

Is weird, because is the same image with the same name, the only difference is located inside another .rco (and this seems to be exactly the cause why are different... because in the PS3 at runtime... the responsible of displaying "xmb ingame" is not the same than the responsible of displaying "main xmb"... technically the responsible should be vsh.self for both, but are considered 2 different XMB modes internally)
Why the ps3 uses this mess of .gim formats is still unknown and a bit speculative... but is also related with the creation date of the .gim (inside 4.70 firmware released in 2015 there are .gim's that was created in 2006... it can be seen in a timestamp at the footer of some .gim's that was created with the setting update_fileinfo = on)
Also is posible they decided to change gim setings for some specific images along all this years, also because the newelly added images in new firmwares maybe was created with new gim settings)

Edit2:
If i remember correctly... another difference is the tex_psn.gim inside xmb_ingame.rco is smaller resolution (widthxheigth in pixels)

SonyBlack · 13/03/2015 09:03 PM

thanks for reply.. here are the both files.. ofw and rebugs.. http://www65.zippyshare.com/v/mKm4Gpxx/file.html http://www65.zippyshare.com/v/BcACHvqa/file.html
so if you look at the psn .png of rebug its transparent and if you go on to xmb if you are ingame then its looks full.. i try to edit it with your bat script.. its convert and repack but all the scales are wrong.. nofication center is white square and many other scale bugs.. idk what to do.. this is my last step on my xmb custo.

sandungas · 13/03/2015 09:59 PM

Im looking at it and im stucked in the same problem i had to identify other ps3 .gim's :(
Is needed to say the identification is like a lottery because there are literally thousand of combinations of settings you can choose when building a .gim
I made 3 tests with different settings, and my results are close to the original, but not exactly, so i can't give you the corect settings (but i can explain you what im doing to try to identify it)
But my english is not so good and i can be boring, so please read the section "how to identify .gim settings" i wrote here --» http://www.psdevwiki.com/ps3/GimConv

As a resume... if you are using rcomagegui... you need to make 2 extractions of the rco contents
one extraction in "raw" (uncheck all the conversion boxes at bottom of rcomagegui)
another extraction with gim--»png conversion enabled (check the image conversion box in rcomagegui)

After this, open the original .gim in a hexeditor (one of the .gim's that was extracted raw, so they didnt suffered any conversion... this "raw" files contains the exact byte data that wee need to replicate)
This is how tex_psn.gim looks (from xmb_ingame.rco ps3 4.70)

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 00 40 70 00 00 00 10 00 00 00 10  ......@p........
00000020  00 03 00 00 00 00 40 60 00 00 00 10 00 00 00 10  ......@`........
00000030  00 04 00 00 00 00 40 50 00 00 40 50 00 00 00 10  ......@P..@P....
00000040  00 30 00 00 00 0A 00 00 00 80 00 80 00 08 00 04  .0.......€.€....
00000050  00 04 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 00 40 40 00 00 00 00 00 01 00 01 00 03 00 01  ..@@............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  00 00 00 00 00 00 00 00 76 03 56 03 FF FF FF FF  ........v.V.ÿÿÿÿ
00000090  00 00 00 00 00 00 00 00 76 03 56 03 FF FF FF FF  ........v.V.ÿÿÿÿ
000000A0  00 00 00 00 00 00 00 00 76 03 56 03 FF FF FF FF  ........v.V.ÿÿÿÿ
000000B0  00 00 00 00 00 00 00 00 76 03 56 03 FF FF FF FF  ........v.V.ÿÿÿÿ

Then you need to take same file that was converted to .png (in the second extraction)
And by using gimconv.exe you need to convert it to .gim by using different settings, this is my results:

When using:
--format_style psp --format_endian big --pixel_order normal --image_format dxt5 --pixel_channel rgba
What i have is:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 00 40 70 00 00 00 10 00 00 00 10  ......@p........
00000020  00 03 00 00 00 00 40 60 00 00 00 10 00 00 00 10  ......@`........
00000030  00 04 00 00 00 00 40 50 00 00 40 50 00 00 00 10  ......@P..@P....
00000040  00 30 00 00 00 0A 00 00 00 80 00 80 00 08 00 04  .0.......€.€....
00000050  00 04 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 00 40 40 00 00 00 00 00 01 00 01 00 03 00 01  ..@@............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  FF 00 49 92 24 49 92 24 56 03 56 03 00 00 00 00  ÿ.I’$I’$V.V.....
00000090  FF 00 49 92 24 49 92 24 56 03 56 03 00 00 00 00  ÿ.I’$I’$V.V.....
000000A0  FF 00 49 92 24 49 92 24 56 03 56 03 00 00 00 00  ÿ.I’$I’$V.V.....
000000B0  FF 00 49 92 24 49 92 24 56 03 56 03 00 00 00 00  ÿ.I’$I’$V.V.....

Note the first 0x80 bytes are exactly like the original, so is pretty close like the original after rebuilding... but the problem is how the pixel data is ordered starting at offset 0x80... the original has lot of "zeroes" at left columns
Ok... to replicate this zeroes i made another rebuild and added another gim setting (the --pixel_alpha 255)
I also removed the --pixel_order normal because as far i saw it doesn't makes any difference when using format dxt5 (so his presence was pointless in my test before)

So by using this:
--format_style psp --format_endian big --image_format dxt5 --pixel_channel rgba --pixel_alpha 255
What i have is this:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 00 40 70 00 00 00 10 00 00 00 10  ......@p........
00000020  00 03 00 00 00 00 40 60 00 00 00 10 00 00 00 10  ......@`........
00000030  00 04 00 00 00 00 40 50 00 00 40 50 00 00 00 10  ......@P..@P....
00000040  00 30 00 00 00 0A 00 00 00 80 00 80 00 08 00 04  .0.......€.€....
00000050  00 04 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 00 40 40 00 00 00 00 00 01 00 01 00 03 00 01  ..@@............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  FF 00 00 00 00 00 00 00 56 03 56 03 00 00 00 00  ÿ.......V.V.....
00000090  FF 00 00 00 00 00 00 00 56 03 56 03 00 00 00 00  ÿ.......V.V.....
000000A0  FF 00 00 00 00 00 00 00 56 03 56 03 00 00 00 00  ÿ.......V.V.....
000000B0  FF 00 00 00 00 00 00 00 56 03 56 03 00 00 00 00  ÿ.......V.V.....

Grrrrr, again, pretty close but is another fail, the header is exactly like the original, and note there are lot ot zeroes added at the left columns as i intended (in the "pixel data" starting at offset 0x80)... so it looks better than the previous test but the result is not exactly like the original file

So well... in resume... im pretty sure this 3 options are correct, but there is some setting more needed to replicate it correctly:
--format_style psp
--format_endian big
--image_format dxt5
--unknown...

SonyBlack · 13/03/2015 10:21 PM

thanks that's was a understandable explaining for me.. i will test some settings.. thanks for your help man.. i will report if i found a solution :)

sandungas · 13/03/2015 10:41 PM

(13/03/2015 10:21 PM)SonyBlack Wrote: thanks that's was a understandable explaining for me.. i will test some settings.. thanks for your help man.. i will report if i found a solution :)

You made the question at a perfect timing, because im stucked in the same problem, heheh... i remember to see more images based in dxt5 with these zeroes at the left columns of the pixel data

I think this gim format is the second in order of "most used" inside ps3 rco's (or the third, but not much more because i don't think ps3 uses too much different gim formats, maybe 3 or 4 as much)

As a last hint (i can't help much, i hope zinga burga illuminates us)... what i understand is the problem is located in how the pixel data is ordered
You need to take a look at the options availables inside the Gimconv.cfg file and try some of the ones that are related with the pixel data
This is why in my tests before i used --pixel_channel rgba and --pixel_alpha 255 (because both does significant changes in how the pixel data is ordered starting at offset 0x80)

The problem with pixel channel is it allows for all combinations of RGBA channels in any order... this makes a total of 24 posible combinations (rgba, argb, gbar, barg, grab, etc...)
I suspect is needed to reorder this pixel channels... but well... is just one of the random things i was trying in my lasts attempts to identify them

Threaded Mode \| Linear Mode [PSP] Rcomage v1.1.1 - new RCO manipulation tool
Author	Message