answered Can a Randomizer of Colosseum/XD be possible with a Shadow Pikachu, for example?

[StarsMmd]

I was feeling up to the challenge so I wrote an app for replacing a texture with an edited png. It wasn't particularly difficult after all.

Forgive the crappy fairy type image. I was improvising using the colours from the pallet. I've noticed that the pallets repeat a lot of colours so it should be possible to replace those colours with whatever we like. Just need to keep the compressed file size in mind.

[psy_commando]

[ATTACH=CONFIG]12332[/ATTACH]

I was feeling up to the challenge so I wrote an app for replacing a texture with an edited png. It wasn't particularly difficult after all.

Forgive the crappy fairy type image. I was improvising using the colours from the pallet. I've noticed that the pallets repeat a lot of colours so it should be possible to replace those colours with whatever we like. Just need to keep the compressed file size in mind.

Looks pretty good !

And yeah, images are pretty easy to work with most of the time. As long as they're not encoded!

And have you tested it in-game ?

[StarsMmd]

Looks pretty good !

And yeah, images are pretty easy to work with most of the time. As long as they're not encoded!

And have you tested it in-game ?

I've been refining the code so haven't tested yet but was just about to. I'm pretty confident since tiledggd opened it the same way with the same settings. Hopefully there aren't any tricks I haven't noticed.

[psy_commando]

I've been refining the code so haven't tested yet but was just about to. I'm pretty confident since tiledggd opened it the same way with the same settings. Hopefully there aren't any tricks I haven't noticed.

Well, the main concern is the header and data structure.

Tileggd ignores the header, but the game needs it to parse the image properly. That's why its not all that much of a good indication to look at it in Tileggd.

[StarsMmd]

Well, the main concern is the header and data structure.

Tileggd ignores the header, but the game needs it to parse the image properly. That's why its not all that much of a good indication to look at it in Tileggd.

It worked !

Also, could I get you to look at the textures in colosseum and tell me what you think? They have a slightly different format which is almost identical but without any pallet data as far as I can tell. Thought you might have some insight as to where the pallets may be. I was thinking maybe a pallet that colosseum shares for all the textures? I've noticed a lot of these textures are reused in .

[psy_commando]

It worked !

[ATTACH=CONFIG]12335[/ATTACH]

[ATTACH=CONFIG]12336[/ATTACH]

Also, could I get you to look at the textures in colosseum and tell me what you think? They have a slightly different format which is almost identical but without any pallet data as far as I can tell. Thought you might have some insight as to where the pallets may be. I was thinking maybe a pallet that colosseum shares for all the textures? I've noticed a lot of these textures are reused in .

Nice!

And I've taken a look, but I can't seem to figure it out for sure. The format of the pixels differs from though, so its possible there aren't any palette involved.

From looking at the repeating patterns, I'd guess they probably encoded pixels on 2 bytes. Possibly 5 bits per color, and 15 bits per pixels. Its not all that common, but it kinda looks like that.

Especially since the highest bit of every groups of 2 bytes is always set to 1 in colosseum's pokemon portraits. And in 15bpp images, that bit is either ignored or possibly used as 1 bit alpha.

Now, the problem is that I don't know any viewers that handle 15bpp, so you'd probably have to write some code to convert the pixels to a 16bpp/32bpp bitmap or png, and see if it works.

Its probably just something as simple as this:

uint16_t rawpixel = 0x8C84; //Example value

uint8_t r = ( pixel & 0x7C00 ) >> 10;
uint8_t g = ( pixel & 0x3E0  ) >> 5;
uint8_t b = pixel & 0x1F;

Or maybe the opposite order.

[StarsMmd]

Nice!

And I've taken a look, but I can't seem to figure it out for sure. The format of the pixels differs from though, so its possible there aren't any palette involved.

From looking at the repeating patterns, I'd guess they probably encoded pixels on 2 bytes. Possibly 5 bits per color, and 15 bits per pixels. Its not all that common, but it kinda looks like that.

Especially since the highest bit of every groups of 2 bytes is always set to 1 in colosseum's pokemon portraits. And in 15bpp images, that bit is either ignored or possibly used as 1 bit alpha.

Now, the problem is that I don't know any viewers that handle 15bpp, so you'd probably have to write some code to convert the pixels to a 16bpp/32bpp bitmap or png, and see if it works.

Its probably just something as simple as this:

uint16_t rawpixel = 0x8C84; //Example value

uint8_t r = ( pixel & 0x7C00 ) >> 10;
uint8_t g = ( pixel & 0x3E0  ) >> 5;
uint8_t b = pixel & 0x1F;

Or maybe the opposite order.

Ah that makes sense. The palettes in use that format as well. If it turns out to just be 2 byte colours then that should be easy enough to convert to a bitmap. It would be rather tedious to do again though so I think I'll pass on this one for now.

[psy_commando]

I just realized something

For some reason, I just completely derped and read bits as byte on the user interface.. even though I've used that thing for nearly a million times before ^^;

And I got it to show up:

16 bits per pixels, RGB, little endian, tiled 4x4.

And the start offset is 0x80.

[StarsMmd]

I just realized something

For some reason, I just completely derped and read bits as byte on the user interface.. even though I've used that thing for nearly a million times before ^^;

And I got it to show up:

[ATTACH=CONFIG]12341[/ATTACH]

16 bits per pixels, RGB, little endian, tiled 4x4.

And the start offset is 0x80.

Sweet. you're really good at this. Okay, so there's just one more if you don't mind. I n "genius_logo.fsys" and "nintendo_logo.fsys" there are the images that come up when the game starts up. I've been comparing the headers between the other two texture file types we've seen. The ones have 0x8 at around the 5th byte and are 8 bits per pixel. The colo ones have 0x10 for the same byte and are 16 bits per pixel. Therefore, I believe the logos are 4 bits per pixel from the header. The first 4 bytes are the width and height (usually) and for the logos they are 640x480. The combination of these works out in Tiledgggd. However, once again I get a good enough image to see what the image is meant to be but I can't get it to show perfectly. I really thought I could figure this one out...

[psy_commando]

I tried taking a look at those, but they're a little odd.

Looking at the empty pixels, there seems to be a repeating pattern every 10 bytes.. And I can't get the image to display properly in any formats either. At 4-8-16 bpp there are still gaps between valid pixels that have an odd coloration..

It might be possible to figure it out by editing some pixels and running the game to see what happens, but that's pretty tedious with this game.

[StarsMmd]

I thought so. I think the header says its 4bits per pixel ( so one bit per channel) and it isn't indexed . That means each colour is only half a byte but tiledggd has a minimum of 2 byte colours. The nintendo logo only has black and red while the genius sonority logo only has white and blue. 2 very simple colours for each. So I assume each pixel only needs half a byte. Do you know any tile viewers that can handle 4bit colours?

[psy_commando]

I doubt it works that way. If it was only 2 colors, it would be 1 bit per pixel.

But the image has gradated colors. So its not just 2 colors, but several.

I'm guessing there's probably something we've missed in there.

The alternating patterns would create faint vertical blue strips on the resulting image. But it actually doesn't.. So either some bytes are ignored, or either they got a particular purpose

[StarsMmd]

I doubt it works that way. If it was only 2 colors, it would be 1 bit per pixel.

But the image has gradated colors. So its not just 2 colors, but several.

I'm guessing there's probably something we've missed in there.

The alternating patterns would create faint vertical blue strips on the resulting image. But it actually doesn't.. So either some bytes are ignored, or either they got a particular purpose

I don't mean a 2 colour palette. I mean each pixel is 4 bits. 1 bit alpha, 1 bit red, 1 bit green and 1 bit blue. I feel like this gives really basic colours and since each pixel is only half a byte, the images are actually pretty high resolution. They could for instance alternate between blue and black pixels to produce a dark blue when viewed on a screen, since our eyes wouldn mix the pixels. This is mainly a theory but it fits with the file headers saying its 4bits per pixel and would explain the weird alternating patterns that don't show up when the images are viewed in game.

What do you think?

[psy_commando]

I don't mean a 2 colour palette. I mean each pixel is 4 bits. 1 bit alpha, 1 bit red, 1 bit green and 1 bit blue. I feel like this gives really basic colours and since each pixel is only half a byte, the images are actually pretty high resolution. They could for instance alternate between blue and black pixels to produce a dark blue when viewed on a screen, since our eyes wouldn mix the pixels. This is mainly a theory but it fits with the file headers saying its 4bits per pixel and would explain the weird alternating patterns that don't show up when the images are viewed in game.

What do you think?

Well, usually 4 bits per pixel images use a palettes. 4 bits is enough to count from 0 to 15, so that allows 16 colors. While the approach you're suggesting would be 2*2*2 colors, which is 8 possible colors. So by using the same space, you have less possible colors. That doesn't seem like it would make much sense, since the space saved is minimal, and the image is compressed anyways.

And, I doubt the gamecube interpolate pixels like that. I don't really see why they'd do that vs displaying the actual image at the screen's resolution in a single pass, there is no benefits. I guess the best way to know for sure would be to dump the frame buffer and or back buffer when the image is drawn, and look at how the raw pixels are organized. That would be a good lead. Or maybe just taking a screenshot, but then you'd have to deal with whatever file format its saved in.

[StarsMmd]

It's been a while since I played on a gamecube but don't all the ngc games use that same nintendo logo athletes e start. It would seem that every game is required to include that image and display it as soon as the game loads. incolo/xd it is bundled in a .fsys file which is as far as I know a file format which only thise games use. It's possible that each game chooses how to handle displaying the logo and if so, comparing with ither games may shed some light on what's going on. I'll see if I can extract it from some ither ISOs and compare.

[psy_commando]

That could help. But yeah, each games handles the logos differently, depending on the image formats it uses.

[StarsMmd]

I gave up on the logo textures for a while but then I stumbled across a texture which the header states is 4bpp and indexed. The pointer to the palette points to a 16 colour palette confirming that the image is indeed 4bpp. This reinforced what I said earlier about the 5th byte in the header being the bpp for the texture. So I decided to investigate the logo again with the following assumptions:

1. The 5th byte indicates that the image is 4bpp.

2. The first four bytes indicate 640x480 dimensions for the image. This makes sense as it gives a 4:3 aspect ratio and the image is displayed full screen. This also adds reinforces the 4bpp info since the number of bytes in the texture is half of 640x480 meaning each byte must be 2 pixels.

3. Tiledggd assumes that the image is indexed if you specify 4bpp.

Therefore, I decided to add a palette to the end of the the file. I made a 16 colour palette where each colour in the palette was the 16bit equivalent of the 4bit colour that would lead to that index. With a tile size of 8x8, this resulted in the following image:

You can see the rough outline of the nintendo logo but it is still very messy. Try looking at the image through a phone's camera from a distance and you can quite clearly see the nintendo logo. Like you said earlier, it makes more sense for 4bpp images to be indexed. The logo looks white from a distance and clearly not red like it is when it's viewed in-game.

From all of this I've come to the conclusion that, although each pixel is indeed 4bits, they aren't colours. My best guess is that each 4bit pixel only contains a 4bit alpha channel. I know that in iOS development you can load an image as a 'template'. In simple terms this ignores the colour values of each pixel, leaving just alpha values. The image can then be assigned a 'tint colour' and each opaque pixel will be displayed as that colour.

I reckon that the file only contains alpha values and is only assigned the colour red when it is loaded. The image would then probably be placed in front of a black background.

I updated the palette so that the index each 4bit value will be converted to has the 8bit equivalent of that alpha value and a red channel of 0xFF. This simulates the effect of adding the red colour to each pixel later. This is what I got:

However, I'm definitely still missing something. From the distribution of opaque and transparent pixels it looks like the pixels aren't properly aligned. Maybe I've got the wrong tile size or I've made an incorrect assumption somewhere. I think the way forward will be to change the values of some of the bytes and see how they look when the game loads them. That's going to be really tedious and I'm not interested enough to do that right now.

nintendo logos.rar

[StarsMmd]

In response to the original question, I've found the ASM function which determines whether the pokemon's shiny model is used or not. This calls the function that calculates whether it is shiny or not. We can quite easily change this to decide whether it uses the shiny image based on if it's a shadow pokemon. The only thing stopping us from using shadow textures for all shadow pokemon is that the model formats aren't understood yet. It would be possible to do it on dolphin by dumping then replacing the textures for every shiny pokemon in the game. Of course, it goes without saying that there would be no shiny pokemon anymore. Personally I would happily make that trade. I haven't had any luck with extracting textures from the model files though...

[StarsMmd]

I've just posted some patches for the game files which will allow the game to be played randomised.

http://projectpokemon.org/forums/showthread.php?46875-First-Pokemon-Colosseum-Randomised-Hack-!!&p=206986#post206986