FPG Edit 2009

[FreeYourMind]

Si es de 16 bits, pero pensaba que al setear a 32 bits en Bennu eso se resolvia.
Efectivamente creo que son restos semi transparentes, aunque en photoshop se ve todo transparente.
El programa fireworks que es de lejos el mejor para tratar png's, seguramente te enseñe esas semi transparencias.
El error ya no se ha vuelto a reproducir, y he seguido los mismos pasos, asi que dejalo, que el grafista ya se ha puesto a revisar los gráficos para quitarle las semi transparencias.
Thanks.

[Danielo515]

A ver gente, que eso que dice FreeyourMind lo estube yo comentando hace ya un mes y me deciais que se me iba la olla. Como veis el problema no es solo mío, yo también tengo ese problema con el fpgedit2009, cosa que no me pasa con el editor de fpg en código bennu.

El fpgedit me parece una herramienta super profesional y muy usable, si solucionaseis ese problemilla seria lo tool definitiva ya que es muy poderosa en todas sus demás virtudes.

¡Y A VER SI CREEMOS MÁS EN MÍ! Que tengo una sensación de paria que no puedo con ella.

[FreeYourMind]

No te creo  ;D ;D

[DCelso]

danielo, a ver, es que tenemos que tener muy claras dos cosas.
Lo que comenta free es que ha creado un fpg de 16 bits y en él ha insertado imágenes de 32 bits. Pues aquí es donde reside la limitación, resulta que los fpgs de 16 bits no guardan "semitranparentes" (podríamos decirle a esto alfas de 8 bits) en vez de esto solo guardan información de si un pixel es transparente o tiene color (vulgarmente podríamos decirle alfas de 1 bits, aunque en realidad es que uno de todos los colores que puedes representar con 16 bits se convertirá en color transparente) así que debido a esa limitación que es intrínseca a imágenes de 16 bits, cuando intentas insertar una imágen de 32 bits (recordemos 8 bits para alfas) pues necesitas crear un convenio para saber cuales de las 256 posibilidades que dan 8 bits de alfa van a dar como resultado un transparente puro, y el convenio es 50%, por tanto del 0 al 127 será convertido a transparente puro y del 128 al 256 no serán transparentes por lo que deja el color RGB que tenga el pixel real. Este es el efecto que veía free en su fpg.

Ahora bien, tu caso, si no recuerdo mal, es otro, que tienes un fpg de 32 bits y no guarda bien las imágenes de 32 bits haciendo ver colores raros en los rebordes, revísame esto por favor, si es un fpg de 32 bits debería guardar bien todas las alfas si la imagen es de 32 bits. Si es un fpg de 16 bits, entonces funciona bien el fpgedit ya que hay que tomar el convenio sí o sí.

[DCelso]

¿Alguien subió el código fuente a algun otro servidor que no sea tipo mediafire, megaupload,etc?
¿o alguien puede subirlo a algun servidor que no sea de ese tipo?
Que no puedo bajarme el código fuente desde el curro por el magnífico proxy que tenemos,cagoen.

[Windgate]

Te lo puedo subir a trinit.es si me pasas por MP el link de descarga o me mandas un correo adjuntándolo

[DCelso]

Ya no hace falta, gracias igualmente, aqui en mi casa si que puedo acceder a esas páginas :D.
El link con el src estaba en el primer post.

[SplinterGU]

DCelso, ahora que estas activo nuevamente, podrias fixear el problema con el nombre de los mapas? fpgedit esta usando el campo nombre para poner  "FPGEDIT2009" y ese campo es el nombre del mapa, no se donde esta metiendo el nombre del mapa, pero no es ese el campo.

gracias.

[Kloppix]

Aprovecho también para comentar. DoctorN reporta que el programa falla cuando se trabaja con muchas imágenes (http://forum.bennugd.org/index.php?topic=3177.msg54600#new).

Hay alguna posibilidad de que el programaa funcione bajo Wine?

[SplinterGU]

es raro ese reporte de que falla con mas de 300 mapas.

creo que el tema de wine escapa del soporte que pueda dar DCelso...

mas que wine, quizas estaria bueno reimplementarlo en linux.

[josebita]

DCelso, el código fuente del FPGEdit no se puede descargar de la dirección del primer post. ¿Está disponible en algún otro sitio?.

[DCelso]

Umn, vayamos por partes.

SplinterGU, eso que dices no es nada normal, si pasa con tu .fpg, algo está fallando en ese .fpg, el FPGEDIT 2009 guarda los nombres de los maps recortando la extensión que tenga y metiendolos en el campo nombre de la cabecera de cada map correspondiente. La prueba está en que si creas un fpg de cero con fpgedit, metes una foto la que sea, guardas, cierras, abres el fpg y extraes la foto verás que te pone el nombre original. Mira a ver si te estás confundiendo de campo y quizás estés viendo el campo descripción en vez del campo nombre de cada map.

En cuanto a hacerlo funcionar en wine, es una posibilidad, aparentemente funciona bien con la última versión de wine, salvo algunos fallos, que creo que son de APIS windows que usa delphi que no están implementadas en wine, así que toca esperar nuevas versiones de wine.

En cuanto a portarlo a linux, única posibilidad rápida que ví sería pasarlo a lázarus, ya que es object pascal al igual que delphi. El problema reside otra vez en que hay algunas APIs de delphi no tienen traducción directa a APIs lazarus, asi que se complica un poco la tarea de portación.

En cuanto a la limitación de meter muchas imágenes de DoctorN, primera noticia que tengo de que eso falle, probablemente esté intentando meter mas de 1000, pero debería avisar el programa en vez de crashear. Puede que también sea problema de alguna imagen en concreto que hace que casque el fpgedit, necesitaría el paquete completo de imágenes que usa para hacer las pruebas a ver por qué casca.

En cuanto al código fuente, mal vamos, perdí mi disco duro donde tenía  el código fuente de esto y más cosas por mi casa, en algún lado debe andar, pero por ahora paradero desconocido, en cuanto lo encuentre lo rescataré y lo subiré a algún lado, mientras a ver si alguien se pudo descargar en su tiempo la última versión que subí y que nos la vuelva a subir a todos. :D.

[SplinterGU]

a ver... en el fpg, esta es la estructura de cada mapa...

Code Select Expand


struct
{
    int     code ;
    int     regsize ;
    char    name[32] ;  // <-- descripcion
    char    fpname[12] ; // <-- filename
    int     width ;
    int     height ;
    int     flags ;
} chunk ;


y esta la estructura de los mapas en si.

Code Select Expand


    char magic[3]; //'map'
    char signature[4]; // 1a 0d 0a 00
    char  version;
    int16     width ;
    int16    height ;
    int32    code;
    char    name[32] ;


en fenix y en bennugd el campo descripcion es el nombre del grafico (no del archivo), desconozco porque en DIV se llama descripcion, cuando deberia ser el nombre, ya que fijate los tamaños de los campos, filename (fpname) no corresponde con el campo name... que demas esta decir en la documentacion de DIV es descripcion, pero no esta en la estructura map el campo name... por eso supongo que el autor original de fenix decidio poner como name el campo descripcion, ya que el otro no tiene correspondencia en la estructura map.

en fin, se necesita que mas alla del nombre del archivo, la descripcion sea el nombre del map y no la etiqueta "FPGEDIT 2009".

podrias corregirlo?

(agrego, el campo filename no se usa en bennugd ni en fenix... tampoco puedo cambiar yo el campo porque se arrastra del diseño original y romperia compatibilidad)

lo de DoctorN dice mas de 300 graficos.

vale, si lo has perdido no hay mucho que hacer... pero creo suponer acertadamente que FreeYourMind los tiene.

te agradezco la respuesta.

saludos

[FreeYourMind]

yo creo que le falla es la version con el icono azul, a mi a veces tb me petaba, pero ya no recuerdo el motivo, pero no es el numero de graficos.

[DCelso]

Umn. Splinter. Cuando pille el codigo voy a comprobar eso. Creo recordar que fpg edit recorta a 1 el nombre. Asi que casi seguro que hace la asociacion mal. Por otro lado cuando dices nombre del map te refieres al nombre del archivo map o bien son dos cosas distintas.