Onde o Framework (XNA) termina e a API (DX) começa?

Eu li muitas perguntas interessantes sobre XNA x OpenTK x SlimDX x OpenGL x DX, e embora seja realmente útil obter outras impressões gerais de centenas de horas usando essas várias APIs / Frameworks, não vi qualquer resposta que defina claramente qual é o escopo de cada um.

Entendeu-se qual é a diferença entre uma API, mecanismo e estrutura, em teoria, mas para alguém que tem experiência limitada com sistemas gráficos, é mais difícil ver o que, do lado prático, se enquadra em cada categoria. (Não é facilitada por toda a sobreposição! Por exemplo, XNA implementando um pipeline de conteúdo como parte integrante)

Tomemos, por exemplo, seleção de rosto - o XNA 'faz' isso em segundo plano, sem que o programador precise pensar sobre isso, mas onde isso acontece? Existe uma função 'cara de abate' no DX que deve ser chamada ou talvez acima no XNA? Ou a GPU ou seu driver faz isso?

Eu li na documentação de um dos projetos gerenciados (irritantemente não me lembro qual) sobre o quão difícil foi implementar código de renderização eficiente e como esse projeto o abstraiu. Isso me deixou um pouco nervoso e me fez pensar no que o XNA está fazendo sob DrawIndexedPrimitives que teria que ser feito manualmente, caso a estrutura fosse deixada para algo mais flexível.

O que o XNA faz em segundo plano, ao renderizar esse cubo, que uma API gerenciada não faria?

architecture

— sebf
fonte

gamedev.stackexchange.com/questions/12701/… Resume a parte engine versus framework .. uma API é simplesmente como essa estrutura / biblioteca / mecanismo é apresentada.

— The Duck comunista

Além do seu exemplo de pergunta de descarte, essa pergunta é bastante vaga. Que tipo de resposta você está procurando? Parece-me que você está pedindo uma lista de tudo o que toda biblioteca faz, para poder discernir quais camadas fazem o quê. Acho que talvez você deva consultar a documentação relevante e, quando disponível, o código-fonte caso a caso. Sua pergunta de seleção de rosto pode ser respondida, mas o restante da pergunta encapsulante parece aberta terminou para mim.

— Ricket

Eu acho que a questão principal está no título. OP gostaria de saber quanto "trabalho pesado" é XNA fazendo programação vs. em C ++ e Direct X

— Nate

@Ricket, desculpe provavelmente é um pouco vago, porque não tenho certeza exatamente da melhor maneira de expressar a resposta. Em relação a uma lista de camadas, você está certo; não são listas exaustivas, mas talvez alguns exemplos do tipo de função que o XNA chama em segundo plano, ou métodos necessários para renderizar no OpenGL, mas não no XNA, ajudariam a ilustrar o tamanho da diferença de nível é. Nate está correto; se você vem de um nível baixo, é bastante fácil ver o que está oculto , mas se você começou com o XNA, é mais difícil ver o que está faltando (e, portanto, o quão alto você está).

— sebf 8/06/11

(Editei a pergunta para ser um pouco mais prescritiva) @ The Duck Comunista, Obrigado, acho esse tópico útil - especialmente sua última opinião sobre o jogo separado do mecanismo, acho que ilustra muito bem o que realmente é um mecanismo.

— sebf 8/06/11

Respostas:

Eu acho que a pergunta seria melhor respondida se você a invertesse. Como exatamente uma placa de vídeo funciona e que chamadas são feitas pelo DirectX ou OpenGL para utilizar esses recursos?

Isso não responderia sua pergunta em si, mas como o DirectX e o OpenGL adicionam muitas classes de nível superior para simplificar as coisas para você, acredito que a diferença é muito vaga com o que o XNA fornece, por exemplo.

Para o básico, você encontrará semelhanças nas chamadas do DirectX / XNA porque, em um determinado nível (inferior), as coisas não podem ser mais abstactas e as chamadas deverão ser feitas por você.

Então, eu diria para criar um mecanismo de renderização simples no OpenGL (eu diria mais acessível para obter um nível mais baixo) e ver aonde isso leva você!

— Jonathan Connell
fonte

É difícil escolher respostas quando o consenso entre todos é essencialmente que a pergunta não tem uma, mas é essencialmente o que farei, pois acho que agora a única maneira de entender a diferença é jogar com SlimDX ou OpenTK (mesmo que eu Comecei com Assembly. Fui tão mimado pelo C # que acho que não vou ficar sem o GC ainda;)) e o vejo em primeira mão.

— sebf 9/06/11

Uma estrutura, essencialmente, fornece uma API. Geralmente, ele usa ou envolve outras APIs para fazer isso. Os dois termos não são necessariamente distintos, não há diferença clara no escopo e não é realmente importante que você consiga diferenciar - o importante é saber em que nível de abstração qualquer API, biblioteca, estrutura, mecanismo, plataforma ou pacote opera em. Descobrir isso varia infelizmente caso a caso.

— Kylotan
fonte

A estrutura começa ... onde a API termina. A API é um conjunto limitado de funções / classes / o que você pode usar, e a estrutura apenas envolve tudo isso.

Se você está perguntando sobre quantas coisas acontecem entre sua chamada para qualquer função da estrutura que você esteja usando para acessar o método de API que está chamando, isso realmente não é responsável no caso geral. Algumas coisas são fáceis, outras são realmente abstratas e podem estar escondendo coisas que seriam úteis para você saber (e é por isso que estou assumindo que você está fazendo essa pergunta).

Para o XNA especificamente, você provavelmente pode ver o código usando uma ferramenta como o ILSpy para abrir as DLLs do XNA e ver o que está acontecendo sob o capô.

— Tetrad
fonte

Eu dei uma olhada no método DrawIndexedPrimitives usando o .NET Reflector e, em muitos aspectos, foi útil, mas em outros incompletos. Por um lado, não acho que os programadores navais de DX desenhem geometria obtendo um ponteiro para um dispositivo, deslocando-o por uma constante codificada para recuperar um ponteiro de função e depois chamando isso (pelo menos eu realmente espero que não!: -O ) Por outro lado, parece que a função DrawUserPrimitives é, pelo menos para essa função, apenas um invólucro com muita verificação de erros e o XNA não faz nada além disso.

— sebf 8/06/11

Acho que posso ter calculado mal o quão variado é o escopo dos exemplos que listei e, como você e Kylotan dizem, a única maneira de ver é aprender uma API gerenciada.

— sebf 8/06/11

A constante codificada permanentemente para recuperar o ponteiro de função é resultado da descompilação do C ++ / CLI. Se você escrever um aplicativo C ++ / CLI Console e fizer referência às apis nativas do Direct3D, faça algo como 'pDirect3DDevice-> EndScene ();' ele será decompilado no que você viu (ou similar) quando visto como C # no Reflector - acredito que muito XNA está escrito em C ++ / CLI e não em C #.

— Jeffora

@ jeffora, isso faz mais sentido. O próprio .NET Reflector faz a descompilação sob demanda ao abrir uma biblioteca?

— sebf 9/06/11

O Reflector da RedGate está essencialmente mapeando a IL para seu equivalente em linguagem gerenciada. Você notará que pode alterar o idioma e até visualizar apenas o IL. O código-fonte exibido nem sempre é preciso para o que foi digitado - é uma descompilação precisa do que o compilador gerou. O código C # a partir de partes do XNA compilado não vai mesmo compilar se você tentar escrevê-lo sozinho (em C #)

— jeffora