1 คะแนน โดย GN⁺ 22 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Minecraft 26.3 Snapshot 4 เปลี่ยนแบ็กเอนด์สำหรับการจัดการหน้าต่าง อินพุต และการผสานกับแพลตฟอร์มจาก GLFW เป็น SDL3 และนำ SDL scancode กับ keycode มาใช้กับอินพุตคีย์บอร์ด
  • การกำหนดปุ่มจะอิงตาม ตำแหน่งจริงของปุ่มบนคีย์บอร์ด แทนรหัสตามผังแป้นพิมพ์, บน Linux จะให้ความสำคัญกับ Wayland หากใช้ได้ และบน macOS รองรับหน้าต่างตัวเลือกการป้อนข้อมูลแบบเนทีฟ
  • เพิ่ม data component สำหรับ เชื้อเพลิงเตาและการปรุงยาแบบกำหนดเอง ให้ตั้งเวลาการเผาไหม้ จำนวนครั้งการใช้งาน และความเร็วการปรุง/การปรุงยาได้ด้วย number provider
  • ใน data pack 111.0 และ resource pack 92.0 มีการเปลี่ยนแปลงครั้งใหญ่กับอีเวนต์คลิกป้าย การอ้างอิงตารางของรางวัล ทริกเกอร์ความก้าวหน้า คุณสมบัติแวดล้อมการเกิดม็อบ การตั้งค่าการสร้างภูมิประเทศ และเชดเดอร์
  • บน Windows แบบหลายจอและ Wayland มีปัญหา exclusive fullscreen ล่ม ที่ทราบอยู่ และเวอร์ชันทดสอบอาจทำให้โลกพังได้ จึงควรสำรองข้อมูลหรือรันในโฟลเดอร์แยกต่างหาก

ระบบหน้าต่างและอินพุตที่ใช้ SDL3

  • เปลี่ยนไลบรารีสำหรับจัดการหน้าต่าง อินพุต และการผสานกับแพลตฟอร์ม จาก GLFW เป็น SDL3
    • อินพุตคีย์บอร์ดใช้ SDL scancode ตามตำแหน่งจริงของปุ่ม
    • คีย์ลัดสำหรับแก้ไขข้อความที่เปลี่ยนไปตามผังแป้นพิมพ์จะใช้ SDL keycode
  • การกำหนดปุ่มจะทำงานโดยอิงจาก ปุ่มจริงบนคีย์บอร์ด ไม่ใช่ key code ตามผังแป้นพิมพ์
  • เอาการตั้งค่าเมาส์ Raw Input ออก และระหว่างเล่นเกมจะใช้โหมดเมาส์แบบสัมพัทธ์เสมอ
  • fullscreen แบบไร้ขอบกลายเป็นโหมด fullscreen เริ่มต้น และสามารถสลับระหว่างโหมดไร้ขอบกับโหมด exclusive ได้โดยไม่ต้องรีสตาร์ต
    • บน macOS จะไม่รองรับ exclusive fullscreen อีกต่อไป
    • ขนาดหน้าต่างต่ำสุดคือ 320×240 พิกเซล
  • บน Linux จะ เลือกใช้ Wayland แบบเนทีฟก่อน หากใช้งานได้
  • บน macOS เมื่อกดปุ่มค้างระหว่างป้อนข้อความ จะมีป๊อปอัปเครื่องหมายกำกับเสียง/ตัวเลือกแบบเนทีฟแสดงขึ้น

ปัญหา fullscreen ที่ทราบอยู่

  • exclusive fullscreen บน Windows อาจทำให้เกมล่มในบางสถานการณ์ โดยเฉพาะใน สภาพแวดล้อมหลายจอ
  • บน Wayland เกมจะล่มเมื่อเข้า exclusive fullscreen

การเล่นและการเปลี่ยนแปลงอินเทอร์เฟซ

  • ผู้เล่นโหมด spectator สามารถโต้ตอบกับพอร์ทัลเพื่อเทเลพอร์ตได้
  • Armadillo จะไม่พยายามขดตัวเมื่อจมอยู่ในของเหลว
  • สามารถใช้สเกล GUI แยกต่างหากกับ debug overlay ได้
    • ตั้งค่าได้ใน Debug Options ของ F3 + F6
    • ค่าเริ่มต้น Auto จะคงความละเอียดสูงกว่าของ GUI ปกติ และ Unchanged จะตรงกับสเกล GUI ปกติ
    • เพิ่ม player_speed ที่แสดงความเร็วการเคลื่อนที่เป็นบล็อกต่อติ๊กของผู้เล่น และการแสดงอัตรารีเฟรชของจอด้วย
  • จัดลำดับแร่ใน creative inventory ใหม่เป็น วัสดุไม่มี tier, วัสดุ tier แบบดิบ, วัสดุ tier แบบแปรรูป
    • บล็อกก่อสร้างจะเรียงเป็น แร่ไม่มี tier, แร่ tier แบบแปรรูป, กลุ่ม Copper และบล็อก Copper ที่มีรายการมากจะถูกวางไว้ด้านหลัง
    • แท็บ Natural Blocks ถูกจัดเป็นลำดับ Overworld → Nether → End

เชื้อเพลิงแบบกำหนดเองและ item component

  • minecraft:cooking_fuel ใช้นิยามเชื้อเพลิงสำหรับ Furnace, Smoker และ Blast Furnace
    • burn_time คือจำนวนติ๊กที่เผาไหม้ และ speed_multiplier คือความเร็วการปรุง/ถลุง โดยกำหนดเป็น minecraft:number_provider
  • minecraft:brewing_fuel ใช้นิยาม จำนวนครั้งการใช้งานและความเร็วการปรุงยา ของเชื้อเพลิงสำหรับ Brewing Stand
    • item tag เดิม #brewing_fuel ถูกลบออก จึงไม่สามารถใช้ลงทะเบียนเชื้อเพลิงการปรุงยาแบบใหม่ได้
  • สูตรของ Smoker และ Blast Furnace จะใช้เวลาปรุงเท่ากับ Furnace และการเร่งความเร็วจะให้ minecraft:cooking/speed_default ใน fuel component เป็นผู้กำหนด
  • ฟิลด์เวลาปรุงและเวลาเชื้อเพลิงของ Furnace, Smoker และ Blast Furnace เปลี่ยนจาก short เป็น integer และเพิ่ม speed_multiplier
  • BrewTime และ Fuel ของ Brewing Stand ก็เปลี่ยนเป็น integer เช่นกัน และเพิ่ม total_brew_time, total_fuel, speed_multiplier
  • data component ที่เพิ่มเข้ามามีดังนี้
    • minecraft:sign_text_front, minecraft:sign_text_back: เก็บข้อความด้านหน้า/ด้านหลังของป้าย และแสดงใน tooltip ของไอเท็ม
    • minecraft:waxed: มาร์กเกอร์แบบไม่มีฟิลด์ที่ระบุว่าเนื้อหาถูกเคลือบแว็กซ์แล้ว
    • minecraft:cushion/color: ใช้สีสีย้อม 16 แบบกับ Cushion ที่วางแล้ว
    • minecraft:villager_food: นิยามไอเท็มที่ชาวบ้านกินได้และค่าทางโภชนาการ
    • minecraft:mob_visibility: กำหนดอัตราส่วนผลของอุปกรณ์ต่อระยะตรวจจับของม็อบเป็น 0.0~10.0 และแม้จะซ้อนกัน ค่าการมองเห็นสูงสุดจะไม่เกิน 10.0

ป้ายและความเข้ากันได้ของ data pack

  • เวอร์ชัน data pack เพิ่มเป็น 111.0
  • คำสั่งและอีเวนต์คลิกในข้อความป้ายแบบกำหนดเอง จะไม่ถูกรันโดยอัตโนมัติเมื่อคลิกบล็อกอีกต่อไป และ text component ของป้ายใหม่ก็จะไม่ถูกตีความอัตโนมัติ
    • ฟิลด์ใหม่ allow_op_features มีค่าเริ่มต้นเป็น false และหากต้องการคืนพฤติกรรมเดิมต้องตั้งเป็น true อย่างชัดเจน
    • ป้ายที่บันทึกจากเวอร์ชันเก่า และ minecraft:block_entity_data ที่มีข้อมูลป้าย จะถูกใช้ allow_op_features=true
  • หน้าจอแก้ไขป้ายหลังจากวาง จะปรากฏเฉพาะเมื่อสามารถเปิดหน้าจอแก้ไขได้ด้วยการคลิกปกติ เช่น ยังไม่ถูกเคลือบแว็กซ์ และแก้ไขข้อความด้านหน้าได้
  • ป้ายจะรับส่ง component minecraft:sign_text_front, minecraft:sign_text_back, minecraft:waxed
  • บล็อกที่ปลอดภัยสำหรับ /spreadplayers ในการวางผู้เล่น จะถูกควบคุมด้วย block tag #entities_can_teleport_to

การอ้างอิงรีจิสทรี และการเปลี่ยนแปลงของของรางวัล/ความก้าวหน้า

  • ประเภท loot table ที่มีรีจิสทรีเฉพาะ รองรับ การอ้างอิง element และ tag ในรีจิสทรี
    • ฟิลด์ element เดี่ยวสามารถรับ namespaced ID หรือค่า inline ได้
    • ฟิลด์รายการสามารถรับค่า inline, namespaced ID เดี่ยว/หลายรายการ, รายการค่า inline หรือ tag ID แบบ #
    • เป้าหมายได้แก่ advancement, item modifier, loot table, number provider, predicate, recipe, slot source
  • ประเภท reference เดิมของ predicate, item modifier, slot source ไม่จำเป็นอีกต่อไปจึงถูกลบออก
  • หลายฟิลด์ของ advancement trigger สามารถรับทั้ง predicate แบบ inline และ namespaced predicate ID ได้
    • พฤติกรรม minecraft:all_of แบบโดยนัยของรายการเงื่อนไขเดิมถูกลบออก ดังนั้นต้องระบุ type เสมอ
    • หลายฟิลด์ของ block, recipe_id, loot_table เปลี่ยนเป็นรูปพหูพจน์ และรองรับ ID เดี่ยว รายการ หรือ tag
  • conditions ของ Loot Pool Entry เปลี่ยนชื่อเป็น condition และ functions เปลี่ยนชื่อเป็น modifier
  • conditions ของ Loot Function เปลี่ยนชื่อเป็น condition และ function ที่เคยใช้บอกประเภทฟังก์ชัน เปลี่ยนเป็น type
    • จะไม่รับรายการเงื่อนไขแบบ inline อีกต่อไป และหากต้องการพฤติกรรมเดิมต้องระบุ minecraft:all_of อย่างชัดเจน
  • ฟิลด์ประเภท condition ของ Predicate เปลี่ยนเป็น type และ minecraft:reference กับ minecraft:block_state_property ถูกลบออก
    • minecraft:match_block ใหม่จะตรวจทั้ง block ID/tag, state, NBT, component และ component predicate พร้อมกัน
  • number provider แบบ inline ต้องระบุ type เสมอ และจะไม่ใช้ minecraft:uniform เป็นค่าเริ่มต้นอีกต่อไป
  • เพิ่ม Vanilla number provider หลายตัวที่ให้ค่าเวลาการเผาไหม้ตามเชื้อเพลิงทำอาหาร ความเร็วเริ่มต้นของการปรุง/การปรุงยา และจำนวนครั้งการปรุงยา

การเกิดม็อบและการสร้างโลก

  • คุณสมบัติแวดล้อมใหม่ minecraft:gameplay/natural_mob_spawns ใช้นิยามการเกิดม็อบตามน้ำหนักรายหมวดหมู่และ spawn cost รายเอนทิตี
    • ระหว่างการวางโลกจาก world generation จะมีเพียง Dimension และ Biome ที่ใช้คุณสมบัตินี้
    • ตัวแก้ไข overlay จะให้ความสำคัญกับการตั้งค่าหมวดหมู่ของชั้นบนและ spawn cost ของเอนทิตีเดียวกันก่อน
  • minecraft:gameplay/creature_world_gen_spawn_probability กำหนดความน่าจะเป็นการวนซ้ำการเกิดม็อบหมวด creature ระหว่างสร้างโลกเป็น ตั้งแต่ 0 ขึ้นไปแต่น้อยกว่า 1 โดยค่าเริ่มต้นคือ 0.1
  • spawners, spawn_costs, creature_spawn_probability ของ Biome ถูกลบออกและย้ายไปยังคุณสมบัติแวดล้อมใหม่
  • คุณสมบัติแวดล้อมของอนุภาครอบข้างจะทำ interpolation ของความน่าจะเป็นระหว่าง timeline keyframe และรองรับตัวแก้ไข append ที่ต่อรายการอนุภาคในชั้นล่าง
  • ใน Noise Settings การตั้งค่า aquifer และ ore vein ถูกจัดใหม่เป็นอ็อบเจ็กต์ aquifers แบบเลือกได้ และรายการ ore_veins
    • หากไม่มีการตั้งค่า จะไม่สร้าง aquifer หรือ ore vein นั้น
    • ฟิลด์ density function ที่เกี่ยวข้องถูกย้ายจาก noise_router ไปยังโครงสร้างใหม่
  • เพิ่ม sub, div, negate, lerp, floor, round, ceil, truncate, beardifier ให้กับ Density Function
    • ชื่ออาร์กิวเมนต์เดิมหลายรายการถูกเปลี่ยนเป็น value, left, right, input, noise
    • invert ถูกเปลี่ยนชื่อเป็น reciprocal
    • final_density จะไม่บวก beardifier แบบโดยนัยอีกต่อไป

กราฟิกและการแก้บั๊กสำคัญ

  • เวอร์ชัน resource pack เพิ่มเป็น 92.0
  • เพิ่มเชดเดอร์ที่รองรับ order-independent transparency และนิยาม OIT_ALWAYS_WRITE_DEPTH
  • core/integrate_depth.fsh จะรวม depth buffer ของ 3D HUD และ gizmo ที่แสดงอยู่ด้านบนเสมอ เข้ากับ depth buffer หลัก
  • ปัญหาสำคัญที่แก้ไขมีดังนี้
    • ปัญหาการกำหนดปุ่มและอินพุตที่เกี่ยวข้องกับคีย์บอร์ดที่ไม่ใช่ QWERTY รวมถึงการป้อนข้อมูลบน macOS/CJK
    • ปัญหา Improved Transparency ที่ทำให้การเรนเดอร์แผนที่ล่ม รวมถึงปัญหาการแสดงผลของกระจก วัตถุกึ่งโปร่งใส อนุภาค และเส้นขอบโลก
    • ปัญหาการล่มจาก projectile นอกความสูงของโลก และการวางรังผึ้งที่ความสูงต่ำสุด
    • ปัญหาการบันทึก/โหลด heightmap ของ world generation และตำแหน่งม็อบไม่ซิงก์หลัง tick sprint
    • ปัญหาเกี่ยวกับการวาง Cushion สี ชื่อแบบกำหนดเอง เวลาเชื้อเพลิง และการตรวจชน
    • ปัญหาความเสียหาย/การบินของ Ender Dragon, การใช้พอร์ทัลของ spectator, และการตัดสินบล็อกปลอดภัยของ /spreadplayers

ข้อควรระวังในการติดตั้งและทดสอบ

  • Snapshot นี้สำหรับ Minecraft: Java Edition และติดตั้งได้โดยเปิดใช้ Snapshot ในแท็บ Installations ของ Minecraft Launcher
  • เนื่องจากเวอร์ชันทดสอบ อาจทำให้โลกเสียหายได้ จึงควรสำรองข้อมูลหรือรันในโฟลเดอร์ที่แยกจากโลกหลัก
  • มี Minecraft server jar สำหรับข้ามแพลตฟอร์มให้ด้วย
  • สามารถส่งบั๊กได้ที่ Minecraft issue tracker และส่งความคิดเห็นได้ที่ เว็บไซต์ Feedback

1 ความคิดเห็น

 
ความคิดเห็นจาก Hacker News
  • อิมพลีเมนต์ LWJGL ของ binding นี้เขียนโดยสมาชิกทีม modpack GTNH ทำให้วงจร vanilla→modded→vanilla กลับมาครบอีกครั้ง https://github.com/LWJGL/lwjgl3/pull/1033

    • ถ้าพูดแบบเกินจริงหน่อย อาจมองได้ว่า GTNH มีส่วนร่วมกับ Minecraft มากกว่า Microsoft เสียอีก ไม่ได้พูดแบบนี้เพราะผมเคยช่วย contribute นิดหน่อยเท่านั้น แต่ความทุ่มเทและปริมาณงานที่ใส่ลงไปนั้นน่าทึ่งมาก
    • สงสัยว่าบรรดานักพัฒนา Minecraft ตอนนี้มีสักกี่คนที่เคยเป็น modder มาก่อน และกี่คนที่ยังทำ mod อยู่ในปัจจุบัน
  • ช่วงหลังได้ย้ายเกม Tribal Trouble(https://github.com/bondolo/tribaltrouble) จาก GLFW ไปเป็น SDL3 ซึ่งโดยรวมแล้วเป็นการ refactor ที่ค่อนข้างราบรื่น มีปัญหาบางอย่างกับโหมด fullscreen แบบ exclusive และ desktop fullscreen แต่สุดท้ายก็แก้ได้
    ผมยังเขียน เดโม ไว้เพื่อทดสอบและทำเอกสารเรื่องการจัดการโหมดหน้าจอที่ยุ่งยากด้วย ตัวเกมเป็น Java เหมือน Minecraft แต่เดโมใช้ C เพื่อให้เรียบง่ายที่สุด

    • Tribal Trouble นี่เป็นชื่อที่ไม่ได้ยินมานานมาก จำได้ว่านักพัฒนาเคยบอกว่าเลือก Java เพราะอยากใช้ ภาษาที่แปลกหรือไม่ค่อยพบในการพัฒนาเกม
    • สงสัยว่า GLFW มีปัญหาอะไร หรือด้วยเหตุผลใดจึงเลือก ย้ายไป SDL3
  • fullscreen แบบ exclusive บน Windows มีปัญหาที่ทราบกันว่าสามารถทำให้เกมค้างได้ โดยเฉพาะในสภาพแวดล้อมหลายจอ และบน Wayland แค่เข้าสู่โหมดนี้ก็ทำให้ค้างได้ ทั้งสองอย่างดูเหมือน บั๊กระดับ blocker ที่ควรเลื่อน snapshot จึงหวังว่าจะได้รับการแก้ก่อนออกเวอร์ชันจริง

    • snapshot คือการเผยแพร่สถานะปัจจุบันของ main branch ตามที่เป็นอยู่ รวมถึงบั๊กระดับ blocker ด้วย
      ผมมองว่าระดับความคาดหวังด้านเสถียรภาพเรียงประมาณนี้: รุ่น LTS, รุ่นจริง, release candidate, beta, alpha, snapshot, commit ที่เพิ่ง merge, PR ที่ยังไม่ merge, draft PR เป็นต้น ถ้าเป็นบั๊กใหญ่ก็ควรเลื่อน release candidate หรือ beta และถ้าเป็นบั๊กร้ายแรงก็ควรบล็อกการ merge เอง แต่ไม่มีเหตุผลต้องเลื่อน snapshot เพียงเพราะบั๊กที่ผ่าน CI แล้วถูก merge เข้ามา
      snapshot ใกล้เคียงกับการตัดสถานะปัจจุบันออกมาเผยแพร่เป็นระยะ เพื่อให้ผู้ใช้รันและส่ง feedback ได้โดยไม่ต้อง build main เอง
    • ถ้าเป็นรุ่นจริงก็อาจเลื่อนได้ แต่ไม่มี เหตุผลที่จะเลื่อน snapshot ควรปล่อยตามสถานะปัจจุบันเพื่อใช้ telemetry ดูว่าปัญหาที่ทราบเกิดบ่อยแค่ไหน และเพื่อค้นหาปัญหาที่ยังไม่รู้ก่อนออกเวอร์ชันจริง
      snapshot ไม่เคยสัญญาว่าจะไม่มีบั๊ก ตรงกันข้ามด้วยซ้ำ นั่นคือสมมติฐานตั้งต้น
    • Minecraft น่าจะใช้ fullscreen แบบไร้ขอบหน้าต่าง มานานแล้ว ถ้าไม่ได้ตั้งค่าแยกไว้ต่างหาก ช่วงกว่า 10 ปีที่ผ่านมา แพลตฟอร์ม บริการ และแอปจำนวนมากเลิกใช้ fullscreen แบบ exclusive กันไปแล้ว
    • ทุกวันนี้การ render เป็นหน้าต่าง fullscreen พบได้ทั่วไปกว่า fullscreen แบบ exclusive โดยปกติ window manager จะใช้ optimization แบบเดียวกับที่ในอดีตใช้เฉพาะกับโหมด exclusive ให้กับหน้าต่าง fullscreen ที่อยู่หน้าสุดด้วย
    • เพราะเป็น snapshot จึงเป็นปัญหาที่เกิดขึ้นได้ และมีโอกาสสูงว่าจะถูกแก้ใน snapshot ถัดไป
  • ในฐานะพ่อสายเทคนิคที่ไม่รู้จัก Minecraft เลย สงสัยว่าถ้าจะตั้งเซิร์ฟเวอร์ครอบครัวในปี 2026 ควรทำอย่างไร เด็ก ๆ ตอนนี้เล่นบน iPad และบางครั้งก็ใช้ MacBook เก่า ๆ กับพีซี Windows

    • Minecraft มีสอง edition คือ Java และ Bedrock เวอร์ชันมือถือ คอนโซล และ Windows Store ใช้ Bedrock ส่วนที่ดาวน์โหลดโดยตรงจากเว็บไซต์คือ Java Edition
      สามารถรันเซิร์ฟเวอร์ Java มาตรฐาน แล้วใช้ Geyser แปลงโปรโตคอล Bedrock แบบเรียลไทม์ได้ สำหรับ client Bedrock ที่มีข้อจำกัดมากอาจต้องมีวิธี workaround บางอย่าง แต่จะทำให้บริหารจัดการโดยยึดเซิร์ฟเวอร์ Java ที่มีตัวเลือกมากกว่าเป็นศูนย์กลางได้
    • คำแนะนำ การจูน JVM สำหรับ Minecraft บนอินเทอร์เน็ตจำนวนมากล้าสมัยหรือผิดพลาด จึงควรละไว้จะดีกว่า
      แค่ใช้ JVM รุ่นใหม่ ตั้งค่า maximum memory ให้สูงเท่าที่ยอมรับได้ แล้วใช้ ZGC ก็เพียงพอ มีคำแนะนำที่ให้ปรับ flag หลายตัวโดยไม่มีหลักฐาน หรือใส่ค่าที่ขัดกันเองอย่างขนาด Eden area กับเป้าหมาย pause time ไปพร้อมกันด้วย
      ZGC มี latency ต่ำมาก และยิ่ง heap ใหญ่ ประสิทธิภาพที่ตกลงก็ยิ่งน้อยลง แต่ถ้าต้องการรักษา object header compression ไว้ ควรตั้งไว้ ต่ำกว่า 32GB JVM รุ่นใหม่ยังช่วยปรับปรุงการใช้หน่วยความจำและประสิทธิภาพโดยรวมด้วย
    • ทำตาม วิธีตั้งค่าเซิร์ฟเวอร์ vanilla ของ Java Edition ได้เลย Java Edition รันได้เฉพาะบน Windows, macOS และ Linux แต่ผมมองว่าบั๊กน้อยกว่าและดีกว่า Bedrock Edition
      ถ้าต้องการประสิทธิภาพเพิ่ม ให้ติดตั้ง fabric และ lithium ส่วน mod อย่าง Paper, Spigot, Purpur อาจทำให้ระบบอัตโนมัติพัง จึงควรหลีกเลี่ยง
    • Minecraft บนโทรศัพท์และแท็บเล็ตปิดและจำกัดกว่า Java Edition จึงมีตัวเลือกน้อยลง
      ผมใช้ itzg/docker-minecraft-server ได้อย่างเสถียรมาหลายปี และชอบตรงที่ image จัดการทุกอย่างให้โดยไม่ต้องติดตั้ง dependency ทีละตัว มี image สำหรับเซิร์ฟเวอร์ Bedrock ด้วย แต่ผมยังทำให้ทำงานได้ไม่สำเร็จ
      ถ้าจะให้ดูแลง่ายที่สุด ทุกคนควรใช้ Java Edition บน Windows, Mac หรือ Linux ไม่เช่นนั้นก็มีทางเลือกคือจ่ายเงินใช้ Realms ซึ่งเป็นเซิร์ฟเวอร์โฮสติ้ง
    • เมื่อคำนึงถึง ความชอบของเด็ก ๆ ที่อยากเล่นบน iPad แล้ว Realms ก็น่าลองดู เท่าที่รู้คือให้เซิร์ฟเวอร์ 10 คนในราคาราว 7 ดอลลาร์ แต่ subscription ของ Java กับ Bedrock แยกกัน และแพ็กเกจก็แตกเป็นหลายระดับ
      อาจไม่เหมาะกับเป้าหมายของเซิร์ฟเวอร์ครอบครัวก็ได้ แต่เป็นวิธีที่ง่ายที่สุดสำหรับให้เด็ก ๆ เล่นด้วยกันได้เร็วและสะดวก ผมเคยเห็นเด็กบางคนที่ยืนกรานใช้ Bedrock มานาน พอย้ายมา Java แล้วก็เสียดายที่ไม่เปลี่ยนให้เร็วกว่านี้
  • Icculus โพสต์วิดีโอยอดเยี่ยมเกี่ยวกับ การพอร์ตเกมจาก SDL2 ไปเป็น SDL3 และวิดีโอพอร์ต Doom อยู่ที่นี่: https://www.youtube.com/watch?v=ixdeGhsoxy8

    • ไม่รู้มาก่อนว่า Chocolate Doom กำลังถูกพอร์ตไป SDL3 และ Icculus ลงมือทำเองด้วย ในบรรดาพอร์ต Doom ที่รู้จัก Woof! ได้ย้ายไปแล้ว: https://github.com/fabiangreffrath/woof
  • น่าทึ่งที่ Minecraft ดูจะค่อย ๆ กลายเป็น เกมเอนจินของตัวเอง มากกว่าเป็นแค่เกมธรรมดา

  • อยากรู้ว่ามีการบันทึกเหตุผลที่เลิกใช้ GLFW ไว้หรือไม่ มีโปรเจกต์ที่ใช้ GLFW อยู่ เลยต้องคิดอยู่เสมอว่า SDL เป็นตัวเลือกที่ดีกว่าหรือเปล่า

    • ในอัปเดตนี้ การรองรับ Wayland ใช้งานได้โดยไม่ต้องทำงานแยกเพิ่มเติม ก่อนหน้านี้ต้องใช้วิธีอ้อม และถึงจะใช้แล้วก็ยังมีปัญหาใหม่เกิดขึ้นเรื่อย ๆ แต่คนส่วนใหญ่ก็พอใจกับการรันผ่าน XWayland เลยไม่ได้ใส่ใจมากนัก
      SDL3 รองรับ Wayland ได้แข็งแรงเป็นพื้นฐานอยู่แล้ว ใน Minecraft นั้น GLFW ใช้แค่สร้างหน้าต่าง, ไอคอนบนแถบงาน, โหมดเต็มจอ และอินพุต ส่วนที่เหลือจัดการด้วย OpenGL แบบดิบ ๆ ดังนั้นการย้ายจึงง่าย ตอนนี้ยังรองรับ Vulkan ด้วย ทำให้ใช้สแตกที่ทันสมัยเต็มรูปแบบได้บน Linux desktop และ Steam Deck
    • SDL รองรับมือถือ แต่ GLFW ไม่รองรับ จึงอาจเป็นความตั้งใจที่จะรวม codebase เฉพาะแพลตฟอร์มเข้าด้วยกัน
      SDL3 ทำงานได้แม้บน Android 4.2 และเคยทำแอปด้วย SDL3 กับ ImGui โดยไม่ใช้ Java ด้วย
    • เหตุผลหนึ่งคือ การรองรับตัวป้อนข้อความ (IME)
    • SDL แทบจะเป็น เลเยอร์แพลตฟอร์ม ที่ใช้ได้เกือบทุกที่ มันมีทั้งหน้าต่าง, กราฟิก, ออดิโอ, อินพุต, เครือข่าย และเธรด แต่ GLFW ให้แค่หน้าต่าง, graphics context และอินพุต จึงต้องเตรียมไลบรารีส่วนที่เหลือเอง
      อาจไม่ใช่ความต่างใหญ่สำหรับทุกโปรเจกต์ แต่ SDL ให้ฟังก์ชันมากกว่าและพอร์ตข้ามแพลตฟอร์มได้ดีกว่า
    • แม้ไม่มี OpenGL หรือ Vulkan ก็สามารถสร้าง เกม 2D เต็มรูปแบบ ด้วย SDL API เพียงอย่างเดียวได้
  • เกมริธึม osu! ก็เพิ่งย้ายจาก SDL2 ไป SDL3 เมื่อไม่นานนี้ และประสิทธิภาพกับ latency ดีขึ้นอย่างมาก การนำ SDL3 มาใช้ดูค่อนข้างช้า และก็น่าแปลกใจที่ Minecraft ใช้ GLFW มาจนถึงตอนนี้
    โดยเฉพาะหลังย้ายไป SDL3 แล้ว latency ที่เคยเกิดเมื่อเปิดไคลเอนต์ Discord ไว้ระหว่างรัน osu! หายไป จำได้ว่าเห็นจากวิดีโอพัฒนาบน YouTube

    • ใน Linux บางดิสโทร sdl2-compat และ sdl12-compat เป็น implementation หลักของ SDL2·1.2 จึงมีหลายกรณีที่ ใช้ SDL3 ทางอ้อม อยู่แล้ว ด้วยเหตุนี้แอปจำนวนมากขึ้นจึงทำงานแบบ native บน Wayland ที่มี latency ต่ำกว่า XWayland และการรองรับคอนโทรลเลอร์ก็ดีขึ้น
      Ubuntu 24.04 ไม่ได้รวม SDL3 มาตั้งแต่แรก ซึ่งดูเหมือนเป็นหนึ่งในเหตุผลที่การนำมาใช้ช้ากว่าที่คาด เพราะ SDL3 ใหม่กว่าที่คิด
    • osu! รองรับระบบปฏิบัติการเดสก์ท็อปหลักทั้ง 3 ตัว รวมถึง iOS·Android และพยายามคงฟีเจอร์อย่าง Wayland ไว้แบบ native จึงใช้เวลา ประมาณ 2 ปีในการย้ายไป SDL3 การย้ายครั้งนี้ดูเหมือนจะมาถึงขั้นสุดท้ายจริง ๆ เป็นครั้งแรก
    • ใน SDL3 มี API หลายตัวเปลี่ยนไป ทำให้การนำมาใช้ยากขึ้น โดยเฉพาะเมื่อผ่าน ไลบรารี binding ภาระจะยิ่งมากขึ้น
  • SDL2 เริ่มแสดงความล้าสมัย โดยเฉพาะในด้าน การ abstract GPU API ที่รวม Vulkan·Metal ด้วย ดังนั้นการย้ายไป SDL3 จึงสมเหตุสมผล อยากรู้ว่าปัญหา input lag และ Alt+Tab ที่มีมานานใน Java Edition บน Linux จะได้รับการแก้ไขจากการเปลี่ยนเลเยอร์หน้าต่าง·อินพุตหรือไม่

    • เป้าหมายการย้ายจริง ๆ ไม่ใช่ SDL2 แต่เป็น GLFW ดังนั้นถ้าต้องเลือกใหม่ ก็เป็นธรรมชาติที่จะเลือก SDL3
  • ถ้าต้องการรองรับม็อดอย่างจริงจัง ดูเหมือนว่าควรใช้ภาษาที่ ดีคอมไพล์และแก้ไขตอนรันไทม์ได้ง่าย อย่าง Java หรือ C# หรือใช้ JVM กับ .NET CLR
    หากคำนึงถึงม็อดเดอร์ไปพร้อมกับการเปลี่ยนแปลงภายใน ก็แทบจะได้ modding API ที่ดีโดยไม่มีต้นทุนเพิ่ม

    • สิ่งที่เกมที่มีม็อดจำนวนมากต้องการจริง ๆ มีเพียง ฐานผู้ใช้ที่ใหญ่พอ เท่านั้น สำหรับม็อดเดอร์ที่ทุ่มเท การแพตช์ไบนารีเล็กน้อยหรือการฉีด DLL ไม่ใช่อุปสรรค