One of the advantages stated about the new texture pack format is that "It will also allow us to mix and match block artwork resolutions" however, it does NOT properly detect non-standard resolutions of blocks (see attached). In the attached sreenshots below, the texture sizes on the blocks that are not mapped properly are 15x and 17x. Instead of properly detecting these resolutions and mapping them properly, the game maps them to the next larger standard (power with a base of 2. 2^4, 2^5, 2^6 ect.) 15x is mapped to 16x, and 17x is mapped to 32x.
Why would anyone want non-standard resolution items? Well, mainly so you and actually have 1 px in the middle instead of jacking the resolution up so high that the middle looks small! 15x will allow you to have objects that actually come to a point in the middle, instead of looking dull or not being centered in the texture space. And lastly, people do it BECAUSE THEY CAN. There is no technical reason why textures should need to be these standard sizes anymore, so we SHOULD be able to use odd resolutions as they have their purpose just as even resolutions do. (Here is the original idea and explanation behind using odd resolutions alongside even ones)
Also attached is my stitched terrain file. It has 21 textures that are 15x (I was excited that they would work, and let down as always), and it has put yellow pixels that become transparent in-game. Also notice it is not square, but doubled due to the amount of textures, and also most of that is unused. It would save space if all of the non-standard resolution textures were put into a different sized image, stitched_terrain_npot.png instead, that way they could also map correctly. Or, it could even stay on the current stitched images, but just be mapped correctly.
2^n sized textures are not required on newer hardware, basically any hardware that supports OpenGL 2.0 or higher.
EDIT: I have become aware that this issue does not just affect non-standard resolution textures, but also smaller standard resolutions, such as 8x, 4x, 2x, and 1x, which are mapped to 16x if you try them.
Attachments
Comments 15
It was possible to do it in the old texture pack format , so no, it's not impossible. I'm sure Mojang could easily make them work if they worked on the resolution mapping code. Also a quick search reveals it is possible, but will not allow MIP mapping. So needing 2^n textures is something that applies more to older hardware.
Working with non-power of two on the old system was limited to high-end video cards that correctly mapped noncompliant textures. They were prepared to handle user error. Using textures with incorrect resolutions is user error and usually not handled very well by the graphics card.
What they can do about this instead is add a width and height parameter to the texture pack. You would still use power of two resolutions, but only display a certain part of it. So if you specify your textures are 17x17, you'd use a small fraction of a 32x32 texture while the game maps only the 17x17 section. This adds the functionality you need while also respecting the basic requirements of video cards.
Just because something is defferent, does NOT mean it is a user error. If someone accidentally cropped an image, that would be a user error. Intentionally doing so is a choice, not an error. Non-standard != incorrect. And no, it was not limited to "high end video cards" just newer cards/computers as most newer systems support it. I have an nVidia GTS 450 (not really a high end card from 2010) and it supports it. (you can check in Minecraft with Snooper, ;ook for ARB_texture_non_power_of_two) EDIT:had to modify it to stop it from being seen as a link...
For older hardware, yes, they could do what you're saying, if that would work. Once again, I don't think that this is a restriction/basic requirement anymore (for newer hardware). From here it says "it is generally a good idea to keep using power-of-two textures unless you specifically need NPOTs. Mip-mapping with such textures can have slightly unintended consequences, compared to the power-of-two case." and also "All newer hardware can handle NPOTs of any kind perfectly."
But anyways, I have tried 15x textures on a netbook from 2008 that doesn't support non 2^n resolution textures (old netbook with no dedicated graphics chip, not surprising at all), and it didn't crash, but instead would not load the terrain.png, instead loading the terrain from the last selected texture pack. If they would do something like you said (once again, if it would work), that'd be great. However, even if they did something that was only supported on newer hardware that did not make any attempt, that would be better than nothing (Minecraft generally doesn't perform that well on older/cheaper hardware anyways).
When I test a 4x4 texturepack it works fine.
Can you please produce a link to the actual texturepack used?
Also, you best make sure that for 1.5 the individual textures are ACTUALLY smaller in size. The Atlas stitchers cares very little for what size texture you input, but if you are padding it with transparant areas it will indeed not work as you hope.
Also almost all videocards lie about supporting 'non-power-of-two' textures, for this reason that codepath is simply turned off by default. Again this has nothing to do with what sort of input textures you have, it only matters for the output texture (so you can have a 129x128 texture rather than forcing that to be 256x128)
Also the textures are mapped to texels that have a size with multiples of 16 as that is what would be required to do 3 levels of mipmapping without getting bleeding. This was a requirement for the new engine.
The screenshots I originally took were cropped to those resolutions (I've uploaded an example texture which you can open in a new tab and see that it is 4x4).
I also unstitched this texture pack and there was still an issue.
All of the textures definitely are the exact size specified, no transparency in them. The the transparency seen is the atlas stitcher places the textures inside of a box sized at the smallest standard-resolution it can fit in, and then the game reads that box as well instead of the original texture size.
All I know on that is I tested out odd resolutions in the old pack format, and it worked on my current computer, and didn't work on my older computer (it would not load the terrain file). This is also consistent with what Minecraft reported to me through snooper-ARB_texture_non_power_of_two was true in the new computer and false in the old computer.
Anyways, you should try to get small resolution textures and non-standard resolution textures working. Disable MIP mapping for them if you have to. Quite a few people use small resolutions, and non-standard resolutions will open up new designs for artists that aren't possible in standard resolutions, and without the devotion it required in the old pack format.
Awesome, the 4x4 texturepack i did try was actually lying it ass off, and it just had 4x4 4x4 pixel blocks each textures (so they were still 16x16).
Fixed the bug that creates the holes and for the time being we also stopped 'scaling' the texture for a certain mipmap level, this packs the icons tighter when they are not 16x16.
It should now also work fine for 15x15 textures, it actually shouldn't even care what the size of the texture is, as long as it is square.
Thank you very much for getting this fixed! Now my broken textures work! http://i.imgur.com/kZ71Pj4.png
Could support for this be touched up a little?
With the snapshot implementation of MIP and anisotropic filtering, odd-resolution textures are sometimes messed up instead of ignored.
A small issue that seems to have been fixed (odd-resolution textures not scaling properly due to MIP) seems to persist if MIP is turned on only after anisotropic filtering. Starting the game with both on or turning on anisotropic filtering last will prevent the issue.
Having anisotropic filtering on causes odd-resolution textures to not display correctly in their extruded state (hand, ground, item frame). They seem to not scale the texture correctly, but it also looks like the faces that make up the model aren't being scaled correctly, or they are offset for some reason.
Lastly, a very minor issue that has always existed after this issue was closed: items (with odd-resolution textures) in the inventory are re-interpolated just slightly. This is noticeable mostly on diagonal lines, because it decides to skew some of the pixels. considering the sprites are usually displayed much larger than their native resolution, is this really necessary? Can't the sprite be instead located as close to the center as possible, and then stretch the entire sprite horizontally by one native-screen pixel so the width is even?
Erik Broes
Yes, texture sizes need to be powers of two because the video hardware requires it. You can't change the way chips work.