tenedor de rayos
1.0.0
Bifurcado del increíble marco del juego raylib: https://www.raylib.com/
AVISO: rayfork aún se encuentra en una fase muy temprana de desarrollo y no se recomienda su uso profesional en este momento.
rayfork solo tiene un archivo .c y solo depende de libc, lo que significa que se puede compilar fácilmente como una biblioteca desde la línea de comandos.
# -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 no proporciona una capa de plataforma, eso significa que no creará una ventana, no cargará OpenGL ni capturará entradas por usted.
Esto es así por diseño, para que pueda usar rayfork fácilmente en múltiples plataformas (incluidas las consolas de juegos) utilizando el método que mejor se adapte a sus necesidades. Hay plantillas para usar rayfork con GLFW, SDL, sokol-app y capas de plataforma personalizadas.
El renderizador actualmente tiene backends OpenGL33 y OpenGL-ES3 (y se agregarán más) que se implementan de forma portátil, lo que permite compilar rayfork en cualquier plataforma, siendo la única dependencia libc. Los procesos OpenGL se pasan explícitamente a rayfork y hay una macro simple para ayudar con esto.
Debido a esto, puedes compilar fácilmente rayfork para cualquier plataforma, ya sea PC, móvil o consolas.
Las funciones que realizan IO suelen ser opcionales y solicitan explícitamente devoluciones de llamada de IO. Se proporciona un contenedor simple para las funciones IO de libc como rf_default_io .
Las funciones que asignan solicitan explícitamente un asignador y, a veces, también un asignador de memoria temporal (memoria que se libera dentro de la función). Se proporciona un contenedor simple para malloc/free de libc como rf_default_allocator .
Todas las dependencias también se utilizan teniendo en cuenta asignadores personalizados; la biblioteca nunca asignará sin que usted lo sepa.
Cada función que requiere un asignador o devoluciones de llamada io tiene una versión _ez que envuelve la función original y la llama con rf_default_allocator y/o rf_default_io , esto es útil para probar el código rápidamente.
La biblioteca tiene solo un archivo de encabezado y fuente y se puede personalizar en tiempo de compilación utilizando definiciones de preprocesador. No se necesitan indicadores de compilación adicionales; dependiendo del backend de gráficos, es posible que necesite vincular ciertas bibliotecas.
raylib se creó inicialmente con fines educativos y con el tiempo ha madurado hasta convertirse en una biblioteca de juegos muy útil, similar a XNA.
Sin embargo, debido a su naturaleza, varias opciones de diseño en raylib dificultan su uso para desarrolladores de juegos profesionales:
Es difícil usar una capa de plataforma personalizada (por ejemplo, usar una capa de plataforma personalizada en Android con Android Studio)
Difícil de portar a otras plataformas (por ejemplo: iOS, consolas)
Poco control sobre las asignaciones de memoria y io.
rayfork está diseñado para abordar esos problemas y facilitar el desarrollo de juegos profesionales utilizando la API de raylib.
Comencé este proyecto porque amo raylib y C99 y realmente quería desarrollar mi juego usándolos.
Sin embargo, muchas bibliotecas no siguen los principios que busco en una biblioteca (consulte este artículo), lo que hace que usarlas en juegos sea difícil o molesto, por eso quiero crear una biblioteca que los desarrolladores independientes puedan usar con confianza y facilidad para desarrollar sus proyectos. sin sacrificar el control, la portabilidad o la calidad.
Si desea poder desarrollar juegos fácilmente con bibliotecas que respeten los principios mencionados anteriormente, considere contribuir a rayfork.
Puede consultar la pestaña de problemas y encontrar muchas cosas que puede hacer para contribuir.
También busco ayuda para desarrollar cosas fuera de mi experiencia:
Contáctame en el servidor de discordia de raylib en el canal #rayfork, soy @BananyaDev#0001, o en Twitter @SasLuca.
Mantenga la convención de nomenclatura en caso de serpiente, use rf_function_name para funciones de interfaz y _rf_function_name para funciones privadas.
Prefije todas las funciones con rf_public o RF_INTERNAL
No incluya encabezados adicionales en la interfaz; trabaje para minimizar las inclusiones en general.
Utilice #pragma region #pragma endregion para plegar regiones de código y considere usar un editor que admita plegar esas regiones para comprender mejor el código.
Intente aplicar los consejos de este artículo en general. Algunos de los consejos más importantes serían:
