Empezando un nuevo engine DX11

[XÑA]

Empieza a verse cositas!!!
:o

http://javiermaura.wordpress.com/2011/08/16/trabajando-con-mi-engine-dx11/

Uff..¡como engancha esto de los engines!

[Vicente]

Porque no usas SlimDX para el wrapper con la parte de DX11? A parte de eso ya sabes donde estoy si necesitas ayuda con cosas de C# :)

[XÑA]

El engine en realidad es a un nivel conceptual. En lugar de trabajar a nivel de DX o OGL o lo que sea, simplemente indicas materiales, luces y demás.
Al final, le mandas algo así al device:

Draw(triangulos, material, luces)

Por lo tanto, por 'debajo' da igual si es DX, OGL. Ahora mismo es DX11, pq el editor debe permitirlo todo, pero luego abres ventanas con el 'device' que quieras (DX,OGL, OGL ES 2.0,...)

[Vicente]

Me refiero a que en el blog cuentas que utilizas C++/CLI para la parte de interacción con DX, porque no usas mejor SlimDX para eso que ya está hecho y requeteprobado? Vamos, por no hacer algo que ya está hecho :)

[XÑA]

Porqué la parte complicada es pasarle los arrays de .Net a DX. Si usaba Slim tenía que pasar del motor a Slim y luego Slim las pasaba a DX. Ese paso me lo quería saltar.

Por otra parte, me ha servido para aprender un poco de Managed C++, y DirectX 11 a bajo nivel, que no tenía ni idea.

Luego, al ser un engine general, las definiciones de Slim no me servían ( los enums). Y depender sólo de mi también es una ventaja, porqué quien sabe que pasará con Slim en el futuro. Ahora mismo, el motor sólo necesita el SDK de DX, y creo que es un buen ejemplo para pasar cosas de C# a C++.

[XÑA]

Nuevos avances!!!  :o

http://javiermaura.wordpress.com/2011/09/23/avances-en-gui-magneto-windows-y-texture-explorer/

La ventaja de este engine es que en teoría, sólo hará falta cambiar el device y funcionará para XNA o para OpenGL.
Lo mejor de hacer tu propio GUI es que añadir elementos se convierte en algo trivial. El hecho de que cada frame se llame a un Update de cada control te facilita cosas como mantener los FPS. Este es el código que crea el label de FPS y sólo se crea al inicio del GUI.

Código [Seleccionar] Expand


            Label fps = new Label(this, bottomWindow);
            fps.AnchorLeft = 4;
            fps.AutoSize = false;
            fps.ActionForUpdate=()=> fps.Text = Mallorca.Timer.Fps.ToString("#,##0.0");
            fps.Size = new SizeI(140, fps.Font.Size);
            fps.ComputeChanges();


Lo malo que me voy encontrando: o me fio del programador o no puedo usar el ref !!! Se echa de menos el ref readonly, para poder pasar un parámetro por referencia que no te puedan modificar. :-\
Al final muchas propiedades son en realidad campor para poder hacer un ref, puesto que no pueden hacerse ref de propiedades. Es penoso a nivel de diseño, pq yo no quiero que me puedan modificar esos valores, pero es lo único qe puedo hacer si no quiero estar creando y destruyendo objetos...  :(

[Vicente]

En serio, en .NET crear y destruir objetos no es un problema (al menos ejecutando sobre PC). Si es en Xbox pues si, pero si es para PC te estas preocupando de resolver un problema que no tienes...

Un articulo muy bueno sobre este tipo de cosas:

http://reedcopsey.com/2011/08/11/c-performance-pitfall-interop-scenarios-change-the-rules/

[Vicente]

Y por cierto la captura tiene muy buena pinta :D

[XÑA]

Ya pero el copy no me lo evito si no paso por ref. Y un vector4, todavía, que son 16 bytes, pero una matriz....

Lo brutal es el salto de Debug (380 fps) a Release 1500!! supongo que es pq el engine mezcla C# y Managed C++. Tiene que ser un poco locura para el debugger...

¿Te ha gustado la imagen? Hombre, es un poco tristón. Estoy pensando seriamente en ponerle las ventanas de windows, con bordes redondeados y todo eso, pero claro es más costoso...¡pero qué narices!  :D

Creo que es un buen proyecto, porqué desarrollar un editor con Undo/Redo te debe obligar a llevar una buena arquitectura de las cosas, y es algo que nunca he hecho.

Lo más seguro es que cuando sea más estable, lo suba a CodePlex. Pero al menos necesito definir las estructuras básicas del..¡FrameWork! ¡Porqué ya no es un Engine, es un framework!!

[[EX3]]

La fiebre motoril de stratos sigue viva :D

Lo brutal es el salto de Debug (380 fps) a Release 1500!! supongo que es pq el engine mezcla C# y Managed C++. Tiene que ser un poco locura para el debugger...

No se que decirte, yo en el proyecto que estamos cerrando en XNA, al menos en un Intel Core 2 Duo 2.16Ghz, 2GB RAM, Intel GMA 950, el salto de Debug a Release lo hemos notado mucho asi que supongo que no sera unicamente tema de que mezcles C# y Managed C++.

Salu2...

[XÑA]

Sí, seguro que el debug en .Net es crminal!! Normal, con todo lo que te guarda...  :D

[Vicente]

El copy de la matriz te la pela tambien de momento :p Y usar una API con parametros ref es muy feo en .NET si es algo interno que no ve el usuario del motor perfecto, pero si es algo que vas a exponer hacia afuera yo quitaria los ref y listo.

[XÑA]

Jo Vicente, como te odio!!!  ;)

Bueno, reconozco que los ref me está destrozando a nivel de diseño y me planteo muy seriamente quitaros. Pero también es verdad que no puedo estar pasando las matrices sin ref, es demasiado costoso. Estuve tentado a hacerlo una clase, pero significaría cambiar demasiado la forma de trabajar de la gente.

De hecho, SlimDX usa ref!!!

El engine necesita velocidad para pasar la información de C# a C++. Mira, yo uso esto, que me evita copys innecesarios:

En C#:

Código [Seleccionar] Expand


                fixed (float* position = &Position[0].X)
                {
                    Internal.BindPosition(position, Position.Length, OffsetForPosition, semanticSize);
                }


Y en Managed C++:

Código [Seleccionar] Expand


void _VertexBuffer::BindPosition(float* p,int numElements,int offset,int semanticSize)
{
m_Position=(float *)p;

m_Count=(int)numElements;

m_OffsetForPosition=offset;

m_VertexSizeInBytes=semanticSize;
}


Ni un copy!!! Fundamental, cuando mueves muchos vértices!!

No te negaré que preferiría un :

Código [Seleccionar] Expand



foreach(Vertex v in Vertices)
{
   BinVertex(v);
}



Pero bueno, total lo hace internamente el engine y no lo ve el usuario, pero tengo que darte TODA la razón con los ref, me están destrozando y cada vez que lo leo pienso...¡qué barbaridad! Al menos el de Vector4 me parece que lo voy a quitar, y ya veré el de la matriz... ::)

[XÑA]

Nuevos avances en el GUI...¡esas pantallitas!  :P

http://javiermaura.wordpress.com/2011/09/29/dandole-otro-look-feel-al-gui/

ah...Y ya está implementado el drag & drop!!  ;)

[Vicente]

Por cierto recuerda que para copiar arrays y cosas asi en Jade usabamos unsafe, para jugar con punteros que iba un huevo mas rapido :) (pero era algo interno tambien, y creo que en todo el proyecto eran como 5 lineas de unsafe).

Respecto a las matrices y el ref, si la copia te esta matando tanto (espero que estes usando un profiler para comprobarlo con un proyecto de verdad y no un test de juguete :p), tienes una alternativa. Diseña tu API para que no pases matrices, si no objetos que dentro tienen una matriz (algo como yo que se, un modelo que dentro tiene su matriz) y haces que los tipos por valor sean campos y no propiedades (asi te ahorras la copia del get).

A mi no me gusta nada, pero me parece algo mejor que el ref.