Ir al contenido principal

Entradas

Mostrando entradas de agosto, 2011

HD 6790, una oferta interesante

Si estás limitado en el presupuesto como yo, esta es una oferta a tener en cuenta. Recién descubrí esta tarjeta hace un par de semanas (y ni siquiera recuerdo cómo). El segmento de los $100-$150 llevaba tiempo tranquilo, con nada importante que mencionar. Recuerden que la opción más atrayente era la Radeon HD 6770, que en esencia es una 5770 renombrada y mejorada con nueva versión de HDMI y capacidad Bluray. Sin embargo, AMD no deja descansar este diseño y para la 6790 le amplían el ancho de bus a 256 bits y la sitúan alrededor de los $140.
El rendimiento es decente, próximo al de la Radeon HD 6850 (y te ahorras unos $20), aunque hay que considerar si vale la pena pagar $20 más por solo duplicar el ancho de bus o si es mejor esperar que se revele alguna nueva serie de tarjetas. Recuerden que la 5770 es tecnología con más de un año de antiguedad y AMD ya debería estar ultimando los detalles de la próxima generación.

Límites del cuerpo humano

Frank Dux (sí, Frank Dux existe) fue el primer y único artista marcial en romper un vidrio a prueba de balas con un golpe de palma. Ostenta otros múltiples récords de rompimiento de objetos.

Masutatsu Oyama, creador del estilo Kyokushinkai, venció una treintena de toros, algunos de ellos con un solo golpe. Para llegar al grado de maestría requerido y alcanzar el ideal "un golpe, una muerte", Masutatsu se aisló en las montañas de Japón durante 18 meses. También existe una película sobre él. Hecho curioso, aunque se convirtió en una leyenda en Japón, nació en Corea.
No solo en las artes marciales se lleva el cuerpo al límite, hace un par de meses la británico-australiana Penny Palfrey estableció un récord de larga distancia al nadar 108 kilómetros en el mar. Durante los 70-80, un campeón de natación soviético (armenio, kazajo o uzbeko, no logro recordar bien) fue testigo de la caída de un autobús al río. El nadador se lanzó a las turbias y frías aguas y rescató una treintena d…

Experimento con Lua

He tenido poco tiempo para dedicarle al blog en estos días debido a que he estado ocupado coordinando el trabajo en el proyecto, resolviendo pequeños detalles y trabajando en un experimento con Lua. Esta última idea consiste en hacer una aplicación donde los scripts tengan más preponderancia y controlen más la lógica del juego. La aplicación en C++ sería un mero lanzador con las funciones de bajo nivel, al estilo Unigine.
En teoría mientras más funciones estén del lado del script, más fácil sería para los artistas o iniciados entender el proyecto y probar cosas nuevas. De momento no tengo muy claro cuánto podría ir de cada lado, porque algunas cosas pueden ser complejas. Por ejemplo, el manejo de eventos de los widgets de CEGUI tienen que ser en C++ a menos que quiera enredarme con soluciones más complejas.
Hasta ahora lo único que he conseguido es una aplicación que inicializa Ogre y ejecuta un script en Lua que hace un lazo, en cada iteración se renderiza un cuadro y se captura la e…

Nuevos cambios

Para los que siguen el SVN del proyecto, buenas noticias. Ya está solucionado el problema del terreno, al final sí tuve que utilizar los mapas normales. Los escenarios han recibido los cambios adecuados y las texturas tienen su correspondiente mapa normal.
He reajustado la velocidad de las animaciones, ahora se corresponde mejor con la velocidad de desplazamiento. Esto pienso mejorarlo un poco más para introducir efectos como ralentización/aceleración de los personajes.
Otro detalle es que se corrigió el fallo de que las entidades no llegaban a ser destruidas (un pequeño error al iterar las entidades). Además reduje el tiempo de gracia, ahora son removidas más rápidamente. Aquí aún persisten problemas que tengo que revisar con calma.

Como pueden ver, también estrenamos nuevo modelo de casa, gracias a Ludo. El anterior, que tenía la textura incompleta, ha sido retirado hasta que se decida qué hacer con él.

Problema de texturizado de terreno corregido

Como pueden ver en las imágenes de hace unos días, la textura del terreno se veía rayada. Durante un buen tiempo me rompí la cabeza inútilmente tratando de encontrar la causa y todo se debía a un olvido de mi parte. El error está en el código siguiente:

for (int tl=0;tl         imp.layerList[tl+1].worldSize =  30;
        imp.layerList[tl+1].textureNames.push_back(layers[tl]);
        imp.layerList[tl+1].textureNames.push_back(normaps[tl]);
    }

En concreto: imp.layerList[tl+1].worldSize =  30;
Esto al parecer ajusta la textura en forma de mosaico sobre el terreno, pero causa las franjas. La forma correcta es:
imp.layerList[tl+1].worldSize =imp.worldSize;
Esto tiene el inconveniente  de que la textura debe ser muy grande para adaptarse al terreno sin verse mal, lo cual, si no ando muy errado, es igual en Unigine (que usa texturas de 2k x 2k en el terreno). No sé si utilizando texturas continuas se pueda solucionar el problema, porque justo ahora solo una de las que utilizo lo es. D…

Al fin, corremos en Windows otra vez

Ayer me dediqué a rehacer el proyecto de Visual C desde cero, con algo de éxito. Por alguna razón la versión Debug no funciona, pero en cambio, la versión Release sí. También se estropeó el generador de la instalación, un daño colateral lamentable, porque ahora tendré que ver cómo distribuir el tech-preview para Windows. Si todo va bien hoy le dedicaré algo más de tiempo y podría tener la demorada versión de Windows mañana o el lunes.
La causa del problema todavía no la sé, al parecer mantener controlado el entorno de desarrollo en Visual C es un poco complicado y se pueden colar versiones de DLLs que no coinciden con la lib correspondiente si no te andas con cuidado.

Gráficos integrados de Intel en Linux: muy mal

Por razones financieras he tenido que deshaceme temporalmente de mi tarjeta de video en casa, así que me vi forzado a experimentar cómo se mueven las cosas con una Intel integrada (GMa4500 si no recuerdo mal). Luego de algunas actualziaciones en Gentoo logré que funcionara, incluso con Direct rendering habilitado. Lamentablemente el proyecto no camina, solo el menú inicial ya se ve un poco lento y al entrar al juego lo que muestra es una pantalla en negro. Al parecer nada de lo que estoy enviando a la tarjeta logra renderizarse. Eché un vistazo a Warzone 2100, que tiene su propio motor gráfico y amén de verse lento, tampoco logra mostrar los modelos de las unidades, apenas saca unas líneas punteadas en los bordes y eso es todo.
Evidentemente las gŕaficas Intel no sirven para jugar, pero al menos en Windows la mayoría de las cosas se ven (solo eso). En cambio, el soporte OpenGL en Linux es pésimo y es de esperar que solo admita cosas muy básicas. O sea, que si quieres empezar a practic…

Tenemos tracker

Hoy he dedicado un buen rato a organizar los trackers del proyecto en Sourceforge. Por haraganería y escaso ancho de banda no los había configurado propiamente, así que llegué a tener un reporte de bug (el único) sin atender durante seis meses, lo cual no es nada agradable para el usuario. Pero ya activé las notificaciones y estoy revisando las categorías, algo que se hace tracker por tracker, porque no son genéricas. De paso, también activé el método de soporte, le eché un vistazo a los foros y creé una lista de correo para los desarrolladores.
El tracker de Sourceforge no está mal, aunque no puedo decir lo mismo de los foros, que eran un poco primitivos y que veo que han recibido algo de trabajo.

Regocijaos, Heroes of Newerth es gratis!

Y además con cliente nativo para Linux, nada de wine. Las limitaciones son bien pocas, hay menos héroes y pacotilla, pero incluso esto puede subsanarse con suficiente tiempo de juego. Para los que no lo conozcan, Heroes of Newerth es un juego estilo DOTA y no daré más detalles.
Tengo muy poco que criticarle, solo que requiere 2Gb de RAM  para correr y aún así es inestable. El motor se mueve muy bien en mi Geforce 9500 y el manejo de la latencia es genial, apenas se nota a pesar de que tengo 850-900 ms.

Aplicación básica de Ogre lista

Ya está disponible para descargar una pequeña aplicación básica  de Ogre 3d. Incluye un par de proyectos de Visual C 2010 y Code::Blocks, no los he probado a fondo porque lo más importante es el código. He tratado de mantenerla lo más simple posible: inicializar Ogre (incluyendo RTShaderSystem), cargar un sky dome y salir con Escape. La licencia es más o menos libre: pueden hacer con el código lo que quieran y espero que les resulte útil. Se aceptan donaciones, claro (estoy ahorrando para comprarme un jet privado).
Como pueden ver en el enlace, estoy probando Ubuntu One. La idea está buena, aunque bastante limitada. Por ejemplo, creo que no tendré estadísticas de las descargas.

Un pequeño aporte

En los escasos minutos que he tenido en estos días he estado trabajando en algo que tenía en mente desde hace tiempo. Muchas veces tenemos que hacer un proyecto en Ogre y hay que pasar por el trabajo de crear la solución de Visual C, el proyecto de Code::Blocks, el SConstruct... Eso sin hablar de que la inicialización de Ogre lleva lo suyo. Sí, los App Wizards crean un proyecto, pero lo hacen usando un enfoque que no es idóneo si quieres controlar el lazo principal por ti mismo, así que hay que reescribir casi todo y corregir los errores.
Es por eso que decidí hacerme una aplicación mínima que sirva como base para crear un proyecto rápidamente, incluyendo RTShader. En cuanto termine los targets de Code::Blocks para Windows la colgaré en algún lugar para que le sirva a cualquiera.