koobas.hobune.stream
GetPixels returning skewed results on DXT5 Texture
I'm making a 2D game in Unity, and I'm trying to use Texture2D.getPixels with a DXT5 compressed texture in order to make a spritesheet. It isn't coming out quite right.
Here's the original texture:
And here's what it looks like after using getPixels() to grab all of its colors, and write it into a new Texture:
Any ideas as to why this might now be working? I've tried this with uncompressed images, and it's worked just fine. It's clearly grabbing the colors, but the resulting image is transformed somehow.
If you need more information, let me know.
EDIT:
I'm using a modified third party tool to create spritesheets and sprite animations in the editor. The sprites are grabbed from the spritesheet at runtime...which may be the solution to the main memory problem. If the actual animation frames aren't needed after making the spritesheet, then I may not need to keep the textures in the editor. I'll try that later and let you know if that works. I don't know offhand if the tool needs the textures to remain in the editor after the spritesheet is built.
Back to the problem at hand: That one line of code is executed in the editor at development time. The texture I'm using is a NPOT .png, resolution 625x226.
The target platform for the game is PC, hypothetically XBox if we can get it done enough. I don't think this matters too much, as we need the textures at development time.
Here's the line where I actually do the GetPixels() call:
_dest.SetPixels(x, y, num5, num6, _src.GetPixels(num3, (_src.height - num4) - num6, num5, num6));
Where: _dest is the destination texture, a spritesheet much larger than the source sprite
x and y are the location in the spritesheet where the source texture will be imported
num5 is the actual width of the sprite (not counting transparent pixels)
num6 is the actual height of the sprite (not counting transparent pixels)
_src is the source texture that contains the sprite
num3 is the x-location of the upper-right corner of the sprite in the source texture
num4 is the y-location of the upper-right corner of the sprite in the source texture
EDIT: The texture is on Advanced import settings
Have you tried making it it non-power of 2 in the import settings?
Ideally if it's going to be a 2D image like a sprite, change its import type to GUI.
I also seem to remember that only certain formats play nicely with GetPixels. ARGB32 and RGBA32 I'm fairly sure work, for example.
Wouldn't making the texture a non-power of 2 scale the sprite? I'd like to keep it at its current size.
I tried changing it to GUI, but it didn't fix the problem.
That's what I've read, but the fact that I can actually get some pixel values from GetPixels() is encouraging. I just need to figure out what it is about DXT compression that doesn't make it work.
That, and we have a TON of sprites in this game, and importing them all on a Truecolor setting is going to take up too much memory.
I am assu$$anonymous$$g your image isn't a power of two. In which case, Unity will scale it to power of two. However part of the GUI import type allows non power of two.
Change the import type to Advanced and see what effect different formats there have, like I mentioned, I'm sure RGBA32 solved my similar issue.
I've had the texture import settings on Advanced, I'll make a note of it in the original question.
As for the other settings, I've run through all of them with the same result: Anything that is compressed fails, everything else works.
However, I cannot leave the textures in as RGBA32. It takes up too much memory for our purposes. Hence why I'm going through all this trouble to get them in a compressed format.
But I thought you were adding them to a sprite sheet for use in the game, meaning that this image will not actually be used, only the sprite sheet?
Yes, the actual problem is that the game runs out of memory on a fresh load. Last time I checked out the project from our repository, Unity.exe used up 3.5 million $$anonymous$$ on the startup import and crashed. I opened it again, and then had to reimport everything that didn't load properly, and even then it sometimes would crash.
Is this not actually as big a problem as I made it out to be?
Well, this looks like your target texture's width is off by one. Without seeing the code which you use to copy the image it's impossible to say anything. GetPixels returns a "flattened 2D array". What you see here is the typical case where you write a flattened array to a greater or smaller image. In this case i would guess the target size is one pixel larger than the source. That means each row has an additional pixel which originally was on the next row.
I've checked the width/height values of both source and target, and they check out. Furthermore, they don't change when I shift from Truecolor to compressed, so that leads me to believe that may not be the case. I'll post the code that does the read/write of the pixels above.
