Talk:Graphic Image Map (GIM): Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(4 intermediate revisions by the same user not shown)
Line 39: Line 39:
*'''frame_type''' with this values doesnt works
*'''frame_type''' with this values doesnt works


=0xFF (Fileinfo) examples from OFW=
*[[explore_plugin]]_full.rco/item_tex_cam_icon.gim
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00006AD0  00 FF 00 00 00 00 00 4C 00 00 00 4C 00 00 00 10  .ÿ.....L...L....
00006AE0  53 70 61 6E 61 2E 74 67 61 00 73 30 30 30 39 33  Spana.tga.s00093
00006AF0  37 00 53 75 6E 20 41 70 72 20 32 33 20 31 38 3A  7.Sun Apr 23 18:
00006B00  33 39 3A 34 38 20 32 30 30 36 00 47 69 6D 43 6F  39:48 2006.GimCo
00006B10  6E 76 20 31 2E 32 30 65 00 00 00 00              nv 1.20e....


=Frankensperiments=
=Frankensperiments=
Line 63: Line 72:
  000000E0  38 00 47 69 6D 43 6F 6E 76 20 31 2E 32 30 68 00  8.GimConv 1.20h.
  000000E0  38 00 47 69 6D 43 6F 6E 76 20 31 2E 32 30 68 00  8.GimConv 1.20h.


At the time the area at 0xA0 is loaded (block id 0x00FF intended to store the '''file_info''') the real header size is 0x10 but the value changed takes the next 0x10 bytes as part of the header... so it starts reading the ''file_info''' at offset 0xC0
At the time the area at 0xA0 is loaded (block id 0x00FF intended to store the '''file_info''') the real header size is 0x10 but the value changed takes the next 0x10 bytes as part of the header... so it starts reading the '''file_info''' at offset 0xC0


This is how it looks when this file is converted GIM to GIS, note the strings at the bottom how has been cropped
This is how it looks when this file is converted GIM to GIS, note the strings at the bottom how has been cropped
Line 97: Line 106:
  Originator "GimConv 1.20h"
  Originator "GimConv 1.20h"
  }
  }
Also, the length of the value marked in red is confirmed to be 4 bytes, it can be seen how the bytes are swapped when using the setting '''format_endian''' = little/big
=Links=
*https://en.wikipedia.org/wiki/PSGL
*https://research.ncl.ac.uk/game/mastersdegree/workshops/ps3introductiontogcm/tutorial6.pdf
*https://research.ncl.ac.uk/game/mastersdegree/workshops/ps3introductiontogcm/GCM%20Texturing.pdf (page 2 about pitch/height memory alignments)

Latest revision as of 11:50, 27 April 2018

Strings from GimConv EXE and DLL[edit source]

image_format 

RGBA8888....RGBA4444....RGBA5551....RGBA5650
INDEX32.INDEX16.INDEX8..INDEX4
DXT5EXT.DXT3EXT.DXT1EXT.DXT5....DXT3....DXT1

pixel_order 

NORMAL
PSPIMAGE
FASTER
GENERIC

level_type 

MIPMAP
MIPMAP2
  • MIPMAP3, MIPMAP4, MIPMAP5, etc... doesnt works (not valid)

Some hints about hierarchy at the most deeper levels 

IMAGE_INDEX
IMAGE_PLANE
IMAGE_LEVEL
IMAGE_FRAME

PALETTE_INDEX
PALETTE_LEVEL
PALETTE_FRAME

frame_type 

SEQUENCE

??? 

HOLD
CYCLE
DISSOLVE
EVENT
CONSTANT
LINEAR
  • frame_type with this values doesnt works

0xFF (Fileinfo) examples from OFW[edit source]

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

00006AD0  00 FF 00 00 00 00 00 4C 00 00 00 4C 00 00 00 10  .ÿ.....L...L....
00006AE0  53 70 61 6E 61 2E 74 67 61 00 73 30 30 30 39 33  Spana.tga.s00093
00006AF0  37 00 53 75 6E 20 41 70 72 20 32 33 20 31 38 3A  7.Sun Apr 23 18:
00006B00  33 39 3A 34 38 20 32 30 30 36 00 47 69 6D 43 6F  39:48 2006.GimCo
00006B10  6E 76 20 31 2E 32 30 65 00 00 00 00              nv 1.20e....

Frankensperiments[edit source]

Block header size[edit source]

This was made with the goal of identifying the last value at the block headers, the file is well formed but the value in red has been modifyed, originally was a 0x10 and has been changed to 0x20 

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 00 E0 00 00 00 10 00 00 00 10  .......à........
00000020  00 03 00 00 00 00 00 80 00 00 00 10 00 00 00 10  .......€........
00000030  00 04 00 00 00 00 00 70 00 00 00 70 00 00 00 10  .......p...p....
00000040  00 30 00 00 00 03 00 00 00 04 00 02 00 20 00 10  .0........... ..
00000050  00 01 00 02 00 00 00 00 00 00 00 3C 00 00 00 40  ...........<...@
00000060  00 00 00 60 00 00 00 00 00 01 00 01 00 03 00 01  ...`............
00000070  55 53 45 52 44 41 54 41 41 52 45 41 00 00 00 40  USERDATAAREA...@
00000080  CA 5E 11 00 CA 5E 12 00 CA 5E 13 00 CA 5E 14 00  Ê^..Ê^..Ê^..Ê^..
00000090  CA 5E 21 00 CA 5E 22 00 CA 5E 23 00 CA 5E 24 00  Ê^!.Ê^".Ê^#.Ê^$.
000000A0  00 FF 00 00 00 00 00 50 00 00 00 50 00 00 00 20  .ÿ.....P...P... 
000000B0  4E 4F 50 41 44 44 2E 42 4D 50 00 41 64 6D 69 6E  NOPADD.BMP.Admin
000000C0  69 73 74 72 61 74 6F 72 00 54 68 75 20 41 70 72  istrator.Thu Apr
000000D0  20 31 39 20 30 39 3A 32 32 3A 35 31 20 32 30 31   19 09:22:51 201
000000E0  38 00 47 69 6D 43 6F 6E 76 20 31 2E 32 30 68 00  8.GimConv 1.20h.

At the time the area at 0xA0 is loaded (block id 0x00FF intended to store the file_info) the real header size is 0x10 but the value changed takes the next 0x10 bytes as part of the header... so it starts reading the file_info at offset 0xC0

This is how it looks when this file is converted GIM to GIS, note the strings at the bottom how has been cropped 

.GIS 1.00

Picture "picture-0" {
	Image "image-0" {
		Format RGBA8888
		Order NORMAL
		Width 4
		Height 2
		PitchAlign 16
		HeightAlign 1
		PlaneMask 0x00000000
		LevelType MIPMAP
		LevelCount 1
		FrameType SEQUENCE
		FrameCount 1
		UserData "userdata-0" {
			0x52455355 0x41544144 0x41455241
		}
		Pixels "pixels-0" RGBA8888 NORMAL 4 2 16 1 {
			0x00115ECA 0x00125ECA 0x00135ECA 0x00145ECA
			0x00215ECA 0x00225ECA 0x00235ECA 0x00245ECA
		}
	}
}

FileInfo "file_info-0" {
	ProjectName "istrator"
	UserName "Thu Apr 19 09:22:51 2018"
	SavedDate "GimConv 1.20h"
	Originator "GimConv 1.20h"
}

Also, the length of the value marked in red is confirmed to be 4 bytes, it can be seen how the bytes are swapped when using the setting format_endian = little/big

Links[edit source]

Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Talk:Graphic_Image_Map_(GIM)&oldid=49266"