Muy buenas,

ando trasteando con el ejemplo de putpixel que trae la documentacion de SDL. Por lo que se, es recomendable bloquear la SDL_Surface con SDL_LockSurface antes de proceder con el pintado del pixel en si mismo y despues desbloquear con SDL_UnlockSurface.

La pregunta es: ¿esta funcion es arriesgada en algun sentido?. Porque estoy haciendo pruebas con el ejemplo, y a veces salta por los aires. Me sale hasta backtrace (o como se escriba) y todo.

Buenas, tal y como se me recomendo estoy haciendo un mini matamarcianos para poner a prueba la libreria que he desarrollado, con la idea de ver sobre el terreno como va todo.

Sin embargo he visto que me va a tomar mas tiempo del que pensaba, y eso que era en plan mini. Por eso se me ha ocurrido que una cosa no quita a la otra, hacer de todas formas unos breves tutoriales concretos que demuestren las capacidades de la libreria. Por ejemplo:

- Tuto sobre como crear una entidad y como destruirla, en plan "Hola mundo"
- Tuto sobre mover entidades.
- Tuto sobre planos: que son, crearlos, usarlos, borrarlos, etc.

Todo en plan mini ejemplos "tipo DIV2".

¿Que se conseguiria con esto?. Una forma rapida de ver como se usa todo y que la gente pueda aportar las ideas que se le ocurran para mejorarla, todo ello sin tener que esperar a terminar el mini juego.

Yo creo que seria positivo hacer esto. ¿Opiniones?

Anotado todo esto, gracias.

Tampoco es necesario que lo hagan ellos mismos xD pero siempre pense que era un poco raro que no hubiera un detallado analisis de todo el proceso de desarrollo, dado que desde el punto de vista didactico creo que fue algo muy interesante.

Si, lo habia visto ya.

Pero esa pag parece explicar como funciona el Quake engine en si mismo, no la forma en que lo hicieron.

Eso vi, y me dejo muy intrigado el asunto. Mas tarde lei de casos de programas muy apoyados por sus respectivas comunidades de usuarios, que habian reunido el dinero suficiente para comprar el codigo fuente a la empresa propietaria de turno y hacer que se convirtiera en GPL. Y los propios usuarios lo mantenian actualizado y ampliando sus caracteristicas.

En su dia dedique un tiempo a buscar en Internet acerca del metodo usado para crear el Quake engine, algo del estilo "se han usado estos programas y se ha hecho de esta forma", pero o no lo encontre o no esta online esa informacion.

Y respecto a que le he dado demasiadas vueltas a este tema.... pues no se si demasiadas, pero darle de vueltas le he dado... muchas xD

Creo que todos los que conocemos un poco de C/C++ y tenemos Internet hemos bajado el codigo fuente del ftp de ID y lo hemos estudiado (o intentado) con la esperanza de entender un poco como funciona por dentro. Y creo que mas de uno (si, me incluyo) nos hemos quedado con cara de  Oo

A lo que voy es a lo siguiente. Si desarrollas algo bajo GPL (por poner un ejemplo de licencia) todo lo que hagas queda bajo licencia GPL: codigo fuente, manuales, ejemplos, imagenes, sonidos, etc.

Si lo haces bajo codigo cerrado, lo que haces queda cerrado y sujeto a las restricciones legales de cada licencia (por ejemplo, EULA).

Quake fue desarrollado usando "Quake C", un lenguaje creado para programar Quake usando el lenguaje C como modelo. Y aqui es donde yo me lio: la wikipedia no indica que programa (o programas) usaron para crear QuakeC, ni tampoco la licencia del propio QuakeC.

¿Que licencias usaron para liberar el motor solo cuando quisieron y no desde el principio cuando publicaron Quake?.

Para algunos este tema tal vez sea una tonteria, pero siempre me ha intrigado.

Leyendo por Internet unas cosas sobre engines, me llamo la atencion esto que encontre acerca del Quake engine.

"Quake engine es el motor de videojuego que fue escrito por id Software en 1996 para su videojuego Quake. Fue uno de los primeros en incorporar renderizado en autenticas 3D en tiempo real y en la actualidad se encuentra liberado bajo los terminos de la licencia GPL."

Lo que me ha chocado ha sido la ultima parte: " en la actualidad se encuentra liberado bajo los terminos de la licencia GPL.". ¿Que sucedio aqui exactamente?, ¿era codigo cerrado y luego paso a ser GPL de alguna manera?.

Fuente: http://es.wikipedia.org/wiki/Quake_engine

(Edito para añadir la referencia a la wikipedia)

Muy buenas,

tengo un teclado Genius, comprado hace ya algun tiempo, para que os orienteis de cual uso.

¿Las teclas que hay a la derecha de las flechas del cursor se suelen usar en los juegos?. Es decir, donde hay una zona de 3x3 donde las teclas estan numeradas del 1 al 9 y tienen funciones añadidas, detallo:

1 - Fin
3 - AvPag
7 - Inicio
9 - RePag

Al lado de estas estan BloNum, Intro, Ins, Supr, y las teclas de la suma (+), resta (-), multiplicacion (*) y division(/).

En un juego de teclado+raton CREO que estas teclas no se suelen usar, ¿no?. Y en un juego de solo teclado, CREO que tampoco. Creo que la gente suele ponerse mas en las flechas del cursor o en la parte habitual del teclado para escribir.

Buenas, por fin tengo un  momento para postear, que estos dias voy de cabeza totalmente.

Ha sido un #define mal puesto, resultado de un "experimento" que hice hace tiempo y que, entre unas cosas y otras, no me acorde de quitar. Y como hasta ahora no me habia metido con programacion de audio, pues ahi se quedo y yo sin darme ni cuenta :P

Buenas,

estoy haciendo unas pruebas de sonido en C/C++ son SDL y SDL_mixer y me ha pasado una cosa muy curiosa, al intentar compilar me da error en cosas que no tenen nada que ver., unas funciones que estan relacionadas con los graficos.

En la libreria que estoy haciendo, cada cosa va por separado: teclado, graficos, sonido, etc.

Otro error que me ha dejado chocado es que me diga que una clase que estoy escribiendo y me diga que esta ya definida en el archivo SDL_mixer.h. Abro el archivo en cuestion para comprobarlo,  y no existe la clase en cuestion.

Ya hay, a modo de tutorial, una serie de mini-programas que muestran el funcionamiento de la mayoria de las cosas.

Tal vez lo mejor sea hacer la libreria sin un algoritmo concreto de busqueda de caminos, y que los usuarios aporten diversos algoritmos adaptados a la forma de trabajar de la libreria.

Veamos, el motivo por el que estoy siendo tal vez un poco difuso es porque no estoy haciendo un juego, sino una libreria.

La idea es usar el lenguaje C, con la libreria SDL y  otras asociadas (SDL_image, SDL_ttf, etc) para facilitar la creacion de juegos 2D bajo Linux. Seria algo asi como una especie de DIV2, pero en Linux.

DIV2 tenia un algoritmo para esto, el "A estrella", y la superficie del mapa de durezas era de como maximo 256x256 pixels. Todo este asunto es para eliminar las limitaciones que en su dia dio el algoritmo (como usuario que fui, para algunas cosas era un calvario), tras leer unas cuantas opiniones por ahi y por alla, pense que posiblemente una buena opcion seria tablas precalculadas. De esta forma, esten donde este el punto de origen del trayecto y el punto destino, se va siempre por una ruta optima.

La verdad es que tengo ganas de tener este asunto resuelto, porque a la libreria le queda muy poco ya para terminarse y publicar la beta1, bajo licencia LGPL

[retro_preview.png]

Llevo unos cuantos dias dandole al asunto este, he aprendido unas cuantas cosas que no conocia (gracias, wikipedia) y he terminado elaborando un metodo que no se si existe ya o que, porque despues de tanto algoritmo, tanta "variante de" y tanta historia, llega un momento que marea hasta lo indecible.

Paso a describir el metodo, potenciales meteduras de pata aparte.

retro_preview.png

   Este es el mapa inicial, donde tenemos las baldosas y las paredes. La imagen esta sacada de Kapman, un clon de Pacman en KDE.

   Las zonas negras interiores indican suelo pisable (baldosa) y las claras son las paredes.

regiones_pintadas.png

   Aqui tenemos las distintas zonas del mapa inicial,destacadas cada una de un color.

region_1_zonas.png

   Necesitamos poner nodos en puntos concretos, de forma que sea cual sea Origen y sea cual sea Destino, sepamos exactamente a que baldosa ir.

   Un problema que presenta esto es que hay que poner el menor numero de nodos posible; a mayor numero de nodos, mayor cantidad de calculos.

   Para saber donde colocar cada nodo, debemos trazar lineas que indiquen donde esta cada pasillo. Un pasillo se forma cuando dos o mas baldosas
   van en la misma direccion, sea horizontal o vertical.

   Las lineas rojas indican los pasillos horizontales, las lineas amarillas los verticales.

region_1_nodos.png

   En cada interseccion ponemos un nodo (verde).

region_1_nodos_ejemplo.png

   Los nodos tienen dos tipos de conexiones: directa y remota. Entre el nodo rojo y el nodo amarillo hay una conexion directa, pues hay un pasillo que
   lleva de uno a otro. Entre el nodo rojo y el nodo azul hay una conexion remota, pues hay que pasar por al menos un nodo adicional para llegar a el.

   En este mapa de ejemplo, un nodo puede tener un maximo de cuatro conexiones directas, una por cada lado. Cada nodo tiene unas coordenadas XY definidas,
   por lo que ir de uno a otro es directo.

   Si vamos del nodo rojo al azul, necesitamos recorrer las baldosas hasta encontrar el camino mas cercano.

   El siguiente algoritmo se basa parcialmente en el "Metodo del Comerciante", consistente en que cada nodo solo se puede visitar una vez.

   Para ir del rojo al azul necesitamos unas normas:

   * Tenemos un total de 10 nodos, pues se descuenta el nodo inicial (rojo). Esto hace un grupo de X (numero desconocido) "comerciantes".
   * Cada nodo sabe cuales son sus nodos directos, en caso del nodo rojo son sus nodos directos verde y amarillo.
   * Cada vez que llegamos a un nodo, sale un comerciante hacia cada uno de los nodos directos, excepto hacia el nodo directo del que venimos.
   * Cada comerciante tiene una memoria que indica el numero del nodo por el que ha pasado.
   * Antes de ir a un nodo, el comerciante comprobara su memoria. No se puede ir mas de una vez a un nodo concreto.
   * Si un comerciante no puede avanzar en un momento dado por estar "atascado", consultara su memoria para retroceder una o varias posiciones y continuar.
   * En el momento que un comerciante alcance el destino, se consulta su memoria para conocer la primera posicion de su trayecto. Fin de la exploracion.

   Esto en si mismo es algo asi como una exploracion por fuerza bruta, estilo recorrido en profundidad de arboles binarios.

   No soy experto en temas de inteligencia artificial, pero me da la impresion que es un algoritmo que consume bastante.

   Supongamos un juego en el que tenemos varias decenas, o incluso cientos, de enemigos que recorren un trayecto, usar ese algoritmo en cada paso que dan, con
   cada uno de los enemigos, no parece practico. Esto me ha hecho pensar en tablas precalculadas, a modo de un array 2D. Si estas en el nodo X y quieres ir
   al nodo Y, sabes directamente que tienes que viajar al nodo Z, que es el primer paso para llegar al nodo Y.

Y esto es todo, no se si lo he complicado innecesariamente, o si ya hay algun algoritmo que haga lo mismo, o que
Lenguaje usado, C/C++

Link a donde esta todo:

http://rapidshare.com/files/448065301/Algoritmo.tar.gz

Veamos, estoy trasteando con un algoritmo basado en Dijkstra, para tener un escenario mas claro he cogido unos cuantos mapas de pacman.

Lo esbozo un poco: trabajamos con dos mapas, uno es general y contiene todo; el otro es especifico de la zona. Baldosa es solo una casilla pisable, y pasillo son dos o mas baldosas contiguas.

El asunto es destacar todos los pasillos, tanto en horizontal como en vertical. Se pone un nodo de control en cada inicio de pasillo, fin de pasillo y en cada interseccion de pasillos. Es decir, en cada esquina y en cada cruce.

De esta forma, cuando tenemos un nodo-origen y un nodo-destino, solo hay que saber cual es el primer nodo del camino, y por tanto a que baldosa hay que ir.

¿Como lo veis?. ¿Me estoy complicando?, ¿voy en una direccion mas o menos correcta?, ¿falta o sobra algo?

Estoy haciendo pruebas sobre el papel y parece funcionar. Eso si, parece bastante laborioso de programar el tema de "cualquier nodo a cualquier nodo". Menos mal que esa parte es solo con el mapa especifico de zona, y no con el mapa general.