Eu realmente preciso usar uma API de gráficos?

É necessário usar APIs gráficas para obter aceleração de hardware em um jogo 3D? Até que ponto é possível liberar dependências para APIs de placas gráficas como OpenGL, DirectX , CUDA, OpenCL ou qualquer outra coisa?

Posso criar minha própria API ou biblioteca gráfica para o meu jogo? Mesmo que seja difícil, é teoricamente possível que meu aplicativo 3D entre em contato com o driver gráfico de forma independente e renderize tudo na GPU?

Acho que muitas das respostas perdem um ponto importante: você pode escrever aplicativos que acessam hardware diretamente, mas não em sistemas operacionais modernos . Não é apenas um problema de tempo, mas um problema de "você não tem escolha".

Windows, Linux, OSX, etc., todos proíbem o acesso direto do hardware a aplicativos arbitrários. Isso é importante por motivos de segurança: você não deseja que nenhum aplicativo aleatório consiga ler a memória arbitrária da GPU pelo mesmo motivo que não deseja que nenhum aplicativo aleatório consiga ler a memória do sistema. Coisas como o buffer de quadros da sua conta bancária ou o que estiver na memória da GPU. Você quer esse material isolado e protegido e o acesso controlado pelo seu sistema operacional.

Somente os drivers podem conversar diretamente com a maioria dos hardwares, e a única maneira de conversar com o driver é através do HAL exposto do sistema operacional e da interface proprietária e incompatível de cada driver. Essa interface do driver não será apenas diferente para cada fornecedor, mas também diferirá entre as versões do próprio driver, tornando quase impossível conversar diretamente com a interface em um aplicativo de consumidor. Essas camadas geralmente são cobertas por controles de acesso que restringem ainda mais a capacidade de um aplicativo acessá-los.

Portanto, não, seu jogo não pode apenas usar o hardware diretamente, a menos que você esteja direcionando apenas sistemas operacionais inseguros como o DOS, e sua única opção viável para um jogo em sistemas operacionais de consumidor modernos é segmentar uma API pública como DirectX, OpenGL ou Vulkan.

Praticamente é necessário, sim. É necessário porque, a menos que você queira passar anos escrevendo o que é essencialmente o código do driver para as diversas configurações de hardware disponíveis, você precisa usar uma API que se unifique aos drivers existentes, escritos pelos fornecedores de GPU, para todos os sistemas operacionais e hardware populares.

A única alternativa realista é que você não usa a aceleração 3D e prefere a renderização de software que, desde que seja escrita em algo verdadeiramente portátil como C, será capaz de rodar em praticamente qualquer sistema / dispositivo. Isso é bom para jogos menores ... algo como SDL é adequado para esse fim ... existem outros por aí também. Mas isso não tem recursos 3D inerentes, então você terá que construí-los você mesmo ... o que não é uma tarefa trivial.

Lembre-se também de que a renderização da CPU é ineficiente e apresenta baixo desempenho em comparação às GPUs.

APIs como OpenGL ou DirectX são parcialmente implementadas pelo sistema operacional e parcialmente implementadas pelo próprio driver gráfico.

Isso significa que, quando você deseja criar sua própria API de baixo nível, que utiliza os recursos das GPUs modernas, você precisa essencialmente escrever um próprio driver gráfico. Certificar-se de que seu driver funcione com todas as placas gráficas comuns seria um grande desafio, principalmente porque os fornecedores geralmente não são muito abertos com suas especificações.

Inicialize seu PC no MS-DOS. Em seguida, usando sua cópia da Enciclopédia de Programadores de Jogos para PC , você pode gravar diretamente nos registros VESA da placa e na memória de vídeo. Ainda tenho o código que escrevi há 20 anos para fazer isso e renderizar 3D rudimentar em software.

Como alternativa, você pode apenas usar o DirectX; é uma camada de abstração muito fina e também permite gravar diretamente em buffers de vídeo e depois trocá-los na tela.

Há também a abordagem extrema de criar seu próprio hardware de vídeo .

As outras respostas respondem bem à sua pergunta principal: tecnicamente, é possível, mas na prática, se seu objetivo é ampliar sua base de clientes, você está realmente fazendo o oposto. Ao desperdiçar uma enorme quantidade de trabalho no suporte a milhares de configurações diferentes de hardware e sistema operacional, você precisa dar suporte.

No entanto, isso não significa que você precise estar 100% dependente de uma API específica. Você sempre pode codificar sua própria camada de abstração e depois trocar as implementações mais específicas (por exemplo, uma implementação do DirectX, uma implementação do OpenGL, ...) dentro e fora.

Mesmo assim, provavelmente não vale a pena. Basta escolher algo que funcione bem o suficiente para seus propósitos e terminar com isso. Você é um criador de jogos independente - precisa se concentrar nas coisas que fazem o jogo, não nas minúcias. Apenas faça o jogo!

Em resumo: teoricamente você pode, mas é inviável e não terá nenhuma vantagem. As limitações das APIs hoje se tornam menores a cada dia, você tem CUDA, OpenCL e shaders. Portanto, ter controle total não é mais um problema.

Explicação mais completa:

Responder a este é um sim chato . A verdadeira questão é por quê ?

Eu mal imagino por que você gostaria de fazer isso a não ser para fins de aprendizado. Você precisa saber que, em algum momento, os desenvolvedores tiveram a liberdade de fazer qualquer coisa com suas implementações de processamento de CPU, todos tinham sua própria API, eles estavam no controle de tudo no "pipeline". Com a introdução de pipeline fixo e GPUs, todos mudaram ..

Com as GPUs, você obtém um desempenho "melhor", mas perde muita liberdade. Os desenvolvedores gráficos estão se esforçando para recuperar essa liberdade. Portanto, mais pipeline de personalização todos os dias. Você pode fazer quase qualquer coisa usando CUDA / OpenCL e até shaders, sem tocar nos drivers.

Você quer falar com o hardware. Você precisa usar uma maneira de conversar com o hardware. Dessa forma, é a interface para o hardware. É isso que OpenGL, DirectX, CUDA, OpenCL e o que mais for.

Se você chegar a um nível inferior, estará apenas usando uma interface de nível inferior, mas ainda estará usando uma interface, apenas uma que não funcione com tantas placas diferentes quanto a de nível superior.

Para obter a Aceleração de hardware 3D sem usar uma API tradicional, é necessário escrever seu próprio código para duplicar a funcionalidade do driver gráfico. Portanto, a melhor maneira de aprender como fazer isso é examinar o código do driver gráfico.

Para placas NVIDIA, você deve examinar o projeto nouveau de código aberto . Eles têm uma coleção de ótimos recursos aqui .

Para outras marcas de placas gráficas, você pode encontrar projetos e documentação semelhantes.

Observe que, como mencionado em outras respostas, os sistemas operacionais mais modernos impedirão que os programas do espaço do usuário acessem diretamente o hardware; portanto, você precisará escrever seu código e instalá-lo como um driver de sistema operacional. Como alternativa, você pode usar o sistema operacional FreeDOS, que não possui essas restrições, e deve permitir (teoricamente) acessar diretamente o hardware e escrever um programa regular que renderiza gráficos acelerados por hardware 3D. Observe que, mesmo aproveitando o código de um driver gráfico de código aberto existente, isso seria uma tremenda quantidade de trabalho não trivial (e, pelo que sei, nunca foi feito e, devido a várias razões, pode não ser realmente tecnicamente possível).

Livrar-se do DirectX ou OpenGl não removeria dependências, introduziria mais delas. As outras respostas já contêm vários pontos positivos de por que nem sequer é possível falar diretamente com o hardware gráfico (pelo menos não é viável), mas minha primeira resposta seria: Se você realmente escrevesse uma biblioteca que abstraísse todas as imagens 3D comuns hardware gráfico em uma única API, você efetivamente reescreveria o DirectX / OpenGl. Se você usasse seu código para escrever um jogo, teria adicionado sua nova biblioteca como uma nova dependência, assim como agora você tem o DirectX / OpenGl como uma dependência.

Ao usar o DirectX ou o OpenGl, suas dependências estão basicamente dizendo "Esse código depende de uma biblioteca para fornecer o código que explica como executar determinados comandos em diferentes placas gráficas". Se você ficasse sem essa biblioteca, introduziria a dependência de "Esse código depende do hardware gráfico que se comporta exatamente da mesma maneira que o hardware existente quando eu construí o jogo".

Abstrações como o OpenGl ou o DirectX permitem que os fabricantes de hardware forneçam códigos próprios (drivers) que levam a uma base de código comum; portanto, os jogos têm maior probabilidade de rodar em hardware que nem existia quando o jogo foi escrito.

Primeiro de tudo, CUDA e OpenCL não são APIs de gráficos. Eles são apis de computação.

O problema de escrever sua própria API gráfica é que ela é muito complexa. Você pode interagir diretamente com o hardware, mas não há garantia de que, se funcionar em um sistema com CPU X, GPU X, quantidade de RAM e sistema operacional X, ele funcionará em um sistema com CPU Y, GPU Y, etc. Um bom ponto é que o DirectX funciona com drivers no modo kernel. Está enraizado no kernel. Além disso, as APIs gráficas não são construídas para suportar GPUs. As GPUs (e seus drivers) são criadas para suportá-las. Portanto, você praticamente não pode criar uma API gráfica, a menos que crie seu próprio sistema operacional e use o x86, desde que as interrupções VGA. Mas você ainda não seria capaz de interagir adequadamente com a GPU e ficaria preso em baixa resolução.

Entendo que você deseja construir tudo sozinho e não usar um mecanismo ou algo assim. Mas criar sua própria API gráfica criaria apenas inconveniência para o usuário.

Você pode escrever seu próprio driver e API, não há nada para impedi-lo, exceto sua capacidade e níveis de conhecimento. Se nada mais seria uma boa experiência de aprendizado, o verdadeiro problema é que, sem ter muita experiência gráfica anterior, mesmo que você seja um ótimo programador, provavelmente ficará sem saber o que precisa fazer ... ou até para começar.

No entanto, a interface que você cria será mais fácil de usar e mais estável para você do que algo atualizado constantemente nas suas costas. Portanto, é um pouco surpreendente para mim que mais pessoas não sigam esse caminho, mas a realidade é que poucas pessoas têm perspicácia técnica e ninguém quer pagar alguém por anos a fio para aprender como fazer tudo isso, e possivelmente eles saem da empresa e os deixam em apuros. O lado bom da padronização é que isso torna os funcionários muito mais dispendiosos e reduz os riscos.