İnce mi klasik mi: oyun hesabınızı okur, bir aracın ise 24 pikselden tahmin etmesi gerekir
Oyun ince ya da klasik modeli PNG'den değil, hesabınızın görünüm ayarından alır. Elinde yalnızca bir PNG olan araç ise ince bir kolun boş bıraktığı iki sütundan tahmin etmek zorundadır. Ayrıca tam UV haritası ve eski 64×32 görünümlerin neden aynalandığı.
Bir görünüm PNG'sinde "ince" olduğunu söyleyen hiçbir şey yoktur. Ne bir işaret ne de bir dosya adı kuralı vardır — ve oyun bunu anlamak için piksellere hiç bakmaz. Modeli, hesabınızın görünüme eklediği model ayarından alır (görünümü yüklerken yaptığınız seçim) ve görünümü olmayan bir profil, UUID'sine göre seçilen 18 varsayılan görünümden birini alır: 9 ince ve 9 klasik.
Yalnızca eline çıplak bir PNG verilen bir aracın — bir düzenleyicinin, bir paket oluşturucunun, bir görüntüleyicinin — modeli tahmin etmesi gerekir ve bunu belirli bir 2 × 12 dikdörtgene bakıp piksellerinden kaçının gerçekten orada olduğunu sayarak yapar.
Test
sample x 54–55, y 20–31 — 2 wide, 12 tall = 24 pixels
count pixels with alpha > 0
slim if fewer than 6 are opaque
Klasik kollar 4 piksel genişliğindedir; ince kollar 3. İnce bir kolun yüzeyleri bir piksel daha dar paketlenir, bu yüzden yan ve arka yüzeyler sola kayar ve kol bloğunun son iki sütunu, x 54–55, boş kalır. Mojang'ın kendi varsayılan görünümlerinde bu dikdörtgen, dokuz ince görünümün hepsinde 24 pikselin 0'ı, dokuz klasik görünümün hepsinde ise 24'te 24'üdür — yirmi dört piksel söylemek için yeterlidir.
Eşik 24'te 6'dır, 1 değil — sütunun dörtte biri dolmalıdır ki klasik sayılsın. Bu tolerans önemlidir: ölü sütunda birkaç başıboş piksel bulunan ince bir görünüm yine ince olarak okunur, ki istediğiniz de budur, çünkü bu başıboş pikseller neredeyse her zaman bir niyet değil, düzenleme kazasıdır.
Bu aynı zamanda hata modunun sessiz olduğu anlamına gelir. Klasik bir görünüm çizip o sütunları yalnızca hafifçe kullanırsanız — ince bir dış çizgi, birkaç gölge pikseli — 6'nın altına düşebilir ve otomatik olarak ince tespit edilebilirsiniz; bir piksel kol genişliğini kaybedersiniz ve bunun nedenini açıklayan hiçbir şey olmaz. Bir görünüm bir araçta yanlış model olarak çıkarsa, bakılacak yer o sütunlardır — oyunda ise hesabınızdaki ayardır.
UV haritası, tam olarak
Görünümün her parçası sabit bir dikdörtgendir ve her birinin sayfanın başka bir yerinde bir kaplama katmanı vardır:
| parça | taban | kaplama | kayma | boyut |
|---|---|---|---|---|
| kafa | (8, 8) | şapka (40, 8) | 32 sağa | 8 × 8 |
| gövde | (20, 20) | ceket (20, 36) | 16 aşağı | 8 × 12 |
| sağ kol | (44, 20) | kol (44, 36) | 16 aşağı | 4 × 12 |
| sağ bacak | (4, 20) | pantolon (4, 36) | 16 aşağı | 4 × 12 |
| sol kol | (36, 52) | kol (52, 52) | 16 sağa | 4 × 12 |
| sol bacak | (20, 52) | pantolon (4, 52) | 16 sola | 4 × 12 |
Altı kaplamadan beşi tabanlarından tam olarak 16 piksel uzaktadır — ama aynı yönde değil. Orijinal üç parça 16 aşağı gider. Daha sonra eklenen ve altlarında yer olmadığı için alt yarıya sıkıştırılan sol kol ile sol bacak ise bunun yerine 16 yana gider — ve birbirlerine zıt yönlerde.
Şapka, 16 uzakta olmayan tek kaplamadır: kafayla aynı satırda, 32 sağdadır.
Yani "kaplama tabanın altındadır" kuralı sayfanın tam olarak yarısı için geçerlidir. Bir taban dikdörtgenini kopyalayıp kaplamasını bulmak için aşağı kaydırmak gövde, sağ kol ve sağ bacak için işe yarar; diğer üçü için ise sessizce yanlış parçaya denk gelir.
İnce bir görünümde 4 genişliğindeki her kol dikdörtgeni bunun yerine 3 geniş olarak okunur. Ön yüzeyler hareket etmez, ama onlardan sonra gelen her şey eder: yan yüzey ve arka yüzey birer piksel daha soldan başlar ve arka yüzey bir piksel daha dardır; x 54–55'ü boş bırakan da budur.
Eski 64 × 32'nin sol tarafı hiç yoktur
1.8 öncesi bir görünüm 64 × 32'dir — sayfanın alt yarısı, yani sol kol ile sol bacağın bulunduğu yer, basitçe yoktur. Onları çizecek hiçbir şey yoktur.
Çözüm aynalamadır: sağ bacak (0, 16) → (16, 48) ve sağ kol (40, 16) → (32, 48) olarak kopyalanır, ikisi de yatay olarak çevrilir. Eski görünümlerin tamamen simetrik olmasının, yenilerinin ise olmak zorunda olmamasının nedeni budur — asimetri, 64 × 32 biçiminin ifade edemediği tek şeydir ve dönüştürdüğünüz her eski görünüme, isteyip istemediğine bakılmaksızın simetri dayatılır.
128 × 128 düzenleyici dosyası aynı düzendir, iki katı boyutta
Java 64 × 64'ü ya da eski 64 × 32'yi kabul eder, başka hiçbir şeyi kabul etmez. Bu sitenin Bedrock görünüm düzenleyicisi 128 × 128 boyutunda çalışır ve başka hiçbir şeyi kabul etmez — ama o dosya, iki kat çözünürlükte çizilmiş aynı UV düzenidir; her parça Java koordinatlarının iki katındadır, farklı bir biçim değildir.
Engel düzende değil, araçlardadır. Her düzenleyici sürümünün doku işlem hattı kendi sayısına göre boyutlandırılmıştır, bu yüzden hiçbiri diğerinin dosyasını açmaz ve Java'ya verilen 128 × 128 boyutunda bir PNG, yarı boyutta gösterilmek yerine reddedilir. Dönüştürmek mekanik bir 2× ölçeklemedir; görünüm düzenleyicisinin ikisini tek bir tuval yerine ayrı sürümler olarak ele almasının nedeni de budur.