rlsw – RaylibソフトウェアOpenGLレンダラー、LOC 5,000行未満

• 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スタイルのゲッター、フレームバッファリサイズ、透視補正, シザリングクリッピング, 深度テスト、ブレンド、カリング

使用とカスタマイズ

• 単一ヘッダ&ソース構造で、#define RLSW_IMPLEMENTATIONにより実装部を生成可能
• ビルド前に複数のマイクロ設定定数でユーザー任意のカスタマイズをサポート
  • 例: フレームバッファまたはテクスチャの最大数/サイズなどを調整可能

構造と型

• 複数のOpenGL互換enumと型、内部専用構造体(sw_vertex_t、sw_texture_tなど)を定義
• OpenGL呼び出しのほとんどをrlsw関数にリマップして代替利用可能
• 複数の行列、状態、テクスチャ管理などの内部状態管理構造が堅牢

ライセンスと活用

• MITライセンスで商用・非商用を問わず自由な利用や二次著作物制作が可能
• 性能より軽量化、完全ソフトウェア代替性に重点を置いているため、シンプルな統合とデプロイに強み

詳細サマリー

ヘッダ構造と説明

• rlswはOpenGL 1.1機能を関数単位でほぼすべてソフトウェアで置換する
• このヘッダ（rlsw.h）は次を定義
  • 値型、カスタムenumおよびstruct
  • マクロでOpenGL命令をrlsw内部関数に置換
  • API宣言部（初期化、フレームバッファコピー/取得、draw、clear、頂点/テクスチャ入力など）

主要機能

• 内部的に複数のスタックベース行列をサポート（Projection/ModelView/Texture専用）
• レンダリング状態管理: Scissor、テクスチャ有効化またはDepth Testなど状態ビット操作
• OpenGLとの互換機能: 各種getter、状態コピー、エラーハンドリング
• テクスチャハンドリング: 非圧縮フォーマット、フィルタ/ラップモード、メモリコピーなど
• 基本的にほとんどの2D/3D形状シェイプ（点、線、三角形、クアッド）およびカラー、深度処理が可能

カスタマイズ可能な設定値

• フレームバッファ/テクスチャ解像度と数、カラー/深度バッファ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⁺]

Hacker Newsの意見

• Raylibの作者が、外部依存なしでWin32アプリだけを使って raylib プログラム全体をコンパイルできると、とても喜んで発表していた リンク
  • とても興味深い話だ。組み込みプロセッサで遊び半分に使うため、LEDスクリーンに何かをレンダリングできるものを探していたが、これまで見つけたものはどれも満足できなかった。正しく理解しているなら、これをコンパイルしてソフトウェアレンダリングができそうだ。自分の 192x128 ピクセル程度のサイズなら、どんなシステムでも十分速そうなので、いよいよ面白いアニメーションを作る時間だ
  • Win32 には、すでにかなりまともな OpenGL 1.2 ソフトウェアレンダラーがある
  • なぜわざわざこれをやる必要があるのか気になる
• こういう話題について Tsoding の意見が気になる
  • たぶんもうメインストリームになって HN にまで上がってきたので、Tsoding は興味を失うだろう
• コンピュータが非常に高速になったおかげで、この種のソフトウェアレンダリング OpenGL 1.1 ライブラリだけでも、かなり decent な 2D ゲームを作れるというのがすごい
  • 解像度を低く保ち、シーンの複雑さを意識して管理し、アートスタイルについて割り切った判断をすれば、20年前のハードウェアでも動く妥当な 3D ゲームを作ることはできた。実際、試しに自分でゲームを作ってみたことがある 1 2。これが可能だと分かった今、もっと「本気」の完成度が高い2本目のゲームを作るつもりだ。コンピュータ性能の大きな向上を感じるし、Raylib のニュースも本当に素晴らしく、実際に導入を検討している
  • 修正: これがソフトウェアレンダリングだとは分かっていなかった。それでも、CPU 上で最適なスプライト深度ソートアルゴリズムだけを使えば、自分のゲームもレンダリングできそうだ（RollerCoaster Tycoon のようなアイソメトリック・ピクセルアート方式）。90年代の Metropolis 1998 プロジェクトでは、古代の OpenGL fixed function パイプラインを使わなければならなかった（幸い、gl.h ファイルで拡張関数として追加フィールドを GPU に渡せることを見つけた）。グラフィックフレームワークとして SFML を使っていて、おそらく OpenGL 1.x ベースだ。最近の例では、Metropolis 1998 というゲームが、このアプローチで何ができるかを示している
  • 結局のところ、ソフトウェアレンダリングこそ未来だと思う。ただし条件があって、GPGPU のようにハードウェアアクセラレーションを積極的に活用できることが必要だ
  • 何十年も前に、すでにソフトウェアでレンダリングされたフル 3D の Unreal Tournament があった。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（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 のようなコンソール向けゲーム制作にも活用できるのか気になる