▲

rlsw – Raylib 소프트웨어 OpenGL 렌더러, 5천 줄 미만 LOC

 (github.com/raysan5)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • rlsw는 OpenGL 1.1 스타일의 소프트웨어 렌더러로, GPU가 없는 환경에서 raylib을 실행할 수 있는 대체 백엔드 제공
  • 포인트, 라인, 삼각형, 쿼드 등 다양한 랜더링 모드와 클리핑, 텍스처, 다중 컬러/깊이 버퍼 등 폭넓은 기능 지원
  • 텍스처는 raylib이 지원하는 모든 비압축 포맷 사용 가능하며, 필터링 및 래핑 설정도 세밀하게 제어 가능
  • 행렬 스택, 깊이 테스트, 블렌드, 컬 페이스 등 주요 3D 그래픽스 기능 내장, OpenGL 함수 바인딩 활용으로 호환성 극대화
  • 규모는 5천 라인 이하로, 성능과 경량화 면에서 다른 소프트웨어 렌더러 대비 단순함과 통합성에 강점 존재

rlsw: Raylib 소프트웨어 OpenGL 렌더러 개요

소개

  • rlsw는 OpenGL 1.1 스타일의 소프트웨어 렌더러로, raylib의 rlgl.h에서 제공하는 기능 전체를 소프트웨어로 구현한 라이브러리임
  • GPU가 아예 없는 디바이스에서도 raylib을 실행할 수 있도록 하는 직접 대체 백엔드로 설계됨

주요 기능

  • 커스텀 내부 프레임버퍼에 랜더링 수행, 다양한 컬러/깊이 모드(RGB 8, 16, 24bit, Depth 8/16/24bit) 지원
  • 지원 랜더링 모드: 포인트, 라인, 삼각형, 쿼드
    • 포인트 두께, 라인 너비, 폴리곤 모드 등 추가 렌더링 세부 설정 가능
    • 모든 랜더링 모드는 클리핑 지원
  • 텍스처 기능: raylib에서 지원하는 모든 비압축 포맷 지원
    • 미니피케이션/매그니피케이션 체크
    • 포인트/바이리니어 필터링
    • S/T 좌표별 Wrap 모드 세분 적용
  • 버텍스 배열 직접 지원, 원시 그리기 바로 가능
  • 매트릭스 스택(Push/Pop) 지원
  • 기타 기능: OpenGL 스타일 getter, 프레임버퍼 리사이즈, 원근 보정, 시저 클리핑, 깊이 테스트, 블렌드, 컬 페이스

사용 및 커스터마이징

  • 단일 헤더 & 소스 구조로 되어 있으며, #define RLSW_IMPLEMENTATION을 통해 구현부 생성 가능
  • 빌드 전에 복수의 마이크로 설정 상수로 사용자 임의 커스터마이징 지원
    • 예: 프레임버퍼 또는 텍스처 최대 개수/사이즈 등 조정 가능

구조 및 타입

  • 여러 OpenGL 호환 enum과 타입, 내부 전용 구조체(sw_vertex_t, sw_texture_t 등) 정의
  • OpenGL 호출 대부분을 rlsw 함수로 리맵하여 대체 사용 가능
  • 여러 가지 매트릭스 및 상태, 텍스처 관리 등 내부 상태 관리 구조 견고

라이선스 및 활용

  • MIT 라이선스로 자유로운 상용, 비상용 활용 및 2차 저작물 제작 가능
  • 성능보다 경량화, 완전 소프트웨어 대체 성격에 중점이 있어 간편 통합 및 배포에 강점

상세 요약

헤더 구조 및 설명

  • rlsw는 OpenGL 1.1 기능을 함수 단위로 거의 모두 소프트웨어로 대체함
  • 본 헤더(rlsw.h)는 다음을 정의
    • 값 타입, 커스텀 enum 및 struct
    • 매크로로 OpenGL 명령어를 rlsw 내부 함수로 치환
    • API 선언부 (초기화, 프레임버퍼 복사/획득, draw, 클리어, 버텍스/텍스처 입력 등)

대표 기능

  • 내부적으로 여러 스택 기반 매트릭스 지원 (Projection/ModelView/Texture 전용)
  • 랜더 상태 관리: Scissor, 텍스처 활성 또는 Depth Test 등 상태 비트 조작
  • OpenGL과의 호환 기능: 다양한 getter, 상태 복사, 에러 핸들링
  • 텍스처 핸들링: 비압축 포맷, 필터/랩 모드, 메모리 복사 등
  • 기본적으로 대부분의 2D/3D형 shape(점, 선, 삼각형, 쿼드) 및 컬러, 깊이 처리 가능

커스터마이즈 가능한 설정값

  • 프레임버퍼/텍스처 해상도 및 개수, 컬러/깊이 버퍼 bit폭, 매트릭스 스택 깊이, 최대 텍스처 갯수 등
  • SW_MAX_CLIPPED_POLYGON_VERTICES 값 등 고급 사용자 조정 가능

내부 구조체 주요 요소

  • sw_context_t : 전체 컨텍스트 모든 상태 및 버퍼 포괄
  • 내부적으로 vertex buffer, texture array, framebuffer, 상태 플래그 등 통합 관리

장점 및 활용처

  • GPU 없는 기기, 임베디드 환경, OS별 이식/테스트/개발 자동화 등에 최적화
  • OpenGL 없이도 raylib 기반 앱을 풀 소프트웨어만으로 구동 가능
  • 경량화 구조로 새로운 실험/개발, 비표준 환경 지원에 매우 유리함

라이선스 및 기여자

  • MIT로의 유연한 재배포 허용
  • 2025–2026 Le Juez Victor, Ramon Santamaria 리뷰

결론

  • rlsw는 OpenGL과 거의 완전 호환되는 raylib용 Pure Software Renderer임
  • 단일 파일, 경량, 확장성, raylib 전체 텍스처 포맷 지원 등에서 다른 소프트웨어 그래픽스 솔루션 대비 진입장벽과 통합성 모두 뛰어남
  • 로우레벨 그래픽스 및 이식성 목표 프로젝트에서 특히 가치 큼
▲
GN⁺ 9시간전  [-]
Hacker News 의견
  • Raylib의 저자가 외부 의존성 없이 오직 win32 앱만으로 전체 raylib 프로그램을 컴파일할 수 있다고 아주 기쁘게 발표한 소식임 링크
    • 정말 흥미로운 이야기임, 임베디드 프로세서로 재미삼아 사용하려고 LED 스크린에서 뭔가를 렌더링할 수 있는 것을 찾고 있었음, 지금까지 찾은 것들은 다 만족스럽지 않았음, 만약 제대로 이해했다면, 이걸 컴파일해서 소프트웨어 렌더링을 할 수 있을 것 같음, 내 192x128 픽셀 정도 사이즈에선 어떤 시스템에서도 충분히 빠를 것 같으니 이제 재미있는 애니메이션을 만들어볼 시간임
    • Win32에는 이미 꽤 괜찮은 opengl 1.2 소프트웨어 렌더러가 있음
    • 왜 굳이 이렇게 해야 하는지 궁금함
  • 이런 소식에 대해 Tsoding의 의견이 궁금함
    • 아마도 이제는 메인스트림이 되어 HN까지 올라왔으니 Tsoding은 흥미를 잃을 것 같음
  • 컴퓨터가 워낙 빨라서 이러한 소프트웨어 렌더링 OpenGL 1.1 라이브러리만으로도 꽤 괜찮은 2D 게임을 만들 수 있다는 점이 멋짐
    • 해상도를 낮게 유지하고, 씬 복잡성을 신경써서 관리하며 아트 스타일에 대해 결단을 내린다면, 20년 전 하드웨어에서도 돌아가는 합리적인 3D 게임을 만들 수 있었음, 실제로 직접 실험 삼아 게임을 만들었으며1 2, 이제 이게 된다는 걸 알게 되어 더 "진지하고" 완성도 높은 두 번째 게임을 만들 계획임, 컴퓨터 성능이 많이 향상된 점을 느낌, Raylib 소식도 정말 멋진 소식이라 실제로 도입을 고민 중임
    • 수정: 이게 소프트웨어 렌더링이라는 점을 몰랐었음, 그래도 CPU에서 최적의 스프라이트 깊이 정렬 알고리즘만 이용하면 내 게임도 렌더링 가능할 것 같음(롤러코스터 타이쿤처럼 이소메트릭 픽셀 아트 방식임), 90년대 메트로폴리스 1998 프로젝트에선 고대 OpenGL fixed function 파이프라인을 사용해야 했음(다행히 gl.h 파일에서 확장 함수로 추가 필드를 GPU로 전달할 수 있다는 걸 발견했음), SFML을 그래픽 프레임워크로 사용중이며 아마도 OpenGL 1.x 기반임, 최신 사례로는 Metropolis 1998 게임이 이러한 접근 방식이 어떤 걸 할 수 있는지 보여줌
    • 소프트웨어 렌더링이 결국 미래라고 생각함, 단 조건이 있다면 바로 GPGPU처럼 하드웨어 가속을 적극적으로 활용할 수 있어야 한다는 점임
    • 수십 년 전에 이미 소프트웨어로 렌더링한 풀 3D 언리얼 토너먼트가 있었음, 2023년에도 잘 동작함 링크
  • Fabrice Bellard가 OpenGL 관련 TinyGL도 작성했었음 링크
    • 놀라운 점은 (2022년 3월 5일) TinyGL 0.4.1이 나왔고 (2002년 3월 17일) TinyGL 0.4가 처음 출시되었다는 것임, "우리의 개발 계획은 수세기에 걸쳐 진행됨"
    • 저 사람은 거의 모든 걸 다 해내는 정말 대단한 롤모델임
    • 90년대에 이런 류의 소프트웨어 렌더러를 많이 봤는데, 솔직히 그때는 느리고 무겁거나 아티팩트가 많이 생겨서 별로였음, 퍼포먼스를 위해서는 게임과 렌더러의 긴밀한 통합이 필요했었음, 역사의 아이러니를 느낌
    • 참고로 C-Chads가 포크해서 만든 tinygl도 있음, 원본보다 훨씬 최근까지 관리되었고 멀티스레딩 등 다양한 기능이 추가됨, 다만 2023년 말에 아카이브되었음
  • pikuma.com 덕분에 소프트웨어 렌더러의 아름다움을 알게 되었고 대부분의 코드를 이해할 수 있었다는 점에 매우 뿌듯함
  • "OpenGL 1.1-style implementation on software"라는 설명을 보고 OpenGL 2.0(Non ES 버전)까지 구현하려면 몇 줄이 필요한지 궁금증이 듦
    • 최소 수십 배는 많아짐, 사용자 프로그래머블 셰이더(ARB 어셈블리/GLSL) 구현이 가장 어렵고, GLSL 파서와 셰이더 인터프리터 구현도 필요함, 멀티텍스처링과 다양한 텍스처 콤바이너 등도 추가해야 함, 전체적으로 아주 낮게 잡아도 4만 줄은 필요하다고 생각함, 물론 스펙을 다 구현하지 않고 최소만 하면 그보다 줄일 수도 있음
    • 예전에 실제로 fixed function 하드웨어용 OpenGL API 구현했던 적이 있는데 1.5 버전까지 구현하고 프레임버퍼 오브젝트 같은 익스텐션 일부 적용함, 1.x대는 쓸데없는 부분이 많지만 구현은 쉬움, 2.x대(셰이더 도입)는 소프트웨어로 구현하기 무척 힘듦
    • 정확한 줄 수는 모르겠지만 PortableGL이라는 3.x 소프트웨어 렌더러도 있음, 굉장히 멋지고 만져보기에도 재미있는 프로젝트임
  • OpenGL-style이라는 말에 대해서
    • 헤더만 보고 이야기하는 거면 축하함, 꽤 괜찮은 OpenGL 1.1 소프트웨어 구현임, 물론 전체 스펙을 다 맞추진 못하지만 예전 MiniGL 드라이버처럼 게임이 돌아갈 만큼만 필요한 부분만 구현한 형태임, 이 프로젝트도 비슷하게 Raylib의 OpenGL 백엔드가 돌아갈 정도만 구현함, 외부 그래픽스 의존성 없이 쓸 수 있도록 하려는 목적임
  • 혹시 CUDA 지원하는지 궁금함
    • 아니고, 오로지 CPU 렌더링임, SIMD조차 사용하지 않고 직접적인 정수/실수 기반 코드만 사용함
  • 이거 Nintendo 3DS에 완벽하게 어울릴 것 같음
    • 그럼 NES, SNES, Genesis 같은 콘솔 게임 제작에도 활용할 수 있을지 궁금함
답변달기