Clases De Un Posible Motor Común

[Haddd]

 

Clase:Video
Descripción: Mantiene todos los objetos referentes a la tarjeta de Vídeo
1.   Effects
2.   Texturas
3.   Skins
4.   Meshes (objeto IBaseMesh de D3DX)

SubClases:

Nombre:Inicializacion
Descripción:
1.   Rellene la estructura de adaptadores y resoluciones.
2.   Comprueba si el device cumple las características exigidas
3.   Inicializa el device


Nombre:Información
Descripción: Mantiene toda la información que pueda pedirse al device:
1.   Parámetros utilizados para crear el device.
2.   Resolución del backbuffer.
3.   Nº de bits del stencil y Depth Buffer.
4.   Otros flags de interés para el desarrollador (versión de shaders soportadas...)

Nombre:Path
Descripción: Mantiene la lista de paths que utiliza la aplicación para buscar un archivo (textura, mesh,...)

Nombre:Render
Descripción: Funciones de Render. Presenta el backbuffer, activa un cierto rendertarget. Renderiza un rectángulo en la pantalla.

Nombre:State
Descripción:Manager de States(Render, Textura y Sampler)

Nombre:Utilidades
Descripción: Utilidades de vídeo:
1.   Grabar la pantalla
2.   Convertir índices de 32 bits a 16 bits.
3.   Convertir a indexado.
4.   Convertir un punto a ClipSpace/Screen Space.

Nombre:Importar
Descripción: Funciones de importación


Clase: Escena
Descripción: Mantiene los elementos que conforman una escena.

1.   Mallas
2.   Luces
3.   Sprites
4.   Terreno


Clase:Skin
Descripción: Mantiene la estructura de texturas y atributos que puede tener un mesh.

Son clases básicas, pero es para animar. Si hay participación en el tema, se decide el lenguaje a utilizar y ponemos objetivos muy simples:

1. Crear un sistema para inicializar el device con las opciones requeridas por el desarrollador.
2. Cargar un .X y mostrarlo en pantalla

Esto yo lo sé hacer, y muchos de aquí también. Lo interesante sería que TODOS trabajáramos igual, consensuando pareceres.

Por favor, si quereis ayudar, no digais eso de ..¡cuenta conmigo!. Dejad aquí escrito en qué podeis ayudar ( testear también es una buena ayuda!!)

[Astat]

 Seria para hacer un motor de uso publico/educativo (nada de cosas comerciales, osea GPL, no?), usando c++, visual2003 (o 2005), directx9 y algun sistema de gestion (estilo cvs)... si es asi, me interesaria participar.

Mejor que clases, como dices, creo que es mejor que se divida todo en namespaces (la mejor forma de organizar, creo, en c++). Por ejemplo:

::core, funciones basicas que usaran todos los sistemas
::video, todo lo necesario para iniciar modo de video, y pintar polis y efectos
::storage, leer/guardar datos en HD (con un formato comprimido/encriptado y seria genial que soportara tambien streaming)
::scene, organizacion de la escena (lo gordo vamos)
::script, casi mejor hacer un puente con una clase virtual y usar AngelScript (de lo mejorcito)
::physic, lo mismo que antes pero con ODE
::input, perifericos
::sound, pues eso
::gui, interfaz de usuario (esto podria estar dentro de ::scene, pero bueno, mejor separarlo porque es tocho)
::terrain, idem que ::gui
::net, conexion de red y gestion de mensajes
::math, quizas un subnamespace de ::core, operaciones matematicas diversas

cada sistema estaria contenido en una DLL (genial para trabajar cada uno en lo suyo) y toda la comunicacion entre sistemas se haria con interfaces virtuales puros (todo =0). Toda la carga de sistemas podria ser dinamica y asi usar lo solo lo que se necesite. Ademas usar DLLs para proyectos en los que curran mucha gente mola porque sirve de cortafuegos de bugs.

Me parece una idea genial hacer un motor bien organizado que sirva a los que empiezan o a los que se quieren dedicar a hacer un juego sin preocuparse del motor (y en vez de ir usando torque, neoengine, etc etc, porque no usar uno de la comunidad??)

Un saludo

[Zaelsius]

 Seryu y Ethy están muy callados desde hace un par de dias.. ¿voy a tener que asumir yo el rol de cabr*ncete desmoralizador o qué?

Algunos pensamientos:

- Si va a ser libre, pues a SourceForge sin dudarlo. Mucha conoce los proyectos buscando desde la página principal.

- ¿Exlusivo Windows/DirectX? Cojonudo siempre que sirva para atajar caminos y aprovechar las ventajas de la plataforma.

Sobre la etapa de diseño(y aquí entra el sermón de la uni):

- No es plan de ponerse a añadir características a lo loco. Creo que deberías especificar primero unos requerimientos para el motor. Es decir, ¿hasta dónde queremos llegar?

Podeis seguir dos metodología de diseño:

- Top-down: especificais requerimientos y a partir de ahí diseñais la estructura del motor, herramientas, etc.

- Bottom-up: partís de una instancia del problema, en este caso un ejemplo de juego que deberia poder ser desarrollado con el motor. A partir de ahí analizáis los componentes necesarios. Por ejemplo: "quiero hacer un gauntlet en 3d, con modelos animados(implica cargar un formato animado), magias(sistemas de partículas) y una bonita IU(GUI)"

Quiero decir, el motor 3d genérico ideal no existe(bueno sí existe pero fué adquirido por EA y es de pago ;)), no deberíais intentar acaparar todos los géneros. Quizá lo mejor es darle sólo unas pocas características orientadas a géneros concretos, y dejar las puertas abiertas a otros géneros mediante un diseño eficaz que permita ampliar el motor por terceras partes sin demasiados problemas.

Yo lo que más valoraría de un motor es la mezcla entre el trabajo a alto y bajo nivel. Es decir, poder hacer un pac-man en 4 patadas pero ser capaz de añadir cosas que no estaban soportadas inicialmente, como podría ser un terreno o una capa de nubes procedural(por poner un ejemplo).

En fin esas son mis consideraciones que espero os sirvan para reflexionar en ciertos aspectos. Yo sólo ayudaría si hiciese falta algun tipo de herramienta de tipo genérico.. pero por el momento tampoco tengo mucho tiempo así que sólo puedo prestar mi apoyo moral, mi arco, y mi hacha.


Edit: se me olvidó decir si el soporte de sonido y red es realmente necesario desde un principio en el motor, o si es mejor relegar esas tareas a librerías externas especializadas. Ah, aunque el diseño modular es positivo, tambien intentaria evitar caer en un infierno de DLL's(como Ogre 3D (asco) ).

[boubou]

 Creo que podria ayudar en lo referente a mallas *.x tanto carga como render, animacion y aplicacion de efectos (No la creacion de estos) Tengo funciones especificas para ello, lo que tendria que hacer es pasarlas a clases porque las tengo en funciones de c++.

Cuando tengas el cvs... Cuenta con mi teclado.

[nsL]

 Yo no puedo ayudar en lo que a programacion se refiere, pero cuando tengais alguna version testeable ahi estare ;)

[Haddd]

 Astat, deacuerdo en lo de namespace, pero muchas de las clases que aquí defines ya las integra .NET. La idea básica es no inventar la rueda. Utilicemos lo que ya está creado. Por ejemplo, utilicemos las D3DX para cargar una textura, no perdamos el tiempo en hacer cosas ya desarrolladas.

Sobre el tema de las DLL, nunca las he utilizado, y pienso que quizás sea algo innecesario, porque seguramente existirá algún tipo de limitación a nivel de variables globales, o si no es una limitación, sí que debe ser complicado que una dll, por ejemplo la de renderizado, tenga que cargar otra dll, por ejemplo la matemática. Creo que no es necesario llegar a esta complejidad. Si partimos de una base, que puede ser la clase básica de mi motor, dando el código fuente y encargando a cada uno un trozo, se podría segmentar bien el trabajo(creo).

En principio mi idea es hacer un motor en C++, que alguien lo encapsule a C# u a otro lenguaje .Net (C++).
TODAS LAS HERRAMIENTAS SE HARIAN EN .NET. La razón es que es tremendamente sencillo hacer editores en este lenguaje(eso no quita que alguien no haga una super herramienta luego con el motor en ensamblador  :huh: !!)

El motor sería 100% DX y D3DX ( todo lo que se pueda hacer con D3DX NO se hace a mano). Sé que aparecerá el típico...¿linux, OGL? Bueno, ¿porque no? Pero para que un proyecto de este estilo esté vivo, tiene que avanzar muy rápidamente, y hay que separarse de paralelismos lo antes posible!.


El motor debería ser libre y gratuito, incluso para utilización comercial. Ponerlo en SourceForge, me parece romper un poco el espiritu que tiene ahora de "made in Stratos".

Bien, añaderé un hilo con la clase básica. Seguimos con este hilo abierto a ver quien se apunta.

¡Animo a todos!

[boubou]

 Tengo una duda:

Se hara en managed c++ o el classic?

Edito: me refiero al motor :).

[CoLSoN2]

 Y digo yo, porque no cojeis uno de los motores que ya hay creados y lo extendeis a vuestro gusto? Es muy bonito tener algo de la comunidad, pero hacer motores constantemente no lleva a ningún sitio. A no ser que lo que quieras sea hacer motores, entonces adelante :)

[AgeR]

 Joder, al final me animaré a participar yo también  (uoh) .
De todos modos ya desde el principio se ven las diferencias entre unos y otros. Yo por ejemplo estoy de acuerdo con Haddd en hacerlo libre para cualquier tipo de uso, en vez de hacerlo GPL.

La idea de Astat de los namespaces parece la más acertada.
Además, aunque haddd prefiera hacerlo 100% DirectX, creo que sería facilísimo abstraerse un poco y permitir que quien lo quiera pueda trabajar en distintos módulos.
Por ejemplo para el sonido, se puede hacer un interface genérico que hayan de cumplir todas las implementaciones : inicializar, cargar archivos, volumen, posicion, finalizar...
Luego se pueden hacer implementaciones que usen DirectX a pelo, que usen FMOD, BASS, OpenAL, Audiere o lo que se quiera.

No sé si me explico...  :huh:

Lo malo... pues la multitud de DLLs que podrían llegar a haber, pero vamos, realmente es más positivo que negativo, ya que permites a los usuarios elegir qué combinación usar : Graficos DX + sonido OpenAL, graficos DX + sonido FMOD, graficos OGL + sonido DX...

No sé si es liar mucho las cosas... pero bueno, al menos creo que vale la pena entretenerse con todas estas cosas antes de empezar nada, y definir bien lo que se quiere hacer.

Vamos, me va gustando cada vez más la idea, y parece que ahora sí la gente se anima.

Colson2 : A mí por ejemplo me gusta el tema de los motores, no sé, se aprende mucho sobre programación gráfica, que es algo que me gusta cada vez más.

[Haddd]

 Bueno, necesitamos ser unos cuantos más. Venga, animaos!!  (ole)  

[Zaelsius]

 Ager, en SourceForge aceptan cualquier licencia aprobada por la OSI. Las hay mucho menos restrictivas que la GPL.

[boubou]

 yo he programado unas clases para el motor (Mallas .x estaticas) y unas funciones para render (Falta una de inicializacion de dispositivo direct3d) , a este motor que vamos a hacer  lo he bautizado "Strat Engine" ¿que os parece?.


Sobre el hosting del proyecto:

-Hablar con Antonio Arteaga para que nos de hosting de este proyecto.

-Ir a SourceForge.

Aqui teneis las clases del motor, a ver si le gusta a haddd :) :

clases y dll lista para compilar

[Minos]

 Mnn, la idea me parece muy atractiva.

Aunque por falta de tiempo y andar ya liado en otros asuntos no pueda dedicarme a ella plenamente colaboraría de vez en cuando en codear partes de OpenGL (si al final este va a estar), una vez que esten definidas las interfaces a implementar.

Teneis todo mi apoyo.

[Haddd]

 Boubou, gracias por tu interés, pero ese no es el camino. La base es lo principal, y no podemos arrancar con una librería que carga un objeto .X. Pero tu entusiasmo dice muchas cosas buenas sobre ti. ¡Sigue así!

Deciros que he estado trasteando con C#. .Net ofrece enormes ventajas que creo que deberíamos aprovechar(ha sido completamente imposible compilar algo en C++.Net :( ) :

Unicode.
Cientos de clases probadas y funcionales.
Window Forms (chao MFC!!!).
Scripting a traves del mismo C#.
Gratuito(Express 2005).

También quiero contaros que no había hecho nada en C# hasta esta mañana y en unas horitas he "descubierto" como crear un device, crear un timer, funciones de texto. Lo digo por aquellos que como yo tienen reticencias a trabajar con lo desconocido.

Así que el tema sigue abierto. Esto va animándose, pero necesitamos más movimiento  (uoh)

Comentarios al respecto...

[Zaelsius]

 Me gustaria hacer saber que tanto Windows XP Service Pack 2 como los últimos drivers de ATI incluyen el .Net Framework 1.1.  Poco a poco más usuarios finales tienen instalada la plataforma .Net... lo cual es bueno para vuestro objetivo.