rlsw – Bộ kết xuất phần mềm OpenGL của Raylib, dưới 5.000 dòng LOC

• rlsw là trình kết xuất phần mềm theo phong cách OpenGL 1.1, cung cấp một backend thay thế để chạy raylib trong môi trường không có GPU
• Hỗ trợ nhiều chế độ kết xuất như điểm, đường, tam giác, quad cùng các tính năng rộng như clipping, texture, nhiều buffer màu/độ sâu
• Texture có thể dùng tất cả các định dạng không nén mà raylib hỗ trợ, đồng thời cho phép kiểm soát chi tiết thiết lập lọc và wrapping
• Tích hợp các chức năng đồ họa 3D chính như stack ma trận, depth test, blend, cull face, và tối đa hóa khả năng tương thích bằng cách tận dụng binding hàm OpenGL
• Mặc dù quy mô dưới 5.000 dòng, nó có lợi thế hơn các trình kết xuất phần mềm khác ở mức đơn giản và khả năng tích hợp trên phương diện hiệu năng và độ nhẹ

---

rlsw: Tổng quan về trình kết xuất OpenGL phần mềm của Raylib

Giới thiệu

• rlsw là một trình kết xuất phần mềm theo phong cách OpenGL 1.1, là thư viện hiện thực toàn bộ các chức năng mà raylib cung cấp trong rlgl.h bằng phần mềm
• Được thiết kế như một backend thay thế trực tiếp, cho phép chạy raylib ngay cả trên thiết bị hoàn toàn không có GPU

Tính năng chính

• Thực hiện render trên framebuffer nội bộ tùy chỉnh, hỗ trợ nhiều chế độ màu/độ sâu (RGB 8, 16, 24bit, Depth 8/16/24bit)
• Các chế độ render được hỗ trợ: điểm, đường, tam giác, quad
  • Có thể cấu hình thêm như độ dày điểm, độ rộng đường, chế độ polygon
  • Tất cả các chế độ render đều hỗ trợ clipping
• Tính năng texture: hỗ trợ tất cả định dạng không nén mà raylib hỗ trợ
  • Kiểm tra minification/magnification
  • Bộ lọc point/bilinear
  • Áp dụng chi tiết chế độ Wrap theo từng tọa độ S/T
• Hỗ trợ trực tiếp vertex array, cho phép vẽ primitive ngay lập tức
• Hỗ trợ stack ma trận (Push/Pop)
• Các chức năng khác: getter kiểu OpenGL, thay đổi kích thước framebuffer, hiệu chỉnh phối cảnh, scissor clipping, depth test, blend, cull face

Cách dùng và tuỳ chỉnh

• Có cấu trúc header & source đơn lẻ, cho phép tạo phần triển khai bằng #define RLSW_IMPLEMENTATION
• Hỗ trợ tuỳ biến theo người dùng bằng nhiều hằng cấu hình micro trước khi build
  • Ví dụ: điều chỉnh số lượng/kích thước tối đa của framebuffer hoặc texture

Cấu trúc và kiểu dữ liệu

• Định nghĩa nhiều enum và kiểu dữ liệu tương thích OpenGL, cùng các struct nội bộ (như sw_vertex_t, sw_texture_t, v.v.)
• Có thể ánh xạ phần lớn lời gọi OpenGL sang hàm của rlsw để thay thế
• Có cấu trúc quản lý trạng thái nội bộ chắc chắn cho nhiều ma trận, trạng thái và quản lý texture

Giấy phép và ứng dụng

• Với giấy phép MIT, có thể sử dụng cho mục đích thương mại, phi thương mại và tạo tác phẩm phái sinh
• Vì tập trung vào sự nhẹ và tính thay thế hoàn toàn bằng phần mềm hơn là tối ưu hiệu năng, nên có điểm mạnh cho việc tích hợp và triển khai dễ dàng

Tổng quan chi tiết

Cấu trúc header và giải thích

• rlsw gần như thay thế bằng phần mềm toàn bộ các chức năng OpenGL 1.1 theo cấp hàm
• Header này (rlsw.h) định nghĩa
  • kiểu giá trị, enum và struct tùy chỉnh
  • thay thế các lệnh OpenGL bằng macro thành các hàm nội bộ của rlsw
  • khai báo API (khởi tạo, sao chép/lấy framebuffer, draw, clear, nhập vertex/texture, v.v.)

Chức năng đại diện

• Hỗ trợ nội bộ nhiều stack ma trận (Projection/ModelView/Texture)
• Quản lý trạng thái render: thao tác bit trạng thái như Scissor, bật texture hoặc Depth Test
• Khả năng tương thích với OpenGL: nhiều getter, sao chép trạng thái, xử lý lỗi
• Xử lý texture: định dạng không nén, filter/wrap mode, sao chép bộ nhớ, v.v.
• Mặc định có thể xử lý phần lớn shape 2D/3D (điểm, đường, tam giác, quad) với xử lý màu và độ sâu

Giá trị cấu hình có thể tuỳ chỉnh

• Độ phân giải/kích thước và số lượng framebuffer/texture, bit-depth của buffer màu/độ sâu, độ sâu stack ma trận, tổng texture tối đa, v.v.
• Các điều chỉnh nâng cao như giá trị SW_MAX_CLIPPED_POLYGON_VERTICES

Thành phần cấu trúc nội bộ chính

• sw_context_t: bao gồm toàn bộ trạng thái và buffer của toàn context
• Bên trong quản lý tích hợp vertex buffer, texture array, framebuffer và các cờ trạng thái

Ưu điểm và trường hợp sử dụng

• Tối ưu cho thiết bị không có GPU, môi trường nhúng, CI cho porting/kiểm thử/phát triển tự động theo từng hệ điều hành
• Có thể chạy ứng dụng dựa trên raylib hoàn toàn bằng phần mềm ngay cả khi không có OpenGL
• Kiến trúc nhẹ nên rất thuận lợi cho thử nghiệm mới, phát triển và hỗ trợ môi trường không chuẩn

Giấy phép và người đóng góp

• MIT cho phép tái phân phối linh hoạt
• Được Le Juez Victor, Ramon Santamaria đánh giá (2025–2026)

Kết luận

• rlsw là trình kết xuất phần mềm thuần gần như tương thích hoàn toàn với OpenGL dành cho raylib
• Với cấu trúc đơn tệp, nhẹ, khả năng mở rộng và hỗ trợ đầy đủ tất cả định dạng texture của raylib, nó có rào cản tham gia thấp và tính tích hợp cao so với các giải pháp đồ họa phần mềm khác
• Đặc biệt có giá trị cho các dự án nhắm đến đồ họa mức thấp và tính di động

[GN⁺]

Ý kiến trên Hacker News

• Tác giả của Raylib đã rất vui mừng thông báo rằng có thể biên dịch toàn bộ chương trình raylib chỉ với ứng dụng win32, không cần phụ thuộc bên ngoài nào liên kết
  • Thật sự rất thú vị, tôi đang tìm thứ gì đó có thể render trên màn hình LED để nghịch với bộ xử lý nhúng, nhưng những gì tìm được cho đến nay đều chưa làm tôi hài lòng. Nếu tôi hiểu đúng, có vẻ tôi có thể biên dịch cái này để render bằng phần mềm; với kích thước khoảng 192x128 pixel của tôi thì có lẽ sẽ đủ nhanh trên bất kỳ hệ thống nào, vậy là đến lúc thử làm vài hoạt ảnh vui vẻ rồi
  • Win32 vốn đã có một bộ render phần mềm OpenGL 1.2 khá ổn
  • Tôi tự hỏi vì sao lại phải làm điều này
• Tôi tò mò Tsoding nghĩ gì về tin này
  • Chắc là giờ nó đã thành mainstream và lên cả HN rồi, nên Tsoding sẽ mất hứng thú
• Điều hay là máy tính giờ đã nhanh đến mức chỉ với thư viện render phần mềm OpenGL 1.1 kiểu này cũng có thể làm được một game 2D khá ổn
  • Nếu giữ độ phân giải thấp, quản lý cẩn thận độ phức tạp của cảnh và đưa ra quyết định rõ ràng về phong cách đồ họa, thì ngay cả phần cứng 20 năm trước cũng có thể chạy được một game 3D hợp lý. Tôi đã tự làm game để thử nghiệm1 2, và giờ khi biết điều này khả thi, tôi định làm game thứ hai "nghiêm túc" và hoàn thiện hơn. Đúng là có thể cảm nhận được máy tính đã mạnh lên rất nhiều. Tin về Raylib cũng thật sự rất hay, đến mức tôi đang cân nhắc dùng nó
  • Sửa: trước đó tôi không nhận ra đây là render bằng phần mềm. Dù vậy, có lẽ game của tôi vẫn render được trên CPU nếu chỉ dùng thuật toán sắp xếp độ sâu sprite tối ưu (kiểu pixel art isometric như RollerCoaster Tycoon). Trong dự án Metropolis 1998 lấy bối cảnh thập niên 90, tôi buộc phải dùng pipeline fixed function OpenGL cổ lỗ (may là tôi phát hiện ra có thể truyền thêm trường dữ liệu sang GPU bằng các hàm mở rộng trong file gl.h). Tôi đang dùng SFML làm framework đồ họa và có lẽ nó dựa trên OpenGL 1.x. Ví dụ hiện đại là game Metropolis 1998 cho thấy cách tiếp cận này có thể làm được những gì
  • Tôi nghĩ render phần mềm rốt cuộc mới là tương lai, với điều kiện là phải có khả năng tận dụng mạnh mẽ tăng tốc phần cứng theo kiểu GPGPU
  • Từ vài chục năm trước đã có Unreal Tournament 3D đầy đủ render bằng phần mềm rồi, và đến 2023 vẫn chạy tốt liên kết
• Fabrice Bellard cũng từng viết TinyGL liên quan đến OpenGL liên kết
  • Điều đáng kinh ngạc là TinyGL 0.4.1 ra mắt vào ngày 5 tháng 3 năm 2022, còn TinyGL 0.4 phát hành lần đầu vào ngày 17 tháng 3 năm 2002, đúng kiểu "kế hoạch phát triển của chúng tôi kéo dài qua nhiều thế kỷ"
  • Ông ấy thật sự là một hình mẫu đáng nể, gần như việc gì cũng làm được
  • Tôi đã thấy nhiều kiểu renderer phần mềm như thế này trong thập niên 90, nhưng nói thật là hồi đó chúng chậm, nặng hoặc đầy artifact nên không mấy ấn tượng. Muốn có hiệu năng thì game và renderer phải tích hợp rất chặt chẽ. Thật đúng là sự trớ trêu của lịch sử
  • Nhân tiện, còn có tinygl do C-Chads fork, được duy trì mới hơn nhiều so với bản gốc và có thêm đủ loại tính năng như multithreading, dù cuối năm 2023 đã bị archive
• Nhờ pikuma.com mà tôi nhận ra vẻ đẹp của renderer phần mềm, và tôi rất tự hào vì mình có thể hiểu được phần lớn mã nguồn của nó
• Khi thấy mô tả "OpenGL 1.1-style implementation on software", tôi bắt đầu tò mò muốn biết cần bao nhiêu dòng để hiện thực tới OpenGL 2.0 (bản không phải ES)
  • Ít nhất cũng phải nhiều hơn vài chục lần. Phần khó nhất là hiện thực shader lập trình được bởi người dùng (ARB assembly/GLSL), đồng thời cần viết parser GLSL và bộ thông dịch shader. Còn phải thêm multitexturing và nhiều loại texture combiner khác nữa. Tính tổng thể, dù ước lượng rất thấp thì tôi nghĩ cũng phải cần 40 nghìn dòng, tất nhiên nếu không làm hết spec mà chỉ làm tối thiểu thì có thể ít hơn
  • Trước đây tôi từng thật sự hiện thực OpenGL API cho phần cứng fixed function, làm tới bản 1.5 và có áp dụng một số extension như framebuffer object. Dòng 1.x có nhiều phần thừa thãi nhưng khá dễ hiện thực; còn dòng 2.x (sau khi có shader) thì cực kỳ khó làm bằng phần mềm
  • Tôi không biết chính xác số dòng, nhưng có PortableGL, một renderer phần mềm 3.x. Đây là một dự án rất tuyệt và cũng rất vui khi vọc thử
• Về cách nói OpenGL-style
  • Nếu chỉ nhìn vào header mà nói vậy thì xin chúc mừng, đây là một hiện thực phần mềm OpenGL 1.1 khá ổn. Dĩ nhiên nó không khớp toàn bộ spec, nhưng giống các driver MiniGL ngày xưa ở chỗ chỉ hiện thực những phần cần thiết để game chạy được. Dự án này cũng tương tự, chỉ hiện thực đủ để backend OpenGL của Raylib hoạt động, với mục tiêu có thể dùng mà không cần phụ thuộc đồ họa bên ngoài
• Không biết có hỗ trợ CUDA không
  • Không, đây là render hoàn toàn bằng CPU, thậm chí còn không dùng cả SIMD mà chỉ dùng mã trực tiếp dựa trên số nguyên/số thực
• Cái này có vẻ hợp hoàn hảo với Nintendo 3DS
  • Vậy không biết liệu nó có thể dùng để làm game cho các máy như NES, SNES, Genesis hay không