Hola a todos,

Soy usuario de estos foros de hace años aunque hace tiempo que he estado algo inactivo.

Me gustaría presentaros el juego en el que hemos estado trabajando: se llama Rise of the Overlords, y es una combinación entre juegos de cartas coleccionables (como Magic o Hearthstone) y juego de mesa (como heroquest o descent).

La idea es hacer un juego de cartas en el que sea importante no sólo cuando jugarlas, sino también como moverlas sobre el tablero, hacer emboscadas, cubrirse de ataques tras muros u otras unidades, explotar las habilidades espaciales de tus unidades.

Además, habrá un modo single player o modo campaña que explotará las mismas cartas y reglas que el juego PVP pero orientado a la exploración de mazmorras enemigas, buscando trampas ocultas, puertas secretas, matando al boss final... Este modo podrá ser colaborativo de modo que podáis explorar una mazmorra simultaneamente por turnos con un amigo.

Todavía no hay mucho visible online pero os dejo el enlace a ver qué os parece el concepto de juego:

http://www.riseoftheoverlords.com

La web la iremos actualizando con el tiempo con nueva información.

¿Qué os parece?

Nuestra idea es empezar una campaña de Kickstarter cuando tengamos suficiente comunidad detrás. ¿Alguno de vosotros que haya hecho crowdfunding nos puede ayudar un poco en esto?

Si os gusta el juego y queréis apoyarnos nos sería muy útil si pudierais pinchar a "me gusta" en FB, compartir el enlace con vuestros amigos, o mejor aún hablando de él en otros foros.

Saludos y gracias por vuestro tiempo.

[Aprovecho para hacer una petición de colaboración]

Hola a todos! hacía siglos que no posteaba en Stratos!

Antes de nada feliz navidad con retraso y feliz año nuevo por adelantado ;)

Me gustaría mostraros el proyecto en el que estoy metido junto con otros colaboradores de varios países.

Se trata de Open Fighting Game Project (nombre provisional a la espera de que se nos ocurra un buen nombre para el juego)

Desde la siguiente web podéis descargaros la última versión del juego y acceder a toda la información relacionada.

http://openfighter.wordpress.com

Os dejo el video de youtube:

http://www.youtube.com/watch?v=G-PyrkUvh7g


Como podéis ver en el video la programación del juego está bastante avanzada y permite que el juego ya sea completamente jugable. Lo que más lastra el avance del juego es sobretodo el tema de las animaciones: se necesitan muchísimas para un juego de lucha.

Aprovecho para hacer una petición de colaboración.
Necesitamos sobretodo riggers y animadores, pero también aceptamos modeladores, texturadores y dibujantes de bocetos.

Os dejo una captura aleatoria del juego:


Espero que el proyecto sea de vuestro agrado y que podáis colaborar.

Saludos!

Hola, me gustaría saber cómo se suelen implementar las colisiones típicas del personaje sobre el entorno en los motores de juegos. Supongo que aproximan el personaje con un cilindro o una elipsoide para garantizar que sólo hay un punto de contacto y determinar la dirección de movimiento resultante de la colisión, pero sólo son suposiciones.

¿Sábeis como se suele hacer? ¿Sabéis de algún buen tutorial en la Web?

Saludos.

Hola a todos. Estoy escribiendo un artículo sobre generación rápida de sombras suaves para un congreso (EuroGraphics) y me gustaría tener  un código / programa lo que sea que permita cargar una escena simple (shadow caster y un shadow receiver) y que use la técnica Percentage-closer soft shadows (PCSS) para medir tiempos.

Os estaría eternamente agradecido. Además, pondría en al sección de agradecimientos del artículo al autor del programa.

Gracias de antemano.

Hola, desde hace un tiempo, me he estado preguntando sobre el posible futuro de un programador 3D en tiempo real que no quiera dedicarse al mundo de los videojuegos. ¿Veis posible un producto de este tipo fuera de este sector? ¿En qué tipo de mercado podría funcionar?¿Sabeis de algún producto de este tipo que funcione?

Yo he estado viendo por la web algun que otro software de visualización de entornos arquitectónicos, pero no demasiados.

Simplemente por curiosodad.

Saludos.

Hola! ya hace tiempo que no escribía. Resulta que queremos hacer una aplicación 3D multiusuario orientado a la visualización de stands y quería saber cual sería la mejor opción en cuanto a motor para usar. Hemos estado usando Torque para algunas cosas pero nos ha dado muchos problemas y me gustaría saber si existen otras alternativas (a un precio menor de 3000 euros por ejemplo).

Saludos!

Hola, me ha surgido una cuestión que seguramente vosotros me podréis contestar. ¿Existe alguna forma de hacer un render a textura a una rodaja de una textura 3D? Sé que en OpenGL sí se puede, pero no controlo lo suficiente Direct3D para poder saber si en D3D se puede.

¿Cual es el veredicto?

Según parece, la XBox podría soportar DirectX 10 simplemente mediante la instalación de los drivers oportunos.

http://www.meristation.com/v3/des_noticia.php?id=cw44eb89875b6a3&pic=GEN

Si se trata de una estrategia de mercado me descubro ante Microsoft. Microsoft desde siempre ha anunciado que su XBox soportaría Dx9. Esto podría haber repercutido en la decisión del soporte DirectX de sus competidoras. Y ahora, resulta que el hardware de la XBox360 realmente sí está preparado para DirectX10 y que se podrá actualizar en un futuro. Esto podría desmarcar muchísimo la potencia gráfica de la XBox, ya que (en mi opinion) DX10 es un cambio tan grande como lo supuso la aparición de los Shaders.

Para los que no lo habíais visto: http://www.meristation.com/v3/des_noticia.php?id=cw44e8cfbf52e3e&pic=GEN

Me han sorprendido mucho sobretodo cosas las siguintes, sobretodo de Carmack:
"se centrará menos en los gráficos que en el diseño de los juegos"

"Carmack comentó que la tecnología está tan avanzada que 'estamos cerca del punto donde no es beneficioso aspirar a más'"

"cada vez más el impresionar a la gente va a venir (...) de lo que hagas con el contenido más que con la tecnología."

¿Estaremos llegando a ese stado en el que las compañías empeicen a mirar más por la jugabilidad que por los refritos con mejores gráficos? Carmack parece que quiere seguir ese camino y no es el único, ya que la Wii sigue ese mismo razonamiento...

[Sobre el juego]

¡Hola! ¡Cuanto tiempo sin pasarme por aquí! He estado bastante liado últimamente, pero ahora que estoy de vacaciones tengo algo de tiempo para echaros una ojeada de cuando en cuando. Bueno vamos al grano.

Últimamente he estado retomando un juego que dejé aparcado hace tiempo, pero que ahora estoy intentando sacar adelante. Se trata de un juego multijugador on-line. ¡No os tireis a mi cuello aun! No es un MMORPG ;)

Sobre el juego

Se trata de un juego bi-jugador por turnos. Es un juego de estrategia que consiste en un tablero de casillas hexagonales donde el jugador debe mover sus criaturas para derrocar al contrario. El jugador se representa como una criatura más (el hechicero). Para vencer al hechicero enemigo podrás invocar criaturas que, luchando contra las criaturas del hechicero enemigo, logren llegar hasta él y asestarle el golpe fatal. Cada criatura contará con habilidades propias y estarán dotadas de varias características que el jugador deberá saber explotar para vencer al contrario.

Además,  aparte de criaturas el jugador podrá hacer conjuros que tendrán cierto efecto sobre las criaturas. Una invocación de criatura es un conjuro más. Los conjuros están en el grimorio del jugador. Al principio el jugador no podrá ver todos los hechizos que contiene el grimorio, que se le irán presentando a medida que pasen los turnos de una manera medio aleatoria - medio dirigida.

Bueno básicamente el juego trata de eso. Aunque las reglas del juego están descritas en un documento (de andar por casa) son susceptibles de cambiar a medida que vayamos testeando el juego y encontremos la mejor combinación de reglas para hacerlo divertido y sobretodo estratégico.

El nombre
Como habreís notado por el título del post, todavia no sabemos que nombre ponerle al juego. Mi idea era Tierra Oscura, pero no acaba de convencer. Despues surgió pugna, por buscar algo en latín. Pero tampoco acaba de convencer. Lo ideal sería una palabra en latín que suene bien (así es mas internacional, porque no me gusta que el nombre esté en inglés) o ponerle de nombre el nombre del reino donde habitan estas criaturas y sus imperios. Se admiten propuestas ;)


Estado de desarrollo
El desarrollo del juego aún está en estado prematuro. Me estoy encargando de la programación yo solo. De las reglas y el diseño general del juego nos encargamos un amigo y yo. No estamos haciendo NADA relacionado con los gráficos. Reuso mallas 3D típicas de 3D studio y blender, como la tetera y la cabeza de mono, y texturas de toda la vida. Ni siquiera se renderiza con iluminación. No hay sonido todavía. No quiero molestar a nadie hasta que la programación, que es lo que depende de mí esté solucionado al menos al 90%.

Lo que más me preocupa ahora mismo es tenerlo programado todo de forma que sea jugable. Aunque sea con gráficos de prueba. Una vez haya conseguido eso hare un call to arms para ver si a alguien le interesa encargarse de la parte gráfica y de sonido.

El juego se está programando con mi propio motor, el Sandra Engine. Pero no con la interfaz "a bajo nivel" del motor, sino a través de la interfaz simpificada: San (de Sandra Simplified). Esta interfaz ya la mostré hace mucho tiempo, pero ahora la he cambiado para que sea orientada a objetos y muy muy sencilla de utilizar. Un ejemplo de su sencillez es que la interfaz San no utiliza punteros para NADA. El usuario solo se preocupa de crear objetos, utilizarlos y darlos de baja cuando quiera paa que el motor libere la memoria cuando lo considere oportuno.

La parte de la programación de Red está al 90% terminada. De hecho ya pueden jugar en red 2 adversarios con las 2 criaturas que tengo definidas. Este tema es bastante sencillo al tratarse de un juego por turnos. No hay que estar constantemente enviando y recibiendo información. Sólo cuando el usuario haga alguna acción y haya que sincronizar las 2 instancias del juego.



Objetivo a corto plazo
Mi objetivo es tener programado toda la parte jugable del juego. Una vez lo consiga será el momento de crear criaturas, dotarlas de habilidades y modelarlas y animarlas. En el documento del juego hay descritas un total de 6 Imperios cada uno de los cuales tiene cierto número de criaturas propias con habilidades propias.

El objetivo a corto plazo sería crear un pequeño número de criaturas únicamente de un imperio, para probar la jugabilidad del juego y de las reglas.

El tiempo que tarden los artistas en modelas, texturizar y animar el pequeño conjunto de criaturas lo usaré para programar la parafernalia gráfica que falte: efectos de aparición de criaturas, partículas al golpear, ...

Objetivo a medio plazo
Con el juego básico acabado y funcionando. El plan es distribuirlo gratuitamente para que terceras personas lo prueben y aporten ideas, mejoras, bugs, sería una especie de etapa de beta testing.

Si el juego fuera bien acogido se seguiría con el desarrollo del juego que en teoría consistiría en corregir/añadir reglas/habilidades/efectos_gráficos en la parte de programación y seguir modelando nuevas criaturas hasta completar al menos un imperio, o como mucho dos, para tener más variedad.


Objetivo a largo plazo
Desde aquí aun no vislumbro objetivos reales a largo plazo, que dependerán en gran medida de como haya ido el desarrollo, la aceptación, etc. Y aunque en un principio se distribuya libremente, no descarto que si el juego sale bien y a la gente le gusta poder sacar dinero de alguna forma. Como por la venta del juego, como por el dinero que se pueda sacar de un portal web con información sobre jugadores, estadísticas, grimorios, etc...
De todas formas para esto aún queda mucho.


El juego ahora

Os dejo algunas capturas de como pinta ahora el juego. No os lo dejo descargar porque aún le queda para ser jugado por terceras personas. De todas formas no os guieis por los gráficos par anada peusto que ya os he dicho que son todos provisionales. PAra mí ahora lo que cuenta es la lógica del juego.

Para no molestar, os dejo una mini imagen aquí en el post, y unos links a imagenes externas un poco más grandes.



Imagen de la pantalla de inicio para elegir ser servidor o cliente de partida. O iniciar el juego sin red (solo para hacer pruebas de desarrolllo):
http://www3.uji.es/~jgumbau/shots/inicio.PNG

Esta imagen muestra la ventana de invocación de criaturas o conjuros:
http://www3.uji.es/~jgumbau/shots/invocar.PNG

Esta otra muestra la ventana de propiedades de la criatura desde donde peudes atacar a otra criatura o mover a alguna casilla.
http://www3.uji.es/~jgumbau/shots/atacar.PNG

En esta otra se muestra el conjunto de casillas a las que puede moverse la criatura en cuestión (en verde) dependiendo de su movimiento y del salto (desnivel que peude saltar entre casillas).
http://www3.uji.es/~jgumbau/shots/moviendo.PNG


Pues eso es todo por ahora. Ya os iré informando sobre como va evolucionando todo este a medida que pase el tiempo.
Para cualqueir sugerencia/duda/bomba podeis dejarme un post aquí o enviarme un correo a jesusgumbau@gmail.com.

Saludos!
Y gracias por leer la parrafada si haveis llegado hasta aquí ;)

[Wii]

 Parece ser que el nombre final de la consola será Wii (aludiendo al inglés we). Un nombre fatal a mi parecer,  pero al que seguro que acabaremos acostumbrándonos...

Podemos ver el anuncio oficial en la página de Nintendo.

Según nintendo:

Os presentamos a? Wii.
Se pronuncia como la palabra inglesa we, que significa nosotros.
El nombre en clave Revolution expresaba la dirección que queríamos seguir, Wii representa a dónde queríamos llegar.
Wii romperá todas las barreras que separan a los usuarios de videojuegos con el resto del mundo.
Wii acercará a los usuarios a sus videojuegos? y al resto de la gente.

Pero lo que te estarás preguntando es, ¿qué significa Wii?

Wii suena como we, lo que enfatiza que esta consola es para todo el mundo.
Wii es muy fácil de recordar para una persona de cualquier parte del globo, hable el idioma que hable. Sin confusiones. Sin necesidad de abreviaturas. Sólo Wii.
Wii tiene una peculiar doble i que simboliza tanto su mando único como la imagen de gente que se da cita para jugar.
Y Wii es el nombre de una consola que va a traer la revolución al mundo de los videojuegos.

Por todo esto es Wii.

 Hace un tiempo seconfirmaba que la PS3 contará con un port del SDK del Physx de Aegia para simular físicas usando algunos de sus cores del procesador CELL para esta tarea. Pero creía que todo esto se trataba de simulación de cuerpos RÍGIDOS, al estilo ODE. Sin embargo, en este video se ven además simulaciones de fluidos y deformaciones de objetos.

Que buena pinta tiene.

 Como ya hace tiempo que no os doy la brasa sobre el motor, voy a comentar algo de lo que he estado haciendo últimamente. En el trabajo tengo la misión de implementar una librería (¿no deberíamos llamarlo bibliotecas?) de manejo de árboles y bosques multirresolución. La idea es conseguir algo similar a lo que es SpeedTree pero implementado sobre modelos multirresolución contínuos, no discretos. Os dejo una captura de pantalla:



Lo que se intenta es que la biblioteca gestione internamente y automáticamente la geometría de cada instancia de árbol y ajuste su nivel de detalle acorde a una serie de parámetros relevantes. Quería poner un video para que se vea todo en movimiento, pero era demasiado pesado, así que os dejo con las imágenes (en la web hay un par más).

Ya he dicho antes que la biblioeca debe ser totalmente independiente del motor o aplicación que se ocupa del render, así para probarla he usado el Sandra Engine, tan válido como cualquier otro para probar esa separabilidad deseada.

Para crear el bosque me decidí por no usar código fuente en C/C++ sino en explotar un poco más la posibilidad de scripting del motor. Hace un tiempo le doté la capacidad de ejecutar comandos de consola, de forma que implementar nuevos comandos es crear una nueva instancia que herede de la clase sandra::ConsoleCommand e implemente la función Execute(). Esto tenia la limitación de ejecutar comandos que el uruarios escribe en la consola, así que para poder ejecutar scripts implementé un nuevo comando de consola ("run") que se encarga de ejecutar por orden todos los comandos contenidos en un fichero de texto. De esta forma, la cosa ya empieza a ser un poco más scriptable.

Os dejo con el script utilizado para crear el bosque para explicarlo un poco.

Código [Seleccionar] Expand

loadplugin lodtree.dll

skybox load texturas\skybox\sky_l.bmp texturas\skybox\sky_r.bmp texturas\skybox\sky_d.bmp texturas\skybox\sky_u.bmp texturas\skybox\sky_f.bmp texturas\skybox\sky_b.bmp

skybox display 1

create vector 100,10,100
set max
create vector -100,10,-100
set min


loadmesh terreno.3ds -
set terreno
create spaceobj
set spterr
prop spterr.displayobj terreno
world add spterr
prop terreno.lighting 1
prop spterr.scale 4,1,4


repeat i 18

 lodtree create lodtree.ini
 set arbol$i$

 rand min max
 set randpos

 create spaceobj
 set s
 prop s.displayobj arbol$i$
 world add s

 raymeshcol spterr randpos 0,-1,0
 set finalpos
 prop s.pos finalpos

 prop arbol$i$.lighting 1

endrepeat


repeat i 27 from 20

 lodtree create tilia.ini
 set arbol$i$
 rand min max
 set randpos

 create spaceobj
 set s
 prop s.displayobj arbol$i$
 world add s

 raymeshcol spterr randpos 0,-1,0
 set finalpos
 prop s.pos finalpos

 prop arbol$i$.lighting 1

endrepeat



# Habilitar iluminaci
world addlight 100,300,0
world addlight 0,400,200
world addlight -150,-450,0
world lighting 1
world lightmul 50000
world ambient 0.3,0.3,0.3


loadtexture GRASS2.JPG
set terrtex
prop terreno.material.texture terrtex
loadtexture normalmap.png
set normalmap
prop terreno.material.normalmap normalmap


Por ahora el scripting por comandos de consola es algo simple. Cada línea en el script representa un comando (la primera palabra de la linea es el comando y el resto los argumentos).

Lo que primero hace el script es cargar el plugin del motor que utiliza la biblioteca de árboles (esa dLL es el nexo de unión entre el motor y la biblioteca). Después se carga un cielo (skybox) y se hace visualizable. Después nos definimos 2 vectores (max y min) que utilizaremos para obtener posiciones aleatorias donde "plantar" los árboles. Max y min representaran los límites en cada dimensión para la posición de cada nuevo árbol aleatorio.

El comando "set" es el que puede marearos. Realmente es un "apaño" que hice para no complicar mucho el scripting inicialmente. Cuando ejecutas un comando de consola, éste puede devolver un valor (de cualquier tipo: malla, textura, vector...). Set se utiliza para coger el valor devuelto por la última instrucción y asociarlo a la variable que se le pasa como parámetro. Realmente un bloque de este tipo:

Código [Seleccionar] Expand

comando arg0 arg1
set res

debería traducirse (y se implementará en el motor dentro de poco) como:

Código [Seleccionar] Expand

res = comando arg0 arg1

El siguiente bloque de isntrucciones simplemente carga un terreno contenido en un fichero 3DS, le asocia una variable y lo escala.

Además de comandos también se pueden definir nuevas propiedades para tipos de objetos. De esa forma, el comando "prop" ejecuta la propiedad al lado derecho del "." asociada al tipo de objeto del lado izquierdo, pasándoselo como referencia para poder modificarlo. De esta forma añadir nuevas propiedades a objetos (incluso en otros módulos o DLLs) es muy sencillo.

La instrucción repeat fue una de las últimas que añadí y permite crear bucles de un número determinado de repeticiones. Su sintaxis es bastante sencilla. Repiten todas las instrucciones que haya entre el repeat y el endrepeat, y además sustituye la construccion $var$ por el valor que tenga esa variable en cada iteración dada.

Dentro del bucle, lo que se hace a grandes rasgos es:
1- crear un nuevo árbol (la instrucción "lodtree" no está implementada en el  motor, sino en la DLL que hemos cargado al principio, de esta forma módulos de terceros pueden registrar nuevos comandos aumentando la funcionalidad del motor).
2- generar un vector aleatorio entre (min,max) en 3 dimensiones. Ese vector representará la posición del plano XZ (horizontal) donde se plantará el arbol.
3- calcular la colissión del rayo vertical desde la posición aleatoria hacia el terreno para calcular el punto de implacto y obtener la posición final donde se plantará el arbol.
4- Añadir el arbol al mundo y habilitar la iluminación.

El siguiente bucle hace lo mismo que el anterior salvo cargando otro modelo de árboles.

El siguiente bloque simplemente crea 3 luces puntuales y configura la iluminación para el mundo. Y por último se carga la textura del terreno y el mapa de normales del mismo y se aplica sobre él.

Os puede parecer raro el rumbo de desarrollo que estoy tomando. La causa es que no programo el motor en mi tiempo libre (hago cosas no-informaticas para intentar no quemarme) ya que además mi trabajo ya me permite jugar con el 3D y los gráficos. Poir eso aprovecho la necesidad que me surge en el curro para añadir nuerva funcinoalidad al motor, como en este caso.
Estoy de enhorabuena, el próximo paso es implementar sombras arrojadas para los árboles y podré permitirme implementarlas en el motor. Había pensado en usar shadow maps ya que los árboles ya tienen mucha geometría y no quería complicarla añadiendo volúmenes de sombra geométricos para las stencil shadows.

Bueno, eso es todo, solo quería comentar como andaba un poco el estado del motor que hace tiempo que no comentaba nada.
Por cierto, estoy implementando la carga de recursos dentro de ficheros ZIP, cosa que ya tengo casi al 100% (implementando una interfaz virtual de lectura de ficheros), el problema con el que me he topado es que me gustaría meter DLLs dentro del paquete (ZIP) y poder cargarlas desde dentro del ZIP. Lo que pasa es que las funciones de Windows para cargar DLLs (LoadLibrary[Ex]) no permiten cargar el fichero de un stream en memoria sino directamente del disco. ¿Alguien sabe como resolver esto?

Gracias a los que habeis leido hasta tan lejos ;)

 Buenas, habiendo comprobado personalmente la gran comodidad, facilidad de uso y potencia de la biblioteca OpenIL (carga y tratamiento de imagenes) que uso en el Sandra Engine, me preguntaba si existiría alguna biblioteca similar al estilo OpenIL pero orientada a la carga y manejo de mallas poligonales.

Buscando por internet lo único que he encontrado ah sido una biblioteca llamada OpenMesh. Lo malo que tiene es que parece que sólo soporta 4 formatos de archivo bastante inútiles para nuestros menesteres cotidianos (OFF,OBJ,STL y OM). Sería ideal una biblioteca capaz de cargar de forma todo lo transparente posible formatos mas ricos en este campo como MD5MESH, MD3, Mesh de Ogre...

¿Alguno de vosotros conoce una biblioteca similar?

De no existir ninguna propondría la creación de una biblioteca con estas características, de forma que no haya que replicar código cada vez que alguien quiera hacerse un cargador de lo que sea y de forma que si alguien hace un cargador de un tipo de archivo.. pueda servir para el resto de la comunidad.

 Buenas, me gustaría iluminar correctamente las dos caras de un triángulo. El problema es que por vértice solo se puede especificar una normal (la de la cara delantera), por lo que cuando se pinta la cara trasera, la normal que recibo en el vertex shader está invertida.

Hablando en OpenGL: en la pipeline fija puedes especificar el atributo two-side-lighting de modo que automáticamente se invierte la normal de las caras traseras. Sin embargo, usando shaders, parece que esto se lo tiene que currar el usuario. Lo que he hecho ahora es meter en un shader una comprobación de que la normal está mirando en sentido inverso, y en ese caso invertirla. Funciona bien pero se le añaden muchas instrucciones al shader, y creo que una cosa así tiene que tener una solución más elegante y menos fuerza bruta.

Lo ideal sería que OpenGL detectara que estás pintando la cara de atrás e invirtiera automáticamente las normales por vértice, aunque parece que no lo haga.

Estoy seguro que no soy el único que se ha topado con este "problema"... ¿alguna idea?

[San Wrapper]

 Buenas, acabo de subir la nueva versión de Sandra Engine. Como mayor novedad, a parte de incluir un renderer basado en iluminación por píxel y nurvas posibilidades con lso comandos de consola, es la inclusión de lo que he llamado San Wrapper.

Esto viene a raiz de un post que ya comentamos anteriormente (Teoria de Motores) en el que discutíamos la mejor manera de presentar el API del motor al usuario.

De esta manera hay 2 formas de usar el motor:

1- Usando el API del motor con todas sus clases y con la responsabilidad compartida con el motor sobre la liberación de recursos y gestión de memoria.

2- Usando San Wrapper (San viene de Sandra Simplified). Este wrapper oculta por completo todo el motor que tiene detrás y presenta al usuario un API en C llana. Además se encarga de la gestión completa de los recursos, de forma que se liberan limpiamente cuando no se necesitan. Con San Wrapper el usuario ya no trabajo con punteros que contienen objetos, sino que trabaja con identificadores opacos que apuntan indirectamente a objetos que están bien protejidos dentro del wrapper. Esto hace que la programación sea más simple, segura y productiva. A costa de perder algo de flexibilidad que normalmente no es necesaria en aplicaciones estándar.

He añadido un primer tutorial a la web del motor sobre San Wrapper, para que os hagais una idea de lo sencillo de usar que es (desde mi punto de vista). El tutorial es bastante simple, pero sirve de introducción. Más adelante pondré tutoriales más complejos para manejar mejor objetos. También podeis echarle una ojeadaal fichero san.h (desde el SDK o desde el CVS) para ver un poco todas las funciones que proporciona el wrapper.

Actualmente, el wrapper no expone toda la funcionalidad del motor, esto es algo que se irá mejorando con el tiempo (y con las propuestas de los usuarios).


Nada más, os agradecería que probarais el SDK o que echarais una ojeada al tutorial, ya que me sería de gran ayuda para obtener ideas, sugerencias y recoger fallos.


Trabajo futuro necesario:
- Mejorar el renderer de iluminación por píxel
- Mejorar las herramientas de exportación e importación de datos al motor

Como siempre, cualquier que quiera echar una mano en lo que sea tiene las puertas (y el código) totalmente abiertas.

Hasta luego!

[OPCION 1:]

 Hola, últimamente estoy replanteandome el diseño de gran parte del motor para conseguir algo más sólido. Me refiero al sistema de manejo de objetos/recursos del motor.

OPCION 1:
Ahora mismo, le pides al motor que cree una nueva instancia de un nodo de escena o de una malla. Entonces el motor te devuelve un shared_ptr (autopuntero compartido) del objeto. Entonces ese puntero se usa para añadirlo al grafo de escena, o en caso de una textura pse añade a las propiedades del material de un objeto. El "problema" de esto es que el objeto no "vive" de una forma clara en ningún lugar de la aplicación: mientras alguno de estos punteros compartidos apunte a un objeto, éste permanecerá vivo, y esos punteros están dispersados por todo el motor. Como además, estos punteros son visibles desde la aplicación que usa el motor, la responsabilidad de eliminar estos objetos es a medias del usuario/motor.

OPCION 2:
Una alternativa que habia pensado es, que cuando se cree un objeto/recurso, este se almacene en un lugar opaco del motor. Cuando se crea el objeto, el usuario recibe un puntero (normal) al objeto. El usuario sabe que no debe borrarlo nunca, sino que se eliminará cuando el motor lo crea oportuno. Aquí el puntero es un identificador del objeto y la resopnsabilidad de crear/eliminar el objeto es 100% responsabilidad del motor.
Aunque un problema que le veo a esto son inconsistencias del tipo: el motor ha eliminado un objeto, pero el usuario no lo sabe y está intentando usar el puntero identificador.

OPCION 3:
Esta opción requiriría un cambio más grande del motor. Se basaría en que el motro gestionara todos los objetos (creación y destrucción) de forma interna. El usuario no guarda ningún puntero al objeto, simlpemente un identificador numérico. De esta forma, cuando el usuario quiere acceder a un objeto para modificar sus propiedades o efectuar alguna operación, le pide al motor que le devuelve un puntero (lock) temporal al objeto/recurso, el usuario la modifica y lo libera (unlock). Esto es algo similar al mecanismo de Direct3D para modificar surfaces. De esta forma el usuario no va a intentar modificar un objeto/recurso eliminado por el motor, ya que este mecanismo controlaria si el objeto existe o no.

OPCION 4:
Similar a la opción 3, pero más similar al funcionamiento de OpenGL o ODE. El usuario guarda identificadores numéricos de los objetos y usa funciones del motor para modificar atributos de los recursos usando los identificadores. Esto sería como ODE, que aunque el motor está construido en C++, la interfaz es C puro. Es un cambio muy brusco a la interfaz del motor y a la forma de suarlo, pero le otorga mucha solidez.

Estas son las opciones que estoy barajando y a todas les veo cosas buenas o cosas malas. Me gustaría que discutiéramos estos aspectos y compartir las formas en que os habeis enfrentado a esto en vuestros trabajos.

Pensamient: Ciertamente, creo que la parte más complicada e importante de hacer un motor, es hacer su diseño de la mejor forma posible, ya que es la que lo limita o potencia.

 Pues sí, parece que ya hace ¡2 años! que está en desarrollo.... eso sí, por ahora solo trabaja en él una única persona: Tim Sweenie - sama.

Unreal Engine 4 en ps3portal

Para cuando la fecha de salido en un hjuego que use UE4?  :D

 Buenas, hay que ver como son los viajes que nunca salen como los planeaste... Tras estar unos dias en Barcelona con mi novia (somos de Castellón) hoy hemos decidido ir a nuestro siguiente destino: pasar unos dias en Andorra.
Pues resulta que a medio camino el coche (un Ford Focus de 6 años) ha empezado a rallarse: el indicador de temperatura ha empezado a subir escandalosamente (yendo por la autovía), aunque conseguía hacer que bajara un poco dejando de acelerar ( :( ). Ha llegado un momento que esto ya no ha funcionado y me han empezado a salir unas luces de emergencia amarillas con muy mala pinta.
El manual de instrucciones del coche (sí! tienen uno!) dice que si eso pasa que lo llevemos inmediatamente a un concesioario Ford... y nosotros perdidos en medio de la autovía...

Cuando la cosa ha estado muy chunga hemos salido por la primera salida que hemos pillado a un pueblo de Cataluña llamado.. mmm... Villanova del Camí... cerca de la famosa "Igualada", donde hace un mes que por fin tienen un carrefour...

Curiosamente, tras pillar la primera salida a boleo de la autovia, nos hemos topado felizmente con un concesionario Ford! Esto sí que es casualidad.. aquí perdidos por la montaña  :lol:

Hemos dejado el coche ahí y el mecánico (un viejete simpático) le ha hecho unas pruebas, y con una cara rara me dice que no sabe que le pasa al coche pero que no va nada bien... que ha cambiado el termostato y sigue yendo mal...

Así que aquí estamos, en un pueblo de cataluña, con el coche rebentado y sin saber cuando podremos seguir nuestro camino  (ole). Al menos son unas vacaciones entretenidas.

¿Que porqué cuento esto? Porque estando paseando por el pueblo, haciendo tiempo para ir al taller, nos hemos encontrado con una biblioteca pública, a la que hemos subido para pasar el rato. En la biblio hay 6 ordenatas con Internet gratuito a los socios de la biblioteca y aquí estoy yo, en uno de ellos posteando mi periplo.

Y ahora voy a desconectar y a ver al simpatico viejete a ver que me cuenta del coche. Os seguiré informando si os interesa  ;)

PD: Ya tengo carnet para cualquier biblioteca de Catañuña  :D
PD2: Tengo miedo de la factura del taller  (uoh)  

 Algunos problemas de punteros que he tenido en el motor me han llevado a pensar que toda la memoria que se reserve dentro de una DLL (dentro de funciones implementadas en una DLL) tiene que liberarse dentro de la misma DLL (por cuestiones del heap)... me gustaría saber si eso es así o no tiene porqué.

Gracias.