fourchette à rayons
1.0.0
Issu du superbe framework de jeu Raylib : https://www.raylib.com/
AVIS : rayfork est encore en cours de développement et il n'est pas recommandé de l'utiliser de manière professionnelle pour le moment.
rayfork n'a qu'un seul fichier .c et ne dépend que de la libc, ce qui signifie qu'il peut être facilement compilé en tant que bibliothèque à partir de la ligne de commande.
# -c compiles the code as a library
# -EHsc disables exceptions on msvc
gcc -c rayfork.c
clang -c rayfork.c
cl -c -EHsc rayfork.crayfork ne fournit pas de couche de plate-forme, ce qui signifie qu'il ne créera pas de fenêtre, ne chargera pas OpenGL ou ne capturera pas d'entrée pour vous.
Ceci est intentionnel, afin que vous puissiez facilement utiliser rayfork sur plusieurs plates-formes (y compris les consoles de jeux) en utilisant la méthode qui vous convient le mieux. Il existe des modèles pour utiliser Rayfork avec les couches de plate-forme GLFW, SDL, sokol-app et personnalisées.
Le moteur de rendu dispose actuellement de backends OpenGL33 et OpenGL-ES3 (avec d'autres à ajouter) qui sont implémentés de manière portable, ce qui permet à rayfork d'être compilé sur n'importe quelle plate-forme, la seule dépendance étant la libc. Les procédures OpenGL sont transmises explicitement à Rayfork et il existe une macro simple pour vous aider.
Pour cette raison, vous pouvez facilement compiler Rayfork pour n'importe quelle plate-forme, qu'il s'agisse d'un PC, d'un mobile ou d'une console.
Les fonctions qui effectuent des IO sont souvent facultatives et demandent explicitement des rappels IO. Un simple wrapper pour les fonctions IO de la libc est fourni sous la forme rf_default_io .
Les fonctions qui allouent explicitement demandent un allocateur et parfois aussi un allocateur de mémoire temporaire (mémoire libérée à l'intérieur de la fonction). Un simple wrapper pour malloc/free de la libc est fourni sous la forme rf_default_allocator .
Toutes les dépendances sont également utilisées avec des allocateurs personnalisés à l'esprit, la bibliothèque n'attribuera jamais sans que vous le sachiez.
Chaque fonction qui nécessite un allocateur ou des rappels io a une version _ez qui encapsule la fonction d'origine et l'appelle avec rf_default_allocator et/ou rf_default_io , ceci est utile pour tester rapidement le code.
La bibliothèque n'est qu'un seul fichier d'en-tête et source et peut être personnalisée au moment de la compilation à l'aide des définitions du préprocesseur. Aucun indicateur de compilation supplémentaire n'est nécessaire, en fonction du backend graphique que vous devrez peut-être lier à certaines bibliothèques.
Raylib a été créé initialement à des fins éducatives et est devenu au fil du temps une bibliothèque de jeux très utile, similaire à XNA.
Cependant, en raison de sa nature, plusieurs choix de conception dans Raylib rendent son utilisation difficile pour les développeurs de jeux professionnels :
Difficile d'utiliser une couche de plateforme personnalisée (par exemple : utiliser avec une couche de plateforme personnalisée sur Android avec Android Studio)
Difficile de porter sur d'autres plateformes (ex : iOS, consoles)
Peu de contrôle sur les allocations de mémoire et les io.
rayfork est conçu pour résoudre ces problèmes et faciliter le développement de jeux professionnels à l'aide de l'API de raylib.
J'ai commencé ce projet parce que j'adore Raylib et C99 et je voulais vraiment développer mon jeu en les utilisant.
Cependant, de nombreuses bibliothèques ne suivent pas les principes que je recherche dans une bibliothèque (voir cet article), ce qui rend leur utilisation dans les jeux difficile/ennuyeuse. C'est pourquoi je souhaite créer une bibliothèque que les développeurs indépendants peuvent utiliser en toute confiance et facilement pour développer leurs projets. sans sacrifier le contrôle, la portabilité ou la qualité.
Si vous souhaitez pouvoir développer facilement des jeux avec des bibliothèques respectant les principes mentionnés ci-dessus, pensez à contribuer à rayfork.
Vous pouvez consulter l'onglet Problèmes et trouver de nombreuses choses que vous pouvez faire pour contribuer.
Je recherche également de l'aide pour développer des choses en dehors de mon expertise :
Contactez-moi sur le serveur Discord Raylib dans la chaîne #rayfork, je suis @BananyaDev#0001, ou sur Twitter @SasLuca.
Conservez la convention de dénomination au boîtier serpent, utilisez rf_function_name pour les fonctions d'interface et _rf_function_name pour les fonctions privées.
Préfixez toutes les fonctions avec rf_public ou RF_INTERNAL
N'incluez pas d'en-têtes supplémentaires dans l'interface, efforcez-vous de minimiser les inclusions en général.
Utilisez #pragma region #pragma endregion pour plier les régions du code et envisagez d'utiliser un éditeur prenant en charge le pliage de ces régions pour mieux comprendre le code.
Essayez d’appliquer les conseils de cet article en général. Certains des conseils les plus importants seraient :
