Estoy mirandome Dijkstra y mira tu por donde, tal vez era justo la pista que necesitaba, estoy haciendo pruebas.

En este caso, el personaje debe aprender cuando ha llegado a un callejon sin salida y volver atras.

Hace algun tiempo hice el A * en DIV2, con casos en que el obstaculo era la letra "C", el personaje estaba a la izquierda de la letra y la salida estaba dentro de la "C". Funcionar funciono, pero joer lo que le costo...

Buenas,

he estado leyendo sobre algoritmos de busqueda de caminos, y como veo que hay tropecientas opciones necesito algo de orientacion, os cuento un poco los detalles del caso.

Tenemos un escenario 2D de una resolucion 320 x 240 que es el mapa del juego, luego aparte tenemos un mapa de durezas de la misma resolucion, con dos colores. El color negro es no pisable (pared) y el blanco es pisable (suelo).

Ejemplo clasico: un laberinto. El jugador esta a la izquierda de la pantalla y la salida esta a la derecha

Al principio pense en usar el algoritmo A *, pero leyendo por Internet me encuentro con distinas opiniones. Que si tiene un coste computacional demasiado elevado, que si es orientado a grafos y no a cuadriculas, que si es el mas sencillo, etc.

Navegando por Google me encontre esto http://es.wikipedia.org/wiki/Categor%C3%ADa:Algoritmos_de_b%C3%BAsqueda

me he pasado por GameDev, pero solo ha servido para confirmar que lo relacionado con la IA es muy amplio. Busco saber cual es el algoritmo (o algoritmos) que mejor suelen adaptarse a este caso en concreto.

Estoy usando C/C++ y SDL

180 º = PI rad

1º = PI /180 rad

En Xna:

Código [Seleccionar] Expand


MathHelper.ToRadians(deg)

MathHelper.ToDegrees(rad)

Veamos... yo pensaba que con una regla de tres simple conseguiria adaptar esto.

PI /180 rad  -> 1 grado
radian_obtenido -> X grados

3.14/180=0.01744, con lo cual queda asi:

0.01744 rad  -> 1 grado
radian_obtenido -> X grados

Angulo=(radian_obtenido*1)/0.01744

Pues algo no encaja, porque me salen algunos angulos negativos.

Veamos, mientras intento aclararme con todo esto, hay una cosa que no entiendo. En el cuadrante 1 y 2 has puesto:

atan2(1,1)=0.785=45º  (Esto en el primero)
atan2(1,-1)=2.356=135º  (Esto en el segundo)

Tanto el 0.785 como el 2.356, ¿como se convierten a grados?

[antihorario]

Buenas de nuevo,

estoy haciendo unas pruebas y me salen cifras de angulos que no me encajan con respecto a las posiciones.

Repito, el angulo crece en sentido antihorario.

Podrías dar algunos ejemplos, tal como te han dado la solución del atan2(Y,X) está perfecto (Fiajte que es Y, X está al revés de lo clásica notación x,y). El hecho que sea antihorario es sólo una ilusión, ya que tu eje Y está invertido, en términos crudos el valor del angulo crece en sentido anti-horario con un eje Y normal, al invertir el eje Y automáticamente el ángulo va a crecer en sentido horario (asumiendo que usas siempre el punto 0,0 en la esquina superior izquierda.).

Edit. Si lo que quieres es un ángulo que crezca en sentido anti-horario, pero con un eje Y invertido, o en otras palabras el ángulo de depresión, entonces invierte el valor de Y.  atan2(-Y,X).

Pues te cuento: Origen esta en el centro de la pantalla, y  en uno de los casos Destino aparecio arriba y a la izquierda. Segun las pruebas, Destino estaba a 60 grados respecto a Origen, lo cual es imposible porque ese angulo debe ser superior a 90 grados.

Repito los datos de referencia:

El eje X es el horizontal, el eje Y el vertical. El lado positivo de las X esta hacia la derecha, el lado positivo de las Y esta hacia abajo.

Eje X positivo, 0 grados.
Diagonal derecha-arriba, 45 grados.
Eje Y negativo, 90 grados.
Como se ve, en angulo crece en sentido antihorario.

Digamos que por "restricciones de proyecto" debe ser asi.

[antihorario]

Buenas de nuevo,

estoy haciendo unas pruebas y me salen cifras de angulos que no me encajan con respecto a las posiciones.

Repito, el angulo crece en sentido antihorario.

Buenas a todo el mundo,

ando liado con un proyecto propio que realizo en C/C++ y SDL y me he topado con un problema de formulas, segun parece es de trigonometria. Como un servidor es bastante malo (por no decir otra cosa xD) en temas de matematicas, pues a ver si me podeis hechar un cable. Si, ya se que es un inconveniente serio si te gusta la programacion, pero asi son las cosas, que le vamos a hacer. Detallo.

Tenemos un sistema 2D, donde las X es el eje horizontal y las Y el eje vertical. El eje X tiene su lado positivo a la derecha, y el eje Y hacia abajo.

Tenemos dos objetos, llamese Origen (Ox, Oy) y Destino (Dx, Dy), ambos pueden estar en cualquier coordenada. Tomando como punto de referencia Origen, hay que calcular el angulo que forma respecto a Destino.

El angulo crece en sentido antihorario, siendo algunos ejemplos:

Eje X positivo, 0 grados.
Diagonal derecha-arriba, 45 grados.
Eje Y negativo, 90 grados.

Ando mirando trigonometria por Google y Wikipedia, pero sigo sin verlo claro, la funcion seno no parece que sea la que busco, pero si alguna parecida a ella.

A eso me referia, si señor. Poderse se puede, otra cosa es el potencial grado de dificultad.

De todas formas ya he visto que esa parte de la programacion grafica esta relativamente abandonada, en favor de la programacion dentro de entornos graficos.

Yo queria saberlo sobretodo por dos cosas. La primera era por saber que opciones habia hoy en dia para hacer algo asi. La segunda es algo que oi a una persona hace mucho tiempo (epoca de los 486 y primeros Pentium) de que si un juego no NECESITABA un Pentium para jugar, es que ese juego era  una mierda.

Por ello siempre me ha interesado saber que clase de juegos podria hacerse con ordenadores con ciertas limitaciones (sin entorno grafico), y es que hay ordenadores por ahi tan limitados que de usted gracias de que tiene "potencia suficiente" como para tener el driver de la grafica cargado y ejecutar algunas operaciones graficas sencillas. Lo que se puede llegar a ver por ahi en algunas empresas con tal de no actualizar el ordenador y poner alguna cosa mas normalita. Al estilo "si funciona, no lo toques". Pero joer, usar al dia de hoy un 486 para navegar por Internet...

Cenquius a tol mundo por esclarecer cosas.

Intentare poner un ejemplo mas claro:

Epoca del MSDOS, imaginate que no ha salido Windows aun. Por lo demas, el hardware (tarjetas graficas, procesadores, etc) es tal y como esta ahora mismo.

¿Seria posible programar algo como Quake4?

Lo que intento determinar es si es posible programar juegos 2D/3D sin usar en ningun momento un entorno grafico. Ni Windows, ni X Window (KDE, Gnome, etc) ni nada.

Cuando dije lo del MSDOS era por poner un ejemplo de juegos que se ejecutan, o pueden ejecutarse, desde la linea de comandos, nada de iniciarlos desde un entorno grafico (Windows).

Imaginemos un ordenador actual, normal y corriente, que usa (por ejemplo) una tarjeta grafica NVidia y un entorno grafico tipo KDE.

Aunque puede pedir el login en modo grafico (KDE) tambien puede hacerlo desde la linea de comandos. Y en ambos casos el driver de NVidia estara correctamente instalado.

Me refiero a eso, iniciar un juego desde linea de comandos y que tenga las prestaciones de los juegos 3D actuales.

CREO que seria posible, es solo una idea. Espero haberme explicado un poco mejor :)

Esto me hace acordarme de una cosa.

¿Os acordais de la epoca en la que los juegos se iniciaba en la linea de comandos (MSDOS) o en una ventana MSDOS (Windows 95)?

Tecnicamente, ¿seria posible hacer juegos que se inciaran de alguna de esas dos maneras y aprovecharan esos efectos graficos que pone el enlace?.

Si, si, eso es lo que inicialmente pense. De hecho primero me puse con SDL_MapRGB y deje para luego SDL_MapRGBA.

Lo raro del asunto es que a veces me suelta:

Fatal signal: Segmentation Fault (SDL Parachute Deployed)

despues de estar funcionando el programa unos segundos. Por poner un ejemplo: acabo de ejecutarlo tal cual, cinco veces, y me ha dado segmentation fault en tres.

En cambio, con la funcion putpixel de SDL nunca ha ocurrido ese error.

Vale, he cambiado todo para que la surface de la pantalla se llame "screen", y he comprobado que funciona porque la tengo delante.

Con la funcion putpixel puedo colocar pixeles en formato RGBA, pero SDL_Color tiene formato RGB.

Dado que los miembros de SDL_Color son Uint8, solo necesito una variable Uint8 alpha para completar de RGB a RGBA.

Tanto los miembros de SDL_Color como alpha admiten un valor entre 0 y 255, lo que lleva (si me estoy enterando bien con lo que leo por Google) a un dato hexadecimal (base 16)

Supongamos algo como esto:

SDL_Color *color1;
Uint8 *alpha;

color1->r=255;
color1->g=0;
color1->b=0;

alpha=150; (150, por poner un numero)

Si me entero bien, eso deberia dibujar un punto rojo con un cierto grado de transparencia, lo que no veo claro es como esos cuatro Uint8 los junto para formar un Uint32.

Si, conozco esa funcion y es muy practica, pero me plantea un pequeño problema.

Yo lo que quiero es controlar los valores RGB y RGBA de un pixel de una surface dada, para lo cual uso SDL_Color.

En esa funcion tenemos "Uint32 pixel", lo cual me lleva a que cada componente de color RGBA esta incluida en un solo numero, logicamente. Lo que no consigo acordarme de como era exactamente para cambiar los valores RGB de SDL_Color para meterlos en el Uint32 de pixel.

Anoche en el canal estuve hablando del tema, y sacamos lo siguiente:

<{_SaLeM_}> supon la combinacion 1, 1, 1, 0
<{_SaLeM_}> eso seria
<{_SaLeM_}> 2^24 + 2^16 + 2^8
<{_SaLeM_}> 16843008
<{_SaLeM_}> que pasado a bin es
<{_SaLeM_}> 00000001000000010000000100000000
<{_SaLeM_}> 1, 1, 1, 0

<{_SaLeM_}> pues 1 * 2^24 + 1 * 2^16 + 1 * 2^8 + 0

Creo que la solucion va por ahi, pero intento pintar la pantalla de rojo (255,0,0) y me sale casi negro, algo me falla en la formula.