Otra mini pregunta acerca de los fpgs

Drumpi · June 16, 2009, 11:22:41 AM

Lo he explicado dos veces, y hasta que splinter no ha respondido no lo ha entendido Syous (dcelso no ha dicho nada, pero preguntó despues de responder yo las dos veces).

DCelso · June 16, 2009, 12:45:44 PM

I'm sorry drumpi, no respondí porque no tenía nada mas que añadir, quedó todo claro, o eso creía. Eres un crack ;).
Yo estaba totalmente desinformado :D.
Por otro lado, es normal que creamos algo que diga SpliterGU antes que otro o incluso esperar que responda él. ¿No crees? :D

Post Data: Es un símil un tanto en cuanto malo pero: creerias lo que dijera un usuario de windows xp o lo que te dijera de primera mano Guillermo Puertas.

DjSonyk · November 28, 2009, 12:56:21 AM

¿Como se sabria cual es el ultimo grafico de un FPG?

Windgate · November 28, 2009, 04:35:10 AM

No se me ocurre una forma eficiente de determinarlo... ¿Qué utilidad tendría una función capaz de determinarlo?

Si se justifica la necesidad de algo así se podría implementar una función que lo determine...

BoMbErLiNk · November 28, 2009, 04:48:42 AM

Quote from: DjSonyk on November 28, 2009, 12:56:21 AM
¿Como se sabria cual es el ultimo grafico de un FPG?

Yo hice un bucle de 1 a 999 midiendo el ancho de cada gráfico para saber donde estaban los huecos, g_wide daba 0 cuando no hay.

Windgate · November 28, 2009, 05:05:38 AM

Eso es eficaz pero ineficiente, coste lineal en el número de gráficos del FPG

Al menos la solución existe :-\

BoMbErLiNk · November 28, 2009, 05:09:35 AM

A que te refieres con " coste lineal en el número de gráficos del FPG " ?

SplinterGU · November 28, 2009, 05:17:48 AM

Quote from: BoMbErLiNk on November 28, 2009, 04:48:42 AM
Quote from: DjSonyk on November 28, 2009, 12:56:21 AM
¿Como se sabria cual es el ultimo grafico de un FPG?

Yo hice un bucle de 1 a 999 midiendo el ancho de cada gráfico para saber donde estaban los huecos, g_wide daba 0 cuando no hay.

y no seria mejor usar MAP_EXISTS ? :P

BoMbErLiNk · November 28, 2009, 05:23:14 AM

Quote from: SplinterGU on November 28, 2009, 05:17:48 AM
Quote from: BoMbErLiNk on November 28, 2009, 04:48:42 AM
Quote from: DjSonyk on November 28, 2009, 12:56:21 AM
¿Como se sabria cual es el ultimo grafico de un FPG?

Yo hice un bucle de 1 a 999 midiendo el ancho de cada gráfico para saber donde estaban los huecos, g_wide daba 0 cuando no hay.

y no seria mejor usar MAP_EXISTS ? :P

Bueno no en mi caso, uso el ancho y largo para localizar colisiones así que reciclo variables, pero si para lo que estamos hablando, si.

Windgate · November 28, 2009, 05:27:39 AM

map_exists sigue teniendo coste lineal en el número de gráficos del FPG, me explico:

En el peor de los casos, si el FPG tiene 998 gráficos hay que hacer 998 comprobaciones.

Por eso preguntaba cuál es la utilidad práctica de conocer el último gráfico del FPG, si estuviese justificada podría plantearse almacenar un valor en el FPG que indicase el último más alto número de map añadido, así el coste sería de 1 comprobación.

BoMbErLiNk · November 28, 2009, 05:36:32 AM

Bueno en realidad siempre tendrías que hacer 999 comprobaciones, puede darse el caso de que hayan graficos salteados dentro del fpg.

Sin embargo no le doy mucha importancia si no se produce ingame, es decir si se procesa 1 vez en un loading por ejemplo.

Yo la utilidad que le doy es un modo debug de animación que ignora los huecos donde no hay graficos y cuando llega al último vuelve al primero.

SplinterGU · November 28, 2009, 05:44:20 AM

no hay solucion mas rapida a eso... ademas las funciones de este estilo son muy rapidas...

por otro lado, yo usaria un metodo doble de busqueda, o sea, comprobando de atras hacia adelante y de adelante hacia atras hasta llegar al medio y de forma simultanea... con esto, si tenemos muchos graficos es posible que el metodo de ir de atras hacia adelante sea mas efectivo... pero si tenemos pocos graficos puede que a la inversa... de esta forma sacrificamos un poco de coste en fpg de pocos graficos pero lo ganamos en los de muchos...

igual, como sea, esa funcion deberia hacer lo mismo que se propone aca (mas rapido al estar el C, seguro), ya que actualizarlo constantemente requeriria que cada vez que se borrar un grafico (si es el ultimo) se recorra la libreria para obtener el ultimo... no me parece algo bonito... y desde bennu esto se podria hacer cuando se carga la lib... con lo que el coste seguramente no afectaria a runtimes criticos... supongo...

Windgate · November 28, 2009, 05:47:50 AM

@Splinter: Por supuesto el coste no sería significativo (Por dios, tenemos hasta 3Ghz!)

Pero si el problema es gestionar bien las animaciones: ¿Has echado un vistazo a la solución para las animaciones de mi tutorial? Es capaz de gestionar CUALQUIER número de animaciones y cambios entre ellas, incluye diagramas de estados para gestionar las condiciones de cambio de animación, que pueden ser complejas:

El tutorial completo: http://trinit.es/tutoriales

Y el diagrama del que hablo (Tema 24 23): http://trinit.es/temario/Diagramas%20de%20Estados%20-%20Animaciones%20II.pdf

Mi solución admite huecos en un FPG, siempre y cuando no haya "cosas raras", se asume que el FPG está bien construido y los diferentes maps de una misma animación son contiguos numéricamente.

Con esto quiero decir que no es necesaria la utilidad que determina el último map del fpg: Si el fpg no tiene los gráficos que se piden, entoces no se muestra nada y ya está, como es natural en Bennu.

SplinterGU · November 28, 2009, 06:03:11 AM

exacto, es natural...

BoMbErLiNk · November 28, 2009, 06:12:13 AM

Si no tengo ningún problema hombre, llevo 9 años en esto ;)

Simplemente me ha extrañado ese nivel de optimización extremo en algo que en teoría apenas tiene importancia.