構築方法

rayfork には .c ファイルが 1 つだけあり、libc にのみ依存します。つまり、コマンドラインからライブラリとして簡単にコンパイルできます。

 # -c compiles the code as a library
# -EHsc disables exceptions on msvc

gcc -c rayfork.c
clang -c rayfork.c
cl -c -EHsc rayfork.c

原則

1. プラットフォームに依存しないコードを提供する

rayfork はプラットフォーム層を提供しません。つまり、ウィンドウの作成、OpenGL のロード、入力のキャプチャは行われません。

これは仕様によるもので、最適な方法を使用して複数のプラットフォーム (ゲームコンソールを含む) で rayfork を簡単に使用できるようにします。 GLFW、SDL、sokol-app、およびカスタムプラットフォームレイヤーで rayfork を使用するためのテンプレートがあります。

現在、レンダラーには OpenGL33 および OpenGL-ES3 バックエンド (さらに追加予定) があり、これらはポータブルな方法で実装されており、libc のみの依存関係で rayfork を任意のプラットフォームでコンパイルできるようになります。 OpenGL プロシージャは明示的に rayfork に渡され、これを支援する単純なマクロがあります。

このため、PC、モバイル、コンソールなど、あらゆるプラットフォーム向けに rayfork を簡単にコンパイルできます。

2. IO とメモリを完全に制御する

IO を実行する関数は多くの場合オプションであり、明示的に IO コールバックを要求します。 libc IO 関数の単純なラッパーは、 rf_default_ioとして提供されます。

明示的に割り当てる関数は、アロケータを要求しますが、場合によっては一時メモリアロケータ (関数内で解放されるメモリ) も要求します。 libc の malloc/free の単純なラッパーがrf_default_allocatorとして提供されています。

すべての依存関係もカスタムアロケーターを念頭に置いて使用され、ライブラリが知らないうちに割り当てられることはありません。

アロケータまたは io コールバックを必要とするすべての関数には、元の関数をラップし、 rf_default_allocatorおよび/またはrf_default_ioで呼び出す_ezバージョンがあります。これは、コードを迅速にテストするのに役立ちます。

3. 構築が簡単

ライブラリは 1 つのヘッダーファイルとソースファイルだけであり、プリプロセッサ定義を使用してコンパイル時にカスタマイズできます。グラフィックバックエンドによっては、特定のライブラリにリンクする必要がある場合がありますが、追加のコンパイルフラグは必要ありません。

理論的根拠

raylib は、当初は教育目的で作成されましたが、時間の経過とともに、XNA に似た非常に便利なゲームライブラリに成長しました。

ただし、その性質上、raylib にはいくつかの設計上の選択肢があるため、プロのゲーム開発者にとっては使用が困難です。

カスタムプラットフォームレイヤーを使用するのが難しい (例: Android Studio を使用して Android 上のカスタムプラットフォームレイヤーを使用する)
他のプラットフォーム (例: iOS、コンソール) への移植が困難
メモリ割り当てと IO をほとんど制御できません。

rayfork は、これらの問題に対処し、raylib の API を使用してプロ仕様のゲームを簡単に開発できるように設計されています。

私がこのプロジェクトを始めたのは、raylib と C99 が大好きで、それらを使用してゲームを開発したかったからです。

しかし、多くのライブラリは、私がライブラリに求めている原則 (この記事を参照) に従っていないため、ゲームでライブラリを使用するのが難しく、煩わしくなります。そのため、インディー開発者がプロジェクトの開発に自信を持って簡単に使用できるライブラリを作成したいと考えています。コントロール、携帯性、品質を犠牲にすることなく。

助けが必要です

上記の原則を尊重するライブラリを使用してゲームを簡単に開発できるようにしたい場合は、rayfork へのコントリビュートを検討してください。

「問題」タブをチェックすると、貢献できることがたくさん見つかります。

また、自分の専門分野以外の開発に関する支援も求めています。

レンダリングAPIの改善
追加のグラフィックスバックエンド (sokol-gfx、vulkan、カスタムコンソールバックエンド)
パーティクルシステム
物理
ネットワーキング

寄稿者へのアドバイス

raylib discord サーバーの #rayfork チャンネル、私は @BananyaDev#0001 、または Twitter の @SasLuca までご連絡ください。
スネークケースの命名規則を維持し、インターフェイス関数にはrf_function_nameを使用し、プライベート関数には_rf_function_name使用します。
すべての関数の前にrf_publicまたはRF_INTERNALを付けます
インターフェイスに追加のヘッダーを含めず、一般にインクルードを最小限に抑えるように努めてください。
コードの領域を折りたたむには#pragma region #pragma endregionを使用し、コードをより簡単に把握できるように、これらの領域の折りたたみをサポートするエディターの使用を検討してください。
この記事のアドバイスを一般的に適用してみてください。より重要なアドバイスとしては次のようなものがあります。
- メモリを割り当てず、ユーザーに vertex_buffers/allocators を要求してください。
- 定数以外のグローバル変数は使用しないでください。
- OSに依存する機能は避けてください。