Sandra Engine 0.4 Y San Wrapper

[Pogacha]

Eso del San Wrapper esta por demas interesante ... no te molesta que te robe la idea?

Trankilo pogacha, para algo el proyecto es Open Source.... haz lo que la LGPL te permita ;)
De todos modos, ¿que tienes en mente?Quizá podamos unir fuerzas.

Que curioso que lo preguntes ... en realidad la idea de dos wrappers era para mi motor 2d ... creo que mi motor 3d murio un año atras  :(. Muchas veces estuve a punto de proponerte unir fuerzas pero como es un proyecto tan personal el tuyo pense que no te interesaria, también pense que como programas de una forma tan ordenada y prolija no podriamos compartir un proyecto ... si me lo pides te paso todo el codigo fuente del engine2 y sus utilidades (map2bsp y no me acuerdo si otras mas) a ver si algo te sirve, esta como lo deje hace un año, en realidad muchas cosas estaban en transición y no servirán ni como ejemplo, el render principal esta medio mal armado, estaba esperando terminar con el svbsp para refactorizarlo como debe pero al final no pude.
Tambien tenia una parte de fisica que no anda y bueno ...

Yo si tuviera que volver a arreglar el Engine2, lo dejaria y empezaria el Engine3 de 0, he aprendido tantas cosas con el motor 2d que implementarlas seria mas engorroso que hacer todo de nuevo.

Te deseo la mejor de la suerte con vuestro motor, que termine con un juego AAA!!!

Saludos.

[DraKKaR]

 ¿Porqué crees que es demasiado personal como para que alguien quiera ayudarme? Tal vez lo fuera cuando lo presenté como proyecto de fin de carrera, pero ahora lo concibo como un proyecto donde todo el mundo puede participar.

Si no te sientes cómodo tocando el mismo código fuente que yo, siempre puedes tocar código fuente de otros módulos hechos por tí y que se comunican con el motor para complementarlo. Aquí hay una lista de cosas que podrían hacerse:

- Crear un renderer nuevo más avanzado. Los renderers se programan como DLLs separadas del motor que implementan la funcionalidad de representar el mundo en pantalla. El motor carece de renderer de DirectX. Además, si te gusta programar la parte gráfica, siempre puedes dedicarte a hacer un renderer que actúe como quieras sin preocuparte de toda la parte del motor que hay detrás. Sería muy interesante un renderer que se base en el shader model 2.0 por ejemplo para ofrecer todo tipo de efectos gráficos.

-Importadores/Exportadores para el motor. Aunque el motor importa desde MAX a un formato propio siempre se puede mejorar para añadir funcionalidad. Cargadores de modelos de Doom3 (tengo uno a medio hacer).

-Módulos del motor. Puedes dedicarte a programar el módulo de físicas, o de sonido, o de scripting del motor, (actualmente los que hay son muy básicos) que, como se hace en una DLL separada, no modificas código del motor en sí mismo.

-Herramientas entorno al motor. Todo tipo de herramientas que faciliten la construcción de niveles por ejemplo o la definición de sistemas de partículas...

-Hacer un wrapper del motor. Como San Wrapper no gustará a todo el mundo, puedes montarte uno propio.

-Programar el motor principal. Como open source que es, siempre se puede modificar el código fuente del motor principal.

Como ves hay un sinfín de cosas que mejorar sin tener que toquetear el código fuente del motor principal, así puedes ir a tu aire, programando una DLL separada.

Esto va dedicado a Pogacha y a cualquiera que quiera participar en el desarrollo de Sandra Engine, que se sienta libre de participar. Cualquiera que se vea con ganas y lo desee, puede enviarme un mail y le daré acceso a modificar los fuentes desde la página del proyecto de Sandra Engine en SourceForge.

Saludos!

[Pogacha]

 La verdad es que lo de motores me parece que terminó para mi ... todo a lo que puedo apuntar es al shareware en este momento por tiempo y utilidad ... :(
Suerte.

[cederron]

 En mi opinion os deberiais programar unas buenas clases Factory/Singleton para crear los objetos de vuestro motor. Es lo mas legible y modular.

P.Ej.

//ResourceMgr es una clase Singleton, por tanto se puede llamar en cualquier parte, y es Factory porque crea los otros objetos
//Obtenemos un punteo al gestor de recursos...

ResourceMgr     *resMgr   =   ResourceMgr::Instance();

//Ahora creamos los objetos...

LightResource    *lightRes =      (LightResource *) resMgr->NewResource( TYPE_LIGHT );
MeshResource    *meshRes =    (MeshResource *) resMgr->NewResource( TYPE_MESH );
TexResource       *texRes =       (TexResource *) resMgr->NewResource( TYPE_TEX );

//Seguidamente trabajariamos con los objetos creados

Realmente asi no me parece que haga falta API de mayor nivel pues es muy legible ni acceder por otras clases.

[tamat]

 ^Creo que esa solución que tu planteas es la más obvia y todos ya la han tenido en cuenta. Perdon por el apunte, no pretendo trollear.

[cederron]

 A lo mejor he dicho lo obvio, realmente no he mirado el codigo de esos motores. Pero es que al ver el codigo de uso de los motores me he quedado un poco  :blink:   api en c? y lo otro supongo que sera la manera de programar en c# del cual no tengo ni idea, lo unico que puedo decir que me parece un poco enrevesado