He visto en el formato fpg (http://fenixworld.se32.com/fenixwiki/index.php?title=Especificaci%C3%B3n_FPG) que dice que el code de los maps puede variar de 0 a 999. en cambio se le asigna un dword, que la capacidad es 0 - 4294967295. Bastante sobrao que va :D, podría dar lugar a eliminar la restricción de 999. ¿Lo tenías en mente?
Por otro lado he visto que fpgedit no deja poner el valor 0, creo recordar que ya hablamos de ello, es un valor factible para graph. el que no lo era era la combinación file = 0 graph = 0 porque era la pantalla o así. No encuentro el post pero ¿como era? o link al post. Gracias.
El número mínimo del graph en el FPG es el 1, no el 0 (aunque corregidme si me equivoco).
La restricción del número de mapas yo creo que viene más que nada para no desmadrarse ya que cuando se carga un fpg se cargan todos los gráficos y si pones 15000 gráficos en un FPG no creo que los vayas a usar todos al mismo tiempo y no sería muy eficiente...
de 1 a 999, el tamaño del elemento, es asi por compatibilidad, performance de acceso, etc...
El 0 no se admite porque el combo file=0 graph=0 es más factible de lo que piensas: el primer FPG que cargas tiene como ID el valor 0.
El límite de 999 viene dado por los MAPs cargados fuera de FPGs, porque el primer load_map devuelve como ID el número 1000, de ahi hacia arriba.
;D una pregunta chorra no puedo tener mas de 1000 fpgs ???
Si puedes tener más de 1000 fpgs (creo).
Lo que no puedes tener es más de 1000 MAPs por cada FPG (maps sueltos tampoco se el máximo).
De chorra no tiene nada, porque si a partir del mil dicen que están los maps, no podrás cargar a la vez más de 1000 fpgs :D.
Lo de los maps, quizas puedas cargar desde código prg más de 1000 maps ya que el id será único.
La duda me corroe :D.
Leamonos los mensajes fan club
(Luego dicen que no puedo trabajar de ninja)
File: cualquier valor.
Graph: 0 = pantalla; 1-999 = gráfico de FPG; >=1000 = gráfico cargado con load_map (o similares que no usan FPG propio).
Quote from: DCelso on June 11, 2009, 04:16:45 PM
De chorra no tiene nada, porque si a partir del mil dicen que están los maps, no podrás cargar a la vez más de 1000 fpgs :D.
Lo de los maps, quizas puedas cargar desde código prg más de 1000 maps ya que el id será único.
La duda me corroe :D.
jooo pos necesito mas pues estoy haciendo todo modular para cargar progresiba y no excesiva joooo :( :( :( :(
0 = pantalla
1-999 = fpg
>= 1000 graficos en el file 0 (aunque no importa mucho el valor de file) y sin limite de graficos
fenix = 64 fpg maximo
bennu = no limit (>=RC2) (versiones previas 1024)
Quote from: splinter_work on June 11, 2009, 08:38:08 PM
0 = pantalla
1-999 = fpg
>= 1000 graficos en el file 0 (aunque no importa mucho el valor de file) y sin limite de graficos
fenix = 64 fpg maximo
bennu = no limit (>=RC2) (versiones previas 1024)
me has alegrado el dia ;D
Me rindo.
Quote from: splinter_work on June 11, 2009, 08:38:08 PM
0 = pantalla
1-999 = fpg
>= 1000 graficos en el file 0 (aunque no importa mucho el valor de file) y sin limite de graficos
fenix = 64 fpg maximo
bennu = no limit (>=RC2) (versiones previas 1024)
me falto agregar, no solo los load_map como bien dijo drumpi, sino tambien los new_map o map_new y cualquier cosa que genere mapas, fuera de lo que son las funciones de fpg.
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).
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.
¿Como se sabria cual es el ultimo grafico de un FPG?
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...
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.
Eso es eficaz pero ineficiente, coste lineal en el número de gráficos del FPG
Al menos la solución existe :-\
A que te refieres con " coste lineal en el número de gráficos del FPG " ?
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
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.
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.
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.
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...
@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.
exacto, es natural...
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.
Humm mi pregunta de como saber cual es el ultimo grafico es para el editor ya que cuando te pasas a otro que no existe ,se rompe el editor ^^^,para decrementar no tengo problema pues uso IF (Graph>1) ect ,pero para avanzar cuando quiero pasar a otro que no existe pos eso se rompe.... de todas formas igual creo que are crear un FPG virtual al cargar los FPGs para que me digan cuando hay no se...
Quote from: DjSonyk on November 28, 2009, 04:48:31 PM
Humm mi pregunta de como saber cual es el ultimo grafico es para el editor ya que cuando te pasas a otro que no existe ,se rompe el editor ^^^,para decrementar no tengo problema pues uso IF (Graph>1) ect ,pero para avanzar cuando quiero pasar a otro que no existe pos eso se rompe.... de todas formas igual creo que are crear un FPG virtual al cargar los FPGs para que me digan cuando hay, no se...
Yo nunca he tenido problemas al asignar mapas que no existen a un proceso, símplemente no se muestran y listo.
Pero una función de este estilo sólo sirve en editores y se usa una única vez por FPG (o al menos no se me ocurre otro momento para ello, no creo que se modifiquen mucho los FPG en memoria, y de hacerlo, ya no necesitaríamos saber el último gráfico, pues lo estamos metiendo nosotros), y aunque la función fuese "lenta", se enmascararía con el tiempo de carga de dicho FPG.
Yo la usé en el "Venturer Resize".
El problema Drumpi esta que hay una opción en el editor que te coje automaticamente el ancho y alto para cada vez que cambies de grafico no tengas que introducirlo a mano ,(para al pintar se te alinien los graficos),la sentencia graphic_info() ,lo que pasa esque para pintar lo divide por 2 tanto ancho por alto para cojer el centro del grafico,y al dividir un grafico que no existe por 2,te da el error division por 0,una idea que me has dado de como el FPG es nuestro sabemos es final es que al cargar el FPG te pida que introduzcas el numero del ultimo grafico,pero seria un pelin chapuzas... una pena que no halla una sentencia parecida a graphic_info() pues me a venido muy bien ....ya se vera...