Managed Directx

[Virgil]

 ¿Es Managed DirectX una reimplementación de DirectX para el framework .NET o acaso está construido sobre él?

¿Existe mucha diferencia de performance entre Managed DirectX y DirectX? Según lei, no debería existir mucha diferencia de performance (según Tom Miller (el tipo de MS que está atrás de todo esto), sólo el 6%). Pero en las demos probando con C++ y C# algunas diferencias son bastante considerables.

Me gustaría conocer su opinión al respecto. Muchas gracias.

[Grugnorr]

 Las demos están muy mal programadas. La de Billboards reserva y libera unos 2 mbs por frame o una burrada aí debido al boxing-unboxing de las structs donde almacena los datos de cada árbol. Cambia esa struct por una class y dime que tal va  :P

Evidentemente no es una reimplementación, no las he usado todavía pero conociendo .NET es un pequeño wrapper por encima, la pérdida de eficiencia va a ser muy poca, el trabajo lo hace la GPU y en el caso de operaciones matemáticas que no lo haga la GPU seguramente llamen directamente a las dlls de d3dx.


PD: El futuro inmediato está en juegos en C#, engines en C++ (salvo seguramente para Playstation 2-3 y Game Cube, la XBOX2 se programará en C#, o eso parece  :P )

Now, when looking at the Billboard managed sample, you may notice that each tree that will be drawn has a corresponding structure that maintains the information needed to draw the tree. Since the trees are alpha blended, and will need to be drawn in a certain order (from back to front), each tree is sorted every frame. You'll see the code in the sample do this:

trees.Sort(new TreeSortClass());

This class implements IComparer, which is needed for comparison. If you look at the implementation of this class, though, you'll see quickly that the comparison method takes two objects in as the parameters, while we are using a structure. This structure must be boxed before it can be passed on to the compare method. Then, as soon as the compare method is started, the object is unboxed to be able to manipulate the data.

The sort method will be called approximately 4,300 times per frame. Each of these calls will perform a total of two boxing operations, followed immediately by two unboxing operations. The structure itself is defined as such:

public struct Tree
{
    public CustomVertex.PositionColoredTextured v0, v1, v2, v3;
    public Vector3 position;
    public int treeTextureIndex;
    public int offsetIndex;
};

Now, if you calculate the structures size, you'll see that it is quite large: 116 bytes. So, calculate the data that is being allocated and copied during a single sort operation. Multiply the number of bytes that will need to be allocated per object (116), by the number of objects (2), by the number of calls per frame (4,300), and you will come up with a whopping 997,600 bytes that will need to be allocated for every frame. This just covers the allocation for the boxing operation; it doesn't even consider the copy operation to get the data into the newly allocated object.

Even after the copy operation has taken place, as soon as the method has been entered, the very first thing that is done is to take all the data that has just been boxed, and unbox it. Which means the exact same allocation and copy will need to be performed a second time, with the exception being that this allocation will be performed on the stack.

So, in reality, for every frame the billboard sample is running, on average 1,995,200 bytes are allocated between the stack and heap and then copied back and forth between them

[seryu]

 oh dios! no! c# del diablo JAMAS!  (asco)

espero y deseo qe c# no se implante

[SpIdEr_]

 por? <_<  

[Malandrin]

 c# mola :)

EDIT: y perdón por el offtopic  :rolleyes:  

[Grugnorr]

 C# rocks!

PD: Seryu, respétanos en trabajo a Daventry y a mí

PDD: Alguna razón decente para odiar C#?

[Virgil]

 C# es un lindo lenguaje, la pregunta es ¿está preparado para la creación de juegos AAA?

Yo creo que no. Aunque usualmente estas discusiones suelen ser muy provechosas y se reparten buenos argumentos de ambos lados.

Managed DirectX es sin dudas una interfaz mucho mas sencilla que (unmanaged) DirectX, es básicamente lo mismo, las clases se mapean casi uno a uno y los métodos cuando no son iguales son muy similares. Pero posee como positivo:

Nombres sencillos (que no incluyen la maldita versión con él)
Ej: en lugar de un "LPDIRECT3DDEVICE8" tenemos un sencillo "Device".

Propiedades en vez de métodos.
Ej: En lugar de deber hacer

pDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_TRUE);

simplemente hacemos:

device.RenderState.ZBufferEnable = true;

Todo el código queda escrito de manera mucho mas limpia.

Para prototipar me parece muy conveniente. En una entrevista a Tom Miller y un colega de él, decían algo como que utilizando Managed DirectX se programa mucho más rápido, acortando tiempos de desarrollo (¡quien no quisiera hacer esto!) se le puede dedicar mas tiempo a aspectos de jugabilidad y a la fase creativa del proyecto.

Como ejemplo saban el juego "the Sims" que no es precisamente avanzando en cuanto a gráficos y sin embargo está en los top ten de lo mas vendido hace varios años. "the Sims" podría haber sido realizado perfectamente con C#/MDX y nadie se hubiese dado cuenta.

El problema aflora, según creo, cuando uno prentede sacar el 101% de jugo del CPU. El Doom3 no podría estar programado sobre MDX. Además Tom Miller dice que usando MDX se obtiene hasta un 98% de la performance de la misma aplicación hecha con C++/DX, lo cual creo que es MENTIRA, si realmente fuese así nadie estaría planteandose nada. Miller se aprovecha de la dificultad existente en la comparación objetiva entre una aplicación C#/MDX y otra C++/DX. Según mis conclusiones muy raramente podremos sobrepasar el 80% de la performance de C++ y usualmente nos quedamos en el 70%.

De todos modos, está claro que el desarrollo de la interfaz estuvo centralizado en la performance, por que bien saben ellos que es lo que mas se valora en estos casos.

En definitiva, no creo que sea compentencia a C++/MDX para desarrollos tipo Doom3 pero sí creo que es una opción para desarrolladores de otros tipos de juegos, donde se valore mucho el terminarlo en menos tiempo. Finalmente, es muy bueno que existan ambos métodos y que podamos elegir el que mas nos convenga.

[Grugnorr]

 Weno, depende de como lo mires. Ellos te dicen que usando Managed DX casi no pierdes rendimiento. Tú hablas de física y IA... no hay Direct IA ni DirectPhysics.. así que... ;).

Para cosas muy CPUIntensivas, las programas en C++ y el resto en C#. Están haciendo un wrapper de ODE managed...