FPG Editor v 4.0

[DCelso]

Respecto a lo de abrir y guardar FNT de 1 bit en el editor de FPG:

Cuando corro por primera vez el programa e intento abrir un FNT de 1 bit desde el editor de FPG (Menu "Ficheros", submenu "Abrir..."), solo me abre el editor pero no me manda ningún mensaje ni me abre el FNT. Cuando abro algun otro FPG o FNT y despues intento abrir un FNT de 1 bit, me manda el siguiente error:

Code Select Expand

division by zero

Gracias, Revisaré esto.

se me acaba de ocurrir otra recomendación:
1)Que cuando se reemplaze una imagen dentro de un FPG por otra, así como se mantienen los puntos de control, que también se mantengan el campo "Nombre" y "Nombre de archivo", lo digo porque (solamente) el campo "Nombre" es accesible desde bennugd y puede que alguien lo use y el otro campo ("Nombre de archivo") es indispensable para guardar desde el editor de FPG un FNT, y cuando reemplazo una imagen estos campos cambian.

Puedes cambiarlo a posteriory dándole a editar. Siempre se hizo así esta parte por guardar el nombre de archivo del origen y poder recuperar su nombre original al exportarlo a imagen (png u otro formato) Pero estudiaré el caso, ahora con los FNT quizas no tenga tanto sentido ;D, quizás  si solo lo evito en caso de FNT ...

Una duda, ¿que diferencia tienen las gamas de colores con la paleta de colores, que utilidad tienen en bennugd? Entiendo que solo es para tener bien organizados los colores de la paleta para un acceso rápido y facilitar el pixel art. ¿cierto?

Muy cierto, solo sirven para diseño de pixelart.  En div nació con esa idea. DIV solo soportaba fpgs e imágenes de 8 bits.

Entonces esta técnica se podría usar para poder tener varias imágenes (de menos profundidad, imaginate de 4 bits (16 colores) ) conviviendo juntas del mismo fpg se podía usar esta técnica y hacer que cada gama fueran los colores de una imagen de 4 bits, pudiendo tener dentro del mismo fpg como 16 paletas distintas para 16 imágenes de 4 bits distintas.

Pero no queda reducido ahí su potencias, como verás, muchas imágenes podrían compartir colores, entonces organizando adecuadamente las gamas, podrías meter más de 16 imágenes de 4 bits distintas sin perder sus colores.

Pero en antaño, en 8 bits, había una cosa que hoy en día se ha perdido su uso, que era el cambio de paleta de colores para generar al segundo jugador o incluso a enemigos distintos. Imagínate un personaje con pantalones azules y camisa blanca, tendrías una gama de colores de azules y blancos, para así hacerle sombras a la ropa. Pues simplemente cambiando esa gama de colores a colores rojos y rosas podrías hacer que el personaje cambiase su vestimenta, por pantalones rojos y camisa rosa,  (por ejemplo Double dragon)
Esta técnica se podía implementar usando gamas de colores. Si divides tus 256 colores de tu fpg en 16 gamas de colores, podrías conseguir cambiar de color 16 objetos distintos a la vez independizando sus colores. Es decir, por ejemplo si cada gama la usas para colorear un objeto de pantalla, imaginate el jugador, un enemigo una lámpara, la calle. Podrías tener al enemigo azul  (usando una gama) , al jugador azul (usando otra) , la lampara  gris (usando otra) y la calle gris (usando otra distinta mas). Y simplemente cambiando la paleta del fpg, podrías hacer que el jugador vistiera de verde, el enemigo de amarillo, la lámpara de azul, la calle de rojo, sin que se solapasen sus colores, ya que cada uno usaría su azul o gris de su gama y no el de otra.

Hoy en día esta técnica  en 32 bis se puede medio simular dibujando tu imagen en escala de grises y luego poniéndole encima una plantilla con la silueta de la misma imagen con un color deseado y una componente de transparencia. Imagina un limón en escala de grises al que delante le pones una plantilla del mismo limón de color verde con alfa 128, (algo así como en la vida real a una foto en blanco y negro de un limón le pones un papel semitransparente verde ).

En fin, fpg edit en 8 bits debe de usar la paleta como un conjunto de 256 colores seleccionables entre todos los colores posibles. y las gamas de color como un conjunto de colores seleccionables solamente de la paleta de colores (son como mini paletas de la paleta)

En otro modo distinto a 8 bits, la paleta y las gamas se usan igual, un conjunto de colores de todos los posibles para acceder rápidamente para dibujar cosas.

[Anyeos]

Hola, por un lado quería ver si podía mejorar el FPG Editor ya que yo llevo años usando Lazarus. Es más, una vez hice un jueguito en Lazarus un par de años después de que usaba DIV. Y comencé con Delphi años anteriores cuando tenía Win, luego me pasé a Lazarus cuando comencé con Linux. Y bueno, eso ya fue hace como 12 años, algo de experiencia en ese lenguaje tengo.

Bueno, el asunto es que puedo colaborar con este software, pero... Igual ya son muchas tareas en las que me voy a meter, por eso no quiero prometer nada, prefiero primero darle prioridad al problema de video que tiene la versión actual de BennuGD.


Ahora, lo que realmente me decidió a responder acá es que estaba leyendo que hablabas de gamas de la paleta. Y aún tengo el DIV2 original y lo ejecuto bajo DOSBOX. Y que yo recuerde no existía una gama, o que se llame así. Pero creo que entiendo a lo que te refieres, te refieres a la parte de la paleta que tiene variaciones de colores en distinta intensidad organizada en filas.
La verdad no me acuerdo si eso estaba explicado en el libro original de DIV o si fue una técnica que comenzaron a emplear muchos creadores de juegos en DIV.

Pero es eso a lo que te refieres, verdad? Porque cuando cargo un map en el DIV2 o un FPG me obliga a cargar una paleta, generarla, o adaptar la carga del archivo a la paleta actual. O sea, sólo puedo manejar una paleta por vez, no existen más paletas cargadas a la vez. Solamente una por vez y cada vez que abres un nuevo map diferente puedes elegir cargar su propia paleta o adaptar su carga con la paleta actual. No veo que haya otra opción, al menos en DIV2.

Estoy viendo y me dice:
Se leyó una paleta nueva...
- Adaptar a la paleta actual
- Fusionar con la paleta actual
- Cargar la nueva paleta

Evidentemente no se pueden tener dos archivos FPG abiertos a la vez con dos paletas distintas. Al menos en DIV2 no.


Bueno, en realidad no me importa mucho para mi, pero lo quiero tener en claro para el tema de las funciones de blit que quiero reescribir para BennuGD.
Si alguien más puede sumarse a la charla o mejor tal vez sea conveniente iniciar un nuevo tema en los foros con este asunto.

Sugerencias acepto.

Que tengas un buen día.

[FreeYourMind]

Si DCElso esta de acuerdo le podrás ayudar, ya que es el que 'oficialmente' ha currado en esta aplicacion los ultimos años.

Por otro lado tambien se esta portando a mi tool BennuGD .Net Tools, la cual tambien se podrá usar para editar fpg's, pero todavia no esta disponible.

Sobre DIV2, por suerte tambien tengo los originales, el 1 y 2, pero aunque en el pasado por nostalgia he apoyado la importandcia de DIV en los div likes actuales, ya no veo que sea tan importante dar soporte o total compatibilidad a DIV en llos entornos actuales.

Creo que se debe pensar en dar soporte a otras tecnologias mas recientes que seguir insistiendo en la compatibilidad con el pasado.

[DCelso]

anyeos las gamas de color ya lo he repetido unas cuantas veces. no son nuevas paletas si no una forma de organizar los 256 colores de tu paleta actual en 16 o 32 conjuntos distintos. Nunca tendrás más de 256 pero sí 32 ordenaciones distintas de éstos 256 colores.
Ya he reiterado unas cuantas veces que esto solo sirve para la hora de edición de imágenes, parece que no usaste mucho o nada esta parte de edición de dv1 y div2. ya que te hubiera quedado clarísimo que sin la configuración de gamas de colores no puedes editar nada en div ;) .

Div guardaba estas gamas en los maps y fpgs, para que no tuvieras que estar configurando cada dos por tres estas gamas al editar imágenes, no sirven para nada en el juego final, estarian de adorno, es por ello que fenix nunca las usó, no estaba orientado a edición de maps o fpgs, solo a su uso para desarrollar juegos. Como esta herramienta está orientada a justo todo lo contrario, creí ver la necesidad de recuperar dicha peculiaridad en imágenes de 8 bits, y ya que me puse, pues apliqué una misma estrategia para 16 y 32 bits, haciendo que tanto la paleta como las gamas en el editor de imágenes en modos distintos a 8 bits funcionen como colecciones de colores de rápido acceso, lo malo es que el formato fpg no guarda paletas ni gamas en esos modos, así que no se guardan.

En cuanto a modificar o ayudar con el desarrollo, pues por mi de PM, tío, empieza con bajarte el código fuente, disponible bajo control de versiones svn, y compilarlo.
Si encuentras o te dicen algún fallo y creas alguna modificación, pues crea un .patch y lo inserto sin problemas en la rama oficial.

[Anyeos]

Respuesta para @FreeYourMind:
Lo que pasa que SplinterGU me dijo que esa era la condición de que debía ser compatible con eso el blit.

Pero yo la verdad que prefiero programar a partir de 16 bits para arriba. Y también si puedo de una ya usar OpenGL, claro, con la opción de no usarlo al iniciar el modo de video. O sea, añadiría una nueva bandera que activa el modo de aceleración OpenGL y un juego se seguiría programando igual nada más que ahora en vez de hacer todo eso por soft lo haría por hard. Obviamente que creo que iría mucho más rápido.

Pero mi idea es no tener que cambiar el código en tu juego, sino que el blit se encargaría de aprovechar el OpenGL si está disponible y si inicias el video en ese modo. De esta forma los mismos juegos que ya se hicieron a partir de 16 bits podrían fácilmente pasarse a 24 bits con OpenGL sin tener que cambiar nada, ni siquiera creo que hubiera necesidad de cambiar los FPG.

Dije 24 bits porque es como trabajan las tarjetas Nvidia con OpenGL para que funcione la aceleración del buffer Z, según recomienda NVIDIA. Pero funcionaría en 16 bits y 32 bits también. Aunque creo que en 16 andaría más rápido. Por eso mejor prefiero agregar el modo 24 bits y listo.


Pero bueno, igual voy a empezar por el modo de 16 bits que es el que ando usando ahora. Después se añadirán los demás si se necesitan.


Pero hay una cosa que no entiendo, por eso vine para acá:
Los puntos en un map (bitmap), por qué son varios? O sea, según tengo entendido el punto central determina justamente el medio de la imagen, donde las coordenadas X e Y van a ir a parar. Los otros puntos, como funcionaban? Había que elegirlos? Porque en el código del blit no veo que haga referencia a todos, simplemente figura un punto central.

Es correcto eso?

¿Actualmente para qué sirve tener varios puntos de control?
Eso quisiera saber.


Por lo de FPG Editor
Tenía más bien pensado tocar la parte del editor de programa porque quiero uno que me ayude bastante con el trabajo de editar un proyecto.
Así que lo único que voy a modificar va a ser eso, lo de los FPG, las FNT y todo lo demás no lo voy a tocar.

Al editor de programas le quisiera poner:

   
• Más opciones de configuración (Personalizar el resaltado de sintaxis y un par predefinido)
• Autocompletar (Que autocomplete con funciones tanto propias de BennuGD como process, globales, locales, etc del usuario)
• Salto a procedimiento (con clic derecho te daría la opción para saltar al procedimiento o la variable o lo que estés seleccionando).
• Ir a línea, buscar, reemplazar (eso ya está hecho igualmente)
• Automáticamente posarse sobre el fuente y el número de línea de un error en la compilación.
• Autosalvado y compilado al intentar ejecutar el programa
• Posibilidad de depurar el programa
• Abrir varios .prg en pestañas.

Podría trabajar también con "Proyectos" en lugar de abrir un prg así nomás, pero eso lo vería después.


Respuesta para @DCelso:
Hola DCelso, que tal, gracias por responder. Sí, tienes toda la razón jamás usé esa funcionalidad en DIV. Lo que me importaba en aquel entonces era que mi juego funcionara bien jaja, no le prestaba tanta atención a cambio de colores era más importante para mí que funcionara y ya.
Igual no pude usar mucho DIV, lo compré como en 2001 y luego tuve un problema en el disco duro y perdí mis proyectos de juego. Me amargué tanto que me desanimé y aparte otras cosas me hicieron no tener tiempo para eso.
Luego al año siguiente creo, o en 2003, vi en una tienda el DIV2 y también lo compré, con la idea de por fin poder empezar un proyecto de videojuego ya un poco mejor (suponía que la 2 era mejor). Sí, algunas mejoras tenía, no lo dudo, pero de vuelta algo similar me pasó perdí el trabajo y bue, otra vez, lo abandoné.

Porque me había costado tanto trabajo que me cansó. Obviamente que no tenía la culpa DIV pero el otro problema gravísimo para mí era que el DOS estaba pasado de moda. Quien le iba a dar auge a jugar a esos juegos bajo DOS. Ya para cuando logré tener algo casi como un juego era una época donde lo que estaba de moda era el Windows 98 y luego el Millenium y el 2000 que no tuvo mucho éxito en fin.

Pero me interesé en cambiarme a Linux, para mi sorpresa aún era peor, de un DOS a Linux, el DIV no iba a correr ni soñando. Ya cada vez era más imposible lograr eso. Entonces como usaba Delphi y estaba haciendo un software para otra cosa, y me pasé a Lazarus, pues, hice uno de mis juegos en Lazarus (Free Pascal) directamente y dejé ya de lado el DIV.
Luego me puse  a buscar y conseguí Fenix, pero tampoco era para Linux sino para Windows. Y así con tantos problemas era más fácil hacer cualquier otra cosa que un juego en DIV.

Hasta que comenzó a hacerse andar Fenix en Linux y luego apareció @SplinterGU con BennuGD que fue cuando comencé recién a intentar retomar el DIV nuevamente. Primero con el Fenix que me andaba en Linux y luego con BennuGD cuando también comenzó a funcionar en linux. Pero eso no fue hace mucho.

Y como te habrás dado cuenta, el tema de los 8 bits me quedó muy en la historia, una historia que ni siquiera yo viví mucho. Así que siempre trabajé a partir de 16 bits y sin paletas. Que para mí fue un alivio porque la paleta además de que te baja la calidad de los gráficos es un tema que hay que prestar atención y trabajar más para hacer encajar todos los gráficos a una paleta más o menos decente y que quede bien.

Y hoy día no me atrevo a desarrollar un juego con paleta porque se alcanza a notar esa deficiencia de colores y la gente es muy prejuiciosa y capaz que el juego está muy bien armado pero seguro no faltarían aquellos que digan que tiene gráficos antiguos y cosas así. Lo que le daría mala propaganda al juego.
Pero el otro tema es que cuesta más trabajo porque hay que andar trabajando con paletas a la hora de hacer los gráficos.

[DCelso]

Por lo de FPG Editor
Tenía más bien pensado tocar la parte del editor de programa porque quiero uno que me ayude bastante con el trabajo de editar un proyecto.
Así que lo único que voy a modificar va a ser eso, lo de los FPG, las FNT y todo lo demás no lo voy a tocar.

Al editor de programas le quisiera poner:

   
• Más opciones de configuración (Personalizar el resaltado de sintaxis y un par predefinido)
• Autocompletar (Que autocomplete con funciones tanto propias de BennuGD como process, globales, locales, etc del usuario)
• Salto a procedimiento (con clic derecho te daría la opción para saltar al procedimiento o la variable o lo que estés seleccionando).
• Ir a línea, buscar, reemplazar (eso ya está hecho igualmente)
• Automáticamente posarse sobre el fuente y el número de línea de un error en la compilación.
• Autosalvado y compilado al intentar ejecutar el programa
• Posibilidad de depurar el programa
• Abrir varios .prg en pestañas.

Podría trabajar también con "Proyectos" en lugar de abrir un prg así nomás, pero eso lo vería después.

:), todo eso lo tenía en mente añadir, el problema es el tiempo, así que si te animas y vas metiendo poco a poco esta parte al programa seria perfecto ;)

[DCelso]

sobre los 8 bits, disiento, no tiene que perder calidad un juego en 8 bits, ocupan menos, consumen menos recursos, hace mas multiplataforma al juego,  ofrece muchas ventajas, por ejemplo puedes cambiar la paleta y cambiar todos los colores para darle un aspecto distinto al juego sin modificar ni un solo gráfico, para los juegos a los que está orientado bennu va mas que sobrado.

[Anyeos]

Tengo buenas noticias estoy estudiando más sobre bitmaps, los formatos de pixel, el canal alfa y sobre composición de imágenes pixel a pixel.

Cuando termine de comprender bien todo eso me va a costar menos trabajo implementar una solución que abarque todos los requisitos. Y estoy viendo que no parece muy difícil trabajar en todos los formatos de bits que se quieren. Así que yo creo que de entrada nomás voy a tener todos los formatos inclusive los 8 bits.

Sería muy parecido a lo que ya hay pero voy a procurar instruirme bien para lograrle sacar el máximo provecho posible.


Saludos.


PD: Para no irme de tema acá mejor lo sigo por este otro lado -> http://forum.bennugd.org/index.php?topic=3538.0

[panreyes]

Me gustaría, si fuera posible, poder exportar las fuentes utilizando el nombre código-1+".png"
Los códigos actualmente son ASCII+1


Me explico. Ahora mismo esto está así:
@ -> ASCII 64 -> FNT 65 -> 65.PNG


Y me gustaría tener esta opción:
@ -> ASCII 64 -> FNT 65 -> 64.PNG

[Drumpi]

Sólo quería responder a Anyeos sobre el tema de los puntos de control.

Antes que nada, saludarte, porque no te había visto antes por aquí. Veo que te has metido en el tema del core: buena suerte.

Al lío: los puntos de control son eso, puntos que sirven de referencia dentro de un gráfico. Usando get_real_point nos permite situar, por ejemplo, un proceso "arma" en las manos del protagonista, aunque este cambie de gráfico: si todos los gráficos de la animación tiene un punto de control 1 situado en la mano, usando dicha función nos aseguramos que siempre esté el arma en la mano.
Esto sirve para indicar otra serie de puntos clave, por ejemplo, desde dónde se debe disparar, los ejes de rotación para las diversas articulaciones de un muñeco, dónde deben ir colocadas las ruedas de un coche... todo esto sin importar el gráfico, la rotación o el escalado del mismo.

Obviamente, esto al blitter le da igual, ya que los puntos de control son coordenadas que se pueden calcular matemáticamente, no tiene nada que ver con dibujar el gráfico. Quizás le pueda afectar por el tema de rotación y/o escalado del gráfico en sí, pero por lo que leí del código en su día, no lo creo.

También existe la función "get_point", que devuelve las coordenadas relativas al propio gráfico de ese punto de control, pero no tiene en cuenta ni escalados, ni rotaciones ni nada.

Son realmente útiles para manejar procesos dependientes de otros, o para situar gráficos en pantalla reduciendo cálculos.

PD: tengo que probar esta nueva versión de FPGEdit, que aun sigo con la primigenia :D
PD2: también tengo que averiguar por qué no soy capaz de meter cualquier map en una FNT de 16 bits :lol:

[Drumpi]

¿Hay que tener algún paquete instalado en Linux para hacerlo funcionar? me dice que no se encuentra un .so (libQt4Pas.so.5).
Instalé el paquete libQt4Pas5 y seguía insistiendo en lo mismo.

[kim-elet-o]

Estoy intentado hacer correr FPG Editor V 4.0, y me sale el mismo error que Drumpi.

De momento ire tirando con la version de windows mediante el Wine.

[DCelso]

superraro, lo único que hay que instalar es eso libqt4pas5 y claro ( libqtgui4 y demás pesca) pero eso creo que viene instalado de serie en casi todas las distros  .
yo he hecho lsof -c fpg-editor y me salen una hartá de .so, pero el que tu dices en cuestión es este /usr/lib/i386-linux-gnu/libQt4Pas.so.5.2.5
mira a ver que versión tienes instalada de ese fichero y en qué ruta está. quizás solo necesites hacer un ln -s del que tengas al que te pide "libQt4Pas.so.5" que le haya faltado hacer a tu instalador de tu distro

[master]

Drumpi y kim-elet-o

me pasaba lo mismo, solo instalen la lib, por ejemplo, yo tengo ubuntu de 64 bits:

Code Select Expand

$ sudo apt-get install libqt4pas-dev:i386

y con eso me funcionó

[kim-elet-o]

Ok master, faltaba esa libreria por instalar, gracias.

Por el nombre de la libreria, deduzco que es una libreria de desarrollo para 32 bits, quizas el problema sea que se ha compilado la ultima version con una libreria de desarrollo, en vez con la libreria de produccion.

De todos modos gracias DCelso por el desarrollo de su herramienta, y gracias a master por la solucion de mi problema.