Sandraengine Y Un Tutorial

[DraKKaR]

 Hola, después de mucho tiempo trabajando en el engine, he decidido publicar lo que tengo hecho en forma de SDK. El SDK contiene los mismos ficheros que he estado usando para realizar  un par de proyectos, de esa manera voy depurando el motor y viendo donde falla. La principal razón de publicar la primera versión del motor es que terceras personas (vosotros XD) me digais que os parece por ahora la estructura del motor y como podría mejorarla. Para ello, voy a reazizar una serie de tutoriales que harán más sencilla la comprensión de la filosofía del motor, aunque de todas formas se incluye una documentación con el SDK del motor (aunque todavia le faltan muchos comentarios).

La página del motor es la siguiente:
http://www.sandraengine.tk
ene sa dirección podreis encontrar tanto el SDK como el primer tutorial.

El primer tutorial trata sobre lo más básico, inicialización del motor.

El SDK representa la primera versión que he publicado del motor, y que llamaré 0.0.1. éste contiene lo siguiente:
- los ficheros de cabecera (includes) del motor.
- las librerías para linkar contra ellas.
- la documentación.
- los binarios necesarios para ejecutarlo.

Me gustaría oir opiniones, sugerencias, etc, aunque con este tutorial no se muestren muchas cosas del motor, espero que me vayais diciendo que tal va en posteriores tutoriales.

Hasta luego.

[Haddd]

 He mirado los includes y leido el tutorial y la verdad es que tu nivel de C++ es excelente!  (ole)

Cuando he visto tus clases y la idea de modularidad, pues la verdad es que he pensado mucho en las primeras versiones de mi motor. La idea es muy buena:modular y sólo tienes que hacer pequeños cambios en los módulos que toca y listo. Pero con el tiempo he desechado este modelo, porque lo he tenido que rehacer tantas veces que por mi experiencia, no es un buen sistema de desarrollo. Voy a hacerte un simil con Gestión:

¿Que es mejor, un programa genérico de facturación o un programa a medida?

Está claro que con un programa genérico puedes ir ampliando módulos para hacerlo más adecuado a cada empresa, pero el esfuerzo será tremendo y nunca llegará a ser tan cómodo ni tan fácil de mantener que uno a medida para cada empresa.

Con los motores es igual. No puede existir un motor génerico bueno(por bueno me refiero a fácil de usar, mantener y potente). Se deben enfocar los motores para cosas concretas.

[Grugnorr]

 No estoy de acuerdo contigo, Hadd. El tema es que es mucho más difícil hacerlo genérico y extensible, pero una vez hecho mucho mejor.

y nunca llegará a ser tan cómodo ni tan fácil de mantener

Fácil de mantener?  :blink: , suele ser mucho más fácil de mantener un motor bien diseñado y muy modularizado.

PD: Cada cual con su estilo, Carmack es de tu escuela  :D  

[CoLSoN2]

 mira Ogre, está genialmente diseñado y es totalmente genérico

[Loover]

 Desde luego cuanto más genérico, más tiempo te lleva. Eso esta claro como el agua.
De hacerte unas clases que manejen una api para cosas concretas a hacer un motor genérico hay un gran trecho. Y cada uno se plantea lo que quiere hacer y a partir de ahí pues se monta el sistema que vea mas viable...

[DraKKaR]

 Yo también creo en una buena modularidad, gracias a abstraerme del contexto de render por ejemplo, me ha ayudado a saber diferenciar bien las cosas, y saber discernir donde tiene que ir cada cosa. Y bueno, como dice Loover cada uno se marca sus propias metas, la mia era (entre otras muchas) que le motor fuera independiente del render, que simplemente ofreciera una interfaz de comunicación. Esto me gusta mucho ya que, ahora, con relativa facilidad, puedo implementar un renderer por opengl, d3d, por software e incluso hacer el motor bastante portable, y no me refiero solo a linux. Imagina que quiero hacer portar mi motor para usarlo en una PS2, en teoria, escribiendo un neuvo renderer que usara la API gráfica de tal consola bastaria. (En teoria XDD)

Tambien es verdad que hacer el motor directamente sobre un API tiene muchas ventajas, al estar tan adheridos, todo es cuestion de prioridades personales.
Como ejemplo de odularidad pondria los UT, que mediante un plugin implementan renderers. Com contra-partida, el HalfLife2, que (me parece que) estará muy apegado a DirectX9 para aprobechar bien sus caracteristicas, y por esa misma razon me temo que no habrá HL2 para linux (y sí que habrá UT para linux).

[Haddd]

 Exacto, tienes sus ventajas y sus inconvenientes. No digo que no sea lo mejor hacerlo modular, digo que te llevará más tiempo y que si tienes que hacer un cambio importante de estructura, será mucho más costoso. Pero que me parece fantástico si tienes tiempo y que como bien dices has aprendido donde tiene que ir cada cosa.

No era una queja, era para que conocieras mi experiencia, nada más.

[ethernet]

 Supongo q sandraengine sea un singleton, excepciones SUCKS (como mucho en debug) y espero que sandra::Window sea un typedef shared_ptr> window;

Un ejemplo bastante interesante de como hacer modulos de render indepedientes esta en el codigo del Unreal (como no).
;P

saludos

[DraKKaR]

 Ups, no habia visto este último post XD

1º: no se que es un singleton XD
2º: a mi las excepciones no me hand ado ningún problema y me son realmente útiles (capturar errores desde dentro de constructores que no pueden devolver nada)
3º: No se a que viene lo esto:

espero que sandra::Window sea un typedef shared_ptr> window;

PD: Parece que el código del Unreal sea el sumum de la buena programación y del diseño.

[AgeR]

 

1º: no se que es un singleton XD

Ki fuirti, a tu edad!  :ph34r:
Básicamente es una clase de la que sólo puede haber una instancia en toda la aplicación.

Lo del tercer punto, de la ventana, supongo que se referirá a que no es lo mismo una ventana en Windows ke en Linux por ejemplo, y si el código ha de ser portable debes tener esto en cuenta.

De todos modos, a ver si trasteo un poco con tu SDK, que supongo que es lo que pretendes al fin y al cabo.  :lol:

Saludos!

[DraKKaR]

 Hombre, pues sí, de la clase SandraEngine sólo debería haber una única instancia, aunque no lo controlo. Supongo ke debería hacerlo.

Sobre lo de las ventanas: sí, el código crea ventanas tanto para linux como para windows. La interfaz no cambia nada, simplemente que las funciones están implementadas de distinta forma según para que plataforma se compile.

Trastea, trastea. Lo que pasa es que la documentación no está ni mcho menos acabada, poco más que empezada) , y el tutoruial que hay en la página del juego es muuy simplón. Pronto crearé un segundo tutorial sobre como hacer alguna cosilla más interesante.