ハクソク

世界を動かす技術を、日本語で。

Raylib v6.0

15時間前原文(github.com)

概要

raylib 6.0は、過去最大規模のアップデートとしてリリースされました。
新しいソフトウェアレンダラーや複数の新規プラットフォームバックエンドが追加されました。
フルスクリーン・高DPI対応やスケルタルアニメーションの再設計が行われています。
ファイルシステムAPIとテキスト管理APIも刷新され、より一貫性のある設計になりました。
多くの新機能・最適化・修正が加えられ、将来の拡張性も強化されています。

raylib 6.0 リリースハイライト

  • 330件以上のIssueクローズ、合計2150件超
  • 2000以上のコミット、累計9760コミット
  • APIに20の新関数追加、合計600関数
  • 70の新しいサンプル追加、合計215以上
  • 210名の新規コントリビューター参加、合計850名超

新機能・主要変更点

新ソフトウェアレンダラー: rlsw

  • CPUのみで動作可能なソフトウェアレンダラーの新実装
    • GPU不要、CPUとRAMさえあれば動作
    • Le Juez Victor（@Bigfoot71）によるOpenGL 1.1+互換の単一ヘッダーライブラリ
    • ユーザー側のコード変更不要で切り替え可能
    • 30-60fpsの基本アプリケーション動作を実現
    • ESP32やRISC-Vデバイス等、GPU非搭載機器への展開可能性
    • SDL、RGFW、DRM等の既存バックエンドも対応
    • **新規プラットフォームバックエンド（Win32, Emscripten, PLATFORM_MEMORY）**も追加

新プラットフォームバックエンド

  • Memory（rcore_memory）

    • プラットフォーム非依存のメモリフレームバッファへの2D/3D描画
    • ヘッドレス動作やイメージ出力用途
    • サーバー上での画像処理やグラフィックスレンダリングにも有用

  • Win32（rcore_desktop_win32）

    • GLFW/SDL/RGFWの代替候補となるWindows専用バックエンド
    • Win32 APIを直接実装、OpenGLウィンドウ/GDIウィンドウ両対応
    • コードの保守性・可読性・移植性向上
    • 現状は実験的扱い、今後のテスト・改善予定

  • Emscripten（rcore_web_emscripten）

    • libglfw.js依存を排除し、Emscripten/JSを直接実装
    • ソフトウェアレンダラーによる非GPUキャンバス描画とWebGL対応
    • こちらも実験的扱い

フルスクリーン・高DPI対応の再設計

  • ボーダーレスフルスクリーンを優先
  • マルチモニター・4K解像度・各OSでの動作確認済み
  • ユーザーが明示的に高DPIを有効化可能（FLAG_WINDOW_HIGHDPI）
  • ウィンドウ・フレームバッファのスケーリング自動化

スケルタルアニメーションシステムの刷新

  • アニメーションブレンディング対応
    • 異なるアニメーション間のスムーズな遷移・タイミング調整
  • Model, ModelSkeleton, ModelAnimation等の構造体を見直し
  • APIの簡素化とGPUスキニングの最適化

ビルド設定システムの再設計（config.h）

  • ビルド時の機能無効化がコマンドラインで簡単に（例: -DSUPPORT_FILEFORMAT_OBJ=0）
  • 不要なフラグ削除、新しいフラグ追加
  • ビルドシステムの簡素化

新ファイルシステムAPI

  • ファイル管理機能を一つのモジュール（rcore）に統合
  • utilsモジュール廃止、ビルド対象モジュール数削減
  • 40以上のファイル管理関数を提供
    • ファイルのロード/アンロード、保存、リネーム、削除、コピー、移動
    • テキスト検索・置換、ファイル/ディレクトリ存在確認
    • 拡張子・パス・ディレクトリ操作、ドロップファイル対応
    • ディレクトリ内ファイル数の取得、フィルタリング等

新テキスト管理API

  • 30以上のテキスト操作関数を追加
    • テキストの行分割・解放、コピー、比較、長さ取得、整形
    • 部分文字列抽出、スペース除去、文字列置換
    • テキスト間抽出、置換、フォーマット等
    • 内部バッファ利用のため、返却値はユーザー側で保持推奨

今後の展望・注意点

  • 新バックエンド（Win32/Emscripten）は実験的、今後さらなるテスト・改善予定
  • ソフトウェアレンダラーの導入で、より幅広いデバイス対応が可能
  • API・ビルドシステムの統一・簡素化により、今後の拡張性強化
  • 多くのコントリビューター・利用者からのフィードバックを歓迎

まとめ

  • raylib 6.0は、新機能・最適化・拡張性で大幅進化
  • 幅広いプラットフォーム・用途に対応する基盤を確立
  • 今後の更なる発展に向けた重要なリリース

Hackerたちの意見

新しいソフトウェアレンダラー、めっちゃかっこいいね。ESP32S3で試してみなきゃ！
└
どのディスプレイのことを話してるの？数年ESPに触れてないけど、これをきっかけに引っ張り出してみるのも楽しそう。
いやー、めっちゃワクワクしてる！raylibのおかげで、プログラミングが本当に楽しくなってきたし、完成と呼べるプロジェクトもいくつか作れたんだ。小さいけどね。
今、swiftでraylibを使ってローグライクゲームを作ってるんだけど、すごく楽しいよ。
└
もっと情報ちょうだい。
まだUnreal EngineやUnityが必要なのかな？もし必要なら、raylibが足りない部分って何だろう？初心者のゲーム開発者だから、優しく教えてね。
└
両者のスコープや機能セットはかなり広いよ。IDEから1stパーティーや3rdパーティーのライブラリや拡張機能のエコシステムまで。レンダリングエンジンやその能力もかなり違うし（UnrealとUnityはどちらもかなり進んでる）。
└
Raylibはエンジンというより、低レベルのランタイムライブラリって感じ。GodotやUnity、Unrealなんかは、ゲーム制作のためのインタラクティブなツールがすごく充実してる。現代のエンジンは、インタラクティブなコンテンツ編集や開発プロセスでのコラボレーションが中心になってる。これが大きなチームでのゲーム開発には必須で、内部の複雑さも増えるんだ。
└
これらのエンジンは、Raylibのようなライブラリとは違う目的を持ってる。ライティングやレイトレーシング（特にUnreal）、パスファインディング、ゲーム制作に使うたくさんのヘルパー関数が最初から用意されてる。Raylibは、ものを描いたり音を鳴らしたり、基本的なことを手助けしてくれる。でも、自分でライティングやレイトレーシング、パスファインディングなどの関数を書くことになるから、結局時間がかかるよ。逆に、すごくユニークなことをしたいなら、Raylibはゲームロジックやパッケージの仕方にこだわらないから、実現するための力は自分の手の中にある。結果をユーザーに届ける配達人みたいなもんだね。
└
オープンソースプロジェクトがUnrealやAAA向けのハイエンド技術と競えるとは思わないけど、それを超えてRaylibはエンジンが持ってるような機能をたくさん提供してるわけじゃないんだよね。これは、自分の好きなようにエンジンを作るためのものだから。UnrealやUnity、Godotなんかは、基本的な機能を作るための手間を省くために、ある程度のコントロールや選択肢を手放すことを許してくれる。
└
Raylibは、すべてをコントロールしたいけど、DirectXやOpenGLの面倒を避けたい趣味の人向けだね。UnrealやUnityとは全然競争してないよ。
└
Unreal、Unity、Godotみたいなエンジンは、ゲームエンジンを作るよりもゲームを作ることに興味がある人に人気が残ると思う。> もしそうなら、Raylibが欠けているものは何？ アセット管理やインポートパイプライン、レンダリングパイプライン、環境やベイクドライティング、グローバルイルミネーション、AO、反射、パーティクルシステム、入力マッピングやイベント伝播、スクリプト、オーディオシステム、GUIシステムなど、たくさんの即使用可能な機能がある。Raylibはそれらを作るために使えるライブラリだけど、完全なゲームエンジンではない。ゲームエンジンが必要ないなら、必要な機能を正確に知っていて、それだけを作りたいならRaylibは素晴らしい選択肢だよ。グローバルイルミネーションシステムやアセット管理パイプラインを作りたくないなら、ゲームプレイの創造に集中するためにゲームエンジンが良い選択だね。
└
Raylibは基本的にグラフィックスを描くだけ。UnityやUnrealは、ほとんどのゲームが必要とする機能を全部持ってて、巨大なエコシステムがあるよ。例えば、Unityには物理、ナビゲーション、アセット管理、入力処理、ビルドシステム、音声処理などが組み込まれてる。Unrealもそれに加えてもっとあるかも。Godotもそこに近づいてるけど、まだ成長痛があるね。大きなプロジェクトになると、ちょっと変なことになる。
これ、めっちゃすごい！グラフィックスプログラミングはやったことないし、Raylibの経験もないけど（プロジェクトの進展も追ってないし）、この数ヶ月でCを学び始めるきっかけになったよ。自分のゼロ依存のソフトウェアレンダラーを作り始めたんだ（背景を色付けして、回転する2Dの長方形を描画するだけだけど）。今日の後でrlswのソースコードをじっくり見てみるのが楽しみ！
Raylibで遊びたいならOdinをおすすめするよ。[0] プロトタイピングには最適だけど、今後の開発がどうなるかはわからないな。それはまだ見極めないと。 [0] https://odin-lang.org/
└
Raylibに関してオーディンの何が特別なの？（本当に気になる）
└
RaylibはGodotと似たような機能的なニッチを満たしてると思う…使いやすさやインターフェースについては言ってないよ。長い間、Godotは中規模から大規模な3Dリリースには準備が整ってなかったけど、今は変わりつつある。ただ、基本的にどちらも信頼性が高くて、2Dゲームをリリースするには全然問題ないよ。スキンメッシュを使った3DゲームがRaylibの範囲に入るかは、ちょっと疑問だね。そうは思えない。
GolangとRaylibでゲームを作ったことがあって、めっちゃ楽しかったよ。ゲームエンジンを使いたくないけど、完全にゼロから作りたくもない人にとっては完璧なバランスだね。開発者に多くのことを任せつつ、プラットフォーム特有の面倒なことはほとんど処理してくれる。超おすすめ！
Raylibを試してみたら大好きになったけど、（ほとんどのゲームフレームワークのように）多くをゼロから作る必要があるんだ。でも、エンジンはあまり好きじゃなくて、GUIよりコードでゲームを作るのが好きなんだ。今はvectarineというフレームワーク/エンジンのハイブリッドを作っていて、コードでゲームを作りながら、ホットリロードや統合デバッグ、アセット管理などのエンジンの便利な機能も楽しんでるよ。[1] https://github.com/vanyle/vectarine
リリースから6時間以上経ったのに、まだtsodingのスピードランがないんだね。
Raylibについての残念な点は、テキストオブジェクトの概念がないことだよ。テキストが多いシーン（速いペースのゲームでのダメージテキストやUI要素がたくさんある時）では、テキストを描画する際にフォントのグリフ関連の計算に時間を取られちゃうんだ。