garfo de raio
1.0.0
Bifurcado a partir da incrível estrutura do jogo raylib: https://www.raylib.com/
AVISO: o rayfork ainda está em desenvolvimento inicial e não é recomendado que você o use profissionalmente no momento.
rayfork possui apenas um arquivo .c e depende apenas da libc, o que significa que pode ser facilmente compilado como uma biblioteca a partir da linha de comando.
# -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 não fornece uma camada de plataforma, o que significa que ele não criará uma janela, não carregará OpenGL ou capturará entrada para você.
Isso ocorre intencionalmente, para que você possa usar facilmente o rayfork em várias plataformas (incluindo consoles de jogos) usando o método que funciona melhor para você. Existem modelos para usar o rayfork com GLFW, SDL, sokol-app e camadas de plataforma personalizadas.
O renderizador atualmente possui backends OpenGL33 e OpenGL-ES3 (com mais a serem adicionados) que são implementados de forma portátil que permite que o rayfork seja compilado em qualquer plataforma, com a única dependência sendo libc. Os processos OpenGL são passados explicitamente para o rayfork e há uma macro simples para ajudar com isso.
Por causa disso você pode compilar facilmente o rayfork para qualquer plataforma, seja PC, Mobile ou Consoles.
As funções que realizam IO geralmente são opcionais e solicitam explicitamente retornos de chamada de IO. Um wrapper simples para as funções libc IO é fornecido como rf_default_io .
Funções que alocam pedem explicitamente um alocador e às vezes também um alocador de memória temporário (memória que é liberada dentro da função). Um wrapper simples para malloc/free da libc é fornecido como rf_default_allocator .
Todas as dependências também são usadas com alocadores personalizados em mente, a biblioteca nunca alocará sem você saber.
Cada função que requer um alocador ou retornos de chamada io tem uma versão _ez que envolve a função original e a chama com rf_default_allocator e/ou rf_default_io , isso é útil para testar código rapidamente.
A biblioteca é apenas um cabeçalho e arquivo de origem e pode ser customizada em tempo de compilação usando definições de pré-processador. Nenhum sinalizador de compilação adicional é necessário, dependendo do back-end gráfico que você pode precisar vincular a determinadas bibliotecas.
raylib foi criado inicialmente para fins educacionais e amadureceu ao longo do tempo em uma biblioteca de jogos muito útil, semelhante ao XNA.
No entanto, devido à sua natureza, várias opções de design no raylib tornam-no difícil de usar para desenvolvedores profissionais de jogos:
Difícil de usar uma camada de plataforma personalizada (por exemplo: usando uma camada de plataforma personalizada no Android com Android Studio)
Difícil de portar em outras plataformas (por exemplo: iOS, consoles)
Pouco controle sobre alocações de memória e io.
O rayfork foi projetado para resolver esses problemas e facilitar o desenvolvimento de jogos profissionais usando a API do raylib.
Comecei este projeto porque adoro raylib e C99 e queria muito desenvolver meu jogo usando-os.
Muitas bibliotecas, no entanto, não seguem os princípios que procuro em uma biblioteca (veja este artigo), o que torna seu uso em jogos difícil/irritante, e é por isso que quero criar uma biblioteca que os desenvolvedores independentes possam usar com segurança e facilidade para desenvolver seus projetos. sem sacrificar o controle, portabilidade ou qualidade.
Se você deseja desenvolver jogos facilmente com bibliotecas que respeitem os princípios mencionados acima, considere contribuir com o rayfork.
Você pode verificar a guia de problemas e encontrar muitas coisas que pode fazer para contribuir.
Também estou procurando ajuda para desenvolver coisas fora da minha experiência:
Contate-me no servidor raylib discord no canal #rayfork, sou @BananyaDev#0001, ou no twitter @SasLuca.
Mantenha a convenção de nomenclatura em maiúsculas e minúsculas, use rf_function_name para funções de interface e _rf_function_name para funções privadas.
Prefixe todas as funções com rf_public ou RF_INTERNAL
Não inclua cabeçalhos adicionais na interface, trabalhe para minimizar as inclusões em geral.
Use #pragma region #pragma endregion para dobrar regiões de código e considere usar um editor com suporte para dobrar essas regiões para obter uma compreensão mais fácil do código.
Tente aplicar os conselhos deste artigo em geral. Alguns dos conselhos mais importantes seriam:
