Yap. Pero de la manera que yo lo hago puedes conseguir que el personaje se mueva por CUALQUIER parte de la escena, lo que hace que gane en calidad la aventura. Es más divertido permitir al usuario moverse por donde quiera, además sería un jaleo editar los caminos posibles; como contrapartida el método que yo utilizo, dependiendo de la complejidad de la ruta, puede ocasionar movimientos extraños o poco lógicos en el personaje (aunque la verdad, actualmente esta bastante optimizado y sólo hace cosas raras en contadas ocasiones).

Saludos
--plugin                                

                                Aqui esta. A ver si se ve ahora. Es tela de cutre, pero valía para ilustrar el ejemplo:



Saludos
--plugin                                

                                Buenas Emotion. Como bien dice Kabila es un método para resolver ecuaciones diferenciales, tales como:
y'=-y+x2+1
y(0)=1

Es otro método como el de Euler, Graff o Adams-Bassforth. Supongo que en internet (o en cualquier libro de cálculo avanzado) encontrarás info de sobra. Yo estos métodos los tengo implementados en Mathlab (junto con una pequeña memoria comparando rendimientos) que tuve que hacer en la universidad. Si los quieres me lo dices y te lo mando (aunque no son gran cosa). Son algoritmos sencillos y muy cortos así que no tendrás problemas en portarlos a otros lenguajes. De todas maneras si quieres teoría como te digo la encontrarás en cualquier libro.

Saludos:
--plugin                                

                                Buenas!
Si no digo que no tengas razón Mchiz, entiendeme. Si parece que es más optimo hacer comprobaciones por objetos que por pixeles. Quizás soy un poco reacio a cambiarlo porque ya me gano la vida haciendo software (no juegos, jeje) y no creo que me la vaya a ganar haciendo software de entretenimiento (ojala!!). Entonces, esto más o menos lo hago porque me gustan los juegos. Así, dado que no lo hago profesionalmente, ya me es dificil encontrar grafistas que me hagan grafikillos "por amor al arte"; imagínate si además les pongo pegas y dificultades a la hora de hacer los fondos. Vamos, que lo que quiero simplemente es hacer un juegecillo y, hombre, si sale bien pues mejor que mejor. Ni duda cabe de que se puede optimizar MUUUUCHO. Aunque como dije antes, juego con ventaja ya que las aventuras gráficas no requieren demasiado.

En cuanto a las pruebas pues... la verdad es que los equipos que tengo son algo "extremos" para sacar conclusiones. Los resultados en mi casa son: (a 800x600x16 FS)

- AMD 1200. RAM 256 DDR PC2100. 3d Phrophet 4500 64 Mb. -> 116 FPS (Windows XP Pro)
- PENTIUM III 800. RAM 1024 PC133. GeForce 2 GTS 64 Mb. -> 82 FPS (Windows 2000)
- PENTIUM 100. RAM 64. S3 Diamond 1MB. -> 10 FPS (Windows 2000)

Como ves, claro, en los dos primeros va bien. En el ultimo ni de coña. Pero es que ahi no va ni el buscaminas...
Una vez este esto más estable preparare una batería de pruebas en ordenadores mas comunes a ver que resultados obtengo.

Y con respecto a dejarte algo, pues no me importaría. Pero preferiría dejartelo una vez tuviera algo mas visible (ahora mismo sólo tengo el sistema de personajes, rutas y el motor de scripts andando mas o menos). Vamos, esta bastante avanzado pero no tengo ni siquiera todos los movimientos del personaje principal (me faltan 2 direcciones) así que esta un poco cutre. Esto va lentillo.... No te preocupes que si te interesa te lo dejare pasado un pequeño tiempo sin problemas. Ademas seguramente haré una web y lo colgaré de alli para que lo veais todos

Venga, saludos
--plugin

                               

                                Buenos ya puestos, os pongo la diferencia de frames que hay utilizando la funcion de Copia mediante "zbuffer" (es que sigo sin saber como llamarlo...) o copiando Directamente con las funciones que trae DX. Nótese que para la prueba usando las funciones de DX NO HE PINTADO NINGUN OBJETO, es decir, a este tiempo habría que añadir el que se tarda en pintar los objetos del escenario que estan por delante y por detras del personaje (arbol, mesa, etc).
(pruebas a 800x600x16 FS)

Usando copia mediante ZBuffer: 116 FPS
Usando copia mediante DX: 128 FPS

(En la prueba el personaje está parado y se está ejecutando una pequeña animación en el fondo)

Hombre.... Diferencia si que hay. Son 12 FPS. Pero como dije todavía quedaría que sumarle el tiempo que tarda en pintar los objetos.

Pues eso, saludos
--plugin
                               

                                Bueno. Creo que lo dejaré como lo tengo. Ahora mismo da a 800x600x16 unos 120 FPS, nada mal para una aventura gráfica. Con respecto a la forma de pintar los objetos como tu dices.... ¿Sabes el coñazo que es para los grafistas dibujar un fondo con TODOS los objetos por separado? Y respondiendo a tu pregunta de que si creo que el Monkey Island lo hicieron asi pues..... hombre, habría que preguntarselo a los de LucasFilm, pero me da a mi que se hizo así. Bueno, en cualquier caso dejaré tu idea en mente por si veo que esto resulta ser un inconveniente pues lo cambio, que tampoco creo que suponga mucho. Venga, saludos

--plugin                                

                                Holap
[Contestando a Kchiz]
Bueno, creo que no he utilizado el término correcto, entre otras cosas porque no se como se denomina, jeje. Vamos a ver, yo tengo el fondo en una imagen PLANA, NO objetos separados. Entonces tengo una imagen (a la que yo le llamo zbuffer, no se como llamarla) que utilizo para RECORTAR los sprites en determinadas zonas. Es decir, a la hora de dibujar un personaje compruebo la zimagen y dependiendo de la posición del personaje RECORTO el sprite a usar. Esto es por ejemplo para "simular" que un personaje pasa por detras de un arbol. Efectivamente, esto se puede solucionar teniendo el arbol dibujado aparte y copiandolo despues del personaje, con lo que obtendríamos la misma ilusión, que el personaje pasa por detras. De todas maneras creo que mi forma es mejor porque no necesito tener varias imagenes, solo una (bueno, y la zimagen). Pero claro, tiene el inconveniente de que la copia tengo que hacerla a mano para comprobar con ayuda de la zimagen que pixels pintar y cuales no.

[Contestando a klinex]
Así lo hare. :ojo:. Aquellas superficies cuya copia necesite hacerla bloqueando la superficie las pondré en memoria del sistema y las demas en la de video

Saludos
--plugin                                

                                [Contestando a Dracula]

¿Que porque lo hago a mano? Bueno, la copia de personajes porque necesito hacerla en función de un z-buffer para hacer lo típico de que el sprite pase por delante o por detrás de un objeto del escenario, función que no puedo hacerla con las que me proporciona DX.  Supongo (corrígeme si me equivoco) que tu si que podrás hacerlo porque tu motor es 3d y las tarjetas vienen preparadas para ello, pero con menos soporte para las 2d. De hecho, supongo que podría programar el engine como si de un juego 3d se tratáse, utilizando texturas y tal... Me imagino que el incremento de velocidad sería bestial, pero tendría que rediseñar todo... Creo que por ahora lo dejaré así, aunque quiero meterme con las 3d, llegado ese momento veré que hago.

Saludos
-- plugin (ahora sí, jeje)                                

                                Uppssss. He puesto el nick que tengo en Meristation. Jeje. Bueno, queria decir: Saludos:
--plugin
                               

                                Buenas de nuevo. Vamos por partes:

[Contestando a Klinex]
- ¿A que te refieres con que esté todo el rato moviendo el bloque de datos en vez de una vez? Cuando el personaje se mueve, SI, estoy todo el rato (cada vez que ha de moverse) moviendo el bloque de datos (no se si te refieres a eso).
- En el cambio de velocidad, pues.... A mi tambien me parece demasiado. El único cambio que hago es sustituir el flag correspondiente a la hora de crear la superficie DirectX para que la cree en memoria normal en vez de la de video. La verdad es que es una caida muy grande de FPS, no se. De tarjeta grafica en este que lo he probado (probare ahora en el otro a ver si la caida es igual) es una Hercules 3d Prophet 4500 64 Mb.

[Contestando a Emotion]
- ¿Cuantas pruebas he hecho? hmmmm. Pues desde luego usar el BitBlt no. Joder, soy un poco negao, porque ni recordaba su existencia. La verdad es que en el aspecto gráfico tampoco me he esmerado demasiado (uso las CDX modificadas) ya que en una aventura gráfica tampoco necesito demasiada velocidad, y ahoro que me pongo a "optimizarlo" me doy cuenta de que se me pasan muchas cosas...... Pues nada Emotion, probaré a usar el BitBlt en vez de bloquear la superficie y leer/Escribir a mano. Os mantendré informado de los resultados.

[Contestando a Fiero]
- O sea si tengo que leer a Mem. Sistema y si solo escribir a Mem. Video ¿Pero esa era mi duda original? Las únicas superficies que pudieran utilizarse sólo para escribir son los back-buffers no? Luego en memoria de vídeo sólo pongo esto?. Bueno, en definitiva. Voy a probar el BitBlt y a hacer algunas guarrerías más y ya os diré que pasa...

Gracias a todos, saludos
--negum
                               

                                Vamos a ver.... que no me cosco (si, soy torpe, jeje). Vamos a poner por ejemplo las superficies que contienen los frames de los personajes. ¿Esas donde las pongo? Si las pongo en memoria de video va de pena y si las pongo en memoria principal va bien. Pero entonces volvemos a lo de antes: tengo que meter todas las superficies en memoria principal y desaprovecho la de video, no?

Entonces... segun me dices. Leer es muy lento y escribir muy rapido en video??

Bye
--plugin                                

                                Buenas. He estado realizando modificaciones en las funciones de copia de superficies de mi engine (2d para aventuras gráficas) y ahora realizo la copia a "mano" moviendo los bytes de una zona de memoria a otra. Cuando termino de modificarla y la pruebo observo que, cuando antes obtenia 70 FPS ahora obtengo 24 FPS, lo cual me preocupa. Entonces, modifico las funciones para que las superficies se cargen en memoria normal en vez de la memoria de video. Con esto consigo refrescar a una velocidad de unos 120 FPS. Perfecto. Pero mi pregunta es: ¿No puedo hacer que vaya a la misma velocidad estando los gráficos en memoria de video? En mi ordenador no importa mucho que este en memoria convencional (ya que dispongo de suficiente) pero en un ordenador algo más corto no creo que sea buena idea almacenar ahí los gráficos además de los sonidos, scripts y demás. Aún en el caso de que todo el mundo tuviera 1 Gb de Ram (bueno, puestos a imaginar... jeje) me parece un poco absurdo desaprovechar la gran cantidad de memoria de video de que disponen las máquinas actuales. Pues eso, a ver como puedo volver a "poner" las imágenes en memoria de video pero manteniendo el framerate.

Gracias y saludos
--plugin                                

                                Joder!! Perdonar mi expresión y, quizás mi ignorancia, pero me ha parecido una pasada tu respuesta... Creia que ibas a proponer una mejora al tipico bucle de juego y lo que predicas es un gran trabajo extra que para mi caso creo no me vale mucho (creo). Estoy haciendo un engine para aventuras gráficas (de ahi la otra pregunta). Las animaciones de los personajes no son muy complejas (no es una aventura en plan serio) y tienen de media unos 10 frames reproduciendose a 12 FPS. Tal y como esta ahora implementado es siguiendo mas o menos lo expuesto por JAvier Arevalo en el articulo que se hacia mencion unos post mas arriba. Pues con dicha implementación y esa calidad de animaciones me parece bastante bueno el método. Ahora bien, si lo que tu comentas es para un motor en 3d, la cosa seguramente cambiaría...... Cuando termine este engine pasaré a experimentar con las 3d y quizás las cosas cambien.

Pues nada, aún así agradezco las respuestas, nunca se sabe cuando puedes utilizar los conocimientos que aprendes en este mundillo. Saludos
--plugin                                

                                Pues si... Eso que comentas me vale.. Como dije, el algoritmo funciona muy bien, aunque todo es mejorable y este trukillo podría valer para hacer el camino con menos zig-zags (mas recto como bien dices). Pues nada, al final parece que va a quedar un algoritmo muy curioso....

Gracias
--plugin                                

                                Buenas. Efectivamente, lo que comentas de calcular el baricentro e ir de uno a otro fue mi idea original, pero el problema es que el personaje parecía que estaba "borracho", vamos que da muchas vueltas. Lo de la spline sería buena idea quizás si fuera un vehículo; siendo un personaje lo que tiene que moverse es más fácil hacer que se mueva en líneas rectas, aunque hay que optimizar éstas. Os he hecho una imagencita para que veais el resultado (no soy muy buen dibujante como vereis):



Lo que se ve en medio (aunque no lo parezca) es un árbol que se supone hay que esquivar. El algoritmo lo que devuelve es la serie de triángulos a pasar para alcanzar el objetivo (en este ejemplos son todos, es que no he pintado la ruta completa). La línea en amarillo lo que hace es ir de baricentro en baricentro como bien dice BerSerKer. Pero como lo he hecho es más óptimo, caminando por las aristas. Como ves, el camino en azul es mucho más corto y hace menos zig-zags que el otro.

Todavía tengo que optimizarlo un poco porque con rutas más complejas a veces no elije el camino que yo (como humano y ser más inteligente que el ordenador, creo...) eligiría.

Pues eso. Saludos a todos
--plugin

P.D. ¿Porque no se me ve la imagen? Bueno,... este es el enlace: http://www.geocities.com/mugenss/imgs/path.gif

[ Este Mensaje fue editado por: plugin el 2002-04-22 00:12 ]