Empieza a verse cositas!!!
:o
http://javiermaura.wordpress.com/2011/08/16/trabajando-con-mi-engine-dx11/ (http://javiermaura.wordpress.com/2011/08/16/trabajando-con-mi-engine-dx11/)
Uff..¡como engancha esto de los engines!
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# :)
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,...)
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 :)
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++.
Nuevos avances!!! :o
http://javiermaura.wordpress.com/2011/09/23/avances-en-gui-magneto-windows-y-texture-explorer/ (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.
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... :(
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/
Y por cierto la captura tiene muy buena pinta :D
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!!
La fiebre motoril de stratos sigue viva :D
Cita de: XÑA en 23 de Septiembre de 2011, 11:53:43 AM
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...
Sí, seguro que el debug en .Net es crminal!! Normal, con todo lo que te guarda... :D
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.
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#:
fixed (float* position = &Position[0].X)
{
Internal.BindPosition(position, Position.Length, OffsetForPosition, semanticSize);
}
Y en Managed C++:
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 :
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... ::)
Nuevos avances en el GUI...¡esas pantallitas! :P
http://javiermaura.wordpress.com/2011/09/29/dandole-otro-look-feel-al-gui/ (http://javiermaura.wordpress.com/2011/09/29/dandole-otro-look-feel-al-gui/)
ah...Y ya está implementado el drag & drop!! ;)
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.
Sí, lo he pensado, lo de enmascarar las estructuras.... ;)
Gracias
Cambios en el GUI. Sé que estoy un poco pesado con esto, pero el GUI es complicado de hacer de narices, o quizás es que me complico demasiado la vida... Como no tengo prisa, rehago y rehago. De momento creo que voy bien, porqué la única forma de saberlo es que sea fácil de programar, y que tenga lógica.
Ahora mismo, he añadido algo muy efectivo, y es que cuando usas el Drag & drop, parpadean los elementos que pueden recibir ese Drop. Me parece muy útil, porqué así ya sabes enseguida dónde puedes llevar los objetos que coges.
http://javiermaura.wordpress.com/2011/10/03/siguiente-con-el-gui/ (http://javiermaura.wordpress.com/2011/10/03/siguiente-con-el-gui/)
El menú también funciona, así que en teoría mañana ya puedo dedicarme al control slider!!! :)
Hola, muy interesante tu proyecto!
Una cosa que no entiendo muy bien es lo de la GUI. Esa GUI es para ingame o para alguna especie de editor?
Un saludo!
Sigo con los avances. Esta vez una pantallita general...
http://javiermaura.wordpress.com/2011/10/08/guigueando/ (http://javiermaura.wordpress.com/2011/10/08/guigueando/)
Pues contestando a Pepius, decirte que el GUI es el para crear un editor del juego, al estilo de Unity ( no es que vaya a hacer un Unity!!! jajaja). Así como un engine facilita mucho el desarrollo de un juego, y nadie lo pone en duda, creo que un GUI facilitará muchísimo el desarrollo de un editor o lo que sea. Para que veas el ejemplo, este es el código para el radio button:
radio = new RadioOption(GUI, this,"Type");
radio.X = 150;
radio.Y = 2;
radio.Name = "RdOption";
radio.Options.AddRange(new string[] { "Fixed size", "Bounded rectangles" });
radio.ComputeChanges();
Al estar orientado a juegos, no tiene nada que ver con Windows Forms. Algo muy muy importante, por ejemplo, es que forms sólo actualiza un control cuando se invalida. Eso te fuerza a gestionar eso por ti mismo, y es...tedioso. Como este GUI es para juegos, yo llamo al update de cada control en cada frame, y también lo dibujo. Por tanto, te olvidas de invalidar, con lo que el código es mucho más claro y sencillo.
Mi idea es desarrollar un editor basado en DX11 (aunque funciona con DX10 ahora mismo) pero que sea independiente del device. Así, se podrá cambiar el device, y funcionará en XNA, o en móvil, o en OpenGL.
El motor ya está hecho por dentro. Tu trabajas con un material que tienes unas propiedades: Diffuse, specular, normal... Luego tienes luces y finalmente un mesh. Entonces el motor genera los shaders que necesita dinámicamente. Si el device no es capaz de soportar normales, por ejemplo, entonces no se ven y listo. No se basa en fallbacks, que son shaders más básicos que se usan por si el hardware no soporta ciertas propiedades. Como lo shaders se construyen dinámicamente si una propiedad no se puede utilizar, se genera ese shader sin esa propiedad y listo.
De hecho, espero que muy pronto pueda ponerme con el editor de escenas 2D, donde podrás ir montando las escenas. Ese para mi será el primer milestone importante.
Por cierto, el editor es 64 bits. Ya lo pensé con vistas a futuro... :D