Ok, pure gold:
QUOTE(Mirage)
a palettized texture means that it's build up of a palette and the actual texture with 'pointers' to those colours.
eg. if the beginning of your palette looks like this: 00 00 00 FF 20 30 40 FF AA BB CC FF and the beginning of the texture looks like this: 0 2 1 0 then the actual RGB data on the screen would be: 00 00 00 AA BB CC 20 30 40 00 00 00
Now, continuing to look at the loadsc0.txd file... Format hacking also involves guessing a lot...
I'm going to GUESS it's a big texture, because the file is called LOADingSCreen0... I'm placing my bet on a 512x512 texture so it can encompas most of the xbox screen (640x512)
1. the palette info ends at $0490
2. the filesize is 263336 bytes
3. 512x512 = 262144
Now, the filesize minus the palette and the beginning of the header equals 263336 - $0490 = 262168
but, 262168 (raw data) -262144 (texturesize) = 24, so i've got some extra data not encounted for... my first guess would be at the beginning of the raw data, but there are just zero's there so i look at the end of the file...
And that's exactly where i find the extra data... from $40490 till $404a8... 24 bytes
So, now I know the raw data I should be looking at is from $0490-$40490, as that is where my 8 bit palettized texture is
save that datablock and load it into photoshop as a raw 512x512 image and see if you see any patterns
QUOTE(Xmax)
As for the patterns, there certainly are.
As a matter of facts, this image is far from being just "white noise", as there are quite clear correlations in the pixels' structure.
The first thing you would notice is that there are "stripes" of pixels that are more "correlated" than others.
The effect is evident looking for both "horizontal" and "vertical" stripes, but on "vertical" ones it is even possible to "see" sort of "lines" that subdivide the strips. Note: those lines are not "made of" pixels, they are rather a sort of "immaterial" lines between a pixel and the adjacent one. You get what I mean?
The most evident vertical "lines" are placed at a distance of 64 pixels each other, thus subdividing the whole 512 pixels image width in 8 vertical stripes.
Try to adjust the your viewer at different zoom levels if you find hard to spot them at first. Can you see them?
Going further, you would also notice that the "median" line placed at 1/2 of the width and the two "sub-median" lines placed at 1/4 and 3/4 of the width are a bit more evident than the others.
On the other side, there are other "lines", less evident though, at a finer grain, further subdividing the image in 16 strips (32 pixels of distance), 23 strips (16 pixels of distance), etc. If you zoom very hard you should be able to see this process going down further to 2 pixels wide stripes (you will be able to find here and there some lines of "blocks" of 2x2 pixels).
Of course, all the above applies also to the other dimension (i.e. "horizontal" stripes instead of "vertical" ones).
So, "what does it all mean?", you would ask...
Let's assume that what we are looking at is a "scrambled" image i.e. an image obtained by "displacing" the pixels of the original, according to a given algorithm(which may be untrue but seems a reasonable starting point).
A "scrambling" algorithm that may lead to this correlation structure is the following:
1. take the original image, subdivide it in 2 vertical slices, then swap them.
2. on the resulting image at point 1: subdivide it in 4 vertical slices, then swap them
3. on the resulting image at point 2: subdivide it in 8 vertical slices, then swap them
4. Go on like this until you will swap slices that are 1 pixel width (you will always come to this condition if the width of the original image is a power of two, which holds true for our test image ;-)
5. Repeat the above process, but using horizontal slices instead of vertical ones.
6. Done.
The above algorithm may have a number of "variations", the most important being the case where the slices are not only "swapped" at each step, but also "mirrored" in the process, either along a vertical or horizontal axis.
A good point of this algorithm is that it is totally reversible: i.e. you can use the very same algorithm for scrambling and unscrambling. Also, what kind of swaps you perform first (i.e. the horizontal, or the vertical ones, the finer grain or the gross grain, etc.) shouldn't matter for the final result, giving a bit of "freedom" in the implementation.
Now, writing a little proggie that takes that 512x512 "raw" image and perform those swaps (+ eventually mirrorings w/ different options) so that the results can be analysed with photoshop, shouldn't be a huge work.
Any coder to join?
@Cyclone, I know you are a very fast one when it comes to delivering apps. (and we've already synergized like this in the past ;-) Would you like to try this out? :-D
QUOTE(Cyclone)
@Blitz: Looking at country.txd (or loadsc0.txd-just replace 256 by 512 everytime):
We know that the image is an 8-bit 256x256 image (from TXDWorkshop)
we know the filesize is 1192+(256x256) bytes
This means each pixel in our 256x256 image occupies ONE byte of data. Follow so far?
This ONEtoONE of one byte per pixel suggests there is NO compression.
This single byte is a number 0-255 that you look-up in the palette table that preceeded the image block.
Straining my brain I think I remember the palette table being:
-triplets in an Windows format BMP (as in R,G,B,R,G,B...)
-------i.e. the preceeding (256*3=)768bytes
-quartlets in OS2 Bitmaps (R,G,B,A,R,G,B,A...)
-------i.e. the preceeding (256*4=)1024bytes
RGBA (=Red, Green, Blue, Alpha)
Which is why you see the repeating xFF for maximum alpha value
Thus an OS2 format Bitmap, understand now?
Therefore I would expect the palette data to start at (1192-1024=)168 bytes in.
You can:
-Ignore Mirage on one point: you don't need to save out the datablock Photoshop7+ will do that for you smile.gif -see attached image
-RENAME file to .RAW & open in Photoshop enter 256x256 by 8bit & header offset as 1192
-You see your image as was seen in TXDWorkshop
@ _Mirage_: IMHO you're wrong about those 24bytes, if you also look at country.txd you will see the palette does start off at 168bytes in & you are reading too much into the data you've seen in loadsc0.
@Xmax et al.:
http://forums.xbox-s...dpost&p=2784863 for preliminary source code
This post has been edited by Cyclone: Today, 07:42 AM
QUOTE(xmax)
Of course! As you wish! :-)
Oh, and don't forget to <quote/ ="be sociable"> too!
rolleyes.gif
[EDIT-1]
I only now see your link to the swizzle topic on X-S!
Guess you're right! (and I hope I didn't reinvent the wheel actually... LOL)
If I look at the images attached some posts below:
http://forums.xbox-s...dpost&p=2785143I've got a strange deja-vu feeling (talking about the first image, not the second! tongue.gif )
[EDIT-2]
Looking closely to the algorythm you referenced to (swizzle/unswizzle block functions), it looks like:
+ the swizzle function recursively works on halved and halved square blocks (1/2, 1/4, 1/8, etc... of the original image width/height) until it reach a 2x2 pixel block (in the input image)
+ on that block the "scrambling/swizzling" is performed by copying those four pixels as a "row" in the output image. i.e. if the input image has those four pixels at a given offset:
CODE
+--->
|AB
|CD
V
in the output image the pixels are re-arranged this way:
CODE
+----->
|ABCD
V
+ doing some recursive steps more, and if I'm not wrong, a 2x2 grid of adjacent blocks in the input image:
CODE
+------>
|AB EF
|CD GH
|
|IJ MN
|KL OP
V
should produce the following output:
CODE
+---------------------->
|ABCD EFGH IJKL MNOP
V
+ and so on, recursively, for greater and greater 2x2 blocks, until all of the image is swizzled.
The opposite (i.e. from "continuous rows" to "2x2 blocks") is done by the "un-swizzle" function.
Now, this algorithm is *different* from the one I posted, but due to its "recursively-halving" nature, I would expect it to give as output the same "correlation" pattern I described some posts ago. (moreover, the same pattern is present on the deja-vu image posted as example on X-S).
So, I agree with you that it's worthy to also explore this algorithm (and its variations) on our screen loader image.
If in the end none of them will work, we may always decide to get in contact with cypher... ;-)
Expect something done soon
