1 điểm bởi GN⁺ 23 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Minecraft 26.3 Snapshot 4 thay thế backend quản lý cửa sổ, nhập liệu và tích hợp nền tảng từ GLFW sang SDL3, đồng thời đưa SDL scancode và keycode vào xử lý nhập liệu bàn phím
  • Key binding sử dụng vị trí phím vật lý thay vì mã theo từng bố cục bàn phím; trên Linux ưu tiên Wayland khi có thể, còn trên macOS hỗ trợ cửa sổ gợi ý nhập liệu native
  • Thêm data component cho nhiên liệu lò nung và pha chế tùy chỉnh, cho phép thiết lập thời gian cháy, số lần sử dụng, tốc độ nấu và pha chế bằng number provider
  • Data pack 111.0 và resource pack 92.0 thay đổi lớn về sự kiện nhấp biển hiệu, tham chiếu loot table, trigger advancement, thuộc tính môi trường sinh mob, thiết lập tạo địa hình và shader
  • Đã biết lỗi crash ở chế độ toàn màn hình độc quyền trên Windows đa màn hình và Wayland; bản thử nghiệm có thể làm hỏng world nên cần sao lưu hoặc chạy trong thư mục riêng

Hệ thống cửa sổ và nhập liệu dựa trên SDL3

  • Chuyển thư viện quản lý cửa sổ, nhập liệu và tích hợp nền tảng từ GLFW sang SDL3
    • Nhập liệu bàn phím dùng SDL scancode cho vị trí phím vật lý
    • Các phím tắt chỉnh sửa văn bản thay đổi theo bố cục bàn phím dùng SDL keycode
  • Key binding hoạt động dựa trên phím vật lý, không dựa trên mã phím theo từng bố cục bàn phím
  • Loại bỏ thiết lập chuột Raw Input, và luôn dùng chế độ chuột tương đối trong khi chơi
  • Toàn màn hình không viền trở thành chế độ toàn màn hình mặc định; có thể chuyển giữa chế độ không viền và độc quyền mà không cần khởi động lại
    • macOS không còn hỗ trợ toàn màn hình độc quyền
    • Kích thước cửa sổ tối thiểu là 320×240 pixel
  • Trên Linux, ưu tiên dùng Wayland native khi có thể
  • Trên macOS, khi giữ phím trong lúc nhập văn bản, popup native cho dấu nhấn và ứng viên nhập liệu sẽ hiển thị

Các vấn đề toàn màn hình đã biết

  • Toàn màn hình độc quyền trên Windows có thể khiến game crash trong một số tình huống, đặc biệt ở môi trường đa màn hình
  • Trên Wayland, game sẽ crash khi vào toàn màn hình độc quyền

Thay đổi về gameplay và giao diện

  • Người chơi ở chế độ Spectator có thể tương tác với portal để dịch chuyển
  • Armadillo sẽ không cố cuộn mình khi bị ngập trong chất lỏng
  • Có thể áp dụng tỷ lệ GUI riêng cho debug overlay
    • Thiết lập trong Debug Options của F3 + F6
    • Giá trị mặc định Auto giữ độ phân giải cao hơn GUI thông thường, còn Unchanged khớp với tỷ lệ GUI thông thường
    • Thêm player_speed hiển thị tốc độ di chuyển theo block mỗi tick của người chơi và hiển thị tần số quét màn hình
  • Sắp xếp lại thứ tự khoáng vật trong Creative Inventory theo vật liệu không theo tier, vật liệu tier thô, rồi vật liệu tier đã tinh chế
    • Building Blocks theo thứ tự khoáng vật không theo tier, khoáng vật tier đã tinh chế, rồi nhóm Copper; các block Copper có nhiều mục được đặt về phía sau
    • Tab Natural Blocks được sắp xếp theo thứ tự Overworld → Nether → End

Nhiên liệu tùy chỉnh và item component

  • minecraft:cooking_fuel định nghĩa nhiên liệu cho Furnace, Smoker và Blast Furnace
    • burn_time chỉ số tick cháy, speed_multiplier chỉ tốc độ nấu/luyện, mỗi trường được chỉ định bằng minecraft:number_provider
  • minecraft:brewing_fuel định nghĩa số lần sử dụng và tốc độ pha chế của nhiên liệu Brewing Stand
    • Item tag #brewing_fuel hiện có bị loại bỏ, không thể dùng để đăng ký nhiên liệu pha chế mới
  • Công thức của Smoker và Blast Furnace dùng cùng thời gian nấu như Furnace; phần tăng tốc do minecraft:cooking/speed_default trong fuel component đảm nhiệm
  • Các trường thời gian nấu và nhiên liệu của Furnace, Smoker, Blast Furnace đổi từ short sang integer và thêm speed_multiplier
  • BrewTimeFuel của Brewing Stand cũng đổi sang integer, đồng thời thêm total_brew_time, total_fuel, speed_multiplier
  • Các data component được thêm gồm:
    • minecraft:sign_text_front, minecraft:sign_text_back: lưu văn bản mặt trước/sau của biển hiệu và hiển thị trong tooltip của item
    • minecraft:waxed: marker không có trường, cho biết nội dung đã được phủ sáp
    • minecraft:cushion/color: áp dụng 16 màu thuốc nhuộm cho Cushion đã đặt
    • minecraft:villager_food: định nghĩa item mà dân làng có thể ăn và giá trị dinh dưỡng
    • minecraft:mob_visibility: chỉ định tỷ lệ ảnh hưởng của trang bị lên khoảng cách phát hiện của mob trong phạm vi 0.0~10.0; dù cộng dồn, giá trị tầm nhìn tối đa không vượt quá 10.0

Biển hiệu và tương thích data pack

  • Phiên bản data pack tăng lên 111.0
  • Lệnh và sự kiện nhấp trong văn bản tùy chỉnh của biển hiệu mặc định sẽ không chạy khi nhấp block, và text component của biển hiệu mới cũng không được diễn giải tự động
    • Trường mới allow_op_features có giá trị mặc định là false; để khôi phục hành vi cũ, phải đặt rõ thành true
    • Biển hiệu được lưu từ phiên bản trước và minecraft:block_entity_data chứa dữ liệu biển hiệu sẽ được áp dụng allow_op_features=true
  • Màn hình chỉnh sửa biển hiệu sau khi đặt chỉ hiển thị khi có thể mở màn hình chỉnh sửa bằng nhấp thông thường, chẳng hạn khi biển hiệu chưa phủ sáp và văn bản mặt trước có thể chỉnh sửa
  • Biển hiệu trao đổi các component minecraft:sign_text_front, minecraft:sign_text_back, minecraft:waxed
  • Block an toàn mà /spreadplayers có thể đặt người chơi lên được điều khiển bằng block tag #entities_can_teleport_to

Tham chiếu registry và thay đổi loot/advancement

  • Các loại loot table có registry riêng hỗ trợ tham chiếu phần tử registry và tag
    • Trường phần tử đơn có thể nhận namespaced ID hoặc giá trị inline
    • Trường danh sách có thể nhận giá trị inline, một hoặc nhiều namespaced ID, danh sách giá trị inline, hoặc ID tag #
    • Đối tượng áp dụng là advancement, item modifier, loot table, number provider, predicate, recipe, slot source
  • Các kiểu reference hiện có của predicate, item modifier, slot source trở nên không cần thiết và bị loại bỏ
  • Nhiều trường của trigger advancement có thể nhận namespaced predicate ID cũng như predicate inline
    • Hành vi minecraft:all_of ngầm định của danh sách điều kiện cũ bị loại bỏ, nên bắt buộc phải chỉ định type
    • Nhiều trường block, recipe_id, loot_table được đổi sang dạng số nhiều tương ứng và hỗ trợ ID đơn, danh sách hoặc tag
  • conditions của Loot Pool Entry được đổi tên thành condition, functions thành modifier
  • conditions của Loot Function được đổi thành condition, còn function từng biểu thị kiểu function được đổi thành type
    • Không còn nhận danh sách điều kiện inline; để có cùng hành vi phải chỉ rõ minecraft:all_of
  • Trường kiểu condition của Predicate được đổi thành type, và minecraft:reference cùng minecraft:block_state_property bị loại bỏ
    • minecraft:match_block mới kiểm tra đồng thời ID/tag block, state, NBT, component và component predicate
  • Number provider inline luôn phải chỉ rõ type, không còn dùng minecraft:uniform làm mặc định
  • Thêm nhiều Vanilla number provider cung cấp thời gian cháy theo từng nhiên liệu nấu, tốc độ nấu/pha chế mặc định và số lần pha chế

Sinh mob và tạo world

  • Thuộc tính môi trường mới minecraft:gameplay/natural_mob_spawns định nghĩa sinh mob theo trọng số từng category và spawn cost theo từng entity
    • Trong quá trình đặt world generation, chỉ Dimension và Biome áp dụng thuộc tính này
    • Modifier overlay ưu tiên áp dụng thiết lập category của lớp trên và spawn cost của cùng entity
  • minecraft:gameplay/creature_world_gen_spawn_probability chỉ định xác suất lặp sinh mob category creature trong quá trình tạo world ở mức từ 0 đến dưới 1, mặc định là 0.1
  • spawners, spawn_costs, creature_spawn_probability của Biome bị loại bỏ và chuyển sang thuộc tính môi trường mới
  • Thuộc tính môi trường hạt xung quanh nội suy xác suất giữa các keyframe timeline, và hỗ trợ modifier append để nối thêm mục vào danh sách hạt của lớp dưới
  • Trong Noise Settings, thiết lập aquifer và ore vein được tái cấu trúc lần lượt thành object aquifers tùy chọn và danh sách ore_veins
    • Nếu không có thiết lập, aquifer hoặc ore vein tương ứng sẽ không được tạo
    • Các trường density function liên quan được chuyển từ noise_router sang cấu trúc mới
  • Density Function thêm sub, div, negate, lerp, floor, round, ceil, truncate, beardifier
    • Nhiều tên đối số hiện có được đổi thành value, left, right, input, noise
    • invert được đổi tên thành reciprocal
    • final_density không còn tự động cộng thêm beardifier ngầm định

Đồ họa và các lỗi chính được sửa

  • Phiên bản resource pack tăng lên 92.0
  • Thêm shader hỗ trợ order-independent transparency và định nghĩa OIT_ALWAYS_WRITE_DEPTH
  • core/integrate_depth.fsh tích hợp depth buffer của HUD 3D và gizmo luôn hiển thị trên cùng vào depth buffer chính
  • Các vấn đề chính đã sửa gồm:
    • Vấn đề key binding và nhập liệu liên quan đến bàn phím không phải QWERTY, macOS và nhập liệu CJK
    • Crash khi render bản đồ trong Improved Transparency, vấn đề hiển thị kính, đối tượng bán trong suốt, particle và world border
    • Crash do projectile ngoài chiều cao world và đặt tổ ong ở độ cao tối thiểu
    • Vấn đề lưu/tải heightmap khi tạo world và lệch đồng bộ vị trí mob sau tick sprint
    • Vấn đề đặt Cushion, màu sắc, tên tùy chỉnh, thời gian nhiên liệu và va chạm
    • Vấn đề sát thương/chuyến bay của Ender Dragon, Spectator dùng portal, phán định block an toàn của /spreadplayers

Lưu ý cài đặt và thử nghiệm

  • Snapshot dành cho Minecraft: Java Edition; cài bằng cách bật Snapshot trong tab Installations của Minecraft Launcher
  • Bản thử nghiệm có thể làm hỏng world, vì vậy cần sao lưu hoặc chạy trong thư mục khác với world chính
  • Cũng có Minecraft server jar cho đa nền tảng
  • Có thể gửi lỗi tại Minecraft issue tracker, và gửi ý kiến tại trang Feedback

1 bình luận

 
Ý kiến trên Hacker News
  • Phần triển khai LWJGL cho binding này do một thành viên nhóm modpack GTNH viết, qua đó hoàn tất lại vòng tuần hoàn vanilla→modded→vanilla https://github.com/LWJGL/lwjgl3/pull/1033

    • Nói hơi quá thì có thể xem GTNH đã đóng góp cho Minecraft còn nhiều hơn Microsoft. Tôi cũng có đóng góp chút ít nên không phải nói suông; mức độ tâm huyết và khối lượng công việc bỏ vào thực sự đáng kinh ngạc
    • Tôi cũng tò mò hiện có bao nhiêu nhà phát triển Minecraft trước đây từng là modder, hoặc đến giờ vẫn đang hoạt động như modder
  • Gần đây tôi đã chuyển game Tribal Trouble(https://github.com/bondolo/tribaltrouble) từ GLFW sang SDL3, và nhìn chung việc refactor khá suôn sẻ. Có vài vấn đề với chế độ toàn màn hình độc quyền và toàn màn hình desktop, nhưng cuối cùng cũng giải quyết được
    Tôi còn viết một bản demo để thử nghiệm và ghi lại cách xử lý các chế độ hiển thị rắc rối. Game này dùng Java như Minecraft, nhưng bản demo thì tôi dùng C để giữ cho nó đơn giản nhất có thể

    • Tribal Trouble à, đúng là cái tên lâu lắm rồi mới nghe lại. Tôi nhớ là các nhà phát triển từng nói họ chọn Java vì muốn làm game bằng một ngôn ngữ lạ hoặc ít phổ biến
    • Không biết GLFW có vấn đề gì, hay lý do nào khiến họ chọn chuyển sang SDL3
  • Toàn màn hình độc quyền trên Windows có vấn đề đã biết là có thể làm treo game, nhất là với thiết lập nhiều màn hình; còn trên Wayland thì chỉ cần vào chế độ đó là cũng có thể treo. Cả hai đều trông như lỗi chặn phát hành snapshot và tôi hy vọng chúng sẽ được sửa trước khi ra bản chính thức

    • Snapshot là việc phát hành nguyên trạng thái hiện tại của nhánh chính, kể cả các lỗi chặn
      Tôi nghĩ mức kỳ vọng về độ ổn định sẽ theo thứ tự: bản hỗ trợ dài hạn, bản chính thức, release candidate, beta, alpha, snapshot, commit vừa được merge, PR chưa merge, draft PR. Nếu là lỗi lớn thì nên hoãn release candidate hoặc beta, còn nếu là lỗi nghiêm trọng thì phải chặn ngay từ lúc merge; nhưng không có lý do gì để hoãn snapshot chỉ vì một lỗi đã qua CI và được merge
      Snapshot gần giống việc định kỳ cắt trạng thái hiện tại ra để phát hành, giúp người dùng có thể chạy và phản hồi mà không phải tự build từ main
    • Nếu là bản phát hành chính thức thì có thể hoãn, nhưng không có lý do để hoãn snapshot. Cứ phát hành ở trạng thái hiện tại để dùng telemetry xem các lỗi đã biết xảy ra thường xuyên đến mức nào, đồng thời phát hiện thêm các vấn đề chưa biết trước khi ra bản chính thức
      Snapshot chưa bao giờ hứa là không có lỗi; ngược lại mới là điều được mặc định
    • Minecraft có lẽ từ lâu đã dùng toàn màn hình không viền nếu người dùng không cấu hình riêng. Trong hơn 10 năm qua, nhiều nền tảng, dịch vụ và ứng dụng đã loại bỏ toàn màn hình độc quyền
    • Hiện nay render cửa sổ toàn màn hình phổ biến hơn toàn màn hình độc quyền. Trình quản lý cửa sổ thường cũng áp dụng cho cửa sổ toàn màn hình ở phía trước những tối ưu vốn trước đây chỉ có ở chế độ độc quyền
    • Vì đây là snapshot nên có thể có những vấn đề như vậy, và nhiều khả năng sẽ được sửa trong snapshot tiếp theo
  • Tôi tò mò nếu là một ông bố làm kỹ thuật nhưng hoàn toàn không biết gì về Minecraft, thì nên dựng server gia đình như thế nào vào năm 2026. Bọn trẻ hiện chơi trên iPad và đôi khi trên MacBook cũ hoặc PC Windows

    • Minecraft có hai bản là Java và Bedrock. Bản mobile, console và bản Windows Store dựa trên Bedrock, còn bản tải trực tiếp từ website là bản Java
      Bạn có thể chạy server Java tiêu chuẩn và dùng Geyser để chuyển đổi giao thức Bedrock theo thời gian thực. Với các client Bedrock bị giới hạn nặng có thể cần cách lách riêng, nhưng bạn vẫn có thể quản lý xoay quanh server Java, vốn có nhiều lựa chọn hơn
    • Các hướng dẫn tuning JVM cho Minecraft trên mạng thường đã cũ hoặc sai, nên tốt nhất là bỏ qua
      Chỉ cần dùng JVM mới, tăng bộ nhớ tối đa lên mức chấp nhận được rồi dùng ZGC là đủ. Có những hướng dẫn chỉnh đủ loại flag mà không có căn cứ, hoặc nhét chung các thiết lập xung đột nhau như kích thước Eden và thời gian pause mục tiêu
      ZGC có độ trễ rất thấp và heap càng lớn thì càng ít suy giảm hiệu năng, nhưng để giữ nén object header thì tốt hơn nên để dưới 32GB. JVM mới cũng cải thiện mức dùng bộ nhớ và hiệu năng tổng thể
    • Chỉ cần làm theo cách thiết lập server vanilla cho Java Edition. Bản Java chỉ chạy trên Windows·macOS·Linux, nhưng tôi thấy nó ít lỗi và tốt hơn Bedrock
      Nếu cần thêm hiệu năng thì cài fabriclithium là được. Các mod như Paper, Spigot, Purpur có thể phá hỏng các hệ thống tự động hóa nên tốt nhất là tránh
    • Minecraft trên điện thoại và máy tính bảng kín và bị giới hạn hơn bản Java, nên ít lựa chọn hơn
      Tôi đã dùng itzg/docker-minecraft-server ổn định suốt nhiều năm, và thích ở chỗ image xử lý hết mọi thứ nên không phải tự cài từng phụ thuộc. Cũng có image cho server Bedrock nhưng tôi chưa làm cho nó chạy ổn thỏa
      Cách vận hành dễ nhất là để tất cả cùng dùng bản Java trên Windows, Mac, Linux; nếu không thì có thể trả tiền cho server lưu trữ Realms
    • Xét đến việc bọn trẻ thích chơi trên iPad, cũng đáng xem qua Realms. Tôi nhớ là khoảng 7 đô thì có server cho 10 người, nhưng đăng ký Java và Bedrock tách riêng, các gói giá cũng bị phân mảnh thành nhiều mức
      Tùy mục đích của server gia đình mà có thể không phù hợp, nhưng nếu muốn bọn trẻ vào chơi cùng nhau nhanh và đơn giản thì đây là cách dễ nhất. Tôi cũng từng thấy những đứa trẻ bám Bedrock rất lâu rồi chuyển sang Java và tiếc vì đã không đổi sớm hơn
  • Icculus đã đăng một video rất hay về việc chuyển game từ SDL2 sang SDL3, còn video chuyển Doom ở đây: https://www.youtube.com/watch?v=ixdeGhsoxy8

    • Không ngờ Chocolate Doom cũng đang được chuyển sang SDL3 và chính Icculus trực tiếp làm việc đó. Trong các bản port Doom mà tôi biết thì Woof! đã chuyển rồi: https://github.com/fabiangreffrath/woof
  • Thật ấn tượng khi Minecraft ngày càng trở nên gần với một game engine riêng hơn là chỉ một trò chơi đơn thuần

  • Tôi tò mò không biết lý do rời bỏ GLFW có được ghi lại thành tài liệu hay không. Tôi có một dự án dùng GLFW nên luôn băn khoăn liệu SDL có phải lựa chọn tốt hơn không

    • Trong bản cập nhật này, hỗ trợ Wayland đã hoạt động mà không cần làm riêng gì thêm. Trước đây cần cách lách, và dù áp dụng rồi vẫn liên tục phát sinh vấn đề mới, nhưng đa số chỉ hài lòng với việc chạy bằng XWayland nên cũng không quá để tâm
      SDL3 có hỗ trợ Wayland rất vững ngay từ nền tảng. Trong Minecraft, GLFW chỉ được dùng cho tạo cửa sổ, biểu tượng trên taskbar, toàn màn hình và input, còn lại đều xử lý bằng OpenGL thuần nên việc chuyển đổi cũng dễ. Giờ còn hỗ trợ cả Vulkan nên có thể dùng một stack hoàn toàn hiện đại trên Linux desktop và Steam Deck
    • SDL hỗ trợ di động còn GLFW thì không, nên có thể họ muốn hợp nhất codebase theo từng nền tảng
      SDL3 hoạt động cả trên Android 4.2, và tôi cũng từng làm app bằng SDL3 với ImGui mà không cần Java
    • Một trong các lý do là hỗ trợ bộ gõ (IME)
    • SDL gần như giống một lớp nền tảng có thể dùng gần như ở mọi nơi. Nó cung cấp cửa sổ, đồ họa, âm thanh, input, mạng và thread, trong khi GLFW chỉ cung cấp cửa sổ, graphics context và input, nên phần còn lại phải tự chuẩn bị thư viện khác
      Điều đó có thể không tạo khác biệt lớn cho mọi dự án, nhưng SDL cung cấp nhiều tính năng hơn và tính di động cũng cao hơn
    • Có thể tạo một game 2D hoàn chỉnh chỉ bằng SDL API mà không cần OpenGL hay Vulkan
  • Game nhịp điệu osu! gần đây cũng đã chuyển từ SDL2 sang SDL3 và hiệu năng cùng độ trễ được cải thiện đáng kể. Việc áp dụng SDL3 có vẻ hơi chậm, và việc Minecraft dùng GLFW đến tận bây giờ cũng khá bất ngờ
    Đặc biệt, sau khi chuyển sang SDL3 thì hiện tượng giật lag từng xảy ra khi mở sẵn client Discord lúc chạy osu! đã biến mất; tôi nhớ là đã thấy nội dung đó trong video dev trên YouTube

    • Trên một số bản phân phối Linux, sdl2-compat và sdl12-compat là triển khai mặc định của SDL2·1.2, nên nhiều trường hợp thực ra đã gián tiếp dùng SDL3. Nhờ vậy nhiều app chạy native trên Wayland với độ trễ thấp hơn XWayland và hỗ trợ controller cũng tốt hơn
      Ubuntu 24.04 ban đầu không đi kèm SDL3, và SDL3 mới hơn tôi nghĩ nên có vẻ đây cũng là một lý do khiến tốc độ tiếp nhận chậm hơn kỳ vọng
    • osu! hỗ trợ cả 3 hệ điều hành desktop chính cùng iOS·Android, lại còn cố giữ native cho các tính năng như Wayland, nên mất khoảng 2 năm để chuyển sang SDL3. Có vẻ lần chuyển đổi này là lần đầu thực sự đi đến giai đoạn cuối cùng
    • Trong SDL3 có nhiều API đã thay đổi nên việc áp dụng khó hơn, nhất là khi đi qua thư viện binding thì gánh nặng càng lớn
  • SDL2 đã bộc lộ sự lỗi thời, đặc biệt ở phần trừu tượng hóa GPU API gồm cả Vulkan và Metal, nên việc chuyển sang SDL3 là hợp lý. Tôi cũng tò mò liệu vấn đề độ trễ input kéo dài trên Linux bản Java cùng lỗi Alt+Tab có được giải quyết nhờ thay đổi lớp cửa sổ·input hay không

    • Đối tượng thực tế được thay thế không phải SDL2 mà là GLFW, nên nếu chọn mới thì đương nhiên sẽ nghiêng về SDL3
  • Nếu muốn hỗ trợ mod thật mạnh thì có vẻ nên dùng ngôn ngữ dễ decompile và sửa đổi lúc runtime như Java hay C#, hoặc dùng JVM và .NET CLR
    Nếu vẫn phải tính đến modder trong lúc thay đổi nội bộ thì về cơ bản sẽ có được một modding API rất tốt mà gần như không tốn thêm chi phí

    • Với một game có cực nhiều mod, thứ thực sự cần chỉ là một lượng người dùng đủ lớn. Với các modder tận tâm thì chút binary patch hay DLL injection không phải trở ngại