Closed rickgaiser closed 6 years ago
What's the smallest Texture-Size (grid in pixels) and Texture-RAM to be allocated on the GS anyway? Is 1KB the smallest? I thought it is 4KB?!
If this helps in getting the same benefits for PNGs like for BMPs (+transparency and a bit better colors THX to the PNG-Format; low VRAM-Space; less used transfer-bandwidth), I am all for this change!
Edit: If it is to spare some VRAM (especially if a lot small textures are used) I am all for it as well!
The TEX_0 register is used to specify the texture of the polygon, but the width is specified via Texture Base Width (TBW). TBW is in units of 64 pixels (does not always directly translate to bytes).
The Texture Base Pointer (TBP) is also in units of 64 (word address / 64). So even if you tried to save space by shrinking another texture, you are restricted by the alignment requirements of the hardware.
There is also some restriction on column sizes due to the layout of its DRAM, as documented in chapter 8.1. But perhaps it is as you wrote - there is not an as-strict restriction on the height (due to chapter 8.1).
@TnA-Plastic Portable Network Graphics (PNG) is a graphics file format. We will decompress the file to get its pixel data, which will be uploaded to the GS. A bitmap file (BMP file) provides the same thing, but we just don't have to decompress anything.
Looking at chapter 8.3.1 the width can be a multiple of 32 instead of 64 for PSMCT32/24. The height can also be a multiple of 32 instead of 64. Note that these are sizes for memory allocation puposes only.
TBW must be a multiple of 64, but this is independent of the allocated memory.
TBP must be aligned to 1 block (256 byte), but that's a really small size compared to the minimum texture size of 2 pages (16 KiB) we're using right now.
I agree. So it does seem that we can relax the restriction on the height. If you are willing to, please make a suitable patch and I shall merge it in.
Not just the height, but also the width. I will test and make a patch.
I'm closing this because I think it was fixed in 26b70e7.
Reading the documents I believe we're allocating too much VRAM for some bit depths.
For instance: a 32x32 32bpp icon, should only need 32x32x4 bytes allocated. But instead we're allocating 64x64x4 bytes (2 whole pages!). That's 4x the size we actually need.
Applications with lots of small icons will use too much VRAM this way.