Open muzikbike opened 2 years ago
Pre-13w02a seems to have the same difference in the x.
Judging by all the screenshots and other info I could dredge up on both pre-13w18a missing textures, the wonky x and co. seem to be the only type that ever existed, rather than there being a whole array of different pixel differences across characters inconsistent across platforms or even sessions, at least from what I saw. So hopefully this news isn't too terrible.
:/ I really thought I covered everything, evidently I didn't. Really sorry, I'll look at this today after I've woken up a bit.
@muzikbike I found another one. Java 1.6.0_65-b14-468 (Apple legacy Java 6 runtime), MacOS 10.14.6.
I've seen both of these variations in bug reports, so I'm not sure which is supposed to be the correct one. I think I'll temporarily note that the generator looks to be inaccurate in the README until I fix whatever is causing this. I'm really sorry about the inconvenience!
On the topic: I'll need to check this more rigorously, but it seems the "unknown" OS I posted earlier might have been Ubuntu according to some recent samples.
What version of Java did you use to generate the original Mac version you posted, anyway?
I also think that this missing texture generator should be moved to the deterministic category, or to a new "system-deterministic" category, since it's much closer to stuff like the newer missing textures than it is to lava and co.
@muzikbike I believe that the cause of this issue is that you're running MC-TextureGen with a different version of Java than the one you used to run Minecraft with!
Minecraft 1.5.2, Java 1.8.0_51 (Windows 10):
Cropped:
Minecraft 1.5.2, Java 11.0.10 (Windows 10):
Cropped:
Running MC-TextureGen with each respective version of Java produces results identical to the dumped textures from Minecraft 1.5.2. Note that the Java 8 one is identical to the one you generated with Minecraft 13w02a, and the Java 11 one is identical to the one you generated with MC-TextureGen. It looks like newer versions of Java changed the way that fonts render on Windows, which is worth documenting.
With note to your recent comment: I agree that I should make a new category for this type of image. I think the first texture I generated was generated with Java 16. Here's a few for the record (all generated on MacOS 10.14.6):
That is relieving.
Worryingly, WinMerge points out some extremely, extremely subtle differences between your generated Retina antialiased texture and the one listed in https://bugs.mojang.com/browse/MC-7208 - with the differences being a single number (for example 194, 194, 194 instead of 193, 193, 193). I'll document these separately for now and just hope the program is still working as expected and that maybe mspaint introduced weirdness like this while cropping or something.
Worryingly, WinMerge points out some extremely, extremely subtle differences between your generated Retina antialiased texture and the one listed in bugs.mojang.com/browse/MC-7208 - with the differences being a single number (for example 194, 194, 194 instead of 193, 193, 193). I'll document these separately for now and just hope the program is still working as expected and that maybe mspaint introduced weirdness like this while cropping or something.
...@muzikbike you're entirely right, that's really subtle. Here's the output of ImageMagick's -compare command (with -metric AE):
It's currently 12:30 at night in my timezone, so I'll have to look at this more tomorrow, but thank you for finding this. I hope it's just a Java version difference (the bug report says "Powermac 10.5.8", suggesting Apple Java 5 on a G4 / G5).
Just to make sure, can you send the terrain atlases generated by those versions as well?
I don't have any atlases to compare any of the other smoothed textures you posted, so I can't be sure on that front.
I also found some stuff through google images that might imply some sort of setting influences these, or that it might be an OS version difference again:
Just to make sure, can you send the terrain atlases generated by those versions as well?
I don't have any atlases to compare any of the other smoothed textures you posted, so I can't be sure on that front.
I also found some stuff through google images that might imply some sort of setting influences these, or that it might be an OS version difference again:
![]()
@muzikbike Here's the texture atlases generated with Java 6 (Apple legacy Java runtime 1.6.0_65-b14-468) on MacOS 10.14.6:
Here's the cropped "missing texture" texture:
This actually seems to match the texture generated with MC-TextureGen perfectly, meaning that it appears to be accurate. Tomorrow I'll boot up an old iMac G4 to see if I can generate the same texture that the bug report had.
I'll also check to see if I can influence anything with font smoothing settings. Different versions of MacOS have various amounts of control over text anti aliasing settings. I have it turned off right now. I remember testing to see if it had any influence on the output textures, which it did not, but I did not test many versions of Java with it.
@muzikbike On a whim, I tried ticking "use font smoothing" with Java 6 (Apple legacy Java runtime 1.6.0_65-b14-468) on MacOS 10.14.6, and it did actually influence the generated texture (uses polychromatic smoothing instead of monochromatic smoothing)!
Texture atlases from 1.5.2:
Cropped:
MC-TextureGen:
The texture generated by MC-TextureGen is an exact match to the one generated by Minecraft 1.5.2.
As it's currently 1:30 in the morning, I'll probably not reply to any further messages until I get some sleep.
I've tried comparing these generated textures with the ones from MC-7267, and they don't match.
Output of ImageMagick -compare command (with -metric AE):
I think this might caused by differences in the font smoothing on different types of screens. RenderingHints defines many types of font anti aliasing, all of which may produce different results. I might add a command line switch to generate a texture for each type of font anti aliasing.
@muzikbike Here's some results for Java 1.6.0_65 on MacOS 10.6.8, running on an Intel iMac.
Command: java -jar MCTextureGenerator.jar -platformTextures true
Notes: standard texture generation
Command: java -Dawt.useSystemAAFontSettings=on -Dapple.awt.textantialiasing=on -jar MCTextureGenerator.jar -platformTextures true
Notes: -Dawt.useSystemAAFontSettings=on -Dapple.awt.textantialiasing=on are passed to force text anti aliasing to be on.
Command: java -Dawt.useSystemAAFontSettings=on -Dapple.awt.textantialiasing=on -Dapple.awt.graphics.UseQuartz=true -jar MCTextureGenerator.jar -platformTextures true
Notes: same as above, but -Dapple.awt.graphics.UseQuartz=true is passed to simulate how Java 5 might render the text. apple.awt.graphics.UseQuartz would normally be set to "true" for Java 5 and below.
The texture generated when apple.awt.graphics.UseQuartz is set to "true" is unique, making it the third unique variation of a polychromatic text texture generated by an Apple Java runtime. Given that there's so much variation in these textures, I think it's likely that MC-TextureGen is accurate, and there's just a lot of variations on this texture. I'll keep this issue open for now, as I may have failed to cover some edge cases.
Worryingly, WinMerge points out some extremely, extremely subtle differences between your generated Retina antialiased texture and the one listed in bugs.mojang.com/browse/MC-7208 - with the differences being a single number (for example 194, 194, 194 instead of 193, 193, 193). I'll document these separately for now and just hope the program is still working as expected and that maybe mspaint introduced weirdness like this while cropping or something.
@muzikbike Here's an exact match for MC-7208:
I'll see if I can replicate this in more natural conditions.
@muzikbike Here's an exact match for MC-7208:
- MC-TextureGen on an iMac G4, running MacOS 10.3.9, on Java 4, with -Dawt.useSystemAAFontSettings=on -Dapple.awt.textantialiasing=on
- MC-7208
I'll see if I can replicate this in more natural conditions.
Getting back into documenting these. Can you provide a b1.4-13w01b version as well?
Probably late on relaying this information, but there was a particularly confusing case last August by a user who no longer appears to be a member of the Omniarchive discord server:
On macOS 12.3.0 using java 1.8.0_74 (64 bit), it appears that monochromatic smoothing is employed, but then all pixels that aren't pure white are immediately set to pure black. The provided texture atlases are reflective of this fact:
However, the generated texture files from MC-TextureGen (assuming the Java version used is the same) didn't match at all: https://discord.com/channels/361634042317111296/361634042317111299/1008511940357791744
This is an especially oddball case - not sure if you'd be able to figure out what went on here.
I'm pretty sure if we included linux (unless you already do) the text on missing texture could be controlled in almost every possible way, so I don't think it's even worth covering all cases and simply generate it same way minecraft does? Also there may have been user error when checking for inconsistency between generated in-game texture and mctexturegen one, such as java on %PATH% being a different one from launching the game.
Oh yeah, and considering this project is also made in java, an accurate port should give the same results. No edge cases
Documenting some Discord discussions for future reference:
Getting back into documenting these. Can you provide a b1.4-13w01b version as well?
My iMac G4 has sadly died, so I was unable to provide those textures.
Probably late on relaying this information, but there was a particularly confusing case last August by a user who no longer appears to be a member of the Omniarchive discord server:
The in-game textures were likely generated with the JRE currently bundled with Minecraft on macOS. Here are the results from using it to generate the text-based missing textures (macOS 12.7, M1):
It's possible the user was using a different version of Java to run MC-TextureGen, but it would be good to investigate any possible inaccuracies.
Oh yeah, and considering this project is also made in java, an accurate port should give the same results. No edge cases
The differences caused by this particular generator are due to how each version of Java handles text rendering. The texture is generated by calls to Graphics2D.drawString
, without a specific font. This may cause differences based on the default font Java uses on each version and operating system, as well as differences from the used text rendering library (may use platform native font rendering, different versions of libraries etc), as well as AWT state (i.e. with the legacy Apple JRE) and operating system state (different anti-aliasing font settings) etc.
I dreaded making this discovery...
This is the version generated by the program:![Missing_Texture_Java_13w02a_to_13w17a](https://user-images.githubusercontent.com/52297970/133888937-2c359dcf-71a4-475d-b422-de1bcc67460d.png)
And this is the texture cropped out from the debug.stitched-(terrain/items).png from 13w02a:![Missing_Texture_(Windows)_JE2](https://user-images.githubusercontent.com/52297970/133888964-94f31067-aff5-4618-80a9-15a829e6aa7d.png)
There are just minimal differences in the "xtu" for whatever reason.
Both of these are generated in Windows 10 version 2004. I'm not sure what version the Java bundled with the launcher is (8?).
Here are the two texture atlases generated by 13w02a:
: