„Bad Apple!!“ in Minecraft

 (purplesyringa.moe)
2 Punkte von GN⁺ 2024-10-12 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Umsetzung, die Bad Apple!! auf der langsamen Engine von Minecraft in Echtzeit mit der originalgetreuen Auflösung von 512×384, 20 fps und Graustufen abspielt
  • Der Kern besteht darin, dass ein structure block im LOAD-Modus sich selbst durch die Struktur des nächsten Frames ersetzt und mit phasenversetzten Takten die 10-Hz-Grenze von Redstone umgeht
  • Würde man einen Block als einen Pixel verwenden, müssten 768 Chunks mit 20 Hz aktualisiert werden; daher reduziert ein Resource Pack mit Custom Textures, Models und blockstates die Datenmenge, indem ein Block mehr Bildinformationen darstellt
  • Der Flaschenhals lag weniger bei Redstone oder Beleuchtung als bei setBlock und der Event-Verarbeitung; Delta Coding und der Austausch häufig wechselnder 4×4-Sprites verringern die Zahl der Updates
  • Die finale Qualität wurde mit 6 Graustufen, Blue-Noise-Dithering und Korrektur von verlustbehaftetem Kompressionsrauschen verfeinert, das Problem der Reduktion des 30-fps-Originals auf 20 fps wurde jedoch nicht vollständig gelöst

Bedingungen für eine möglichst originalgetreue Wiedergabe

  • Ziel war es, Bad Apple!! innerhalb von Minecraft so nah wie möglich am Original abzuspielen
    • Das Video wird mit 20 fps abgespielt
    • Die Auflösung entspricht der Originalanimation: 512×384
    • Nicht nur Schwarzweiß, sondern Graustufen
    • Auf modernen CPUs und GPUs lässt es sich tatsächlich mit 20 fps ansehen, ohne die Aufnahme nachträglich zu beschleunigen
    • Es werden keine Command Blocks verwendet
  • Einfache Abkürzungen wurden aus den Implementierungsbedingungen ausgeschlossen
    • Mods werden nicht als Implementierungsweg genutzt; erlaubt sind nur Optimierungsmods für Tests auf leistungsschwacher Hardware
    • Command Blocks, /setblock und Datapacks werden nicht verwendet
    • Animierte Texturen werden ebenfalls nicht verwendet
  • Auf schwächeren Geräten kann VulkanMod oder Sodium nötig sein
    • C2ME sollte vermieden werden, weil die Autosave-Funktion die Performance verschlechtert

Grenzen bisheriger Umsetzungen

  • Frühere Bad-Apple!!-Umsetzungen blieben meist bei kleinen Bildflächen oder langsamem Rendering
    • Der Versuch von catlord5 erreichte 512×384 und 30 fps, wurde aber etwa 40-mal langsamer gerendert
    • Einige Redstone-basierte Echtzeitumsetzungen lagen bei etwa 5 fps oder niedriger Auflösung
  • Minecraft hat nicht nur eine langsame Simulations-Engine, sondern auch eine langsame Rendering-Engine; mit steigender Chunk-Zahl wächst die Belastung
    • Ein 16×16×16-Chunk ist unabhängig vom Inhalt teuer neu zu rendern
    • Entscheidend ist, die Zahl der Chunks zu reduzieren, über die sich das Bild erstreckt
  • Redstone lässt sich für 20-fps-Wiedergabe nicht direkt gut nutzen, weil praktikable Taktgeneratoren meist ein 10-Hz-Signal liefern
    • Redstone Dust ist zwar ein wichtiges Bauteil ohne Verzögerung, aber aus Performance-Sicht teuer

Experimente mit Datenspeicherung

  • Eine Hopper-Line ist eine typische Speichertechnik, bei der in Truhen gespeicherte Items per Hopper entnommen und mit Comparatoren ausgelesen werden
    • Hopper übertragen Items nur alle 0,4 Sekunden, die maximale Framerate liegt daher bei 2,5 fps
    • Für 20 fps wären mehrere parallele Hopper-Strukturen nötig, wobei Tiling und Simulationskosten problematisch werden
  • Auch ein Verfahren mit Jukebox und Musikdiscs wurde ausprobiert, um Werte von 1 bis 15 auszulesen und damit fast 4 Bit zu speichern
    • Legt man die Bits auf die Zeitachse, könnten zwei Hopper theoretisch 20 fps erreichen
    • Die für Bit-Shifts nötige Redstone-Logik und der Dust waren jedoch zu langsam; selbst ein Prototyp war nicht performant genug
  • Eine Repeater Delay Line ist ein einfacher Ansatz, bei dem für jeden Pixel eine Repeater-Leitung aufgebaut wird, die Werte zeitlich passend ausgibt
    • 1×1-Pixel-Tiling ist möglich
    • Selbst deutlich kleinere frühere Umsetzungen hätten eine 20-fache Beschleunigung gebraucht, daher reichte das nicht aus

Frames mit structure blocks weiterschalten

  • Structure Blocks (structure block) können mit SAVE einen Bereich speichern und ihn mit LOAD an anderer Stelle laden
    • In Survival sind sie nicht erhältlich, ersetzen aber nicht wie ein Command Block mit einem einzigen Befehl alles
    • Sie können durch ein Redstone-Signal aktiviert werden
  • Entscheidend ist, dass ein LOAD-Structure-Block einen Bereich laden kann, der mit ihm selbst überlappt
    • Ersetzt man den aktuellen Structure Block durch den nächsten, lädt jede Aktivierung den nächsten Frame
  • Wird er schlicht ersetzt, erkennt der neue Structure Block sofort das umliegende Redstone-Signal und aktiviert sich rekursiv
    • Diese Rekursion läuft weiter, bis sie an Minecrafts hartes Limit stößt
    • Auch das Ausschalten des Redstone Dust ist dann noch nicht abgeschlossen, wodurch fehlerhafte Stromzustände zurückbleiben
  • Ein Repeater mit 1 Redstone Tick Verzögerung verhindert die rekursive Aktivierung
    • Die Struktur muss im Zustand /tick freeze erstellt werden, damit der Repeater ausgeschaltet gespeichert wird
    • Nach dem Laden wird nach einem Redstone Tick zur nächsten Struktur gewechselt

Tick-Verarbeitung für 20 fps

  • Minecraft unterscheidet zwischen Game Ticks und Redstone Ticks
    • Die Game Engine berechnet Physik mit 20 Hz neu
    • Redstone-Komponenten planen Aktualisierungen typischerweise in 0,1-Sekunden-Schritten, also mit 10 Hz
  • Tatsächliche Events werden in 0,05-Sekunden-Abständen verarbeitet; je nach Timing der Nutzereingabe kann auch die Redstone-Reaktion auf diese Phase verschoben werden
  • Für 20 fps werden vier Strukturen verwendet
    • Rote und gelbe Strukturen bilden einen 10-Hz-Takt
    • Blaue und grüne Strukturen bilden einen anderen 10-Hz-Takt
    • Startet man beide Takte mit unterschiedlicher Phase, erscheinen die vier Farben an derselben Stelle abwechselnd mit 20 Hz
  • Um beide Takte zuverlässig phasenverschoben zu starten, wird ein alter Bug genutzt: Wenn ein Piston einen Redstone Block schiebt, dauert es bei direkter Nutzereingabe 3 Game Ticks

Resource-Pack-Techniken zur Reduzierung der Chunk-Zahl

  • Würde man einen Block als einen Pixel verwenden, hätte ein 512×384-Bild vertikal 24 Chunks und horizontal 32 Chunks
    • Insgesamt müssten 768 Chunks permanent mit 20 Hz aktualisiert werden
    • Auch wegen der maximalen Render Distance von 32 Chunks in Vanilla ist das unrealistisch
  • Mit Custom Textures in einem Resource Pack werden die Texturen mehrerer Blöcke so verändert, dass ein Block mehrere Subpixel enthält
    • 16 Blockvarianten entsprechen 4 Bit
    • Mit 256 Blöcken und zusätzlichen Farben lässt sich statt reinem Schwarzweiß Graustufenbild darstellen
  • Dadurch wird die Blockauflösung um den Faktor 4 auf 256×192 Blöcke reduziert
    • Die Zahl der zu aktualisierenden Bild-Chunks sinkt auf 192
    • Für 20-Hz-Updates bleibt das aber weiterhin eine große Last

Rendering-Queue und Delta Coding

  • Minecrafts Rendering-Engine priorisiert Chunk-Updates in der Nähe des Spielers
    • Mehrere Threads erzeugen gleichzeitig Chunks und holen sich aus der Update-Queue zuerst die dem Spieler nächsten Chunks
    • Wenn die nächsten N Chunks dauerhaft mit 20 Hz aktualisiert werden, kann es passieren, dass nur diese Chunks verarbeitet werden und der Rest nicht gerendert wird
  • Mit Spark zeigte sich, dass der Flaschenhals eher in allgemeinen Updates lag als bei Redstone oder Beleuchtung
    • Besonders setBlock und Event Handler waren problematisch
  • Die Lösung war eine Reduktion der Update-Zahl; dafür wurde Delta Coding angewandt, bei dem nur die zwischen Frames geänderten Blöcke aktualisiert werden
    • Da sich in den meisten Frames nicht sehr viel ändert, gibt es theoretisch Spielraum für Performance-Gewinne
  • Ein Structure Block kann auf einmal nur 48×48×48 Blöcke laden, daher wird das Bild in 6×4 Subscreens mit je 48×48 geteilt
    • Frames werden mit ffmpeg extrahiert
    • Bilder werden mit Python Pillow eingelesen
    • NBT-Dateien werden mit nbtlib erzeugt
  • Der erste Prototyp brauchte pro Durchlauf etwa 7 Minuten und erforderte /tick freeze, 24 Buttons und /tick unfreeze, funktionierte aber
    • Delta Coding allein war trotzdem noch nicht schnell genug

Optimierung von Models und blockstates

  • Minecraft-Models definieren die Form eines Blocks als Cuboids; Koordinaten können über den Bereich von (0,0,0) bis (16,16,16) hinaus von -16 bis 32 angegeben werden
    • Richtig eingestellt kann ein Block so gerendert werden, als sei er bis zu dreimal so groß, und damit einen Bereich von 9 Blöcken ersetzen
    • Für alle Kombinationen gibt es nicht genug Blöcke, daher ist das nur für häufige Fälle sinnvoll, etwa komplett schwarze 6×6-Bereiche
  • Von rund 600 verfügbaren Blöcken werden 256 für die grundlegende Subpixel-Darstellung genutzt; ein Teil der übrigen Blöcke dient der Optimierung
  • Der finale Ansatz teilt das Bild in 2×2-Blockzellen und behandelt das 4×4-Pixel-Sprite jeder Zelle als Kandidaten für den Ersatz durch einen einzelnen Block
    • Die Differenz zwischen zwei aufeinanderfolgenden Frames wird berechnet
    • Vorher- und Nachher-Versionen geänderter Zellen erhalten Punkte
    • In schnell wechselnden Szenen bekommen Zellen mit mehr geänderten Pixeln eine höhere Punktzahl
    • Den höchstbewerteten Sprites werden zuerst verfügbare Blöcke zugewiesen
  • Um die Grenze der normalen Blockzahl zu überschreiten, wurden blockstates untersucht
    • Wie bei oak_log kann je nach Eigenschaft ein anderes Model ausgewählt werden
    • Wie bei grindstone können mehrere Eigenschaftskombinationen als Schlüssel dienen
  • Aus den Standard-Assets wurden blockstate-Varianten extrahiert; nach dem Herausfiltern nicht steuerbarer Eigenschaften stieg die Zahl zugänglicher Models von etwa 600 auf 1700
    • Die Zahl der Farben wurde auf 6 erhöht
    • Die Zahl der optimierten Blöcke stieg auf 400

Audio und Startmechanismus

  • Die Musik wird über ein Resource Pack umgesetzt, das den Sound einer Musikdisc ersetzt
    • Die Abspieldauer einer Disc bleibt auch bei geändertem Audio fest
    • Verwendet wird die Relic-Disc, deren Länge „Bad Apple!!“ am nächsten kommt
    • assets/minecraft/lang/en_us.json wird geändert, damit der Untertitel im Spiel „Now Playing: Bad Apple!!“ anzeigt
  • Button, Dropper, Hopper und Jukebox werden so verbunden, dass ein einziger Button-Druck die Disc in die Jukebox einlegt und die Wiedergabe startet
    • Nach Ende der Wiedergabe befördert der Hopper die Disc zurück in den Dropper und bereitet den nächsten Start vor
  • Wegen Quasiconnectivity brachte das Redstone-Signal der spielenden Jukebox die Zustände von Hopper und Dropper durcheinander
    • Beim Button-Druck sorgt Dust dafür, dass der Dropper aktualisiert wird
    • Einen Redstone Tick später schaltet ein Repeater den Dropper erneut ein, um die Disc einzulegen
  • Um vom Zuschauerstandort ein Signal zu den Geräten hinter dem Bildschirm zu senden, wurde ein auf Structure Blocks basierender Instant Wire gebaut
    • Ein Structure Block lädt eine powered Redstone Torch in den nächsten Abschnitt; im nächsten Tick wird sie wegen eines Redstone Blocks ausgeschaltet
    • Dieser Puls aktiviert den nächsten Structure Block und leitet das Signal weiter
    • Ein Structure Block kann bis zu 48 Blöcke abdecken, sodass ein Startsignal an das 48×48-Subscreen-Raster gesendet werden kann
  • Die rund 150 Blöcke vom Zuschauer bis zur Rückseite des Bildschirms werden mit einer separat resetbaren Struktur überbrückt
    • Kombinationen aus Structure Blocks und Redstone Blocks werden kettenartig erzeugt und gelöscht, um das Signal weiterzuleiten
    • Da diese Struktur in Creative nur schwer direkt zu speichern ist, werden die Structure-Dateien mit einer Python-Bibliothek erzeugt
  • Der finale Mechanismus wird in einer von außen per Button bedienbaren 4×2×3-Box zusammengeführt

Frame-Vorverarbeitung und Bildqualität

  • Die verbliebenen Vorverarbeitungsaufgaben waren, das Full-Color-Video auf 6 Farben zu reduzieren und das 30-fps-Video auf 20 fps umzuwandeln
  • Bad Apple!! verwendet in vielen Szenen nicht nur reines Schwarzweiß, sondern Graustufen
    • Motion Blur
    • Objekte mit unterschiedlicher Helligkeit
    • Gradienten bei Szenenübergängen
    • Darstellungen wie Feuer, Sonne, Schatten und Wellen
  • Rundet man einfach auf die nächstliegende Farbe, entsteht Banding
    • Dithering mildert das, indem nicht darstellbare Zwischenfarben durch Muster benachbarter darstellbarer Farben ersetzt werden
  • Hochwertiges globales Dithering kann zwischen Frames stark unterschiedliche Ergebnisse erzeugen
    • Das menschliche Auge erkennt solche Inkonsistenzen leicht
    • Außerdem entstehen so viele Updates, dass Minecraft sie kaum bewältigen kann
  • Lokales Dithering wie Bayer Dithering ist stabil, aber qualitativ schwach; Blue-Noise-basiertes Ordered Dithering wurde zum Mittelweg
  • Das Originalvideo stammte als verlustbehaftet komprimiertes Material vom Niconico-Upload und enthielt Rauschen
    • Rauschen in schwarzen und weißen Bereichen wurde nach dem Dithering sichtbarer
    • Zur Korrektur wurden fast schwarze Bereiche auf Schwarz und fast weiße auf Weiß gerundet; Zwischentöne wurden so verteilt, dass Kontinuität erhalten bleibt
  • Das Problem, 30 fps auf 20 fps zu reduzieren, wurde nicht vollständig gelöst
    • Lässt man jeden dritten Frame weg, unterscheiden sich die Bewegungsabstände in ungeraden und geraden Frames, was störend auffällt
    • Auch die Update-Menge verändert sich in einem sägezahnartigen Muster
    • Online verfügbare 60-fps-Bad-Apple!!-Videos wurden mit KI oder automatischen Tools hochskaliert und zeigen bei schnellen Szenenwechseln viele Artefakte

Ergebnis und Folgearbeiten

  • Die Umsetzung begann bei 48×36 Auflösung und 2 Farben, führte über 128×96 mit 10 Farben und 256×192 schließlich zu 512×384 mit 6 Farben
  • Es gab auch Versuche, die Musik mit Note Blocks abzuspielen; um gute Qualität zu erreichen, wäre das aber ein eigenes Projekt geworden, daher wurde es aufgegeben
  • Es entstand eine Structstone-Technik, bei der Structure Blocks wie Redstone genutzt werden; damit wurde auch ein Computer-Prototyp begonnen
  • Im Entwicklungsprozess wurden ffmpeg, mpv, Rusts image crate, dekompilierter Minecraft-Code und Techniken zur Minimierung der Größe des World-Verzeichnisses genutzt
  • Die gesamte Arbeit dauerte mehr als einen Monat und wurde zu einer Erfahrung, bei der gemeinsam mit Freunden Probleme auf andere Weise als in üblichen Projekten gelöst wurden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-12
Meinungen auf Hacker News

  • Ich habe viel mehr über Computergrafik gelernt als erwartet; großes Lob an den Autor.
    Eine kleine Korrektur: Das Bild, das der Autor „The sun“ nennt, zeigt eigentlich Eirin [0], wie sie zum Mond blickt. In dieser Szene [1] streckt Eirin die Hand nach dem Mond aus, von dem sie verbannt wurde, zögert dann aber und zieht sie zurück; in der nächsten Szene streckt auch Kaguya [2] die Hand nach dem Mond aus, zögert jedoch nicht. Laut Touhou-Wiki war der Plan, den Mond zu stehlen, Eirins Idee; daher bin ich mir nicht sicher, was genau diese Symbolik bedeuten soll.
    [0] https://en.touhouwiki.net/wiki/Eirin_Yagokoro
    [1] https://youtu.be/FtutLA63Cp8?t=99
    [2] https://en.touhouwiki.net/wiki/Kaguya_Houraisan

    • Bei der Szene denke ich immer an „the sun“, wegen dieses lustigen Videos: https://www.youtube.com/watch?v=ReblZ7o7lu4
    • Ich glaube, das wurde falsch gelesen. Im Wiki steht, dass der Plan war, den Durchgang zwischen der Erde bzw. Gensokyo und dem Mond zu sealen, nicht ihn zu „steal“en.
      Eirin entschied sich bewusst dafür, die Verbindung zum Mond zu kappen, um Kaguya zu schützen.

  • Ich verstehe nicht ganz, warum Bad Apple gewissermaßen zum Hello World des Grafik-Renderings wird, aber es in Echtzeit zu sehen, macht Spaß.
    Ich habe auch diese Demo gesehen, die High-Framerate-Hypermedia mit Bad Apple zeigt: https://data-star.dev/examples/bad_apple

    • Dafür gibt es zwei Gründe. Erstens ist der ursprüngliche Urheber gegenüber Remixes und Fan-Nutzung sehr großzügig.
      In vielerlei Hinsicht war Touhou, anders als frühere Fandoms, so etwas wie der Prototyp moderner Internet-Fandoms, und Bad-Apple-Videos werden auch bei Verwendung derselben Audiospur nicht offline genommen.
      Zweitens ist das Schattenspiel-Format selbst bei extrem niedriger Auflösung leicht erkennbar. Ich habe sogar schon ein Beispiel mit einem 3x3-Raster gesehen. Außerdem ist es schwarzweiß, also nur zwei Farben, 1/0; damit lässt sich, sobald man auch nur auf „Hello World“-Niveau ist, jeder Frame sehr leicht in fast jedes vorstellbare Format umwandeln.
    • Der DOOM-Maßstab ist inzwischen hier angekommen: https://www.reddit.com/r/Doom/comments/1c0g0mi/i_made_doom_i...
      Läuft auf einer vollständig programmierbaren CPU aus Redstone. Die Spezifikationen des IRIS Computer: Custom-16-Bit-CPU, 8 kB RAM, 64 kB ROM, 1 kB Textur-ROM, 96x64-Pixel-Display mit 16 Farben, Gleitkommaeinheit (add/sub/mult/div/sqrt), 173-Redstone-Tick-Takt, keine 3D-Grafik-Hardwarebeschleunigung, führt in URCL geschriebene Programme aus; dank eines MCHPRS-Servers läuft er mit 1 Million Ticks pro Sekunde, was einer Taktfrequenz von 5,8 kHz entspricht.
    • Eine der weniger erwähnten Eigenschaften von Touhou-Stücken, einschließlich des ursprünglichen Bad Apple!![1], ist, dass sie zumindest für mich weniger wie Musik klingen als wie eine Statusanzeige eines Datenbusses.
      Statt Musik mit gleichmäßigem Beat und Takten ergibt es viel mehr Sinn, wenn man sich vorstellt, während MS-DOS bootet die geraden Bits eines 16-Bit-Busses an Instrumente anzuschließen und mitzuhören. Da der Touhou-Spieleentwickler ohne formale Ausbildung in Musiktheorie allein Hardcore-Shoot’em-ups für PC-88/PC-98 entwickelte und dafür komponierte, wirkt das wie ein natürliches Ergebnis; deshalb kann es sich für Embedded-Hardware-Ingenieure vertrauter anfühlen als gewöhnliche Musik.
      Ein weiterer Faktor war die aus der 2ch/futaba-Kultur entstandene nicovideo.jp-/nico-tech-Community. Nutzer mit weit mehr Expertise als Vergütung oder finanziellen Ambitionen, damals auch viele STEM-Studierende, steckten aus Spaß Technik in Remixes. Mysteriöse FPGA-Zauberer, Motortreiber-Experten und Videoeditoren tauchten plötzlich auf, warfen einem halluzinatorische Videos hin und verschwanden wieder; es war wirklich absurd. Auf der Maker Faire Tokyo wurden Leute, die verdächtig nach nico-tech-Dressshirts aussahen, einmal in einen separaten Eventbereich abgesondert, offenbar zugunsten von Webentwicklern in T-Shirts, die ihr Gesicht wahren wollten. Das war eine Ironie der Geschichte, führte zur Entstehung von nico-tech-Treffen und wiederholte sich nicht. Die Dichte an Qualität und Menge solcher absurder Inhalte erzeugte die Trägheit hinter dem Bad Apple!! PV.
      Das letzte entscheidende Element war, dass das PV einfarbig war, streng genommen Graustufen. Wahrscheinlich ist es deshalb dieses Video geworden und nicht ein anderes aus der goldenen Zeit von nicovideo.jp.
      1: https://www.youtube.com/watch?v=Yw5HTeT_dis
    • Dass das Video vollständig einfarbig und zugleich sehr flüssig und ausgefeilt ist, erzeugt bei der Anwendung auf technische Probleme eine interessante Doppelwirkung.
      Es ist auch für sich genommen ein schönes und beeindruckendes Kunstwerk; ich denke, es hat viele Eigenschaften, die besonders Leuten aus der Demoszene gefallen dürften.
    • Es gibt auch andere Optionen. Eine frühe Arbeit in Factorio, bei der Lampen per Schaltungen gesteuert wurden: https://youtu.be/Kry8lbrHjeY und eine Sound-Implementierung: https://youtu.be/b_FumvuFRXA
      Es gibt auch einen anderen Videoclip mit Farben: https://youtu.be/mgfwwqwxdxY

  • „Bad Apple auf allem!“ ist einer meiner liebsten Nerd-Trends.
    Als ich es zum ersten Mal auf Genesis/Mega Drive gesehen habe, war ich verblüfft, dass das auf so schwacher Hardware möglich ist. Ich mag es, neue Ports auf Dingen entstehen zu sehen, die eigentlich zu leistungsschwach sind. Ich bin nicht gut genug in Low-Level-Programmierung und wahrscheinlich nicht klug genug, um so etwas selbst zu bauen, aber ich habe großen Respekt vor denen, die es können.

  • Die Stelle „Diese Rekursion endet, wenn Minecraft an ein hartes Limit stößt, und mit etwas Glück wird statt eines roten Blocks ein gelber Block erzeugt“ erinnert an den früheren Update-Suppression-Glitch (https://mcdf.wiki.gg/wiki/Java_Edition:Update_Suppression)
    Die noch kniffligere Population Suppression (https://mcdf.wiki.gg/wiki/Java_Edition:Population_Suppressio...) kann die Game Engine auf ähnliche Weise in einem Glitch-Zustand belassen, sodass Blöcke sofort herunterfallen.

  • Mein liebster Dithering-Algorithmus für Videos ist Yliluoma Dithering: https://bisqwit.iki.fi/story/howto/dither/jy/
    Besonders nützlich ist er bei Graustufeninhalten, weil das Finden der optimalen Dithering-Matrix aus der verfügbaren Palette eine einfache exakte Berechnung ist und man das Ergebnis in eine Lookup-Tabelle stecken kann, um es für Echtzeit-Rendering zu nutzen. Persönlich finde ich, dass es besonders bei Gradienten deutlich besser aussieht als Bayer- oder zufälliges Dithering.

  • Aussagen wie „Redstone dust ist fast die einzige Komponente, die keinen Tick-Delay erzeugt, aber sehr langsam ist. Bei Mojang scheint niemand Graphalgorithmen zu kennen“ sind überzogen.
    Seit dem Artikel, den der Originalbeitrag als Quelle verlinkt, ist es deutlich weniger langsam geworden, und in den letzten drei Jahren gab es viele Verbesserungen, darunter auch eine ganz aktuelle. Mojang bekommt von allen Seiten viel Kritik ab. Der Grund, warum es so lange gedauert hat, Redstone weniger langsam zu machen, ist, dass die Community schreit, sobald man Redstone auch nur ein wenig anfasst, und dass die Community auch schreit, wenn man etwas tut, das keine neue Funktion ist — dadurch wurde es weniger lohnend. Im Internet wütend zu behaupten, sie würden keine Graphalgorithmen kennen, hilft nicht. Mojang hat mehrfach sehr talentierte Leute aus der Minecraft-Community eingestellt, etwa Panda4994, Kingbdogz und Gnembon, und verfügt über die technische Expertise, um zu tun, was sie wollen. Was sie nicht haben, sind unbegrenzte Zeit und unbegrenztes Budget. Eine 15 Jahre alte Java-Codebasis und eine riesige plattformübergreifende C++-App gleichzeitig zu pflegen und synchron zu halten, ist wirklich schwierig; ich würde mir daher etwas mehr Nachsicht wünschen. Ich bin es leid, den ganzen Tag von überall Hass zu sehen, und fände es schön, einfach sagen zu können, dass Minecraft großartig ist.

    • Sätze dieser Art sieht man in Programmierblogs ziemlich häufig.
      Früher hat mich das mehr genervt, aber später wurde mir klar, dass es weniger Überheblichkeit ist als eine gewisse Naivität der Altersgruppe 16 bis 21, die wenig „professionelle“ Erfahrung hat.
    • Warum sollten sie das müssen? Sie haben die Macht, die Engine in Rust neu zu schreiben und daraus alles zu machen, was sie wollen.
      Es scheint ihnen ja auch nicht besonders wichtig zu sein, die Kompatibilität zwischen Versionen zu wahren.

  • Seit der Highschool war ich nicht mehr so in Minecraft vertieft, dass ich ernsthafte Redstone-Apparaturen gebaut hätte.
    Heute spiele ich nur noch ein paar Mal im Monat mit Freunden, wenn plötzlich wieder der Wunsch aufkommt, etwas zu bauen und zu erkunden. Wenn ich mir das heutige Redstone-Ökosystem ansehe, ist es völlig anders und kaum wiederzuerkennen; ich frage mich, ob ich ein ähnliches Gefühl haben werde, während ich langsam zum Senior Software Engineer werde. Nach einigen Jahren wird man wohl auf Stacks schauen, die man beruflich seit Jahren nicht mehr angefasst hat, und staunen, wie schnell sich Technik verändert und was Menschen Neues darauf aufbauen.

  • Der Reaktion „Und … das war’s? Rückblickend wirkt das Ergebnis fast trivial erreichbar, und man fragt sich, warum es vorher niemand gemacht hat“ stimme ich nicht zu.
    Das ist ein großartiges Entwicklungsprotokoll und eine kleine Lektion darin, eine überwältigend wirkende Aufgabe in fast unmögliche, aber machbare Teile zu zerlegen. Hat mir wirklich gut gefallen. Zur Einordnung: Diese Implementierung rendert Bad Apple in Vanilla Minecraft mit 20 fps, nur mit einer Custom-Textur und einigen angepassten Custom-Objektdefinitionen, um mehr Texturen zu erlauben. Der Rest ist sehr exotisch, aber Vanilla.

    • Am beeindruckendsten ist die Breite des Wissens, die in den verworfenen Lösungsansätzen sichtbar wird.

  • Es ist irgendwie lustig, dass so viel Aufwand in das eigentliche Video selbst gesteckt wurde.
    Wenn ich eine Bad-Apple-Implementierung fertig habe, bin ich normalerweise so erschöpft, dass ich keine Kapazität mehr habe, über Dithering oder Framerate nachzudenken; ich lasse es einfach durch ffmpeg laufen und erkläre es für erledigt.

  • Auch Bad Apple als Minecraft-Welt ist sehenswert: https://www.youtube.com/watch?v=RN3QW9SVnds