“Bad Apple!!” trong Minecraft

 (purplesyringa.moe)
2 điểm bởi GN⁺ 2024-10-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một bản triển khai cho phép phát Bad Apple!! theo thời gian thực trên engine chậm của Minecraft với độ phân giải 512×384 như bản gốc, 20fps và thang độ xám
  • Cốt lõi là dùng structure block ở chế độ LOAD để tự thay thế chính nó bằng cấu trúc của khung hình kế tiếp, đồng thời dùng các xung nhịp lệch pha để vượt qua giới hạn 10Hz của redstone
  • Nếu dùng một block cho mỗi pixel thì phải cập nhật 768 chunk ở 20Hz, nên tác giả giảm tải bằng texture, model và blockstate tùy biến trong resource pack để một block biểu diễn được nhiều thông tin màn hình hơn
  • Nút thắt cổ chai không nằm ở redstone hay ánh sáng mà ở setBlock và xử lý sự kiện, nên tác giả giảm lượng cập nhật bằng mã hóa delta và thay thế các sprite 4×4 thay đổi thường xuyên
  • Chất lượng cuối cùng được tinh chỉnh với 6 mức xám, dithering blue-noise và hiệu chỉnh nhiễu nén mất dữ liệu, nhưng bài toán giảm bản gốc 30fps xuống 20fps vẫn chưa được giải quyết trọn vẹn

Các điều kiện để phát lại gần với bản gốc

  • Mục tiêu là phát Bad Apple!! trong Minecraft sao cho càng giống bản gốc càng tốt
    • Video phát ở 20fps
    • Độ phân giải là 512×384, giống bản hoạt hình gốc
    • Không phải đen trắng thuần mà là thang độ xám
    • Trên CPU và GPU hiện đại có thể xem ở tốc độ 20fps thực, không cần ghi hình rồi tăng tốc
    • Không dùng command block
  • Các đường tắt dễ dàng bị loại khỏi điều kiện triển khai
    • Không dùng mod như một cách triển khai, chỉ cho phép mod tối ưu hóa để kiểm thử trên máy cấu hình thấp
    • Không dùng command block, /setblock, hay datapack
    • Cũng không dùng texture động
  • Trên thiết bị cấu hình thấp có thể cần VulkanMod hoặc Sodium
    • Nên tránh C2ME vì tính năng tự động lưu của nó gây giảm hiệu năng

Những giới hạn mà các triển khai trước đây gặp phải

  • Các bản Bad Apple!! trước đây phần lớn chỉ dừng ở màn hình nhỏ hoặc render chậm
    • Nỗ lực của catlord5 đạt 512×384 và 30fps nhưng render chậm hơn khoảng 40 lần
    • Một số bản thời gian thực dựa trên redstone chỉ ở mức 5fps hoặc độ phân giải thấp
  • Minecraft không chỉ chậm ở engine mô phỏng mà cả engine render cũng chậm, và gánh nặng tăng mạnh khi số chunk nhiều lên
    • Chunk 16×16×16 có chi phí render lại lớn bất kể bên trong chứa gì
    • Việc giảm số chunk mà màn hình đi qua là rất quan trọng
  • Redstone khó dùng trực tiếp cho phát 20fps vì bộ tạo xung nhịp thực tế thường chỉ cho tín hiệu 10Hz
    • Redstone dust là thành phần chủ lực không có độ trễ, nhưng lại gây tải hiệu năng lớn

Thử nghiệm các cách lưu trữ dữ liệu

  • Cách hopper line là kiểu lưu trữ điển hình: lấy item từ chest qua hopper rồi đọc bằng comparator
    • Hopper có khoảng cách truyền item là 0,4 giây nên framerate tối đa chỉ 2,5fps
    • Muốn lên 20fps phải dùng nhiều hopper song song, nhưng lại gặp vấn đề về tiling và chi phí mô phỏng
  • Tác giả cũng thử cách dùng jukebox và music disc để đọc giá trị 1~15, tức lưu được gần 4 bit
    • Nếu trải bit theo trục thời gian thì có thể nhắm 20fps với 2 hopper
    • Nhưng logic redstone và dust cần cho bit shift quá chậm, nên ngay cả prototype cũng không đủ hiệu năng
  • Repeater delay line là cách đơn giản, đặt một hàng repeater cho mỗi pixel để xuất giá trị đúng thời điểm
    • Có thể tile ở mức 1×1 pixel
    • Nhưng ngay cả các bản cũ nhỏ hơn mục tiêu rất nhiều cũng đã cần tăng tốc 20 lần, nên cách này không đủ

Chuyển khung hình bằng structure block

  • Structure block (structure block) có thể lưu một vùng bằng SAVE và nạp lại ở nơi khác bằng LOAD
    • Không thể kiếm được trong survival, nhưng cũng không thay thế mọi thứ chỉ bằng một lệnh như command block
    • Có thể kích hoạt bằng tín hiệu redstone
  • Điểm mấu chốt là structure block ở chế độ LOAD có thể nạp một vùng chồng lên chính nó
    • Nếu block structure hiện tại được thay bằng block structure kế tiếp, thì mỗi lần kích hoạt nó sẽ nạp khung hình tiếp theo
  • Nếu chỉ thay trực tiếp, structure block mới sẽ ngay lập tức phát hiện tín hiệu redstone xung quanh và kích hoạt đệ quy
    • Đệ quy này tiếp diễn cho tới khi chạm hard limit của Minecraft
    • Việc xử lý ngắt nguồn của redstone dust cũng chưa kịp xong, để lại trạng thái cấp điện bất thường
  • Tác giả chèn độ trễ 1 redstone tick bằng repeater để chặn kích hoạt đệ quy
    • Các cấu trúc phải được tạo trong trạng thái /tick freeze để lưu lại khi repeater đang tắt
    • Sau khi nạp, nó chuyển sang cấu trúc kế tiếp sau một redstone tick

Xử lý tick để đạt 20fps

  • Minecraft có game tick và redstone tick
    • Engine game tính lại vật lý ở 20Hz
    • Các thành phần redstone thường lên lịch cập nhật theo bước 0,1 giây, tức 10Hz
  • Sự kiện thực tế được xử lý theo khoảng 0,05 giây, và tùy thời điểm nhập của người dùng mà phản ứng redstone cũng có thể bị lệch theo pha đó
  • Để tạo 20fps, tác giả dùng bốn cấu trúc
    • Cấu trúc đỏ và vàng tạo thành một xung nhịp 10Hz
    • Cấu trúc xanh dương và xanh lá tạo thành một xung nhịp 10Hz khác
    • Khi khởi động hai xung nhịp ở các pha khác nhau, bốn màu này sẽ thay nhau xuất hiện ở cùng vị trí với tần số 20Hz
  • Để khởi động ổn định hai xung nhịp có lệch pha, tác giả tận dụng một bug cũ: khi piston đẩy redstone block thì nếu kích hoạt trực tiếp bằng thao tác người dùng sẽ mất 3 game tick

Kỹ thuật resource pack để giảm số chunk

  • Nếu dùng một block cho mỗi pixel thì màn hình 512×384 sẽ chiếm 24 chunk theo chiều dọc và 32 chunk theo chiều ngang
    • Tổng cộng 768 chunk phải liên tục cập nhật ở 20Hz
    • Điều này cũng đụng trần khoảng nhìn 32 chunk tối đa của vanilla nên không thực tế
  • Tác giả thay texture của nhiều block bằng texture tùy biến trong resource pack để nhét nhiều subpixel vào trong một block
    • 16 biến thể block tương ứng với 4 bit
    • Dùng 256 block cùng thêm các màu phụ thì có thể biểu diễn thang độ xám thay vì chỉ đen trắng
  • Bằng cách này, độ phân giải theo block giảm đi 4 lần, còn 256×192 block
    • Số chunk phải cập nhật cho màn hình giảm xuống còn 192
    • Nhưng với cập nhật 20Hz thì đây vẫn là gánh nặng lớn

Hàng đợi render và mã hóa delta

  • Engine render của Minecraft ưu tiên xử lý cập nhật chunk quanh người chơi
    • Nhiều luồng sẽ dựng chunk đồng thời và lấy từ hàng đợi cập nhật theo thứ tự chunk gần người chơi trước
    • Nếu N chunk gần nhất cứ liên tục cập nhật ở 20Hz thì chỉ các chunk đó được xử lý, phần còn lại có thể không được render
  • Dùng Spark, tác giả xác nhận nút thắt cổ chai là cập nhật tổng quát chứ không phải redstone hay ánh sáng
    • Cụ thể, setBlock và các event handler là vấn đề chính
  • Cách giải quyết là giảm số lượng cập nhật, bằng cách áp dụng mã hóa delta chỉ cập nhật các block thay đổi giữa hai khung hình
    • Phần lớn khung hình không thay đổi quá nhiều nên về lý thuyết còn nhiều dư địa cải thiện hiệu năng
  • Structure block chỉ có thể nạp tối đa 48×48×48 block mỗi lần, nên màn hình được chia thành 6×4 màn hình con 48×48
    • Dùng ffmpeg để trích xuất từng frame
    • Dùng Python Pillow để đọc ảnh
    • Tệp NBT được tạo bằng nbtlib
  • Prototype ban đầu mất khoảng 7 phút cho mỗi lần chạy, cần /tick freeze, 24 nút bấm và /tick unfreeze, nhưng ít nhất là đã hoạt động
    • Chỉ riêng mã hóa delta vẫn chưa đủ nhanh

Tối ưu model và blockstate

  • Model trong Minecraft định nghĩa hình khối block bằng cuboid, và tọa độ có thể vượt khỏi phạm vi (0,0,0) đến (16,16,16) để chỉ định trong khoảng -16 đến 32
    • Nếu thiết lập phù hợp, một block có thể được render như thể lớn gấp 3 lần, thay thế được vùng 9 block
    • Không đủ số block để xử lý mọi tổ hợp, nên cách này chỉ hiệu quả với các trường hợp phổ biến như vùng 6×6 toàn màu đen
  • Trong khoảng 600 block có thể dùng được, 256 block dành cho biểu diễn subpixel cơ bản, phần còn lại được dùng cho tối ưu hóa
  • Cách tiếp cận cuối cùng là chia màn hình thành các ô block 2×2, rồi chọn các sprite 4×4 pixel của từng ô làm ứng viên để thay bằng một block duy nhất
    • Tính chênh lệch giữa hai frame liên tiếp
    • Cộng điểm cho phiên bản trước và sau của các ô đã thay đổi
    • Cảnh thay đổi nhanh sẽ cho điểm cao hơn với các ô có nhiều pixel đổi hơn
    • Gán block khả dụng cho các sprite có điểm cao trước
  • Để vượt qua giới hạn số block cơ bản, tác giả khai thác blockstates
    • Như oak_log, có thể chọn model khác nhau tùy thuộc thuộc tính
    • Như grindstone, có thể dùng tổ hợp nhiều thuộc tính làm khóa
  • Sau khi trích xuất các biến thể blockstate từ asset gốc, lọc bỏ các thuộc tính không thể điều khiển, số model có thể truy cập tăng từ khoảng 600 lên 1700
    • Số mức màu tăng lên 6
    • Số block tối ưu hóa tăng lên 400

Âm thanh và thiết bị khởi động

  • Âm nhạc được xử lý bằng cách thay âm thanh của music disc trong resource pack
    • Thời lượng phát của disc là cố định dù có thay âm thanh
    • Tác giả dùng disc Relic vì thời lượng gần nhất với “Bad Apple!!”
    • Sửa assets/minecraft/lang/en_us.json để phụ đề trong game hiện thành “Now Playing: Bad Apple!!”
  • Tác giả nối button, dropper, hopper và jukebox để chỉ với một lần bấm, disc sẽ được đưa vào jukebox và phát
    • Khi phát xong, hopper đưa disc trở lại dropper để chuẩn bị cho lần phát sau
  • Do quasiconnectivity, tín hiệu redstone từ jukebox khi đang phát làm rối trạng thái của hopper và dropper
    • Tác giả khiến redstone dust cập nhật dropper tại thời điểm bấm nút
    • Rồi một redstone tick sau, repeater sẽ kích hoạt lại dropper để chèn disc vào
  • Để gửi tín hiệu từ vị trí xem tới thiết bị phía sau màn hình, tác giả tạo instant wire dựa trên structure block
    • Structure block sẽ nạp một redstone torch đang cấp điện vào đoạn kế tiếp, rồi ở tick sau bị tắt do redstone block
    • Xung này kích hoạt structure block kế tiếp để truyền tín hiệu
    • Vì structure block bao được tối đa 48 block, nó có thể gửi tín hiệu khởi động tới lưới màn hình con 48×48
  • Quãng khoảng 150 block từ vị trí người xem tới mặt sau màn hình được nối bằng một cấu trúc riêng có thể reset
    • Tín hiệu được truyền bằng cách tạo rồi xóa liên tiếp các tổ hợp structure block và redstone block
    • Cấu trúc này khó lưu trực tiếp trong creative, nên tác giả tạo tệp structure bằng thư viện Python
  • Cơ chế cuối cùng được gói vào một hộp 4×2×3 vận hành bằng nút bấm bên ngoài

Tiền xử lý khung hình và chất lượng video

  • Các bài toán tiền xử lý còn lại là giảm video full-color xuống 6 màu và chuyển video 30fps thành 20fps
  • Bad Apple!! không chỉ có đen trắng thuần mà còn dùng thang xám ở nhiều cảnh
    • Motion blur
    • Vật thể có độ sáng khác nhau
    • Gradient ở các chuyển cảnh
    • Các biểu hiện như lửa, mặt trời, bóng đổ, gợn nước
  • Nếu chỉ làm tròn về màu gần nhất thì sẽ xuất hiện banding
    • Dithering giúp giảm hiện tượng này bằng cách biến màu trung gian không thể biểu diễn thành mẫu của các màu khả dụng lân cận
  • Dithering toàn cục chất lượng cao có thể cho kết quả thay đổi mạnh giữa các khung hình
    • Mắt người rất dễ nhận ra sự thiếu nhất quán
    • Đồng thời còn tạo ra quá nhiều cập nhật khiến Minecraft không chịu nổi
  • Dithering cục bộ như Bayer dithering thì ổn định hơn nhưng chất lượng thấp, và ordered dithering dựa trên blue-noise trở thành lời giải trung gian
  • Video gốc là dữ liệu nén mất dữ liệu lấy từ bản đăng trên Niconico, nên có nhiễu
    • Nhiễu ở các vùng đen và trắng càng dễ thấy hơn sau khi dithering
    • Tác giả hiệu chỉnh bằng cách làm tròn vùng gần đen thành đen, gần trắng thành trắng, còn màu trung gian thì phân bố sao cho giữ được tính liên tục
  • Bài toán giảm từ 30fps xuống 20fps vẫn chưa được giải quyết trọn vẹn
    • Nếu bỏ mỗi frame thứ ba thì khoảng chuyển động giữa các frame lẻ và chẵn sẽ khác nhau, nhìn khá khó chịu
    • Lượng cập nhật cũng biến thiên theo kiểu răng cưa
    • Các video Bad Apple!! 60fps trên mạng thường được upscale bằng AI hoặc công cụ tự động nên có nhiều artifact ở các cảnh chuyển động nhanh

Kết quả và phần việc tiếp theo

  • Dự án bắt đầu từ độ phân giải 48×36 và 2 màu, rồi đi qua 128×96 và 10 màu, 256×192, và cuối cùng đạt 512×384 với 6 mức xám
  • Tác giả cũng từng thử phát nhạc bằng note block, nhưng để đạt chất lượng tốt thì sẽ thành một dự án riêng nên đã bỏ
  • Tác giả tạo ra kỹ thuật structstone dùng structure block như redstone, và còn bắt đầu một prototype máy tính dựa trên kỹ thuật này
  • Trong quá trình phát triển đã sử dụng ffmpeg, mpv, image crate của Rust, mã decompile của Minecraft, và các kỹ thuật giảm dung lượng thư mục world
  • Toàn bộ công việc kéo dài hơn một tháng, và là trải nghiệm giải bài toán theo cách rất khác với các dự án thông thường cùng bạn bè

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-12
Các ý kiến trên Hacker News

  • Tôi đã học được về đồ họa máy tính nhiều hơn hẳn so với dự đoán, xin gửi lời khen tới tác giả bài viết
    Một chỉnh sửa nhỏ: bức hình mà tác giả gọi là “The sun” thực ra là cảnh Eirin [0] nhìn lên mặt trăng. Trong cảnh đó [1], Eirin vươn tay về phía mặt trăng nơi mình bị lưu đày, nhưng rồi do dự và rút tay lại; ở cảnh tiếp theo, Kaguya [2] cũng vươn tay về phía mặt trăng nhưng không do dự. Theo Touhou Wiki, kế hoạch đánh cắp mặt trăng là của Eirin, nên tôi cũng không rõ biểu tượng này chính xác mang ý nghĩa gì
    [0] https://en.touhouwiki.net/wiki/Eirin_Yagokoro
    [1] https://youtu.be/FtutLA63Cp8?t=99
    [2] https://en.touhouwiki.net/wiki/Kaguya_Houraisan

    • Cứ nhìn cảnh đó là tôi lại nghĩ đến “the sun”, vì video buồn cười này: https://www.youtube.com/watch?v=ReblZ7o7lu4
    • Có vẻ bạn đọc nhầm rồi. Trên wiki nói kế hoạch là seal con đường giữa Trái Đất, hay Gensokyo, và mặt trăng, chứ không phải “steal”
      Eirin đã cố ý chọn cắt đứt liên kết với mặt trăng để bảo vệ Kaguya

  • Tôi không thật sự hiểu vì sao Bad Apple đang dần trở thành Hello World trên thực tế của việc render đồ họa, nhưng xem theo thời gian thực thì rất thú vị
    Tôi cũng đã thấy demo này, dùng Bad Apple để trình diễn hypermedia tốc độ khung hình cao: https://data-star.dev/examples/bad_apple

    • Có hai lý do. Thứ nhất, tác giả gốc rất thoáng với remix và việc fan sử dụng
      Theo nhiều cách, Touhou gần với nguyên mẫu của fandom internet hiện đại hơn so với các fandom trước đó, và video Bad Apple sẽ không bị gỡ dù dùng cùng phần âm thanh
      Thứ hai, hình thức kịch bóng rất dễ nhận ra dù độ phân giải thấp đến đâu. Tôi từng thấy cả ví dụ lưới 3x3. Hơn nữa, vì chỉ có đen trắng, tức hai màu 1/0, nên chỉ cần biết ở mức “Hello World” là đã rất dễ chuyển các khung hình sang gần như bất kỳ định dạng nào có thể tưởng tượng được
    • Chuẩn DOOM đã đi xa tới mức này: https://www.reddit.com/r/Doom/comments/1c0g0mi/i_made_doom_i...
      Nó chạy trên một CPU hoàn toàn lập trình được làm bằng Redstone. Cấu hình IRIS Computer gồm CPU 16-bit tùy chỉnh, RAM 8 kB, ROM 64 kB, texture ROM 1 kB, màn hình 96x64 pixel 16 màu, đơn vị dấu phẩy động (add/sub/mult/div/sqrt), xung nhịp 173 tick Redstone, không có tăng tốc phần cứng đồ họa 3D, chạy chương trình viết bằng URCL, và nhờ máy chủ MCHPRS nên chạy ở 1 triệu tick mỗi giây, tương đương tốc độ xung nhịp 5,8 kHz
    • Một trong những đặc điểm ít được nhắc tới của các bản nhạc Touhou, gồm cả bản gốc Bad Apple!![1], là ít nhất với tôi, chúng nghe giống hiển thị trạng thái bus dữ liệu hơn là âm nhạc
      Thay vì là nhạc có nhịp và ô nhịp đều đặn, sẽ hợp lý hơn nhiều nếu tưởng tượng đang nghe các bit chẵn của bus 16-bit được nối vào nhạc cụ trong lúc MS-DOS khởi động. Đây là các bản nhạc do nhà phát triển game Touhou tự sáng tác khi một mình làm game bắn súng hardcore cho PC-88/PC-98 mà không được đào tạo chính quy về lý thuyết âm nhạc, nên có vẻ đó là kết quả tự nhiên; vì vậy chúng có thể tạo cảm giác quen thuộc với kỹ sư phần cứng nhúng hơn là âm nhạc thông thường
      Một yếu tố khác là cộng đồng nicovideo.jp / nico-tech, phát triển từ văn hóa 2ch/futaba. Những người dùng có chuyên môn vượt xa mức được trả công hay tham vọng tiền bạc — thời đó cũng có nhiều sinh viên STEM — đã dồn kỹ thuật vào các bản remix chỉ cho vui. Những phù thủy FPGA không rõ lai lịch, chuyên gia driver động cơ, biên tập viên video đột nhiên xuất hiện, ném ra các video gây ảo giác rồi biến mất; thật sự quá phi lý. Maker Faire Tokyo từng có lần, để giữ thể diện cho các web developer mặc áo phông, đã đưa những người bị nghi là mặc sơ mi kiểu nico-tech vào một khu cách ly ở hội trường riêng. Việc đó khá trớ trêu, dẫn tới sự ra đời của các buổi gặp mặt nico-tech, và không lặp lại nữa. Mật độ dày đặc về cả chất lượng lẫn số lượng của những nội dung phi lý như vậy đã tạo nên quán tính cho PV Bad Apple!!
      Yếu tố then chốt cuối cùng là PV này là đơn sắc, nói chính xác là thang xám. Có lẽ vì thế mà video này, chứ không phải một video khác từ thời hoàng kim của nicovideo.jp, đã trở thành lựa chọn
      1: https://www.youtube.com/watch?v=Yw5HTeT_dis
    • Việc video hoàn toàn đơn sắc nhưng lại rất mượt và tinh xảo tạo ra một tính hai mặt thú vị khi áp dụng vào các bài toán kỹ thuật
      Bản thân nó đã là một tác phẩm nghệ thuật đẹp và ấn tượng, nên tôi nghĩ nó có nhiều đặc tính mà đặc biệt là giới demoscene sẽ thích
    • Cũng có các lựa chọn khác. Một tác phẩm ban đầu trong Factorio điều khiển đèn bằng mạch: https://youtu.be/Kry8lbrHjeY và phần triển khai âm thanh: https://youtu.be/b_FumvuFRXA
      Cũng có một clip video khác có màu: https://youtu.be/mgfwwqwxdxY

  • “Bad Apple trên mọi thứ!” là một trong những trào lưu kỳ quặc mà tôi thích
    Lần đầu thấy nó trên Genesis/Mega Drive, tôi đã rất ngạc nhiên khi biết phần cứng yếu như vậy cũng làm được. Tôi thích xem người ta tạo các bản port mới cho những thứ thiếu hiệu năng. Tôi không giỏi lập trình cấp thấp nên chắc không đủ thông minh để tự làm, nhưng tôi thật sự nể những người làm được

  • Phần “đệ quy này kết thúc khi Minecraft chạm tới giới hạn cứng, và may mắn là thay vì khối đỏ thì khối vàng được tạo ra” làm tôi nhớ đến glitch ức chế cập nhật trước đây (https://mcdf.wiki.gg/wiki/Java_Edition:Update_Suppression)
    Population suppression khó hơn (https://mcdf.wiki.gg/wiki/Java_Edition:Population_Suppressio...) cũng có thể tương tự để lại game engine ở trạng thái glitch, khiến khối rơi ngay lập tức

  • Thuật toán dithering tôi thích nhất cho video là Yliluoma dithering: https://bisqwit.iki.fi/story/howto/dither/jy/
    Nó đặc biệt hữu ích với nội dung grayscale, vì việc tìm ma trận dithering tối ưu từ palette khả dụng chỉ là một phép tính chính xác đơn giản, và kết quả có thể đưa vào bảng tra cứu để dùng cho render thời gian thực. Cá nhân tôi thấy nó trông đẹp hơn hẳn Bayer hay dithering ngẫu nhiên, nhất là ở các gradient

  • Kiểu nói “Redstone dust gần như là thành phần duy nhất không tạo tick delay nhưng lại rất chậm. Có vẻ ở Mojang không có ai biết graph algorithm” là quá lời
    Kể từ bài mà bài gốc liên kết làm nguồn thông tin, nó đã bớt chậm hơn rất nhiều, và trong 3 năm qua đã có nhiều cải tiến, gồm cả một cải tiến gần đây. Mojang bị chửi từ khắp nơi rất nhiều. Lý do việc làm Redstone bớt chậm mất nhiều thời gian là vì chỉ cần đụng nhẹ vào Redstone thì cộng đồng la ó, và nếu làm những việc không phải thêm tính năng mới thì cộng đồng cũng la ó, nên chuyện đó trở nên ít đáng làm. Nổi giận trên Internet rồi nói họ không biết graph algorithm chẳng giúp ích gì. Mojang đã nhiều lần tuyển những nhân tài rất giỏi trong cộng đồng Minecraft như Panda4994, Kingbdogz, Gnembon, và họ có chuyên môn kỹ thuật để làm những gì họ muốn. Thứ họ không có là thời gian và ngân sách vô hạn. Việc vừa duy trì vừa đồng bộ một codebase Java 15 năm tuổi cùng một ứng dụng C++ đa nền tảng khổng lồ thật sự rất khó, nên mong mọi người rộng lượng hơn một chút. Tôi đã mệt vì cả ngày phải thấy thù ghét đổ tới từ mọi phía, và chỉ muốn có thể nói rằng Minecraft thật tuyệt

    • Những câu kiểu này khá thường thấy trên các blog lập trình
      Trước đây tôi thấy khó chịu hơn, nhưng về sau nhận ra đó không hẳn là tự cao, mà gần với sự ngây thơ của nhóm 16~21 tuổi còn ít kinh nghiệm “chuyên nghiệp” hơn
    • Tại sao phải vậy? Họ có đủ sức viết lại engine bằng Rust và biến nó thành bất cứ thứ gì họ muốn
      Có vẻ họ cũng chẳng bận tâm đến khả năng tương thích giữa các phiên bản

  • Từ sau cấp ba tôi không còn mê Minecraft đến mức làm các thiết bị Redstone nghiêm túc nữa
    Giờ tôi chỉ chơi với bạn vài lần mỗi tháng khi đột nhiên có lại ham muốn xây gì đó và khám phá. Nhìn vào hệ sinh thái Redstone hiện nay thì nó đã khác hoàn toàn đến mức không nhận ra, và tôi tự hỏi liệu khi dần trở thành một senior software engineer, mình có cảm giác tương tự không. Có lẽ qua năm tháng, khi nhìn vào những stack mình không đụng tới trong công việc vài năm, tôi sẽ kinh ngạc trước tốc độ công nghệ thay đổi và những thứ mới mà mọi người xây dựng trên đó

  • Tôi không đồng ý với phản ứng kiểu “Và… hết rồi à? Nhìn lại thì kết quả trông gần như tầm thường, dễ đạt được, khiến người ta tự hỏi tại sao trước đây chưa ai làm”
    Đây là một bản ghi chép phát triển tuyệt vời, đồng thời là một bài học nhỏ về cách chia một việc trông áp đảo thành những mảnh gần như bất khả thi nhưng vẫn khả thi. Thật sự rất hay. Nhân tiện, implementation này render Bad Apple ở 20fps trong Minecraft vanilla chỉ với một custom texture và vài định nghĩa custom object được sửa để cho phép nhiều texture hơn. Phần còn lại thì rất kỳ lạ nhưng vẫn là vanilla

    • Điều ấn tượng nhất là bề rộng kiến thức thể hiện qua các giải pháp bị loại

  • Việc họ bỏ nhiều công sức như vậy cho chính video thực tế cũng khá thú vị
    Thường thì sau khi hoàn thành một implementation Bad Apple, tôi đã quá kiệt sức để nghĩ đến dithering hay frame rate, chỉ chạy qua ffmpeg rồi coi như xong

  • Bad Apple được làm bằng Minecraft world cũng đáng xem: https://www.youtube.com/watch?v=RN3QW9SVnds