El futuro de FPG.EXE y MAP.EXE

SplinterGU · March 13, 2009, 06:48:55 PM

es una buena pregunta... lo que no se si es buena idea...
voy a ponerle a revision...

Windgate · March 17, 2009, 10:55:40 AM

Mmmh... Yo tengo otra cuestion. Cuando utilizo FPGedit para generar mis FPG y añado algun mapa de mas de 4096 pixels, ya sea de ancho o de alto, "a veces" se me corrompe el FPG. ¿Eso tambien pasaria si usase el FPG.exe? ¿Es problema del FPGedit o del formato de fichero FPG en si mismo?

Tenia un jueguito muy bonito y como el scroll tenia 5000 pixels de ancho, tras añadir algun grafico mas me ha terminado corrupto, y eso pone a Windgate muuuuy triste :'(

SplinterGU · March 18, 2009, 12:53:56 AM

jejeje... hablando en 3ra persona... jajaja...

creo que es un error del fpgedit... en bennu no deberia fallar... si mal no recuerdo no hay limite de tamaño... pero puede que mi memoria falle.

Drumpi · March 18, 2009, 10:09:41 AM

Pues ahora que lo dices, los map de DIV tenían una limitación, y alguna vez recuerdo haber leido a Slainte decir algo de los límites de tamaño, pero ya no se si era por el viejo formato, o por el de Fenix.
Una nueva oportunidad de revisar el código fuente :D

splinter_work · March 18, 2009, 12:36:35 PM

El load_fpg no tiene limite de tamaño... bueno, hasta 32767 funciona bien... aunque seria necesario cambiar el tip de las variables para que sea unsigned, y asi llegar a los 65535.

Windgate · March 18, 2009, 12:59:29 PM

Oh, claro, con load_fpg() podría solucionarse. Creo que el problema es del FPG Edit que al añadir nuevos gráficos, si hay alguno de más de 4096 puede machacar el FPG.

Puede ser una solución, voy a probar con load_fpg() y el scroll completo del Castlevania de GBA, que son unos 25K pixels tanto de ancho como de alto!!! Y os digo a ver qué tal lo mueve.

Qué curiosidad tengo... xD

blostec · March 18, 2009, 01:34:06 PM

Tampoco tiene mucho sentido usar maps tan grandes, implica un uso de memoria muy grande y poco eficiente, mejor partir el mapa en partes mas pequeñas.

splinter_work · March 18, 2009, 02:38:30 PM

la eficiencia es la misma... el uso de memoria si es gigante, pero una vez que un mapa supera el tamaño de la pantalla da lo mismo que sea, 2 veces una pantalla o 100...

la cuestion con el load_fpg es que tenes que tener el fpg correctamente creado, creo que lo mejor sera adicionar el grafico desde codigo bennu (cargandolo previamente con un load_png, por ejemplo) y luego guardar el fpg desde bennu...

ahi deberia funcionar...

emov2k4 · March 18, 2009, 02:45:08 PM

hola buenas... este post no tiene mucho que ver con el tema...
en la Universidad me dicen que soy un experto en programacion , porque hago juegos para pc, celular , Nds ... , manejo php , java... entre muchos otros lenguajes , de todo "UN POCO "... pero... la verdad es que me gustaria saber mucho mas y llegar a un conocimiento como el de ustedes, e leido todo este post y hay cosas que no entiendo, pero que me encantaria aprender, el problema que tengo es que nunca tube clases de ingles en mis estudios basicos, osea tube.. pero no lo que yo espera como para aprender y la mayoria de los tutoriales y libros estan en ingles, hay varios en español que son portados del ingles, pero me doy cuenta que tienen muy mala traduccion, me gustaria que coloquen una seccion que se llama "como se hace" :D donde expliquen las cosas basicas para llegar a lo que es hoy bennu.. fenix...entre otras cosas, paletas de colores... entre muchos temas que a muchos nos interezarian...GRACIAS

Windgate · March 18, 2009, 06:25:47 PM

Hola emov2k4, te remito a esta entrada de mi blog donde tienes una plantilla 100% lista para empezar a trabajar con Bennu y enlaces a todos los programas que yo uso:

http://trinitformacion.blogspot.com/2009/03/plantilla-para-empezar-programar-en.html

Si ya has programado alguna vez, con esta plantilla y el manual de referencia de Fenix puedes empezar sin temor alguno, ¿Tienes ese manual?

Y volviendo al tema, en cuanto al uso de mapas "enormes" en el FPG, con load_png me ha funcionado de lujo, creo que esa es la solución buena, aunque también me gustaría probar con el FPGedit "nuevo" que han programado en Bennu, que está en otro hilo.

Y ahora hago una pregunta peculiar sobre puntos de control. Para un videojuego de plataformas con su gravedad y sus cositas, ¿Conviene tener el punto de control siempre abajo o da lo mismo? ¿FPG.exe permite modificar muchos puntos de control al mismo tiempo a diferencia de FPGedit?

emov2k4 · March 18, 2009, 07:08:42 PM

Quote from: Windgate on March 18, 2009, 06:25:47 PM
Hola emov2k4, te remito a esta entrada de mi blog donde tienes una plantilla 100% lista para empezar a trabajar con Bennu y enlaces a todos los programas que yo uso:

http://trinitformacion.blogspot.com/2009/03/plantilla-para-empezar-programar-en.html

Si ya has programado alguna vez, con esta plantilla y el manual de referencia de Fenix puedes empezar sin temor alguno, ¿Tienes ese manual?

quisas no me explique bien , lo que quise decir es que me gustaria saber un poco mas sobre lo que hay detras de bennu trabajar en su codigo fuente... un tutorial que te enseñe a crear un interprete... programar graficos.. como en este caso programar un fpg.exe o un map.exe

Windgate · March 18, 2009, 07:37:01 PM

Oh, pensé que estabas en un nivel un poco más noob. Yo programo en Bennu, pero no para Bennu por ahora... Como mucho algunos módulos de código reutilizables en otros proyectos. Seguro que otros pueden asesorarte mejor que yo en ese sentido xD

Drumpi · March 19, 2009, 01:06:44 PM

Quote from: Windgate on March 18, 2009, 06:25:47 PM
Y ahora hago una pregunta peculiar sobre puntos de control. Para un videojuego de plataformas con su gravedad y sus cositas, ¿Conviene tener el punto de control siempre abajo o da lo mismo? ¿FPG.exe permite modificar muchos puntos de control al mismo tiempo a diferencia de FPGedit?

El punto de control da lo mismo dónde lo tengas, sólo te sirve como referencia para buscar durezas en el mapa de idem. se suele poner en los pies porque, por lo general, estamos comprobando más tiempo la "colisión" con el suelo que con las paredes. Pero si te fijas, a la hora de mirar las paredes, la primera operación es "desplazar" el punto de observacion anchográfico/2.
Y supongo que con fpg.exe podrías cambiar el punto de control a muchos gráficos usando un .bat o algo así, que realice varias llamadas al ejecutable con los parámetros adecuados.

Quote from: emov2k4 on March 18, 2009, 07:08:42 PM
quisas no me explique bien , lo que quise decir es que me gustaria saber un poco mas sobre lo que hay detras de bennu trabajar en su codigo fuente... un tutorial que te enseñe a crear un interprete... programar graficos.. como en este caso programar un fpg.exe o un map.exe

Pues el caso es que, para mi editor de fuentes, he estado mirando el código de fenix (el de bennu será similar), y para otros detalles de gráficos, y viene muy bien comentado y estructurado. Vamos, que incluso me estoy planteando hacer alguna ligera modificación, añadir algunas funciones, aunque claro, aun no me he mirado el código del compilador ^^U
Yo recomendaría hacerle una visita, así, por encima, mirando cosillas sueltas. Se puede aprender mucho (como que usar las SDL simplifica muchíiiiisimo la programación de gráficos XD)

DCelso · June 14, 2009, 11:55:18 AM

Anda, ni me acordaba de este post, lo he leído de casualidad buscando map.exe.
A ver yo quería saber si alguien había hecho estos programillas para bennu y recordaba que se habló de ello, veo que no.
He visto que se intentó la actualización del FPGEdit, kimeleto, siento que no pudieras de haberlo hecho me hubieras ahorrado muchos comederos de cabeza :D, a mi me ha costado un poco adaptarme a delphi, hace mucho que lo toqué pero como era más de c me pasé a c++builder que es exactamente como delphi pero usando C. Mi primera opción fue migrarlo a C++, pero pensé que sería mucho curro aún teniendo el código delphi como algorítmico, y dedicí repasar delphi para poder tocar el cógido, tengo que decir que aunque es un poco tosco el código de fpgedit, está bastante bien estructurado y me facilitó la tarea un poco, está claro que cada uno tiene su forma de programar y he ido cambiando el código a la mía así que hay cosas que he reprogramado porque las veía más intuitivas de mi forma.

He visto que habeis hablado de las limitaciones de los maps y los fpgs, analizando el código de FPG edit y las especificaciones de MAPs y FPGs puedo deciros que un map está mas limitado en tamaño de imágenes que un fpg. Hablando en plata un MAPs solo puede guardar imágenes cuyo ancho o alto sea el máximo permitido por una palabra (word) osea dos bytes, lo que es considerablemente ya grande porque un word puede guardar números desde el 0 al 65536. En cambio un fpg puede almacenar imágenes cuyo alto o ancho sea una palabra doble (dword) osea cuatro bytes, es decir, del 0 al 4294967296, creo que esa pudo ser la razón de porqué antes el FPG edit no exportaba ni leía los MAPs los consideraría su autor una limitación, aunque internamente tenía puesta una limitación de longitud de ancho por usar un array estático. Al FPG Edit 2009 le puedes añadir imágenes de cualquier tamaño, si pasas dicha limitación de dword entonces truncará la imagen hasta ese número máximo, de todas formas espero que nadie tenga imágenes tan grandes :D, ya me cuesta imaginar superar los aproximadamente 65000 de ancho de un "word" en una imagen.
La única ventaja de los maps sobre otro formato es que pueden guardar un vector de puntos, pero esto se podría solventar usando un png y un archivo de texto con los puntos, ya que FPGEdit puede exportar ese tipo de archivo. En teoría también podía guardar animaciones pero nunca se llevó a cabo esta tarea que yo sepa.

Drumpi · June 16, 2009, 11:10:00 AM

Hombre, los MAPs también guardaban una paleta en formato DIV, y son el único formato 8bits compatible con DIV (reconozco que aun sigo utilizando su editor gráfico... bueno, aunque la última vez fue hace meses ;D).
Sobre las animaciones, si que se estuvo haciendo algo. Yo aun debo conservar algun FBM animado que me pasaron para hacer pruebas. de todas formas, quedó demostrado que dichas animaciones carecían de mucha utilidad (aunque la tiene, no digo que no).
Aun así, MAP es un formato más que se usa, y que hay que tener en cuenta.