Minecraft’in “Bad Apple!!”ı

 (purplesyringa.moe)
2 puan yazan GN⁺ 2024-10-12 | 1 yorum | WhatsApp'ta paylaş
  • Bu, Minecraft’ın yavaş motoru üzerinde Bad Apple!!’ı orijinaliyle aynı 512×384 çözünürlükte, 20fps ve gri tonlamalı olarak gerçek zamanlı oynatmayı sağlayan bir uygulama
  • Temel fikir, LOAD modundaki structure block’un kendisini bir sonraki kare yapısıyla değiştirmesi ve faz farkı verilmiş saatlerle redstone’un 10Hz sınırının aşılması
  • Her bloğu bir piksel olarak kullanmak 768 chunk’ın 20Hz’de güncellenmesini gerektirdiğinden, kaynak paketindeki özel doku·model·blockstate ile tek bir blok daha fazla ekran bilgisini temsil edecek şekilde azaltıldı
  • Darboğazın redstone veya aydınlatmadan çok setBlock ve olay işlemede olduğu görüldü; bu yüzden delta coding ve sık değişen 4×4 sprite değiştirmeleriyle güncelleme miktarı azaltıldı
  • Nihai kalite 6 renkli gri tonlama, mavi gürültü dithering ve kayıplı sıkıştırma gürültüsü düzeltmesiyle iyileştirildi; ancak 30fps’lik orijinali 20fps’ye indirme sorunu tamamen çözülemedi

Orijinale yakın oynatma için koşullar

  • Amaç, Bad Apple!!’ı Minecraft içinde olabildiğince orijinaline yakın oynatmaktı
    • Video 20fps’de oynatılıyor
    • Çözünürlük, orijinal animasyonla aynı olan 512×384
    • Siyah-beyaz değil, gri tonlamalı
    • Modern CPU ve GPU’larda kayıt alıp sonradan hızlandırmaya gerek olmadan gerçek 20fps’de izlenebiliyor
    • Komut bloğu kullanılmıyor
  • Kolay kestirme yollar uygulama koşullarının dışında bırakıldı
    • Modlar uygulama yöntemi olarak kullanılmadı; sadece düşük donanım testleri için optimizasyon modlarına izin verildi
    • Komut blokları, /setblock, datapack kullanılmadı
    • Animasyonlu dokular da kullanılmadı
  • Düşük donanımlı cihazlarda VulkanMod veya Sodium gerekebilir
    • C2ME, otomatik kayıt özelliği nedeniyle performans düşüşüne yol açabildiği için kaçınılmalı

Mevcut uygulamaların çarptığı sınırlar

  • Önceki Bad Apple!! uygulamalarının çoğu küçük ekranlar veya yavaş render ile sınırlı kaldı
    • catlord5’in denemesi 512×384 ve 30fps’ye ulaştı, ancak yaklaşık 40 kat daha yavaş render ediyordu
    • Redstone tabanlı bazı gerçek zamanlı uygulamalar ise 5fps veya düşük çözünürlük düzeyindeydi
  • Minecraft, yalnızca simülasyon motoru değil, render motoru açısından da yavaş; chunk sayısı arttıkça yük büyüyor
    • 16×16×16 chunk’lar, içerikten bağımsız olarak yeniden render edilince yüksek maliyet çıkarıyor
    • Ekranın kapsadığı chunk sayısını azaltmak kritik
  • Redstone’da pratik saat üreteçleri genellikle 10Hz sinyal verdiği için bunu doğrudan 20fps oynatma için kullanmak zor
    • redstone dust gecikmesiz temel bileşen olsa da performans yükü yüksek

Veri depolama yöntemi deneyleri

  • Hopper line yöntemi, sandıkta depolanan eşyaları hopper ile çekip comparator ile okuyan tipik bir depolama yaklaşımı
    • Hopper’ların eşya aktarım aralığı 0.4 saniye olduğundan azami kare hızı 2.5fps
    • 20fps için çok sayıda paralel hopper düzeni gerekir ve tiling ile simülasyon maliyeti sorun olur
  • Jukebox ve müzik diskleriyle 1~15 değerlerini okuyup neredeyse 4 bit depolama yöntemi de denendi
    • Bitler zaman eksenine yayılırsa 20fps için 2 hopper ile hedeflenebilir
    • Ancak bit kaydırma için gereken redstone mantığı ve dust çok yavaş olduğundan prototip bile yeterli performansı veremedi
  • Repeater delay line, her piksel için bir repeater hattı kurup doğru anda değer üreten basit bir yöntem
    • 1×1 piksel tiling mümkün
    • Hedeften çok daha küçük mevcut uygulamaların bile 20 kat hızlandırmaya ihtiyaç duyması nedeniyle bu da yeterli olmadı

Structure block ile kare ilerletme

  • Yapı bloğu (structure block), SAVE ile bir alanı kaydedip LOAD ile başka bir konuma yükleyebiliyor
    • Survival’da elde edilemese de komut bloğu gibi tek bir komutla her şeyi ikame etmiyor
    • Redstone sinyaliyle etkinleştirilebiliyor
  • Ana fikir, LOAD durumundaki structure block’un kendiyle çakışan alanı yükleyebilmesi
    • Mevcut structure block bir sonraki structure block ile değiştirilirse, her etkinleştirmede sonraki kare yüklenmiş oluyor
  • Basitçe değiştirilirse yeni structure block çevredeki redstone sinyalini hemen algılayıp özyinelemeli şekilde etkinleşiyor
    • Bu özyineleme, Minecraft’ın katı üst sınırına çarpana kadar sürüyor
    • redstone dust’un güç kesme işlemi de tamamlanmadan durduğu için anormal güç durumları kalıyor
  • Repeater ile 1 redstone tick gecikmesi eklenerek özyinelemeli etkinleşme engellendi
    • Yapılar, /tick freeze durumunda oluşturulup repeater kapalı halde kaydedilmeli
    • Yüklendikten bir redstone tick sonra sonraki yapıya geçiliyor

20fps için tick işleme

  • Minecraft’ta game tick ve redstone tick bulunuyor
    • Oyun motoru fiziği 20Hz’de yeniden hesaplıyor
    • Redstone bileşenleri genelde 0.1 saniyelik, yani 10Hz güncelleme planlıyor
  • Gerçek olaylar 0.05 saniye aralıklarla işleniyor ve kullanıcı girişinin zamanlamasına göre redstone tepkisi de bu faza kayabiliyor
  • 20fps üretmek için dört yapı kullanılıyor
    • Kırmızı ve sarı yapılar bir 10Hz saat oluşturuyor
    • Mavi ve yeşil yapılar başka bir 10Hz saat oluşturuyor
    • İki saat farklı fazlarda başlatılınca aynı konumda dört renk 20Hz dönüşümlü görünüyor
  • İki saati güvenilir faz farkıyla başlatmak için, pistonun redstone block itmesinde doğrudan kullanıcı girdisinde 3 game tick süren eski bir bug’dan yararlanıldı

Chunk sayısını azaltan kaynak paketi tekniği

  • Her blok bir piksel olsaydı, 512×384 ekran dikeyde 24 chunk, yatayda 32 chunk olurdu
    • Toplam 768 chunk’ın 20Hz’de sürekli güncellenmesi gerekirdi
    • Bu, vanilla’nın 32 chunk azami render mesafesiyle birleşince pratik olmuyor
  • Kaynak paketindeki özel dokularla çeşitli blokların dokuları değiştirilip tek blok içine birden fazla alt piksel yerleştirildi
    • 16 blok varyantı 4 bite karşılık geliyor
    • 256 blok ve ek renklerle siyah-beyaz yerine gri tonlama ifade edilebiliyor
  • Bu sayede blok çözünürlüğü 4 kat düşürülerek 256×192 blok şeklinde ifade edildi
    • Ekran güncelleme chunk sayısı 192’ye indi
    • Yine de 20Hz güncelleme için hâlâ büyük bir yük kaldı

Render kuyruğu ve delta coding

  • Minecraft render motoru, oyuncu çevresindeki chunk güncellemelerine öncelik veriyor
    • Birden çok thread aynı anda chunk oluşturuyor ve güncelleme kuyruğundan oyuncuya yakın chunk’ları önce alıyor
    • Yakındaki N chunk 20Hz’de sürekli güncellenirse yalnızca bunlar işlenip geri kalanı render edilmeyebilir
  • Spark ile doğrulanan darboğazın redstone veya aydınlatma değil, genel güncellemeler olduğu görüldü
    • Özellikle setBlock ve event handler’lar sorunluydu
  • Çözüm, güncelleme sayısını azaltmak oldu; kareler arasında değişen blokları yalnızca gerektiğinde güncelleyen delta coding uygulandı
    • Karelerin çoğunda değişim miktarı büyük olmadığı için teorik olarak performans iyileştirme alanı vardı
  • Structure block bir seferde yalnızca 48×48×48 blok yükleyebildiğinden ekran 6×4 adet 48×48 alt ekrana bölündü
    • Kareler ffmpeg ile çıkarıldı
    • Görüntüler Python Pillow ile okundu
    • NBT dosyaları nbtlib ile üretildi
  • İlk prototip tek çalıştırmada yaklaşık 7 dakika sürüyor ve /tick freeze, 24 düğme, /tick unfreeze gerektiriyordu; ama çalışıyordu
    • Yalnızca delta coding yine de yeterince hızlı değildi

Model ve blockstate optimizasyonu

  • Minecraft modelleri blok şeklini cuboid olarak tanımlar; koordinatlar (0,0,0) ile (16,16,16) aralığını aşarak -16’dan 32’ye kadar verilebilir
    • Uygun ayarlanırsa bir blok 3 kat daha büyükmüş gibi render edilip 9 blokluk alanı ikame edebilir
    • Tüm kombinasyonları işleyecek kadar blok olmadığından, yalnızca tamamen siyah 6×6 alan gibi yaygın durumlarda anlamlıydı
  • Kullanılabilir yaklaşık 600 bloktan 256’sı temel alt piksel gösterimine ayrıldı, kalanların bir kısmı optimizasyon için kullanıldı
  • Nihai yaklaşım, ekranı 2×2 blok hücrelere bölüp her hücrenin 4×4 piksel sprite’ını tek bloğa dönüştürme adayı yapmak oldu
    • Art arda iki kare arasındaki fark hesaplandı
    • Değişen hücrelerin önceki ve sonraki sürümlerine puan eklendi
    • Hızlı değişen sahnelerde daha çok piksel değiştiren hücrelere daha yüksek puan verildi
    • En yüksek puanlı sprite’lardan başlayarak kullanılabilir bloklar atandı
  • Temel blok sayısı sınırını aşmak için blockstates incelendi
    • oak_log gibi bloklar özelliklere göre farklı model seçebiliyor
    • grindstone gibi bloklar birden fazla özellik kombinasyonunu anahtar olarak kullanabiliyor
  • Varsayılan varlıklardan blockstate varyantları çıkarıldı, kontrol edilemeyen özellikler elendi ve erişilebilir model sayısı yaklaşık 600’den 1700’e çıktı
    • Renk sayısı 6’ya yükseldi
    • Optimize edilmiş blok sayısı 400’e çıktı

Ses ve başlatma düzeneği

  • Müzik, kaynak paketiyle müzik diskinin sesini değiştirme yöntemiyle işlendi
    • Disk çalma süresi, ses değiştirilse bile sabit kalıyor
    • “Bad Apple!!” süresine en yakın olan Relic diski kullanıldı
    • assets/minecraft/lang/en_us.json değiştirilerek oyun içi altyazının “Now Playing: Bad Apple!!” göstermesi sağlandı
  • Düğme, dropper, hopper ve jukebox bağlanarak tek düğmeyle diskin jukebox’a girip çalmaya başlaması sağlandı
    • Oynatma bitince hopper diski yeniden dropper’a göndererek bir sonraki oynatmaya hazırlıyor
  • Quasiconnectivity nedeniyle jukebox’ın çalarken ürettiği redstone sinyali hopper ve dropper durumlarını bozuyordu
    • Düğme girdisinde dust’un dropper’ı güncellemesi sağlandı
    • Bir redstone tick sonra repeater dropper’ı yeniden etkinleştirip diski yerleştirecek şekilde ayarlandı
  • İzleme konumundan ekran arkasındaki düzeneğe sinyal göndermek için structure block tabanlı anlık kablo yapıldı
    • Structure block, güç verilmiş bir redstone torch’u bir sonraki bölüme yüklüyor ve bir sonraki tick’te redstone block nedeniyle kapanıyor
    • Bu darbe sonraki structure block’u etkinleştirip sinyali iletiyor
    • Structure block en fazla 48 blok kapsayabildiği için 48×48 alt ekran ızgarasına başlatma sinyali gönderilebiliyor
  • İzleyiciden ekran arkasına kadar yaklaşık 150 blokluk mesafe ayrıca sıfırlanabilir bir yapıyla bağlandı
    • Structure block ve redstone block birleşimi ardışık biçimde oluşturulup silinerek sinyal iletildi
    • Bu yapıyı creative’de doğrudan kaydetmek zor olduğundan structure dosyaları Python kütüphanesiyle üretildi
  • Son mekanizma, dış taraftaki bir düğmeyle çalışan 4×2×3 kutu içine toplandı

Kare ön işleme ve video kalitesi

  • Kalan ön işleme görevleri, tam renkli videoyu 6 renge düşürmek ve 30fps videoyu 20fps’ye çevirmekti
  • Bad Apple!! yalnızca saf siyah-beyaz değil; birçok sahnede gri tonlama kullanıyor
    • Hareket bulanıklığı
    • Farklı parlaklıktaki nesneler
    • Sahne geçişlerindeki gradyanlar
    • Ateş, güneş, gölge ve dalga gibi ifadeler
  • En yakın renge basit yuvarlama banding oluşturuyor
    • Dithering, ifade edilemeyen ara tonları komşu ifade edilebilir tonların deseniyle değiştirerek bunu hafifletiyor
  • Yüksek kaliteli küresel dithering, kareler arasında çok farklı sonuçlar üretebiliyor
    • İnsan gözü bu tutarsızlığı kolay fark ediyor
    • Ayrıca Minecraft’ın kaldıramayacağı kadar çok güncelleme doğuruyor
  • Bayer dithering gibi yerel dithering kararlıydı ama kalitesi düşüktü; mavi gürültü tabanlı ordered dithering orta yol oldu
  • Kaynak video, Niconico yüklemesinden gelen kayıplı sıkıştırılmış bir materyaldi; bu yüzden gürültü içeriyordu
    • Siyah ve beyaz alanlardaki gürültü, dithering sonrası daha görünür hale geldi
    • Neredeyse siyah alanlar siyaha, neredeyse beyaz alanlar beyaza yuvarlandı; orta tonlar ise süreklilik korunacak şekilde dağıtılarak düzeltildi
  • 30fps’yi 20fps’ye düşürme sorunu tamamen çözülemedi
    • Her üçüncü kareyi atmak, hareket aralığının tek ve çift karelerde farklı görünmesine yol açarak rahatsızlık veriyor
    • Güncelleme miktarı da testere dişi gibi değişiyor
    • İnternetteki 60fps Bad Apple!! videoları yapay zeka veya otomatik araçlarla yükseltilmiş olduğundan hızlı sahne geçişlerinde çok artefakt üretiyordu

Sonuç ve devam çalışmaları

  • Uygulama 48×36 çözünürlük ve 2 renkle başladı; 128×96 ve 10 renk, ardından 256×192 üzerinden ilerleyip sonunda 512×384 ve 6 renk düzeyine ulaştı
  • Note block ile müzik çalma denemeleri de yapıldı, ancak iyi kalite için bunun ayrı bir proje ölçeğine çıkacağı düşünülerek vazgeçildi
  • Structure block’u redstone gibi kullanan structstone tekniği geliştirildi ve bununla çalışan bir bilgisayar prototipine de başlandı
  • Geliştirme sürecinde ffmpeg, mpv, Rust’ın image crate, Minecraft decompile kodu ve world dizini boyutunu küçültme teknikleri kullanıldı
  • Tüm çalışma bir aydan uzun sürdü; arkadaşlarla işbirliği yapılarak, sorunları sıradan projelerden farklı biçimde çözme deneyimi oldu

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-12
Hacker News yorumları

  • Beklediğimden çok daha fazla bilgisayar grafiği öğrendim; yazara övgüler.
    Küçük bir düzeltme: Yazarın “The sun” dediği görsel aslında Eirin’in [0] aya baktığı sahne. O sahnede [1] Eirin, sürgün edildiği aya doğru elini uzatıyor ama tereddüt edip geri çekiyor; bir sonraki sahnede ise Kaguya [2] da aya doğru elini uzatıyor ama tereddüt etmiyor. Touhou wiki’ye göre ayı çalma planı Eirin’e aitmiş; bu yüzden bu sembolün tam olarak ne anlama geldiğinden emin değilim.
    [0] https://en.touhouwiki.net/wiki/Eirin_Yagokoro
    [1] https://youtu.be/FtutLA63Cp8?t=99
    [2] https://en.touhouwiki.net/wiki/Kaguya_Houraisan

    • O sahneyi görünce aklıma hep “the sun” geliyor; sebebi şu komik video: https://www.youtube.com/watch?v=ReblZ7o7lu4
    • Sanırım yanlış okumuşsun. Wiki’de planın Dünya ile, ya da Gensokyo ile Ay arasındaki geçidi “steal” etmek değil, seal etmek olduğu yazıyor.
      Eirin, Kaguya’yı korumak için Ay’la bağlantıyı bilerek kesmeyi seçmişti.

  • Bad Apple’ın neden grafik render etmenin fiili Hello World’ü hâline geldiğini pek anlayamıyorum ama gerçek zamanlı izlemek eğlenceli.
    Bad Apple ile yüksek kare hızlı hipermedyayı gösteren şu demoyu da gördüm: https://data-star.dev/examples/bad_apple

    • Bunun iki nedeni var. Birincisi, orijinal yaratıcı remix’lere ve hayran kullanımına çok hoşgörülü.
      Birçok açıdan Touhou, önceki fandomlardan farklı olarak modern internet fandomunun prototipine yakındı; aynı sesi kullansa bile Bad Apple videoları kaldırılmıyor.
      İkincisi, gölge oyunu formatı çözünürlük ne kadar düşük olursa olsun kolayca tanınabiliyor. 3x3 ızgara örneği bile görmüştüm. Üstelik siyah-beyaz, yani yalnızca 1/0 iki renk olduğu için, “Hello World” seviyesinde bilgiyle bile kareleri hayal edilebilecek neredeyse her formata dönüştürmek çok kolay.
    • DOOM çıtası buraya kadar geldi: https://www.reddit.com/r/Doom/comments/1c0g0mi/i_made_doom_i...
      Redstone ile yapılmış tamamen programlanabilir bir CPU üzerinde çalışıyor. IRIS Computer’ın özellikleri: özel 16 bit CPU, 8 kB RAM, 64 kB ROM, 1 kB doku ROM’u, 96x64 piksel 16 renk ekran, kayan nokta birimi (add/sub/mult/div/sqrt), 173 Redstone tick saat hızı, 3D grafik donanım hızlandırması yok, URCL ile yazılmış programları çalıştırıyor; MCHPRS sunucusu sayesinde saniyede 1 milyon tick’te çalıştığından saat hızı 5,8 kHz.
    • Orijinal Bad Apple!![1] dahil Touhou parçalarının daha az dile getirilen özelliklerinden biri, en azından bana müzikten çok veri yolu durum göstergesi gibi gelmeleri.
      Düzenli ritim ve ölçülere sahip müzikten ziyade, MS-DOS açılırken 16 bit veri yolunun çift bitlerini enstrümanlara bağlayıp dinlediğinizi hayal edince çok daha anlamlı oluyor. Touhou oyun geliştiricisinin resmî müzik teorisi eğitimi almadan PC-88/PC-98 için hardcore shoot ’em up oyunlarını tek başına yaparken bestelediği parçalar olduklarından bu doğal bir sonuç gibi görünüyor; bu yüzden gömülü donanım mühendislerine sıradan müzikten daha tanıdık gelebilir.
      Bir diğer etken de 2ch/futaba kültüründen gelişen nicovideo.jp / nico-tech topluluğuydu. Ücret ya da maddi hırstan çok daha büyük uzmanlığa sahip kullanıcılar — o dönemde STEM öğrencileri de çoktu — eğlence olsun diye remix’lere teknik emek döküyorlardı. Nereden çıktığı belli olmayan FPGA büyücüleri, motor sürücü uzmanları, video editörleri birden belirip halüsinojenik videolar bırakıp giderdi; gerçekten akıl almazdı. Maker Faire Tokyo bir ara, itibar peşindeki tişörtlü web geliştiricileri için, nico-tech gömleği giydiğinden şüphelenilen kişileri ayrı bir etkinlik alanındaki karantina bölgesine koymuştu. Bu olay ironikti, nico-tech buluşmasının doğmasına yol açtı ve tekrarlanmadı. Bu absürt içeriklerin kalite ve miktar yoğunluğu Bad Apple!! PV’sinin momentumunu yarattı.
      Son kilit unsur, PV’nin tek renkli — daha doğrusu gri tonlamalı — olmasıydı. Muhtemelen nicovideo.jp’nin altın çağındaki başka bir video yerine bunun seçilmesinin nedeni de buydu.
      1: https://www.youtube.com/watch?v=Yw5HTeT_dis
    • Videonun tamamen tek renkli olmasına rağmen çok akıcı ve incelikli olması, teknik problemlere uygulandığında ilginç bir ikilik yaratıyor.
      Kendi başına da güzel görünen, etkileyici bir sanat eseri; özellikle demoscene insanlarının seveceği pek çok niteliğe sahip olduğunu düşünüyorum.
    • Başka seçenekler de var. Factorio’da devrelerle ışıkları kontrol eden erken bir çalışma: https://youtu.be/Kry8lbrHjeY ve ses uygulaması: https://youtu.be/b_FumvuFRXA
      Renkli başka bir video klip de var: https://youtu.be/mgfwwqwxdxY

  • “Her şeyin üzerinde Bad Apple!” sevdiğim inekçe akımlardan biri.
    Genesis/Mega Drive’da ilk gördüğümde, böylesine zayıf bir donanımda bunun mümkün olmasına çok şaşırmıştım. Performansı yetersiz şeylere yeni portlar yapıldığını görmeyi seviyorum. Düşük seviyeli programlamada iyi değilim; kendim yapacak kadar zeki olduğumu da sanmıyorum ama yapabilenlere gerçekten saygı duyuyorum.

  • “Bu özyineleme, Minecraft sert sınıra ulaştığında sona eriyor ve şans eseri kırmızı blok yerine sarı blok üretiliyor” kısmı bana eski update suppression glitch’ini (https://mcdf.wiki.gg/wiki/Java_Edition:Update_Suppression) hatırlattı.
    Daha zorlayıcı olan population suppression(https://mcdf.wiki.gg/wiki/Java_Edition:Population_Suppressio...) da benzer şekilde oyun motorunu glitch’li bir durumda bırakıp blokların anında düşmesini sağlayabiliyor.

  • Video için en sevdiğim dithering algoritması Yliluoma dithering: https://bisqwit.iki.fi/story/howto/dither/jy/
    Özellikle gri tonlamalı içerikte işe yarıyor; çünkü kullanılabilir paletten en iyi dithering matrisini bulmak basit bir tam hesaplama işi ve sonucu gerçek zamanlı render için bir lookup table’a koyabiliyorsunuz. Bana göre özellikle gradyanlarda Bayer ya da rastgele dithering’den çok daha iyi görünüyor.

  • “Redstone dust, tick gecikmesi yaratmayan neredeyse tek bileşen ama çok yavaş. Mojang’da grafik algoritmalarını bilen kimse yok gibi” tarzı sözler fazla ağır.
    Orijinal yazının bilgi kaynağı olarak link verdiği yazıdan bu yana çok daha az yavaşladı; son 3 yılda, yakın zamanda yapılan biri de dahil, çok sayıda iyileştirme oldu. Mojang her taraftan çok eleştiri alıyor. Redstone’u daha az yavaş hâle getirmenin bu kadar uzun sürmesinin nedeni, Redstone’a azıcık dokunulduğunda topluluğun bağırması, yeni özellik eklemek dışında bir şey yapıldığında da topluluğun bağırması; bu yüzden buna değme olasılığı düşüyor. İnternette öfkelenip grafik algoritmalarını bilmediklerini söylemek yardımcı olmuyor. Mojang, Panda4994, Kingbdogz, Gnembon gibi Minecraft topluluğunun çok parlak isimlerini defalarca işe aldı ve istediklerini yapacak teknik uzmanlığa sahip. Sahip olmadıkları şey sınırsız zaman ve bütçe. 15 yıllık bir Java codebase’i ile devasa bir çok platformlu C++ uygulamasını aynı anda sürdürüp senkronize etmeye çalışmak gerçekten zor; bu yüzden biraz anlayış gösterilmesini isterim. Gün boyu her taraftan yağan nefretten yoruldum ve sadece Minecraft’ın harika olduğunu söyleyebilmek istiyorum.

    • Bu tarz cümleler programlama bloglarında epey sık görülüyor.
      Eskiden daha çok sinir olurdum ama sonra bunun kibirden ziyade “profesyonel” deneyimi az olan 16-21 yaş aralığındaki saflığa daha yakın olduğunu fark ettim.
    • Neden öyle olsun? Motoru Rust ile baştan yazıp istedikleri her şeye dönüştürecek güçleri var.
      Sürümler arası uyumluluğu pek umursuyor gibi de görünmüyorlar.

  • Liseden beri Minecraft’a kapılıp ciddi Redstone düzenekleri yapmışlığım yok.
    Artık bir şeyler inşa etme ve keşfetme isteği birden geri geldiğinde, arkadaşlarla ayda birkaç kez oynuyorum. Şimdiki Redstone ekosistemine bakınca tamamen değişmiş, tanınmaz hâle gelmiş gibi görünüyor; yavaş yavaş senior software engineer olurken benzer bir his yaşayıp yaşamayacağımı merak ediyorum. Yıllar geçip birkaç yıl pratikte dokunmadığım stack’lere baktığımda, teknolojinin ne kadar hızlı değiştiğine ve insanların onun üzerinde ne gibi yeni şeyler yaptığına hayran kalacak gibiyim.

  • “Ve… hepsi bu mu? Geriye dönüp bakınca sonuç neredeyse önemsiz biçimde elde edilebilir gibi görünüyor; insan neden daha önce kimsenin yapmadığını merak ediyor” tepkisine katılmıyorum.
    Bu harika bir geliştirme günlüğü ve ezici görünen bir işi neredeyse imkânsız ama mümkün parçalara ayırmaya dair küçük bir ders. Gerçekten çok hoşuma gitti. Bu arada bu uygulama, tek bir özel texture ve daha fazla texture’a izin vermek için değiştirilmiş birkaç özel nesne tanımıyla, vanilla Minecraft’ta Bad Apple’ı 20fps render ediyor. Geri kalanı çok egzotik ama vanilla.

    • Reddedilen çözümlerde görülen bilgi genişliği en etkileyici kısım.

  • Asıl videonun kendisine bu kadar emek harcanmış olması biraz komik.
    Ben bir Bad Apple uygulamasını bitirdiğimde genelde dithering ya da frame rate düşünecek hâlim kalmıyor; sadece ffmpeg’den geçirip bitti diyorum.

  • Minecraft dünyasıyla yapılmış Bad Apple da izlemeye değer: https://www.youtube.com/watch?v=RN3QW9SVnds