如何建造

rayfork 只有一個 .c 文件，並且只依賴 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

原則

rayfork 不提供平台層，這表示它不會為您建立視窗、載入 OpenGL 或擷取輸入。

這是設計使然，以便您可以使用最適合您的方法在多個平台（包括遊戲機）上輕鬆使用 rayfork。有一些模板可以將 rayfork 與 GLFW、SDL、sokol-app 和自訂平台層一起使用。

該渲染器目前具有 OpenGL33 和 OpenGL-ES3 後端（還有更多後端需要添加），這些後端以可移植的方式實現，允許 rayfork 在任何平台上編譯，唯一的依賴項是 libc。 OpenGL 程序明確傳遞給 rayfork，並且有一個簡單的巨集可以幫助實現這一點。

因此，您可以輕鬆地為任何平台（無論是 PC、行動裝置還是控制台）編譯 rayfork。

執行 IO 的函數通常是可選的，並且明確要求 IO 回呼。 libc IO 函數的簡單包裝器是作為rf_default_io提供。

明確分配的函數需要一個分配器，有時還需要一個臨時記憶體分配器（在函數內部釋放的記憶體）。 libc 的 malloc/free 的簡單包裝器是作為rf_default_allocator提供。

所有依賴項也都與自訂分配器一起使用，庫永遠不會在您不知情的情況下進行分配。

每個需要分配器或 io 回呼的函數都有一個_ez版本，它包裝原始函數並使用rf_default_allocator和/或rf_default_io呼叫它，這對於快速測試程式碼非常有用。

該函式庫只有一個頭檔和原始文件，可以在編譯時使用預處理器定義進行自訂。不需要額外的編譯標誌，具體取決於您可能需要連結到某些庫的圖形後端。

raylib 最初是為了教育目的而創建的，隨著時間的推移已經成熟為一個非常有用的遊戲庫，類似於 XNA。

然而，由於其性質，raylib 中的一些設計選擇使其難以被專業遊戲開發人員使用：

rayfork 旨在解決這些問題，並讓使用 raylib 的 API 輕鬆開發專業遊戲。

我開始這個專案是因為我喜歡 raylib 和 C99，我真的很想使用它們來開發我的遊戲。

然而，許多庫並不遵循我在庫中尋找的原則（請參閱本文），這使得在遊戲中使用它們變得困難/煩人，這就是為什麼我想創建一個庫，獨立開發人員可以自信地輕鬆地使用它來開發他們的項目無需犧牲控制性、便攜性或品質。

如果您希望能夠使用尊重上述原則的程式庫輕鬆開發遊戲，請考慮為 rayfork 做出貢獻。

您可以檢查問題選項卡並找到很多您可以做出貢獻的事情。

我也在尋求幫助來發展我的專業知識之外的東西：

請在 #rayfork 頻道的 raylib Discord 伺服器上聯絡我，我是 @BananyaDev#0001，或在 Twitter 上@SasLuca。
保持蛇形命名約定，對介面函數使用rf_function_name ，對私有函數使用_rf_function_name 。
所有函數都帶有rf_public或RF_INTERNAL前綴
不要在介面中包含額外的標頭，總體上盡量減少包含。
使用#pragma region #pragma endregion來折疊程式碼區域，並考慮使用支援折疊這些區域的編輯器，以便更輕鬆地掌握程式碼。
嘗試總體應用本文中的建議。一些更重要的建議是：
- 不要分配內存，向使用者詢問 vertex_buffers/allocators。
- 不要使用非常量全域變數。
- 避免依賴作業系統的函數。