rayfork

C99 • Single Source • Plattformunabhängig • XNA-ähnlich • Allocator-aware • Game Dev Library

HIER HERUNTERLADEN • GITHUB-VORLAGE

Entstanden aus dem fantastischen Raylib-Game-Framework: https://www.raylib.com/

HINWEIS: Rayfork befindet sich noch in einem sehr frühen Entwicklungsstadium und es wird derzeit nicht empfohlen, es professionell zu verwenden.

Wie baut man

Rayfork verfügt nur über eine .c-Datei und ist nur von libc abhängig, was bedeutet, dass es einfach über die Befehlszeile als Bibliothek kompiliert werden kann.

 # -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

Prinzipien

1. Stellen Sie plattformunabhängigen Code bereit

Rayfork bietet keine Plattformschicht, das heißt, es erstellt kein Fenster, lädt OpenGL und erfasst keine Eingaben für Sie.

Dies ist beabsichtigt, sodass Sie Rayfork problemlos auf mehreren Plattformen (einschließlich Spielekonsolen) verwenden können, indem Sie die für Sie am besten geeignete Methode verwenden. Es gibt Vorlagen für die Verwendung von Rayfork mit GLFW-, SDL-, Sokol-App- und benutzerdefinierten Plattformebenen.

Der Renderer verfügt derzeit über OpenGL33- und OpenGL-ES3-Backends (weitere werden hinzugefügt), die portabel implementiert sind, sodass Rayfork auf jeder Plattform kompiliert werden kann, wobei die einzige Abhängigkeit libc ist. OpenGL-Procs werden explizit an Rayfork übergeben und es gibt ein einfaches Makro, das dabei hilft.

Dadurch können Sie Rayfork problemlos für jede Plattform kompilieren, sei es PC, Mobilgerät oder Konsolen.

2. Bieten Sie vollständige Kontrolle über E/A und Speicher

Funktionen, die IO ausführen, sind oft optional und fragen explizit nach IO-Rückrufen. Ein einfacher Wrapper für die libc-IO-Funktionen wird als rf_default_io bereitgestellt.

Funktionen, die explizit zuweisen, fragen nach einem Allokator und manchmal auch nach einem temporären Speicherzuteiler (Speicher, der innerhalb der Funktion freigegeben wird). Ein einfacher Wrapper für malloc/free von libc wird als rf_default_allocator bereitgestellt.

Alle Abhängigkeiten werden auch im Hinblick auf benutzerdefinierte Allokatoren verwendet. Die Bibliothek wird niemals ohne Ihr Wissen Zuweisungen vornehmen.

Jede Funktion, die einen Allocator oder io-Rückrufe erfordert, verfügt über eine _ez -Version, die die ursprüngliche Funktion umschließt und sie mit rf_default_allocator und/oder rf_default_io aufruft. Dies ist nützlich, um Code schnell zu testen.

3. Einfach zu bauen

Die Bibliothek besteht nur aus einer Header- und Quelldatei und kann zur Kompilierzeit mithilfe von Präprozessordefinitionen angepasst werden. Es sind keine zusätzlichen Kompilierungsflags erforderlich. Abhängig vom Grafik-Backend müssen Sie möglicherweise bestimmte Bibliotheken verknüpfen.

Begründung

Raylib wurde ursprünglich für Bildungszwecke entwickelt und hat sich im Laufe der Zeit zu einer sehr nützlichen Spielebibliothek entwickelt, ähnlich wie XNA.

Aufgrund seiner Beschaffenheit erschweren jedoch mehrere Designoptionen in Raylib die Verwendung für professionelle Spieleentwickler:

• Es ist schwierig, eine benutzerdefinierte Plattformebene zu verwenden (z. B. Verwendung einer benutzerdefinierten Plattformebene unter Android mit Android Studio).

• Schwer auf andere Plattformen zu portieren (z. B. iOS, Konsolen)

• Wenig Kontrolle über Speicherzuweisungen und io.

Rayfork wurde entwickelt, um diese Probleme zu lösen und die Entwicklung professioneller Spiele mithilfe der API von Raylib zu vereinfachen.

Ich habe dieses Projekt gestartet, weil ich Raylib und C99 liebe und mein Spiel unbedingt damit entwickeln wollte.

Viele Bibliotheken folgen jedoch nicht den Prinzipien, nach denen ich in einer Bibliothek suche (siehe diesen Artikel), was ihre Verwendung in Spielen schwierig/lästig macht. Deshalb möchte ich eine Bibliothek erstellen, die Indie-Entwickler sicher und einfach zur Entwicklung ihrer Projekte verwenden können ohne Einbußen bei Kontrolle, Portabilität oder Qualität.

Hilfe benötigt

Wenn Sie in der Lage sein möchten, Spiele einfach mit Bibliotheken zu entwickeln, die die oben genannten Prinzipien respektieren, denken Sie bitte über einen Beitrag zu Rayfork nach.

Sie können die Registerkarte „Probleme“ überprüfen und viele Dinge finden, die Sie tun können, um einen Beitrag zu leisten.

Ich suche auch Hilfe bei der Entwicklung von Dingen, die außerhalb meines Fachgebiets liegen:

• Verbesserung der Rendering-API
• Weitere Grafik-Backends (Sokol-GFX, Vulkan, benutzerdefinierte Konsolen-Backends)
• Ein Partikelsystem
• Physik
• Vernetzung

Ratschläge für Mitwirkende

• Kontaktieren Sie mich auf dem Raylib-Discord-Server im #rayfork-Kanal, ich bin @BananyaDev#0001, oder auf Twitter @SasLuca.

• Behalten Sie die Namenskonvention bei, um die Groß-/Kleinschreibung zu berücksichtigen, verwenden Sie rf_function_name für Schnittstellenfunktionen und _rf_function_name für private Funktionen.

• Stellen Sie allen Funktionen rf_public oder RF_INTERNAL voran

• Fügen Sie keine zusätzlichen Header in die Schnittstelle ein, sondern arbeiten Sie darauf hin, Includes im Allgemeinen zu minimieren.

• Verwenden Sie #pragma region #pragma endregion zum Falten von Codebereichen und erwägen Sie die Verwendung eines Editors mit Unterstützung für das Falten dieser Bereiche, um den Code leichter verstehen zu können.

• Versuchen Sie, die Ratschläge aus diesem Artikel allgemein anzuwenden. Einige der wichtigeren Ratschläge wären:

  • Weisen Sie keinen Speicher zu, sondern fragen Sie den Benutzer nach vertex_buffers/allocators.
  • Verwenden Sie keine nicht konstanten globalen Variablen.
  • Vermeiden Sie betriebssystemabhängige Funktionen.

Rayfork-Beispiel für iOS und Windows: