rlsw – Raylib ซอฟต์แวร์ OpenGL renderer น้อยกว่า 5,000 บรรทัด LOC

 (github.com/raysan5)
2 คะแนน โดย GN⁺ 2025-10-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • rlsw เป็น เรนเดอร์เดอร์ซอฟต์แวร์สไตล์ OpenGL 1.1 ที่ให้ backend แทน สำหรับรัน raylib ได้ในสภาพแวดล้อมที่ไม่มี GPU
  • รองรับโหมดการเรนเดอร์หลากหลายอย่าง จุด, เส้น, สามเหลี่ยม, ควอด และฟีเจอร์กว้างขวางอื่น ๆ เช่น การคลิป (clipping), texture และบัฟเฟอร์สี/ความลึกแบบหลายชนิด
  • Texture ใช้งานได้กับฟอร์แมตที่ไม่อัดอั้นทั้งหมดที่ raylib รองรับ และมีการควบคุม การกรอง (filtering) และการห่อตัวอย่าง (wrapping) ได้อย่างละเอียด
  • มีฟีเจอร์กราฟิกส์ 3D หลักอย่าง matrix stack, depth test, blend, cull face และใช้ OpenGL function binding เพื่อเพิ่มความเข้ากันได้สูงสุด
  • ขนาดต่ำกว่า 5,000 บรรทัด ทำให้ด้านประสิทธิภาพและความเบามีจุดเด่นในการเปรียบเทียบกับเรนเดอร์ซอฟต์แวร์อื่น คือความเรียบง่ายและการผสานรวมที่ดี

rlsw: ภาพรวม Raylib OpenGL Software Renderer

แนะนำ

  • rlsw คือ เรนเดอร์เดอร์ซอฟต์แวร์สไตล์ OpenGL 1.1 ซึ่งเป็นไลบรารีที่นำฟีเจอร์ทั้งหมดที่ rlgl.h ของ raylib ให้มาใช้งานในรูปแบบซอฟต์แวร์ทั้งหมด
  • ออกแบบมาเป็น backend ทดแทนแบบตรง เพื่อให้ raylib รันได้บนอุปกรณ์ที่ไม่มี GPU เลย

ฟีเจอร์หลัก

  • เรนเดอร์ไปยัง custom internal framebuffer พร้อมรองรับโหมดสี/ความลึกหลายแบบ (RGB 8, 16, 24 บิต, Depth 8/16/24 บิต)
  • โหมดการเรนเดอร์ที่รองรับ: จุด, เส้น, สามเหลี่ยม, ควอด
    • สามารถตั้งค่าเพิ่มเติม เช่น ความหนาของจุด, ความกว้างของเส้น, โหมด polygon ได้
    • โหมดเรนเดอร์ทั้งหมดรองรับการตัดภาพ (clipping)
  • ฟีเจอร์ texture: รองรับฟอร์แมตไม่อัดอั้นทั้งหมดที่ raylib รองรับ
    • รองรับการตรวจสอบ minification/magnification
    • รองรับ point/bilinear filtering
    • รองรับการกำหนดค่า wrap mode แบบละเอียดตามพิกัด S/T
  • รองรับ vertex array โดยตรง และสามารถวาด primitives ทันทีได้
  • รองรับ matrix stack (Push/Pop)
  • ฟีเจอร์เพิ่มเติม: OpenGL-style getter, การปรับขนาด framebuffer, perspective correction, scissor clipping, depth test, blend, cull face

การใช้งานและการปรับแต่ง

  • มีโครงสร้างแบบ single header & source และรองรับการสร้าง implementation ผ่าน #define RLSW_IMPLEMENTATION
  • ก่อน build รองรับการปรับแต่งได้ด้วยค่าคงที่จุลภาคหลายตัวที่ผู้ใช้กำหนดเองได้
    • ตัวอย่างเช่น การปรับจำนวนสูงสุด/ขนาดของ framebuffer หรือ texture

โครงสร้างและชนิดข้อมูล

  • กำหนดค่าประเภทค่า, enum, และ struct ภายในเฉพาะ (เช่น sw_vertex_t, sw_texture_t) ที่เข้ากันได้กับ OpenGL หลายตัว
  • แทนที่การเรียก OpenGL ส่วนใหญ่ด้วยฟังก์ชันของ rlsw เพื่อใช้งานได้แทนกัน
  • โครงสร้างจัดการสถานะภายในที่ค่อนข้างครบถ้วน ครอบคลุม matrix, state, และการจัดการ texture

ลิขสิทธิ์และการใช้งาน

  • ภายใต้ ลิขสิทธิ์ MIT ใช้งานเชิงพาณิชย์/ไม่เชิงพาณิชย์ และทำ derivative works ได้อย่างเสรี
  • เน้นความเบาและการแทนที่แบบซอฟต์แวร์ทั้งหมดเหนือประสิทธิภาพ จึงมีข้อดีในการผสานรวมและเผยแพร่อย่างง่าย

สรุปโดยละเอียด

โครงสร้างหัวข้อและคำอธิบาย

  • rlsw แทนที่ฟีเจอร์ OpenGL 1.1 ได้เกือบทั้งหมดในระดับฟังก์ชันด้วยซอฟต์แวร์
  • header นี้ (rlsw.h) กำหนด
    • ประเภทค่า, enum และ struct แบบกำหนดเอง
    • การแทนที่คำสั่ง OpenGL ด้วย macro ไปเป็นฟังก์ชันภายในของ rlsw
    • ประกาศ API (การเริ่มต้น, การคัดลอก/เข้าถึง framebuffer, draw, clear, การรับค่าจาก vertex/texture เป็นต้น)

ฟีเจอร์ตัวแทน

  • ภายในรองรับ matrix หลายสแตก (เฉพาะ Projection/ModelView/Texture)
  • การจัดการสถานะการเรนเดอร์: การจัดการบิตสถานะอย่าง Scissor, เปิด/ปิด texture, Depth Test เป็นต้น
  • ฟีเจอร์ความเข้ากันได้กับ OpenGL: getter หลากหลาย การคัดลอกสถานะ การจัดการ error
  • การจัดการ texture: ฟอร์แมตไม่อัดอั้น, โหมด filter/wrap, การคัดลอกหน่วยความจำ ฯลฯ
  • โดยพื้นฐานแล้วรองรับการจัดการ shape 2D/3D ส่วนใหญ่ (จุด, เส้น, สามเหลี่ยม, ควอด) และการประมวลผลสี/ความลึก

ค่ากำหนดที่ปรับแต่งได้

  • ความละเอียดและจำนวนของ framebuffer/texture, ความกว้างบิตของ color/depth buffer, ความลึก matrix stack, จำนวน texture สูงสุด ฯลฯ
  • รองรับการปรับแต่งขั้นสูงเช่นค่า SW_MAX_CLIPPED_POLYGON_VERTICES

องค์ประกอบโครงสร้างหลักภายใน

  • sw_context_t: จัดการสถานะและบัฟเฟอร์ทั้งหมดของ context
  • จัดการอย่างบูรณาการระหว่าง vertex buffer, texture array, framebuffer, state flag ภายใน

ข้อดีและกรณีใช้งาน

  • เหมาะอย่างยิ่งกับอุปกรณ์ที่ไม่มี GPU, สภาพแวดล้อม embedded, และการพอร์ต/ทดสอบ/ทำ automation ตาม OS ต่าง ๆ
  • ทำงานได้แอป raylib แบบเต็มไปด้วยซอฟต์แวร์เท่านั้น โดยไม่ต้องพึ่ง OpenGL
  • โครงสร้างที่เบามีความได้เปรียบมากต่อการทดลอง/พัฒนาใหม่ และการรองรับสภาพแวดล้อมที่ไม่เป็นมาตรฐาน

ลิขสิทธิ์และผู้มีส่วนร่วม

  • อนุญาตให้ทำการเผยแพร่ซ้ำแบบยืดหยุ่นภายใต้ MIT
  • รีวิวโดย Le Juez Victor, Ramon Santamaria ในปี 2025–2026

บทสรุป

  • rlsw คือ เรนเดอร์เดอร์ซอฟต์แวร์บริสุทธิ์ (Pure Software Renderer) สำหรับ raylib ที่เข้ากันได้กับ OpenGL ได้เกือบทั้งหมด
  • ในด้านไฟล์เดียว/ขนาดเล็ก/ความสามารถในการขยาย และการรองรับฟอร์แมต texture ทั้งหมดของ raylib ทำให้มีจุดเด่นด้าน อุปสรรคในการเริ่มต้นใช้งานและการผสานรวม เมื่อเทียบกับโซลูชันกราฟิกซอฟต์แวร์อื่น
  • มีคุณค่ามากสำหรับโครงการที่ตั้งเป้าหมาย กราฟิกระดับต่ำ (low-level) และพกพา (portability)

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2025-10-23
ความเห็นจาก Hacker News
  • ผู้เขียน Raylib ประกาศอย่างยินดีมากว่าสามารถคอมไพล์โปรแกรม raylib ทั้งหมดได้ด้วยแอป win32 เพียงอย่างเดียวโดยไม่พึ่งพา external dependency ใด ๆ ลิงก์
    • น่าสนใจมาก กำลังหาอะไรสักอย่างที่เรนเดอร์บนจอ LED ได้เพื่อเอาไปเล่นสนุกกับ embedded processor อยู่ ของที่หาเจอจนถึงตอนนี้ยังไม่ค่อยถูกใจ ถ้าเข้าใจไม่ผิดก็น่าจะคอมไพล์สิ่งนี้เพื่อทำ software rendering ได้ และสำหรับขนาดประมาณ 192x128 พิกเซลของผม มันน่าจะเร็วพอในแทบทุกระบบ ได้เวลาทำแอนิเมชันสนุก ๆ แล้ว
    • ใน Win32 มี OpenGL 1.2 software renderer ที่ค่อนข้างดีอยู่แล้ว
    • สงสัยว่าทำไมถึงต้องทำแบบนี้ด้วย
  • อยากรู้ความเห็นของ Tsoding กับข่าวนี้
    • ตอนนี้มันคงกลายเป็นกระแสหลักจนขึ้น HN แล้ว Tsoding น่าจะหมดความสนใจ
  • มันเจ๋งดีที่คอมพิวเตอร์สมัยนี้เร็วพอจนสามารถทำเกม 2D ที่ดูดีได้ด้วยไลบรารี OpenGL 1.1 software rendering แบบนี้
    • ถ้ารักษาความละเอียดให้ต่ำ คุมความซับซ้อนของฉากอย่างระวัง และตัดสินใจเรื่อง art style ให้ชัด ก็สามารถทำเกม 3D ที่สมเหตุสมผลและรันได้บนฮาร์ดแวร์เมื่อ 20 ปีก่อนได้ ผมเคยลองทำเกมเองเป็นการทดลองด้วย1 2 ตอนนี้พอรู้ว่าสิ่งนี้ทำได้แล้ว ก็มีแผนจะทำเกมที่สองที่ "จริงจัง" และสมบูรณ์ยิ่งขึ้น รู้สึกได้เลยว่าพลังคอมพิวเตอร์พัฒนาไปมาก ข่าวของ Raylib ก็ยอดเยี่ยมมากจนกำลังคิดจะนำมาใช้จริง
    • แก้ไข: ผมไม่รู้ว่านี่เป็น software rendering แต่ถึงอย่างนั้น เกมของผมก็น่าจะเรนเดอร์ได้โดยใช้แค่อัลกอริทึมจัดเรียงความลึกของสไปรต์บน CPU ที่เหมาะสมที่สุดเท่านั้น (เป็น pixel art แบบ isometric คล้าย RollerCoaster Tycoon) ในโปรเจกต์ Metropolis 1998 ที่ทำแนวยุค 90s นั้น ผมต้องใช้ OpenGL fixed function pipeline โบราณ (โชคดีที่ค้นพบว่าสามารถส่งฟิลด์เพิ่มเติมไปยัง GPU ได้ด้วย extension function ในไฟล์ gl.h) กำลังใช้ SFML เป็น graphics framework ซึ่งก็น่าจะอยู่บน OpenGL 1.x และตัวอย่างล่าสุดอย่างเกม Metropolis 1998 ก็แสดงให้เห็นว่าแนวทางนี้ทำอะไรได้บ้าง
    • คิดว่าในที่สุดแล้ว software rendering คืออนาคต เพียงแต่มีเงื่อนไขว่าต้องใช้ hardware acceleration อย่างจริงจังได้แบบ GPGPU
    • เมื่อหลายสิบปีก่อนก็มี Unreal Tournament แบบ 3D เต็มรูปแบบที่เรนเดอร์ด้วยซอฟต์แวร์อยู่แล้ว และในปี 2023 ก็ยังทำงานได้ดี ลิงก์
  • Fabrice Bellard ก็เคยเขียน TinyGL ที่เกี่ยวกับ OpenGL ด้วย ลิงก์
    • สิ่งที่น่าทึ่งคือ TinyGL 0.4.1 ออกเมื่อ (5 มีนาคม 2022) และ TinyGL 0.4 ออกครั้งแรกเมื่อ (17 มีนาคม 2002) "แผนการพัฒนาของเรากินเวลาหลายศตวรรษ"
    • คนนี้เป็นแบบอย่างที่น่าทึ่งจริง ๆ เพราะทำได้แทบทุกอย่าง
    • ในยุค 90s ผมเห็น software renderer แนวนี้เยอะมาก แต่พูดตรง ๆ ว่าตอนนั้นมันช้า เทอะทะ หรือมี artifact เยอะ เลยไม่ค่อยดีนัก ถ้าจะให้มีประสิทธิภาพต้องผสานเกมกับ renderer เข้าด้วยกันอย่างใกล้ชิด เป็นความย้อนแย้งของประวัติศาสตร์ดี
    • เผื่อใครสนใจ ยังมี tinygl ที่ C-Chads fork ไว้ด้วย ได้รับการดูแลต่อเนื่องใหม่กว่าต้นฉบับมาก และเพิ่มฟีเจอร์หลายอย่างรวมถึง multithreading แต่ถูก archive ไปช่วงปลายปี 2023
  • ต้องยกความดีความชอบให้ pikuma.com ที่ทำให้ผมเห็นความงามของ software renderer และภูมิใจมากที่เข้าใจโค้ดส่วนใหญ่ได้
  • พอเห็นคำอธิบายว่า "OpenGL 1.1-style implementation on software" ก็เลยสงสัยว่าถ้าจะทำให้ถึง OpenGL 2.0 (เวอร์ชัน Non ES) ต้องใช้กี่บรรทัด
    • อย่างน้อยก็มากขึ้นหลายสิบเท่า ส่วนที่ยากที่สุดคือการทำ user-programmable shader (ARB assembly/GLSL) และยังต้องมี GLSL parser กับ shader interpreter ด้วย นอกจากนี้ยังต้องเพิ่ม multitexturing และ texture combiner หลากหลายแบบ โดยรวมแล้วถึงจะประเมินต่ำมากก็น่าจะต้องมีอย่างน้อย 40,000 บรรทัด แน่นอนว่าถ้าไม่ทำตามสเปกครบทั้งหมดและทำแค่ขั้นต่ำ ก็อาจน้อยกว่านั้นได้
    • ผมเคยทำ OpenGL API implementation สำหรับฮาร์ดแวร์ fixed function จริง ๆ มาก่อน ทำถึงเวอร์ชัน 1.5 และใส่ extension บางตัวอย่าง framebuffer object ด้วย ซีรีส์ 1.x มีส่วนที่ไม่จำเป็นเยอะ แต่ implement ง่าย ส่วน 2.x (ที่เริ่มมี shader) นั้นทำแบบ software ยากมาก
    • ไม่แน่ใจจำนวนบรรทัดที่แม่นยำ แต่ก็มี software renderer ระดับ 3.x ชื่อ PortableGL ด้วย เป็นโปรเจกต์ที่เจ๋งมากและเล่นด้วยสนุก
  • เกี่ยวกับคำว่า OpenGL-style
    • ถ้าดูจากแค่ header ก็ต้องบอกว่ายินดีด้วย เพราะนี่คือ OpenGL 1.1 implementation แบบ software ที่ค่อนข้างดี แม้จะไม่ตรงสเปกทั้งหมด แต่ก็เหมือนไดรเวอร์ MiniGL สมัยก่อนที่ implement เฉพาะส่วนจำเป็นให้เกมรันได้ โปรเจกต์นี้ก็คล้ายกัน คือ implement เท่าที่พอให้ OpenGL backend ของ Raylib ทำงานได้ จุดประสงค์คือให้ใช้งานได้โดยไม่ต้องพึ่งพา graphics dependency ภายนอก
  • สงสัยว่ารองรับ CUDA ไหม
    • ไม่รองรับ เป็นการเรนเดอร์ด้วย CPU ล้วน ๆ ไม่ได้ใช้แม้แต่ SIMD ใช้แค่โค้ดพื้นฐานแบบจำนวนเต็ม/จำนวนจริงโดยตรง
  • สิ่งนี้ดูเหมาะกับ Nintendo 3DS แบบสมบูรณ์แบบ
    • งั้นก็น่าสงสัยว่าจะเอาไปใช้ทำเกมสำหรับคอนโซลอย่าง NES, SNES หรือ Genesis ได้ด้วยไหม