Os ha quedado fantastico, enhorabuena!

Al fin pude leer el archivito de marras, me ha tocado instalar el Presentation de OpenOffice.

He visto confirmadas ahi muchas cosas que me habia encontrado en las hojas y hojas que llevo llenas haciendo pruebas. Teorias, problemas en potencia, posibles soluciones (no confirmadas hasta ahora), etc.  Por ejemplo, lo que pone en la pagina 13 es exactamente lo mismo que habia pensado yo. No lo he leido del todo porque hay palabras que no recuerdo que significa, pero no pasa nada porque tengo el diccionario Ingles-Español aqui al lado.

Ayer a ultima hora estuve mirandome http://es.wikipedia.org/wiki/Algoritmo_de_Dijkstra por enesima vez. y aunque una vez mas no entendi la explicacion (cuando uno es un negado para las mates, eres un negado y punto, es lo que hay  ^_^'  ) se me ocurrio una cosa mirando la ejecucion del ejemplo, basandome en lo que veia.

http://tinypic.com/r/5wfpf4/7

En negro, el numero del nodo. En rojo el "peso" del nodo. Se empieza por Destino (nodo 2) y se hace un recorrido en profundidad, evitando los nodos repetidos, hasta llegar a Origen (nodo 4). El peso de cada nodo esta repartido en plan padre-hijo.

Al empezar la busqueda (nodo 4) solo necesitamos mirar cual de los posibles nodos vecinos tiene el menor peso. A menor peso, mas cerca esta Destino (nodo 2). En caso de varios nodos con el mismo peso minimo, cogemos uno cualquiera de los dos. Esto hace que la busqueda del camino sea mas eficiente, creo.

Hay una cosa que me llama la atencion, los nodos sin descendencia (3 y 1) no afectan a la busqueda del camino pese a ser redundantes. Posiblemente esto sea despreciable a nivel de recursos y velocidad en mapas de nodos pequeños, pero en otros con muchos mas nodos quiza habria que añadir una poda antes de la busqueda, liberando asi recursos.

No se si esto en concreto se trata en el archivo que me pasaron, pero me parecio una buena idea. Y ahora, a leer con mas calma el archivo porque me parecio muy interesante xD

No sabia yo nada de esto de los "LUTs", ni que existian. Pues nada, estoy esperando a que me llegue la conversion del formato a PDF para leerlo.

Lo de calcular una especie de prioridades es algo que se me ha ocurrido hace unas horas, basandome precisamente en manhattan de A-Star. Es decir, si estoy en el nodo 8, el nodo 5 es mas importante que el nodo 1 porque esta "fisicamente" mas cerca. Esto haria que en la primera tabla, en la rama del 8, quedara asi:

8: 5, 1

Que conste que sigo con lo de "ramas" y "hojas" solo porque estoy esperando que me llegue el PDF  ^_^'

Otra posibilidad que se me habia ocurrido era asignar un "peso" a cada nodo, el cual se va incrementando de padres a hijos. Es decir; el nodo 2 tendria un peso de "1", el nodo 5 y 6 tendrian un "peso" de "2" y asi sucesivamente. Seria una busqueda en profundidad, pero empezando por Destino. De esta forma, voy por prioridades, si estoy en nodo 8 puedo ir a los nodos 1, 5, 7, sin embargo al mirar los "pesos" de esos mismos nodos ya se que el camino mas corto pasa por el nodo 5. Esto creo que haria que las busquedas fueran mas cortas. Ahora el colmo seria que esto mismo ya se haga con los LUTs  :D

Para Vicente:
Pues no lo sabia, es lo que suele pasar cuando te metes en berenjenales que conoces poco tirando a menos  ^_^'  yo pensaba que se obtenia un camino que no necesariamente era el mas corto, al menos eso es lo que daban a entender los ejemplos que vi.

Para Warchief:
Pues parece que si, eso de las http://es.wikipedia.org/wiki/Lookup_table o es lo mismo que se me ocurrio o se parece bastante. Lo malo son los puntos en contra que comentas, como los cambios en nodos o objetos dinamicos.

En que no es solamente encontrar UN camino, sino  evitar (en lo posible) caminos mas largos de lo necesario. Es decir, en vez de 4,8,5, 2, que no salga 4, 8, 7, 3, 6, 5, 2, que tambien seria valido pero mas largo.

[en profundidad]

Ya sabia yo que habia leido por algun sitio donde alojar archivos mas pequeños.

Veamos, el asunto esta en que al calcular el contenido de las tablas precalculadas podemos disponer de mas tiempo, un elemento critico en algoritmos en tiempo real.

La idea se basa en: "Si estas en el nodo X y vas al nodo Y, el primer paso es el nodo Z". Y eso es todo lo que nos interesa del camino entre X e Y, porque avanzamos un unico paso. Por tanto, la ruta completa es irrelevante. El ejemplo nos da 8 posibles nodos, hay que encontrar una ruta entre X e Y. Para no caer en bucles infinitos cada nodo solo se puede visitar una vez. Si miramos las taclas de "ramas" y "hojas", se ve que el recorrido del arbol es en profundidad .

En principio pagamos el tiempo mas alto. Pero... al eliminar nodos ya visitados, poco a poco empezamos a eliminar ramas enteras. En ejemplos pequeños no se nota tanto, pero en otros mas grandes (20 nodos, por ejemplo) se notan mucho mas las ramas eliminadas. Esto hace que el precio sea menor. No se si el mas optimo (lo dudo) pero si menor.

Una posible optimizacion es descartar tambien las ramas cuyas hojas hayan sido anuladas, aun no he hecho pruebas al respecto.

http://www.megaupload.com/?d=AYM0TFOO

Aqui os dejo en PDF lo que se me ha ocurrido, a ver que os parece.

PD: me bajo al supermercado a por unas cuantas botellas de agua y unos cuantos frascos de aspirinas  ^_^'

Muy buenas,

estoy mirando con mas detalle el tema de los numeros aleatorios usando C/C++ y  me he encontrado lo siguiente:

Para la semilla:
srand(time(NULL));

Para numeros aleatorios entre un MIN y un MAX que sean distintos de cero, formulas a montones:
rand () % (N-M+1) + M; // N es el max y M el min
P+(int)(((U-P+1.0)*rand())/(RAND_MAX+1.0)); // U y P son dos numeros cualesquiera
max_value%rand())+ min_value;

Problema: estoy haciendo pruebas con una funcion que dibuja lineas horizontales en la pantalla, y por lo visto algo falla porque veo muchos azules y verdes pero poco mas. Algun amarillo perdido, y creo que no he visto aun ningun rojo ni otros colores.

Opcion A: la formula de semilla esta mal. Lo malo de esta opcion es que me la he encontrado en mil sitios. Otra posibilidad es hacerlo tomando como base la fecha+hora actual del sistema, pero CREO que no necesito tanta precision.

Opcion B: la formula del rand esta mal. Lo que pasa con estas formulas es que esta el factor de hasta que punto queremos que sean aleatorios. ¿Buscamos que no se repitan nunca o casi nunca o eso es mas bien poco importante y no pasa "nada" si la secuencia se repite?. Tal vez por este factor es por el que algunas formulas son mas elaboradas que otras.

Dado que estoy usando colores RGB, los valores van de 0 a 255. Para las pruebas le pido a rand un valor entre 1 y 255. Siempre los mismos azules y verdes, ponga la formula que ponga. Seguramente sea una tonteria, pero no caigo.

Por fin, llego la hora, despues de muchos retrasos por mil cosas.

http://ngl.ayudaprogramacion.net/NGL_BETA-0.1.tar.gz

Nautilus Game Library (NGL) es una libreria en C/C++ que combina el lenguaje C (y un poco de C++) con las librerias SDL para crear una forma de programar juegos 2D bajo Linux que sea "tipo DIV".

Es una primera version, y aunque hay muchas cosas mejorables creo que ha quedado bastante bien para ser la primera version. Pero, sobretodo, hay mucha ilusion y ganas de aprender.

No soy ningun experto en C/C++, ni tampoco en SDL. Lo que estais viendo aqui es un proyecto personal. El resultado de muchos dolores de cabeza al enfrentarme a problemas que han ido surgiendo y horas investigando foros, Internet, la wikipedia, manuales y ejemplos. Comparado con la mayoria de la gente del foro, creo que soy muy novato en muchos temas xD

Mi agradecimiento tambien a las muchas personas que han apoyado este proyecto, de forma directa o indirecta.

En la descarga hay: el codigo fuente, unos cuantos ejemplos a modo de tutorial listos para compilar, unas cuantas capturas de pantalla y el manual de referencia.

Como se como soy, me aplico a mi mismo la ley de Murphy: "podras revisarlo de arriba a abajo, de abajo a arriba, de derecha a izquierda y de izquierda a derecha; cuando creas que lo tienes todo bien atado es cuando puedes estar seguro de que te has dejado algo".

Espero vuestros comentarios.

Depende de la licencia, puedes cambiarla después o no, pues modificaciones en la librería podrían considerarse obra derivada.

Independientemente de la licencia, tu tienes los derechos sobre el software que creas, lo que significa que siempre puedes elegir relicenciarlo.

A mi esto me parece contradictorio  ???

Primero dices que depende de la licencia que use, luego puedo cambiarla o no.
Despues dices que da igual la licencia porque luego puedo cambiarlo.

Veamos, la version que quiero publicar es la Beta 0.1 ¿En futuras versiones puedo cambiar la licencia a la que yo elija?. ¿O al ser el desarrollo inicial publicado en una determinada licencia, todos los posteriores desarrollos quedan bajo esa licencia?.

P.D: Si, estoy pez en temas de licencias. No tengo cabeza para temas legales.

¿Que otras licencias podria ponerle?

Buenas,

me falta practicamente para publicar la Beta 0.1 y CREO que tengo que usar la licencia LGPL version 2. He aqui los datos.

- Desarrollado en Linux Debian estable (Squeeze).
- Compilador gcc de Debian
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

- SDL 1.2.14, licencia LGPL version 2
- SDL image 1.2.10, si lo entiendo bien hereda la licencia de SDL
- SDL_GFX, LGPL 2.1
- SDL_ttf, LGPL 2.1
- SDL_mixer, LGPL 2.1

¿Estoy en lo correcto y es LGPL version 2.1?.

Buenas,

pongo aqui este post porque no estaba muy seguro de donde colocarlo  ^_^'

Al grano, he hecho un par de mini manuales sobre la libreria que estoy haciendo, uno esta enfocado a "tipo DIV" y el otro esta mas enfocado a "tipo C". Un usuario de cada tipo. Me gustaria tener opiniones.

Estos manuales recogen solamente el indice y el primer capitulo, pero aun asi dan una idea de por donde van los tiros. Creo.

http://www.megaupload.com/?d=CQJJEIE9

[n]

Posiblemente el problema de intentar reproducir un error que no tienes npi (ni puñetera idea, mal pensados :P) del porque se produce es.... sacarle "la foto".

funcion de llamada:

unsigned char
ngl_put_pixel(ngl_entity *entity_id, unsigned int x, unsigned int y, unsigned char r, unsigned char g, unsigned char b)
{
   Uint32 color;

   color=SDL_MapRGB(ngl_screen.graph->format, r, g, b);
   putpixel(entity_id->graph, x, y, color);

   return 0;
}

funcion en si misma:

void
putpixel(SDL_Surface *surface, int x, int y, Uint32 pixel)
{
   int bpp = surface->format->BytesPerPixel;
   int tmp;

   Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;
   
   tmp=SDL_LockSurface(surface);
   if (tmp<0) {
      //return 1; // Error, entidad no bloqueada
      printf("\nngl error - putpixel - entidad no bloqueada");
   }

   switch (bpp) {
      case 1:
         *p = pixel;
      break;

      case 2:
         *(Uint16 *)p = pixel;
      break;

      case 3:
         if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
            p[0] = (pixel >> 16) & 0xff;
            p[1] = (pixel >> 8) & 0xff;
            p[2] = pixel & 0xff;
         } else {
            p[0] = pixel & 0xff;
            p[1] = (pixel >> 8) & 0xff;
            p[2] = (pixel >> 16) & 0xff;
              }
      break;
      case 4:
         *(Uint32 *)p = pixel;
      break;
   }

   SDL_UnlockSurface(surface);
}

Explicaciones:

- ngl_entity es un objeto. Dentro de el esta "graph" que es una SDL_Surface (la imagen en si misma)
- putpixel es una funcion que tiene la propia documentacion de SDL, no se bien porque se ha hecho asi pero siendo la oficial de SDL, la pongo tal cual. Mi unico cambio ha sido el bloqueo y desbloqueo de la SDL_Surface, ya que la info de SDL recomienda usarlo.

El codigo completo es:

#include "Nautilus.h"

int
main(int argc, char* args[] )
{
   unsigned char Salir;
   unsigned char Tecla;
   unsigned char tmp;

   ngl_create_screen(m320x240);
   ngl_screen.set_main_text("Nautilus Game Library - Tut 8 - Pathfinding", "");
   
   ngl_entity tapiz;
   tapiz.load("tapiz.png");
   tapiz.x=320/2;
   tapiz.y=240/2;
   ngl_paint(&tapiz);
   ngl_rand_seed();
   ngl_frame();

   Salir=0;
   while (Salir==0) {
      Tecla=0;
      Tecla=ngl_key(_q);
      if (Tecla>0) {
         Salir=1;
      }
      
      Tecla=0;
      Tecla=ngl_key(_a);
      if (Tecla>0) {
         ngl_put_pixel(&tapiz, ngl_rand(0,320), ngl_rand(0,240), ngl_rand(0,255), ngl_rand(0,255), ngl_rand(0,255));
         ngl_paint(&tapiz);
         ngl_frame();
      }

   }
   tapiz.unload();

   ngl_quit();
   printf("\n");

   return 0;

Creo que el codigo es intuitivo. Se crea una ventana de 320x240, se crea y carga la entidad tapiz. Creamos un valor semilla para rand. Cuando pulsamos la tecla "A" se pinta un pixel de color aleatorio en unas coordenadas aleatorias del tapiz. A veces falla, no caigo en porque, posiblemente sea algun fallo tonto que no veo aun.