Minecraft में “Bad Apple!!”

 (purplesyringa.moe)
2 पॉइंट द्वारा GN⁺ 2024-10-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Minecraft के धीमे engine पर Bad Apple!! को original जैसी 512×384 resolution, 20fps और grayscale में real-time चलाने के लिए बनाया गया implementation
  • मुख्य idea यह है कि LOAD mode वाला structure block खुद को अगले frame की structure से replace करे, और phase difference वाले clocks से redstone की 10Hz limit को पार किया जाए
  • अगर एक block को एक pixel की तरह इस्तेमाल करें, तो 768 chunks को 20Hz पर update करना पड़ेगा; इसलिए resource pack की custom texture, model और blockstate से एक block में ज्यादा screen information दिखाकर इसे घटाया गया
  • bottleneck redstone या lighting से ज्यादा setBlock और event processing में था; delta coding और बार-बार बदलने वाले 4×4 sprite replacement से update की मात्रा कम की गई
  • final quality को 6-color grayscale, blue-noise dithering और lossy compression noise correction से बेहतर किया गया, लेकिन 30fps original को 20fps में घटाने की समस्या पूरी तरह हल नहीं हो पाई

original के करीब playback के लिए शर्तें

  • लक्ष्य Minecraft के अंदर Bad Apple!! को जितना हो सके original के करीब चलाना था
    • video 20fps पर चलता है
    • resolution original animation जैसा ही 512×384 है
    • black-and-white नहीं, बल्कि grayscale है
    • आधुनिक CPU और GPU पर recording के बाद speed बढ़ाए बिना असली 20fps पर देखा जा सकता है
    • command block इस्तेमाल नहीं किया गया
  • आसान shortcuts को implementation conditions से बाहर रखा गया
    • mods को implementation method के रूप में इस्तेमाल नहीं किया गया; केवल low-end testing के लिए optimization mods की अनुमति थी
    • command block, /setblock, datapack इस्तेमाल नहीं किए गए
    • animated textures भी इस्तेमाल नहीं की गईं
  • low-end devices पर VulkanMod या Sodium की जरूरत पड़ सकती है
    • C2ME से बचना चाहिए, क्योंकि autosave feature की वजह से performance घटती है

मौजूदा implementations की limits

  • पहले के Bad Apple!! implementations ज्यादातर छोटे screen या slow rendering तक सीमित रहे
    • catlord5 की कोशिश ने 512×384 और 30fps हासिल किया, लेकिन rendering लगभग 40 गुना धीमी थी
    • कुछ redstone-based real-time implementations 5fps या low resolution स्तर पर थे
  • Minecraft में simulation engine ही नहीं, rendering engine भी slow है, और chunks की संख्या बढ़ने पर load बढ़ता है
    • 16×16×16 chunk को उसके content से अलग, फिर से render करने की cost बड़ी होती है
    • screen जिन chunks को cover करती है, उनकी संख्या घटाना जरूरी है
  • redstone में practical clock generators आमतौर पर 10Hz signal देते हैं, इसलिए 20fps playback में सीधे इस्तेमाल करना मुश्किल है
    • redstone dust बिना delay वाला main component है, लेकिन performance के लिहाज से भारी पड़ता है

data storage method experiments

  • hopper line method एक typical storage method है, जिसमें chest में stored items को hopper से निकाला और comparator से read किया जाता है
    • hopper का item transfer interval 0.4 seconds है, इसलिए maximum frame rate 2.5fps
    • 20fps के लिए कई hoppers की parallel configuration चाहिए, और tiling व simulation cost समस्या बनती है
  • jukebox और music discs से 1~15 values read करके लगभग 4-bit store करने का तरीका भी आजमाया गया
    • bits को time axis पर फैलाएँ तो 2 hoppers से 20fps का लक्ष्य रखा जा सकता है
    • लेकिन bit shift के लिए जरूरी redstone logic और dust slow थे, इसलिए prototype की performance भी कम पड़ी
  • repeater delay line एक simple तरीका है, जिसमें हर pixel के लिए repeater line रखकर समय के अनुसार value दी जाती है
    • 1×1 pixel tiling possible है
    • target से काफी छोटे मौजूदा implementation को भी 20x acceleration चाहिए था, इसलिए यह पर्याप्त नहीं था

structure block से frames आगे बढ़ाना

  • structure block (structure block) SAVE से area save कर सकता है और LOAD से उसे किसी दूसरी जगह load कर सकता है
    • survival में इसे पाया नहीं जा सकता, लेकिन यह command block की तरह एक command से सब कुछ replace नहीं करता
    • redstone signal से activate किया जा सकता है
  • core point यह है कि LOAD structure block खुद से overlap होने वाला area load कर सकता है
    • current structure block को अगले structure block से बदल दें, तो हर activation पर अगला frame load होने वाली structure बन जाती है
  • सीधे replace करने पर नया structure block तुरंत आसपास के redstone signal को detect करके recursively activate हो जाता है
    • यह recursion Minecraft की hard limit तक चलता है
    • redstone dust के power-off processing पूरी होने से पहले ही रुक जाता है, जिससे abnormal power state बची रह जाती है
  • repeater से 1 redstone tick delay डालकर recursive activation रोका गया
    • structures को /tick freeze state में बनाना पड़ता है, ताकि repeater off state में save हो
    • load होने के बाद एक redstone tick के बाद अगली structure पर जाता है

20fps मिलाने के लिए tick processing

  • Minecraft में game tick और redstone tick होते हैं
    • game engine 20Hz पर physics को फिर calculate करता है
    • redstone components आम तौर पर 0.1 second intervals, यानी 10Hz पर updates schedule करते हैं
  • actual events 0.05 second intervals पर process होते हैं, और user input timing के अनुसार redstone response भी उसी phase में shift हो सकता है
  • 20fps बनाने के लिए चार structures इस्तेमाल की गईं
    • red और yellow structures एक 10Hz clock बनाती हैं
    • blue और green structures दूसरा 10Hz clock बनाती हैं
    • दोनों clocks को अलग phases में start करने पर एक ही जगह पर चार colors 20Hz पर बारी-बारी से दिखाई देते हैं
  • दोनों clocks को reliable phase difference के साथ start करने के लिए, piston द्वारा redstone block push करते समय direct user input में 3 game ticks लगने वाले पुराने bug का उपयोग किया गया

chunks की संख्या घटाने की resource pack technique

  • अगर एक block को एक pixel की तरह इस्तेमाल करें, तो 512×384 screen vertical 24 chunks और horizontal 32 chunks बनती है
    • कुल 768 chunks को 20Hz पर लगातार update करना पड़ता
    • यह vanilla की maximum render distance 32 chunks से भी जुड़ता है, इसलिए practical नहीं है
  • resource pack की custom textures से कई blocks की textures बदलकर एक block में कई subpixels रखे गए
    • 16 block variants 4-bit के बराबर हैं
    • 256 blocks और extra colors इस्तेमाल करें तो black-and-white की जगह grayscale दिखा सकते हैं
  • इस तरीके से block resolution 4 गुना घटाकर 256×192 blocks में represent किया गया
    • screen update chunks की संख्या 192 तक घट गई
    • फिर भी 20Hz updates के लिए काफी भारी load बचा रहा

rendering queue और delta coding

  • Minecraft rendering engine player के आसपास chunk updates को priority देता है
    • कई threads एक साथ chunks बनाते हैं, और update queue से player के पास वाले chunks पहले लेते हैं
    • अगर पास के N chunks 20Hz पर लगातार update होते रहें, तो केवल वही chunks process होंगे और बाकी render नहीं हो पाएंगे
  • Spark से मिला bottleneck redstone या lighting से ज्यादा normal updates थे
    • खासकर setBlock और event handlers समस्या थे
  • solution था updates की संख्या घटाना, और frame-to-frame बदलने वाले blocks ही update करने के लिए delta coding लागू की गई
    • ज्यादातर frames में change amount बड़ा नहीं होता, इसलिए theory में performance improve करने की गुंजाइश है
  • structure block एक बार में केवल 48×48×48 blocks load कर सकता है, इसलिए screen को 6×4 48×48 subscreens में बाँटा गया
    • ffmpeg से frames extract किए गए
    • Python Pillow से images read की गईं
    • NBT files nbtlib से generate की गईं
  • initial prototype को एक run में लगभग 7 minutes लगे, और /tick freeze, 24 buttons, /tick unfreeze की जरूरत थी, लेकिन यह काम करता था
    • सिर्फ delta coding अभी भी पर्याप्त तेज नहीं थी

model और blockstate optimization

  • Minecraft model blocks की shape को cuboid के रूप में define करता है, और coordinates (0,0,0) से (16,16,16) range से आगे -16 से 32 तक specify किए जा सकते हैं
    • सही setup करने पर एक block अधिकतम 3 गुना बड़ा render होकर 9-block area replace कर सकता है
    • सभी combinations handle करने के लिए blocks की संख्या कम है, इसलिए यह केवल पूरी तरह black 6×6 area जैसे common cases में ही उपयोगी है
  • लगभग 600 usable blocks में से 256 basic subpixel representation के लिए इस्तेमाल किए गए, और कुछ बचे blocks optimization में लगाए गए
  • final approach में screen को 2×2 block cells में बाँटा गया, और हर cell के 4×4 pixel sprite को single block से replace करने का candidate माना गया
    • लगातार दो frames का difference calculate किया गया
    • बदले हुए cells के before/after versions को score जोड़ा गया
    • तेज़ी से बदलते scenes में ज्यादा pixels बदलने वाले cells को higher score दिया गया
    • high-score sprites से उपलब्ध blocks assign किए गए
  • basic block count limit से आगे जाने के लिए blockstates की जांच की गई
    • oak_log की तरह properties के आधार पर अलग model चुना जा सकता है
    • grindstone की तरह कई property combinations को key की तरह इस्तेमाल किया जा सकता है
  • default assets से blockstate variants निकाले गए, uncontrollable properties filter की गईं, और accessible models की संख्या लगभग 600 से 1700 हो गई
    • colors की संख्या 6 colors तक बढ़ी
    • optimized blocks की संख्या 400 हो गई

audio और start device

  • music को resource pack से music disc की sound बदलने के तरीके से handle किया गया
    • disc playback time audio बदलने पर भी fixed रहता है
    • “Bad Apple!!” की length के सबसे करीब Relic disc इस्तेमाल की गई
    • assets/minecraft/lang/en_us.json बदलकर in-game subtitle को “Now Playing: Bad Apple!!” दिखाने के लिए किया गया
  • button, dropper, hopper, jukebox को जोड़कर ऐसा बनाया गया कि एक button press से disc jukebox में जाकर play हो
    • playback खत्म होने पर hopper disc को वापस dropper में भेज देता है ताकि next playback तैयार रहे
  • quasiconnectivity की वजह से jukebox द्वारा playback के दौरान दिया गया redstone signal hopper और dropper states को उलझा देता था
    • button input पर dust को dropper update करने दिया गया
    • एक redstone tick बाद repeater फिर dropper को on करके disc insert कराता है
  • viewing position से screen के पीछे वाले device तक signal भेजने के लिए structure block-based instant wire बनाया गया
    • structure block powered redstone torch को next segment में load करता है, और next tick में redstone block की वजह से off हो जाता है
    • यह pulse अगले structure block को activate करके signal आगे भेजता है
    • structure block अधिकतम 48 blocks cover करता है, इसलिए 48×48 subscreen grid तक start signal भेजा जा सकता है
  • viewer से screen के पीछे तक लगभग 150 blocks को अलग resettable structure से जोड़ा गया
    • structure block और redstone block combination को chain में create और delete करते हुए signal भेजा जाता है
    • यह structure creative में directly save करना मुश्किल था, इसलिए Python library से structure file generate की गई
  • final mechanism को बाहर के button से चलने वाले 4×2×3 box में combine किया गया

frame preprocessing और video quality

  • बचे हुए preprocessing tasks full-color video को 6 colors में घटाना और 30fps video को 20fps में बदलना थे
  • Bad Apple!! pure black-and-white ही नहीं है, कई scenes में grayscale का उपयोग करता है
    • motion blur
    • अलग brightness वाले objects
    • scene transitions के gradients
    • fire, sun, shadows, ripples जैसी expressions
  • simply nearest color पर round करने से banding आती है
    • dithering unrepresentable intermediate colors को nearby representable colors के pattern में बदलकर इसे कम करती है
  • high-quality global dithering के results frames के बीच काफी बदल सकते हैं
    • human eye को mismatch आसानी से दिखता है
    • Minecraft के लिए संभालना मुश्किल हो जाए इतने updates बनते हैं
  • Bayer dithering जैसी local dithering stable थी, लेकिन quality low थी; blue-noise based ordered dithering बीच का solution बना
  • original video Niconico upload से आया lossy-compressed source था, इसलिए noise था
    • black और white areas में noise dithering के बाद ज्यादा दिखा
    • almost black को black, almost white को white में round किया गया, और intermediate colors को continuity बनाए रखते हुए spread करके correct किया गया
  • 30fps को 20fps में घटाने की समस्या पूरी तरह हल नहीं हो पाई
    • हर तीसरा frame drop करने पर movement intervals odd/even frames में अलग हो जाते हैं, जो खटकता है
    • update amount भी sawtooth pattern में बदल जाता है
    • online 60fps Bad Apple!! videos AI या automatic tools से upscale किए गए थे, और fast scene transitions में artifacts ज्यादा थे

result और follow-up work

  • implementation 48×36 resolution और 2 colors से शुरू हुआ, 128×96 और 10 colors, 256×192 से गुजरते हुए आखिर में 512×384 और 6 colors तक पहुँचा
  • note block से music play करने की कोशिश भी हुई, लेकिन अच्छी quality के लिए यह अलग project जितना बड़ा हो सकता था, इसलिए छोड़ दिया गया
  • structure block को redstone की तरह इस्तेमाल करने वाली structstone technique बनाई गई, और इससे computer prototype भी शुरू किया गया
  • development के दौरान ffmpeg, mpv, Rust का image crate, Minecraft decompiled code, world directory size minimization techniques आदि इस्तेमाल हुए
  • पूरा काम एक महीने से ज्यादा चला, और दोस्तों के साथ collaborate करते हुए सामान्य projects से अलग तरीके से problems solve करने का अनुभव बना

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-12
Hacker News टिप्पणियाँ

  • उम्मीद से कहीं ज़्यादा computer graphics सीखने को मिला, और लेखक को सलाम
    एक छोटी-सी सुधार: लेखक ने जिस तस्वीर को “The sun” कहा है, वह दरअसल Eirin [0] के चांद की ओर देखने वाला दृश्य है। उस दृश्य [1] में Eirin उस चांद की ओर हाथ बढ़ाती है जहाँ से उसे निर्वासित किया गया था, लेकिन झिझककर हाथ वापस खींच लेती है; अगले दृश्य में Kaguya [2] भी चांद की ओर हाथ बढ़ाती है, मगर झिझकती नहीं। Touhou wiki के अनुसार चांद को चुराने की योजना Eirin की थी, इसलिए यह प्रतीक ठीक-ठीक क्या मतलब रखता है, यह मुझे स्पष्ट नहीं है
    [0] https://en.touhouwiki.net/wiki/Eirin_Yagokoro
    [1] https://youtu.be/FtutLA63Cp8?t=99
    [2] https://en.touhouwiki.net/wiki/Kaguya_Houraisan

    • वह दृश्य देखकर मुझे हमेशा “the sun” याद आता है, इस मज़ेदार वीडियो की वजह से: https://www.youtube.com/watch?v=ReblZ7o7lu4
    • लगता है आपने गलत पढ़ा है। wiki में योजना धरती, या Gensokyo और चांद के बीच के रास्ते को “steal” नहीं बल्कि seal करने की बताई गई है
      Eirin ने Kaguya की रक्षा के लिए जानबूझकर चांद से कनेक्शन काटने का विकल्प चुना था

  • Bad Apple धीरे-धीरे graphics rendering का de facto Hello World क्यों बनता जा रहा है, यह मुझे पूरी तरह समझ नहीं आता, लेकिन इसे real-time में देखना मज़ेदार है
    Bad Apple के साथ high-framerate hypermedia दिखाने वाला यह demo भी देखा: https://data-star.dev/examples/bad_apple

    • वजहें दो हैं। पहली, मूल creator remix और fan use को लेकर बहुत उदार हैं
      कई मायनों में Touhou पहले के fandoms से अलग आधुनिक internet fandom के prototype जैसा था, और वही audio इस्तेमाल करने पर भी Bad Apple वीडियो हटाए नहीं जाते
      दूसरी, shadow-play format resolution कितना भी कम हो, पहचानना आसान रहता है। मैंने 3x3 grid वाला उदाहरण भी देखा है। ऊपर से यह black-and-white, यानी सिर्फ 1/0 दो रंगों में है, इसलिए “Hello World” जितना जानने भर से frames को लगभग किसी भी कल्पनीय format में बदलना बहुत आसान हो जाता है
    • DOOM की कसौटी अब यहाँ तक पहुँच गई है: https://www.reddit.com/r/Doom/comments/1c0g0mi/i_made_doom_i...
      यह Redstone से बने पूरी तरह programmable CPU पर चलता है। IRIS Computer की specs हैं: custom 16-bit CPU, RAM 8 kB, ROM 64 kB, texture ROM 1 kB, 96x64 pixel 16-color screen, floating-point unit(add/sub/mult/div/sqrt), 173 Redstone tick clock, कोई 3D graphics hardware acceleration नहीं, URCL में लिखे programs चलाता है, और MCHPRS server की वजह से 10 लाख ticks प्रति सेकंड पर चलता है, जिससे clock speed 5.8 kHz है
    • मूल गीत Bad Apple!![1] सहित Touhou songs की कम चर्चा होने वाली खूबियों में से एक यह है कि, कम से कम मुझे, वे संगीत से ज़्यादा data bus status display जैसे सुनाई देते हैं
      तय beat और bars वाले संगीत की बजाय, अगर आप कल्पना करें कि MS-DOS boot होते समय 16-bit bus के even bits को instruments से जोड़कर सुन रहे हैं, तो यह कहीं ज़्यादा समझ में आता है। Touhou games के developer ने formal music theory training के बिना PC-88/PC-98 के लिए hardcore shooting games अकेले बनाते हुए ये compositions लिखीं, इसलिए यह स्वाभाविक परिणाम लगता है, और शायद इसी वजह से यह आम संगीत की तुलना में embedded hardware engineers को ज़्यादा परिचित लग सकता है
      एक और factor 2ch/futaba culture से विकसित nicovideo.jp / nico-tech community थी। ऐसे users जिनकी expertise, compensation या financial ambition से कहीं ज़्यादा थी; उस समय STEM students भी बहुत थे, और वे मज़े के लिए remixes में technology झोंक देते थे। रहस्यमय FPGA wizards, motor driver experts, video editors अचानक प्रकट होते और hallucinatory videos डालकर चले जाते—यह सचमुच बेतुका था। Maker Faire Tokyo ने एक समय इज़्ज़त बचाने की कोशिश कर रहे T-shirt पहने web developers के लिए, nico-tech dress shirts जैसे संदिग्ध लोगों को अलग venue के quarantine zone में डाल दिया था। वह घटना व्यंग्यात्मक थी, nico-tech meetup के जन्म की वजह बनी, और दोहराई नहीं गई। ऐसे बेतुके content की quality और quantity की density ने Bad Apple!! PV की inertia बनाई
      आखिरी अहम element यह था कि PV monochrome था, सख्ती से कहें तो grayscale। शायद इसी वजह से nicovideo.jp के golden age के किसी और video की बजाय यही video चुना गया
      1: https://www.youtube.com/watch?v=Yw5HTeT_dis
    • वीडियो पूरी तरह monochrome होते हुए भी बहुत smooth और sophisticated है, और यही बात इसे technical problems पर apply करने के लिए दिलचस्प duality देती है
      अपने आप में भी यह देखने में अच्छा और प्रभावशाली artwork है, इसलिए मुझे लगता है कि इसमें खासकर demoscene लोगों को पसंद आने वाली कई खूबियाँ हैं
    • और विकल्प भी हैं। Factorio में circuits से lights control करने का शुरुआती काम: https://youtu.be/Kry8lbrHjeY और sound implementation: https://youtu.be/b_FumvuFRXA
      रंगों वाला एक और video clip भी है: https://youtu.be/mgfwwqwxdxY

  • “हर चीज़ पर Bad Apple!” मेरे पसंदीदा geek trends में से एक है
    जब मैंने इसे पहली बार Genesis/Mega Drive पर देखा, तो यह देखकर हैरान रह गया कि इतना कमजोर hardware पर भी यह संभव है। कम-performance वाली चीज़ों पर नए ports बनते देखना मुझे अच्छा लगता है। मैं low-level programming में अच्छा नहीं हूँ, इसलिए शायद खुद ऐसा बनाने जितना होशियार नहीं हूँ, लेकिन जो लोग कर सकते हैं, उनका मैं सचमुच सम्मान करता हूँ

  • “यह recursion तब खत्म होती है जब Minecraft अपनी hard limit पर पहुंचता है, और किस्मत से लाल block के बजाय पीला block बनता है” वाला हिस्सा पुराने update suppression glitch(https://mcdf.wiki.gg/wiki/Java_Edition:Update_Suppression) की याद दिलाता है
    ज्यादा पेचीदा population suppression(https://mcdf.wiki.gg/wiki/Java_Edition:Population_Suppressio...) भी इसी तरह game engine को glitch वाली अवस्था में छोड़कर blocks को तुरंत गिरा सकता है

  • video के लिए मेरा पसंदीदा dithering algorithm Yliluoma dithering है: https://bisqwit.iki.fi/story/howto/dither/jy/
    यह grayscale content के लिए खास तौर पर उपयोगी है, क्योंकि उपलब्ध palette में optimal dithering matrix ढूंढना बस एक exact computation है, और result को lookup table में डालकर real-time rendering के लिए इस्तेमाल किया जा सकता है। मुझे व्यक्तिगत रूप से यह खासकर gradients में Bayer या random dithering से कहीं बेहतर दिखता है

  • “Redstone dust उन लगभग इकलौते components में से है जो tick delay नहीं बनाता, लेकिन बहुत धीमा है। लगता है Mojang में graph algorithms जानने वाला कोई नहीं है” जैसी बात कुछ ज्यादा है
    मूल लेख ने जिस post को information source के रूप में link किया है, उसके बाद से यह काफी कम धीमा हुआ है, और पिछले 3 सालों में कई improvements हुए हैं, जिनमें एक हालिया भी शामिल है। Mojang को हर तरफ से बहुत गालियां पड़ती हैं। Redstone को कम धीमा बनाने में इतना समय लगने की वजह यह है कि Redstone को जरा-सा छूने पर भी community चिल्लाती है, और नई features जोड़ने के अलावा कुछ भी करने पर भी community चिल्लाती है, इसलिए इसकी priority कम हो गई। इंटरनेट पर गुस्से में यह कहना कि उन्हें graph algorithms नहीं आते, मददगार नहीं है। Mojang ने Panda4994, Kingbdogz, Gnembon जैसे Minecraft community के बेहद प्रतिभाशाली लोगों को कई बार hire किया है, और वे जो करना चाहते हैं उसके लिए उनके पास technical expertise है। जो नहीं है, वह है अनंत समय और budget। 15 साल पुराने Java codebase और एक विशाल multi-platform C++ app को एक साथ maintain करते हुए sync में रखना वाकई मुश्किल है, इसलिए थोड़ा उदार होकर देखने की उम्मीद है। दिन भर हर तरफ से बरसती नफरत से थक चुका हूं, और अच्छा लगेगा अगर बस यह कहा जा सके कि Minecraft शानदार है

    • इस तरह के वाक्य programming blogs में काफी अक्सर दिखते हैं
      पहले मुझे इससे ज्यादा चिढ़ होती थी, लेकिन बाद में समझ आया कि यह घमंड से ज्यादा 16~21 साल की उम्र वाली मासूमियत है, जहां “professional” experience कम होता है
    • ऐसा क्यों करना चाहिए? उनके पास engine को Rust में फिर से लिखकर उसे अपनी मर्जी की हर चीज बनाने की ताकत है
      ऐसा भी नहीं लगता कि उन्हें versions के बीच compatibility की परवाह है

  • high school के बाद से मैं Minecraft में इतना नहीं डूबा कि गंभीर Redstone devices बनाऊं
    अब तो बस महीने में कुछ बार दोस्तों के साथ खेलता हूं, जब अचानक कुछ बनाने और explore करने की इच्छा लौट आती है। अभी Redstone ecosystem को देखूं तो यह पूरी तरह बदल चुका है और पहचान में नहीं आता, और सोचता हूं कि क्या धीरे-धीरे senior software engineer बनते हुए मुझे भी ऐसा ही महसूस होगा। समय बीतने पर, जिन stacks को कई सालों तक practical work में नहीं छुआ, उन्हें देखते हुए शायद हैरानी होगी कि technology कितनी तेजी से बदलती है और लोग उसके ऊपर क्या-क्या नया बनाते हैं

  • “और… बस इतना ही? पीछे मुड़कर देखें तो result लगभग मामूली तरीके से हासिल होने लायक लगता है, और सवाल उठता है कि पहले किसी ने ऐसा क्यों नहीं किया” वाली प्रतिक्रिया से मैं सहमत नहीं हूं
    यह एक शानदार devlog है और दिखाता है कि भारी-भरकम लगने वाले काम को लगभग असंभव लेकिन संभव टुकड़ों में कैसे बांटा जाए। बहुत अच्छा लगा। संदर्भ के लिए, यह implementation vanilla Minecraft में Bad Apple को 20fps पर render करता है, सिर्फ एक custom texture और कुछ custom object definitions के साथ जिन्हें ज्यादा textures allow करने के लिए बदला गया है। बाकी सब बहुत exotic है, लेकिन vanilla है

    • खारिज किए गए solutions में दिखने वाली ज्ञान की व्यापकता सबसे प्रभावशाली है

  • असली video पर ही इतनी मेहनत लगाई गई, यह थोड़ा मजेदार है
    मैं जब Bad Apple implementation खत्म करता हूं, तो आमतौर पर इतना थक चुका होता हूं कि dithering या frame rate के बारे में सोचने की फुर्सत नहीं रहती, बस ffmpeg से चला देता हूं और कह देता हूं कि हो गया

  • Minecraft world से बना Bad Apple भी देखने लायक है: https://www.youtube.com/watch?v=RN3QW9SVnds