Buenas, antes de todo no vengo a pedir una solución, me gusta poner todas las imagenes en el mismo FPG punto pelota xD
Resulta que me ha ocurrido lo impensable, me he quedado sin espacio en el FPG :-[
La sugerenica es que se puedan meter mas de 999 imagenes en un FPG, no se si el FPG Edit soportaria esto, así que la sugerencia va tanto para Splinter como para DCElso ;D
Estoooo. ¿Que cenaste anoche? ;D ;D ;D
Hhahhahaha, toy gordo lo se xDDDD
olvidate de eso... no solo es ridiculo sino que una locura.
no se puede romper la compatibilidad hacia atras a tal punto solo porque queres meter todos tus graficos en 1 solo fpg...
cargalos en map, png, pcx o lo que quieras por separado si los queres tener todos en el mismo file.
Quote from: SplinterGU on April 01, 2011, 02:13:05 PM
olvidate de eso... no solo es ridiculo sino que una locura.
no se puede romper la compatibilidad hacia atras a tal punto solo porque queres meter todos tus graficos en 1 solo fpg...
cargalos en map, png, pcx o lo que quieras por separado si los queres tener todos en el mismo file.
perdon, creo que mi respuesta sono mal...
lo que quiero decir es que seria romper mucha compatibilidad...
Splinter, no le hagas caso, que ayer seguro que se comió cinco raciones de gambas para cenar y todavía le afecta el cerebro. Jua, jua, jua.
juaz! igual no esta mal retractarme si me parecio agresiva mi respuesta.
Uiiiiu, splinter fue agressivo, creamos ahora mismito la encuesta para descubrir la verdad ;D ;D
jajaja...
Juer, más de 999 gráficos son muchos gráficos :D
Si tienes gráficos repetidos con distintos colores, plantéate el usar diversas paletas en modo 16 bits... o recomendar 4GB de RAM como mínimo :D
Un sólo FPG no suele traer nada bueno :P
Más en serio, esto se hizo así porque los gráficos cargados de forma independiente obtienen del valor 1000 en adelante como ID para las variables GRAPH, de forma que aunque tengas un FPG cargado no entra en conflicto con los gráficos sueltos (recuerda que tanto el primer FPG como los gráficos sueltos usan 0 para FILE).
yo creo recordar que en el fpgedit no hay límite de gráficos en el código, lo único que hay es una comprobación para no insertar más de 999, pero quitándola te dejaría insertar más, ahora está que si que hay un límite debido al formato del contenedor fgp, que es el de 16 bits que se usa para guardar el número de gráficos que contiene :D.
DCelso, el formato esta pensando para no usar mas de 999, no porque el contador no pueda llegar a mas, sino porque la filosofia DIV de los fpg es esa...
no se puede cambiar eso, sin romper compatibilidad y toda la filosofia DIV al respecto.
Hay una solucion, la implementas si quieres.
Le pones una nueva variable de sistema, por ejemplo:
extended_fpg = true;
Por defecto vendria a false manteniendo retrocompatibilidad.
A true, esto permitiria usar fpg's extendidos en su numero de graficos y la logica interna ya la cambiarias para volver todo compatible y poder solventrar las limitaciones que dice Drumpi.
Cheers ;D
hay otra solucion,
Le pones una nueva variable de local, por ejemplo:
extended_fpg = true;
luego al asignar el file y graph preguntas por la variable si esta en true va un FPG si esta en false, va el otro
y asi tienes 1998 graficos en lugar de 999
:P
EDIT parodiaba el comentario de free, y de paso le daba una solucion, sin necesidad de cambiar la retrocompatibilidad...
olvidenlo...
llamemos a daniel navarro y que alimente este debate , de porque ...
??? jajajaja
free si necesitas usar mas de 999 graficos, usa varios PFG, puedes faciltemeente cambiar de FPG por codigo...
puffff, parece que no habeis leido mi primer post :D
No busco una solución, esa solución ya la tengo of course, he comentado una sugerencia no una duda ;D
De todas formas necesitaba separarlos, porque la Wiz se queda corta de memoria.
Quote from: FreeYourMind on April 02, 2011, 12:39:23 AM
puffff, parece que no habeis leido mi primer post :D
No busco una solución, esa solución ya la tengo of course, he comentado una sugerencia no una duda ;D
De todas formas necesitaba separarlos, porque la Wiz se queda corta de memoria.
ese es otro de los motivos por el cual tiene limite... porque la wiz se queda corta si cargas muchos graficos... :P
Que mentira mas tonta :D
Tiene limite porque viene de DIV almenos que hubieran adivinado que en el futuro un clon de DIV estaria en una consola portatil llamada Wiz limitada de recursos como los pc's de la epoca xD
Pues el fpg lo carga completito que sepas, el problema viene por el resto de cargas, solo ocupa unos 7 megas.
Quote from: FreeYourMind on April 02, 2011, 05:11:16 PM
Que mentira mas tonta :D
Tiene limite porque viene de DIV almenos que hubieran adivinado que en el futuro un clon de DIV estaria en una consola portatil llamada Wiz limitada de recursos como los pc's de la epoca xD
Pues el fpg lo carga completito que sepas, el problema viene por el resto de cargas, solo ocupa unos 7 megas.
me extraña que no sepas que DIV estaba muy adelantado a su epoca...
Mira que he explicado el motivo de los 999 gráficos :D
Si quieres tener más, basta con crearte tu propio formato FPG y tu propia función para cargarlos. Lo puedes hacer en lenguaje Bennu, sólo necesitas un array que guarde los ID de todos los mapas que vayas creando en memoria, y que uses MAP_PUT_PIXEL para copiar las imágenes en los nuevos mapas ;D
Sigo opinando que más de 1000 sprites en un FPG es una salvajada, ni Prince Of Persia tenía tal cantidad (y podría dudar incluso de Dragon's Lair, si vamos habitación por habitación :D).
obviamente mi respuesta fue ironica.
:D, pues yo no veo problemas de compatibilidad, si el sistema es capaz de leer mas de mil imagenes en un fpg, ¿por qué no va a poder leer menos de mil imágenes, :D?
Si te refieres a incompatibilidad con dcbs ya compilados, buenoo, si eso pasa en cada nueva version de bennu ... :D.
compatibilidad de no de dcb, de codigos y no solo eso, de funcionamiento interno...
dcb que necesitan detectar que graficos existen o no en un fpg, o saber si un grafico pertenece a un fpg o a uno creado/cargado manualmente, tablas de optimizacion de busquedas, ids a partir de los cuales se asignan y se diferencian internamente a que pertenece un grafico... miles de cosas que esperan 1000 o superior para graficos fuera de fpg... y no hablo solo de cosas internas, tambien pueden existir dlls externas que se basen en esto... muchas cosas se basan en esto, yo diria que todo lo que tiene que ver con graficos se apoya y se basa en esto... es parte de su espiritu...
esto no es algo que alguien diga, si, vamos a cambiarlo porque se me antoja tener todos los graficos en 1 unico fpg... ni tampoco afirmar tan livianamente que no hay problemas de compatibilidad, sin detenerse a pensarlo un minuto... esto es algo demasiado basico y arraigado a los like DIV... es una parte su escencia...
por otro lado, te puedo asegurar que hace muchas versiones que no necesito recompilar un dcb... salvo versiones muy concretas.
incluso hay versiones donde hay cambios en los dcb y muy internos asociados con los opcodes generados, y sin embargo el motor nuevo se los mastica de lo lindo, y no da ningun problema.
Sobre la compatiblilidad del dcb entre versiones de bennu y para no abrir otro hilo, necesito saber todas las versiones de bennu (una lista) donde se ha rompido compatibilidad del dcb con la version anterior.
Y tambien saber a que version se corresponde el port a Pandora, porque he compilado un juego con la r128 y su dcb ya no es compatible con el port de pandora.
para que quieres saber todas las versiones que el dcb rompe compatibilidad con la anterior? no te puedo dar ese dato, no conservo las versiones anteriores de los binarios, yo si se que hace tiempo que no tengo que recompilar para que un dcb funcione, salvo el bug que se metio en una version en concreto en la que el juego de naves para wiz que habias probado vos, hacia que las naves salgan constantemente una tras de otra, salvo ese bug, hace mucho que no recompilo, incluso ese bug fue solo de esa version en concreta, entre la anterior a esa version y la posterior, los dcb (viejos y nuevos) corren en la version mas nueva.
por de pandora, ni idea.
La version de pandora tiene fecha asociada, podias ver que version es por fecha ?
En el cvs estan marcadas por fecha.
eso no significa que hayan hecho el port con la misma version del svn... deberias preguntar a quien hizo el port...
Lo hizo en la version que en su dia tenias en el cvs, con lo cual mirando la fecha de su port y las del cvs con fechas cercanas se puede determinar con una margen de error minima, por lo menos para saber que version usar para compilar un dcb compatible...