“Bad Apple!!” di Minecraft

 (purplesyringa.moe)
2 poin oleh GN⁺ 2024-10-12 | 1 komentar | Bagikan ke WhatsApp
  • Ini adalah implementasi yang membuat Bad Apple!! diputar secara real time di atas engine Minecraft yang lambat, dengan resolusi 512×384 seperti aslinya, 20fps, dan grayscale
  • Intinya adalah membuat structure block dalam mode LOAD mengganti dirinya sendiri dengan struktur frame berikutnya, lalu melampaui batas 10Hz redstone dengan clock yang diberi perbedaan fase
  • Jika satu blok dipakai sebagai satu piksel, 768 chunk harus diperbarui pada 20Hz, jadi jumlahnya dikurangi dengan tekstur, model, dan blockstate kustom dari resource pack agar satu blok dapat merepresentasikan lebih banyak informasi layar
  • Bottleneck-nya bukan redstone atau pencahayaan, melainkan setBlock dan pemrosesan event; jumlah pembaruan dikurangi dengan delta coding serta penggantian sprite 4×4 yang sering berubah
  • Kualitas akhir dipoles dengan grayscale 6 warna, blue-noise dithering, dan koreksi noise dari kompresi lossy, tetapi masalah mengurangi sumber 30fps menjadi 20fps belum sepenuhnya terselesaikan

Syarat agar pemutaran mendekati aslinya

  • Tujuannya adalah memutar Bad Apple!! di dalam Minecraft sedekat mungkin dengan versi asli
    • Video diputar pada 20fps
    • Resolusinya sama dengan animasi asli, yaitu 512×384
    • Bukan hitam-putih, melainkan grayscale
    • Pada CPU dan GPU modern, dapat ditonton pada 20fps sungguhan tanpa merekam lalu mempercepat videonya
    • Tidak memakai command block
  • Jalan pintas yang mudah dikecualikan dari syarat implementasi
    • Mod tidak dipakai sebagai cara implementasi, hanya mod optimisasi untuk pengujian perangkat berspesifikasi rendah yang diizinkan
    • Command block, /setblock, dan datapack tidak digunakan
    • Tekstur animasi juga tidak digunakan
  • Pada perangkat berspesifikasi rendah, VulkanMod atau Sodium mungkin diperlukan
    • C2ME sebaiknya dihindari karena fitur autosave-nya menyebabkan penurunan performa

Batasan yang ditemui implementasi sebelumnya

  • Sebagian besar implementasi Bad Apple!! sebelumnya hanya sampai layar kecil atau rendering yang lambat
    • Percobaan catlord5 mencapai 512×384 dan 30fps, tetapi dirender sekitar 40 kali lebih lambat
    • Beberapa implementasi real time berbasis redstone hanya berada di kisaran 5fps atau resolusi rendah
  • Minecraft lambat bukan hanya pada engine simulasi, tetapi juga engine rendering-nya; semakin banyak chunk, semakin besar bebannya
    • Chunk 16×16×16 mahal untuk dirender ulang terlepas dari isinya
    • Mengurangi jumlah chunk yang tersentuh layar menjadi penting
  • Redstone sulit dipakai langsung untuk pemutaran 20fps karena pembangkit clock praktis biasanya menghasilkan sinyal 10Hz
    • Redstone dust adalah komponen utama tanpa delay, tetapi berat dari sisi performa

Eksperimen cara penyimpanan data

  • Metode hopper line adalah cara penyimpanan klasik: item yang disimpan di chest diambil dengan hopper lalu dibaca dengan comparator
    • Hopper memiliki interval transfer item 0,4 detik, sehingga frame rate maksimumnya 2,5fps
    • Untuk 20fps diperlukan beberapa hopper paralel, dan biaya tiling serta simulasi menjadi masalah
  • Dicoba juga cara menyimpan hampir 4 bit dengan membaca nilai 1–15 dari jukebox dan music disc
    • Jika bit dibentangkan di sumbu waktu, 20fps bisa ditargetkan dengan 2 hopper
    • Namun logika redstone dan dust yang diperlukan untuk bit shift terlalu lambat, sehingga prototipenya pun kurang performa
  • Repeater delay line adalah cara sederhana dengan menaruh jalur repeater untuk tiap piksel dan mengeluarkan nilai sesuai waktu
    • Tiling piksel 1×1 memungkinkan
    • Karena implementasi yang sudah ada dan jauh lebih kecil dari target pun perlu dipercepat 20 kali, cara ini tidak cukup

Mengganti frame dengan structure block

  • Structure block (structure block) dapat menyimpan area dengan SAVE dan memuatnya ke lokasi lain dengan LOAD
    • Tidak bisa diperoleh di survival, tetapi tidak menggantikan semuanya dengan satu command seperti command block
    • Dapat diaktifkan dengan sinyal redstone
  • Intinya adalah structure block LOAD dapat memuat area yang bertumpang tindih dengan dirinya sendiri
    • Jika structure block saat ini diganti dengan structure block berikutnya, tiap aktivasi akan memuat frame berikutnya
  • Jika diganti begitu saja, structure block baru langsung mendeteksi sinyal redstone di sekitarnya dan aktif secara rekursif
    • Rekursi ini berlanjut sampai mengenai hard limit Minecraft
    • Proses pemutusan daya redstone dust juga berhenti sebelum selesai, meninggalkan status daya yang tidak normal
  • Delay 1 redstone tick ditambahkan dengan repeater untuk mencegah aktivasi rekursif
    • Struktur harus dibuat dalam keadaan /tick freeze dan disimpan saat repeater berada dalam kondisi mati
    • Setelah dimuat, struktur berpindah ke struktur berikutnya satu redstone tick kemudian

Pemrosesan tick untuk mencapai 20fps

  • Minecraft memiliki game tick dan redstone tick
    • Engine game menghitung ulang fisika pada 20Hz
    • Komponen redstone umumnya menjadwalkan pembaruan dalam satuan 0,1 detik, yaitu 10Hz
  • Event sebenarnya diproses dalam interval 0,05 detik, dan respons redstone juga bisa bergeser mengikuti fase tersebut tergantung timing input pengguna
  • Untuk membuat 20fps, digunakan empat struktur
    • Struktur merah dan kuning membentuk satu clock 10Hz
    • Struktur biru dan hijau membentuk clock 10Hz lainnya
    • Jika kedua clock dimulai pada fase berbeda, empat warna akan bergantian ditampilkan di lokasi yang sama pada 20Hz
  • Untuk memulai dua clock secara stabil dengan perbedaan fase, dimanfaatkan bug lama ketika piston mendorong redstone block membutuhkan 3 game tick pada input pengguna langsung

Teknik resource pack untuk mengurangi jumlah chunk

  • Jika satu blok dipakai sebagai satu piksel, layar 512×384 menjadi 24 chunk secara vertikal dan 32 chunk secara horizontal
    • Total 768 chunk harus terus diperbarui pada 20Hz
    • Ini juga berbenturan dengan jarak render maksimum vanilla yang 32 chunk, sehingga tidak realistis
  • Dengan tekstur kustom di resource pack, tekstur beberapa blok diubah untuk memasukkan beberapa subpiksel dalam satu blok
    • 16 variasi blok setara dengan 4 bit
    • Dengan 256 blok dan warna tambahan, grayscale dapat direpresentasikan alih-alih hitam-putih
  • Dengan cara ini, resolusi blok dikurangi 4 kali menjadi representasi 256×192 blok
    • Jumlah chunk yang diperbarui di layar turun menjadi 192
    • Meski begitu, beban untuk pembaruan 20Hz masih tetap besar

Antrean rendering dan delta coding

  • Engine rendering Minecraft memprioritaskan pembaruan chunk di sekitar pemain
    • Beberapa thread membuat chunk secara bersamaan, lalu mengambil chunk dari antrean pembaruan mulai dari yang paling dekat dengan pemain
    • Jika N chunk terdekat terus diperbarui pada 20Hz, hanya chunk tersebut yang bisa terproses dan sisanya mungkin tidak dirender
  • Bottleneck yang ditemukan dengan Spark bukan redstone atau pencahayaan, melainkan pembaruan umum
    • Terutama setBlock dan event handler yang bermasalah
  • Solusinya adalah mengurangi jumlah pembaruan, dan delta coding diterapkan agar hanya blok yang berubah antar-frame yang diperbarui
    • Karena sebagian besar frame tidak banyak berubah, secara teori ada ruang peningkatan performa
  • Structure block hanya bisa memuat 48×48×48 blok sekaligus, sehingga layar dibagi menjadi 6×4 sublayar 48×48
    • Frame diekstrak dengan ffmpeg
    • Gambar dibaca dengan Python Pillow
    • File NBT dibuat dengan nbtlib
  • Prototipe awal membutuhkan sekitar 7 menit untuk satu kali eksekusi dan memerlukan /tick freeze, 24 tombol, serta /tick unfreeze, tetapi berhasil berjalan
    • Delta coding saja masih belum cukup cepat

Optimisasi model dan blockstate

  • Model Minecraft mendefinisikan bentuk blok sebagai cuboid, dan koordinatnya dapat ditentukan dari -16 sampai 32, melampaui rentang (0,0,0) hingga (16,16,16)
    • Jika diatur dengan tepat, satu blok dapat dirender seolah-olah hingga 3 kali lebih besar dan menggantikan area 9 blok
    • Jumlah blok tidak cukup untuk menangani semua kombinasi, sehingga ini hanya efektif untuk kasus umum seperti area 6×6 yang sepenuhnya hitam
  • Dari sekitar 600 blok yang tersedia, 256 dipakai untuk representasi subpiksel dasar, dan sebagian blok yang tersisa dimanfaatkan untuk optimisasi
  • Pendekatan akhir membagi layar menjadi sel 2×2 blok dan menjadikan sprite 4×4 piksel pada tiap sel sebagai kandidat untuk diganti dengan satu blok
    • Menghitung perbedaan antara dua frame berurutan
    • Menambahkan skor pada versi sebelum dan sesudah dari sel yang berubah
    • Pada adegan yang berubah cepat, sel dengan lebih banyak piksel berubah diberi skor lebih tinggi
    • Sprite berskor tinggi diberi blok yang tersedia terlebih dahulu
  • Untuk melampaui batas jumlah blok dasar, blockstates diteliti
    • Seperti oak_log, model berbeda dapat dipilih berdasarkan properti
    • Seperti grindstone, beberapa kombinasi properti dapat dipakai sebagai key
  • Variasi blockstate diekstrak dari aset bawaan, lalu properti yang tidak dapat dikendalikan disaring; jumlah model yang dapat diakses naik dari sekitar 600 menjadi 1700
    • Jumlah warna bertambah menjadi 6 warna
    • Jumlah blok yang dioptimalkan naik menjadi 400

Audio dan perangkat start

  • Musik ditangani dengan mengganti suara music disc lewat resource pack
    • Durasi pemutaran disc tetap sama meski audionya diganti
    • Disc Relic dipakai karena durasinya paling dekat dengan “Bad Apple!!”
    • assets/minecraft/lang/en_us.json diubah agar subtitle dalam game menampilkan “Now Playing: Bad Apple!!”
  • Button, dropper, hopper, dan jukebox dihubungkan agar dengan satu tekan tombol disc masuk ke jukebox dan mulai diputar
    • Setelah pemutaran selesai, hopper mengembalikan disc ke dropper untuk menyiapkan pemutaran berikutnya
  • Karena quasiconnectivity, sinyal redstone yang dikeluarkan jukebox saat memutar membuat status hopper dan dropper kacau
    • Saat tombol ditekan, dust dibuat memperbarui dropper
    • Satu redstone tick kemudian, repeater menyalakan dropper lagi untuk memasukkan disc
  • Untuk mengirim sinyal dari posisi menonton ke perangkat di belakang layar, dibuat kabel instan berbasis structure block
    • Structure block memuat powered redstone torch ke segmen berikutnya, lalu pada tick berikutnya torch mati karena redstone block
    • Pulse ini mengaktifkan structure block berikutnya untuk meneruskan sinyal
    • Karena structure block dapat mencakup hingga 48 blok, sinyal start dapat dikirim ke grid sublayar 48×48
  • Sekitar 150 blok dari penonton ke belakang layar dihubungkan dengan struktur terpisah yang dapat di-reset
    • Kombinasi structure block dan redstone block dibuat serta dihapus secara berantai untuk meneruskan sinyal
    • Struktur ini sulit disimpan langsung di creative, sehingga file structure dibuat dengan library Python
  • Mekanisme akhir digabungkan ke dalam kotak 4×2×3 yang dioperasikan dengan tombol luar

Prapemrosesan frame dan kualitas video

  • Tugas prapemrosesan yang tersisa adalah mengurangi video full-color menjadi 6 warna dan mengubah video 30fps menjadi 20fps
  • Bad Apple!! bukan hanya hitam-putih murni, melainkan memakai grayscale di banyak adegan
    • Motion blur
    • Objek dengan kecerahan berbeda
    • Gradien transisi adegan
    • Ekspresi seperti api, matahari, bayangan, dan riak air
  • Jika dibulatkan begitu saja ke warna terdekat, akan muncul banding
    • Dithering menguranginya dengan mengganti warna perantara yang tidak dapat direpresentasikan menjadi pola warna terdekat yang dapat direpresentasikan
  • Dithering global berkualitas tinggi dapat menghasilkan hasil yang sangat berbeda antar-frame
    • Ketidaksesuaian itu mudah terlihat oleh mata manusia
    • Pembaruan yang muncul juga terlalu banyak untuk ditangani Minecraft
  • Dithering lokal seperti Bayer dithering stabil tetapi kualitasnya rendah, dan ordered dithering berbasis blue noise menjadi solusi tengah
  • Video asli berasal dari materi kompresi lossy dari unggahan Niconico, sehingga memiliki noise
    • Noise pada area hitam dan putih menjadi lebih terlihat setelah dithering
    • Ini dikoreksi dengan membulatkan area yang hampir hitam menjadi hitam, area yang hampir putih menjadi putih, dan menyebarkan warna tengah agar kontinuitas tetap terjaga
  • Masalah mengurangi 30fps menjadi 20fps belum sepenuhnya terpecahkan
    • Jika setiap frame ketiga dibuang, jarak gerakan berbeda antara frame ganjil dan genap sehingga mengganggu
    • Jumlah pembaruan juga berubah menjadi pola bergerigi
    • Video Bad Apple!! 60fps di internet di-upscale dengan AI atau alat otomatis dan memiliki banyak artefak pada transisi adegan cepat

Hasil dan pekerjaan lanjutan

  • Implementasi dimulai dari resolusi 48×36 dengan 2 warna, lalu melewati 128×96 dengan 10 warna dan 256×192, hingga akhirnya mencapai 512×384 dengan 6 warna
  • Ada juga percobaan memutar musik dengan note block, tetapi ditinggalkan karena kualitas yang baik bisa menjadi proyek tersendiri
  • Dibuat teknik structstone yang memanfaatkan structure block seperti redstone, dan prototipe komputer yang menggunakannya juga mulai dibuat
  • Dalam proses pengembangan digunakan ffmpeg, mpv, image crate di Rust, kode hasil dekompilasi Minecraft, serta teknik meminimalkan ukuran direktori world
  • Seluruh pekerjaan memakan waktu lebih dari satu bulan, menjadi pengalaman berkolaborasi dengan teman-teman dan menyelesaikan masalah dengan cara yang berbeda dari proyek biasa

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-12
Komentar Hacker News

  • Saya belajar jauh lebih banyak tentang grafika komputer daripada yang saya perkirakan, dan salut untuk penulisnya
    Satu koreksi kecil: gambar yang disebut penulis sebagai “The sun” sebenarnya adalah adegan Eirin [0] memandang bulan. Dalam adegan itu [1], Eirin mengulurkan tangan ke arah bulan yang telah mengusirnya, tetapi ragu lalu menariknya kembali, dan di adegan berikutnya Kaguya [2] juga mengulurkan tangan ke arah bulan tetapi tidak ragu. Menurut wiki Touhou, rencana untuk mencuri bulan adalah milik Eirin, jadi saya tidak begitu yakin apa tepatnya simbolisme ini berarti
    [0] https://en.touhouwiki.net/wiki/Eirin_Yagokoro
    [1] https://youtu.be/FtutLA63Cp8?t=99
    [2] https://en.touhouwiki.net/wiki/Kaguya_Houraisan

    • Setiap melihat adegan itu saya selalu teringat “the sun”, gara-gara video lucu ini: https://www.youtube.com/watch?v=ReblZ7o7lu4
    • Sepertinya saya salah baca. Di wiki tertulis rencananya adalah seal, bukan steal, jalur antara bumi, atau Gensokyo, dan bulan
      Eirin sengaja memilih memutus hubungan dengan bulan demi melindungi Kaguya

  • Saya kurang paham kenapa Bad Apple makin menjadi semacam Hello World de facto untuk rendering grafis, tapi memang seru melihatnya secara real-time
    Saya juga pernah melihat demo ini yang menampilkan hipermedia frame rate tinggi dengan Bad Apple: https://data-star.dev/examples/bad_apple

    • Ada dua alasan. Pertama, kreator aslinya sangat longgar terhadap remix dan penggunaan oleh penggemar
      Dalam banyak hal, Touhou lebih mirip purwarupa fandom internet modern daripada fandom-fandom sebelumnya, dan video Bad Apple tidak diturunkan walau memakai audio yang sama
      Kedua, format teater bayangan sangat mudah dikenali berapa pun rendahnya resolusi. Saya bahkan pernah melihat contoh kisi 3x3. Selain itu hitam-putih, jadi hanya dua warna 1/0, sehingga dengan pemahaman setingkat “Hello World” pun sangat mudah mengubah frame-nya ke hampir format apa pun yang bisa dibayangkan
    • Standar DOOM sekarang sudah sampai sini: https://www.reddit.com/r/Doom/comments/1c0g0mi/i_made_doom_i...
      Berjalan di atas CPU yang sepenuhnya dapat diprogram yang dibuat dengan Redstone. Spesifikasi IRIS Computer adalah CPU 16-bit kustom, RAM 8 kB, ROM 64 kB, ROM tekstur 1 kB, layar 96x64 piksel 16 warna, unit floating-point (add/sub/mult/div/sqrt), clock 173 tick Redstone, tidak ada akselerasi perangkat keras grafis 3D, menjalankan program yang ditulis dalam URCL, dan berkat server MCHPRS berjalan pada 1 juta tick per detik sehingga kecepatan clock-nya 5,8 kHz
    • Salah satu ciri lagu Touhou yang jarang dibahas, termasuk Bad Apple!! asli[1], adalah bahwa setidaknya bagi saya lagu-lagu itu terdengar lebih seperti indikator status bus data daripada musik
      Alih-alih musik dengan ketukan dan birama yang tetap, rasanya jauh lebih masuk akal jika dibayangkan seperti mendengarkan bit-bit genap dari bus 16-bit yang dihubungkan ke instrumen saat MS-DOS sedang boot. Lagu-lagu itu digubah oleh pengembang game Touhou tanpa pendidikan teori musik formal, sambil sendirian membuat game shoot 'em up hardcore untuk PC-88/PC-98, jadi ini terasa seperti hasil yang wajar, dan mungkin itulah sebabnya lagu-lagu itu bisa terasa lebih akrab bagi insinyur perangkat keras embedded daripada musik pada umumnya
      Faktor lain adalah komunitas nicovideo.jp / nico-tech yang berkembang dari budaya 2ch/futaba. Ada pengguna dengan keahlian yang jauh melampaui kompensasi atau ambisi finansial mereka, dan saat itu juga banyak mahasiswa STEM, yang mencurahkan kemampuan teknis mereka ke remix hanya untuk bersenang-senang. Penyihir FPGA misterius, ahli motor driver, dan editor video sering muncul tiba-tiba lalu melempar video halusinatif, benar-benar keterlaluan. Maker Faire Tokyo bahkan pernah, demi menjaga gengsi, menempatkan orang-orang yang tampaknya memakai kemeja dress nico-tech ke area karantina acara terpisah dari para web developer berkaus yang sok berwibawa. Itu konyol dan kemudian memicu lahirnya pertemuan nico-tech, dan tidak terulang lagi. Kepadatan kualitas dan kuantitas konten semacam itulah yang membangun momentum PV Bad Apple!!
      Elemen kunci terakhir adalah bahwa PV itu monokrom, atau lebih tepatnya grayscale. Mungkin itulah sebabnya video inilah yang terpilih, bukan video lain dari masa keemasan nicovideo.jp
      1: https://www.youtube.com/watch?v=Yw5HTeT_dis
    • Fakta bahwa videonya sepenuhnya monokrom namun sangat mulus dan detail menciptakan dualitas menarik ketika diterapkan ke persoalan teknis
      Sebagai karya seni pun enak dilihat dan mengesankan, jadi menurut saya ia punya banyak sifat yang terutama akan disukai orang-orang demoscene
    • Ada pilihan lain juga. Karya awal di Factorio yang mengendalikan lampu dengan rangkaian: https://youtu.be/Kry8lbrHjeY dan implementasi suara: https://youtu.be/b_FumvuFRXA
      Ada juga klip video lain yang berwarna: https://youtu.be/mgfwwqwxdxY

  • “Bad Apple di atas segalanya!” adalah salah satu tren nyeleneh favorit saya
    Pertama kali saya melihatnya di Genesis/Mega Drive, saya kaget bahwa itu mungkin dilakukan di perangkat keras selemah itu. Saya suka melihat port baru dibuat untuk hal-hal yang performanya terbatas. Saya sepertinya tidak cukup pintar untuk membuatnya sendiri karena kemampuan pemrograman level rendah saya kurang bagus, tapi saya benar-benar menghormati orang-orang yang bisa melakukannya

  • Bagian “rekursi ini berakhir saat Minecraft mencapai batas kerasnya, dan untungnya blok kuning dibuat alih-alih blok merah” mengingatkan pada glitch penekanan pembaruan lama (https://mcdf.wiki.gg/wiki/Java_Edition:Update_Suppression)
    Population suppression yang lebih rumit (https://mcdf.wiki.gg/wiki/Java_Edition:Population_Suppressio...) juga bisa dengan cara serupa meninggalkan mesin game dalam keadaan glitch sehingga blok langsung jatuh

  • Algoritma dithering favorit saya untuk video adalah Yliluoma dithering: https://bisqwit.iki.fi/story/howto/dither/jy/
    Ini sangat berguna khususnya untuk konten grayscale, karena mencari matriks dithering optimal dari palet yang tersedia hanyalah operasi eksak sederhana, dan hasilnya bisa dimasukkan ke tabel lookup untuk rendering real-time. Menurut saya pribadi, terutama pada gradien, hasilnya terlihat jauh lebih baik daripada Bayer atau dithering acak

  • Pernyataan seperti “Redstone dust adalah salah satu komponen yang hampir satu-satunya tidak menimbulkan penundaan tick, tetapi sangat lambat. Sepertinya tidak ada orang di Mojang yang paham algoritma graf” itu berlebihan
    Setelah tulisan yang dijadikan sumber oleh artikel asli, performanya menjadi jauh kurang lambat, dan dalam 3 tahun terakhir ada banyak perbaikan, termasuk satu yang baru-baru ini. Mojang mendapat banyak cercaan dari segala arah. Alasan kenapa butuh waktu lama untuk membuat Redstone tidak terlalu lambat adalah karena sedikit saja menyentuh Redstone, komunitas akan berteriak, dan kalau mereka mengerjakan sesuatu yang bukan fitur baru pun komunitas akan berteriak, jadi nilainya menjadi rendah untuk dikerjakan. Marah-marah di internet sambil bilang mereka tidak paham algoritma graf tidak membantu. Mojang sudah berkali-kali merekrut talenta luar biasa dari komunitas Minecraft seperti Panda4994, Kingbdogz, dan Gnembon, dan mereka punya keahlian teknis untuk melakukan apa yang mereka inginkan. Yang mereka tidak punya adalah waktu dan anggaran tak terbatas. Mencoba memelihara sekaligus menyinkronkan codebase Java berusia 15 tahun dan aplikasi C++ multiplatform yang sangat besar itu benar-benar sulit, jadi saya berharap orang bisa sedikit lebih memakluminya. Saya lelah dengan kebencian yang datang dari segala arah sepanjang hari, dan rasanya menyenangkan kalau kita bisa sekadar bilang bahwa Minecraft itu keren

    • Kalimat seperti ini cukup sering muncul di blog pemrograman
      Dulu saya lebih kesal, tetapi kemudian saya sadar bahwa itu bukan sekadar kesombongan, melainkan lebih mirip kepolosan dari orang berusia 16~21 tahun yang belum banyak punya pengalaman “profesional”
    • Kenapa harus begitu? Mereka punya kekuatan untuk menulis ulang engine dalam Rust dan menjadikannya apa pun yang mereka mau
      Mereka juga tampaknya tidak terlalu peduli pada kompatibilitas antarversi

  • Sejak lulus SMA saya tidak lagi terlalu mendalami Minecraft sampai membuat perangkat Redstone yang serius
    Sekarang paling hanya beberapa kali sebulan bermain dengan teman saat tiba-tiba muncul keinginan untuk membangun sesuatu dan menjelajah. Melihat ekosistem Redstone sekarang, rasanya sudah berubah total sampai nyaris tidak bisa dikenali, dan saya penasaran apakah saya akan merasakan hal serupa saat pelan-pelan menjadi software engineer senior. Seiring waktu berlalu, saya merasa saya akan menatap sebuah stack yang tidak saya sentuh selama beberapa tahun di dunia kerja dan terkagum-kagum melihat seberapa cepat teknologi berubah serta hal-hal baru yang dibangun orang di atasnya

  • Saya tidak setuju dengan reaksi seperti “Lalu… cuma ini? Kalau dipikir-pikir lagi, hasilnya tampak hampir sepele untuk dicapai, dan jadi bertanya-tanya kenapa tidak ada yang melakukannya sebelumnya”
    Ini adalah catatan pengembangan yang keren, sekaligus pelajaran kecil tentang memecah pekerjaan yang tampak luar biasa besar menjadi potongan-potongan yang nyaris mustahil tetapi tetap mungkin. Sangat bagus. Sebagai catatan, implementasi ini merender Bad Apple pada 20fps di Minecraft vanilla hanya dengan satu tekstur kustom dan beberapa definisi objek kustom yang diubah untuk mengizinkan lebih banyak tekstur. Sisanya sangat eksotis, tetapi tetap vanilla

    • Yang paling mengesankan adalah luasnya pengetahuan yang terlihat dari solusi-solusi yang akhirnya ditolak

  • Cukup lucu juga bahwa begitu banyak usaha dicurahkan ke video aktualnya
    Begitu saya selesai dengan implementasi Bad Apple, biasanya saya sudah terlalu lelah untuk memikirkan dithering atau frame rate, lalu tinggal menjalankannya lewat ffmpeg dan menganggapnya selesai

  • Bad Apple yang dibuat sebagai world Minecraft ini juga layak ditonton: https://www.youtube.com/watch?v=RN3QW9SVnds