FPG Editor v 4.0

[DCelso]

splintergu, ya encontré el por qué de todo (en el otro hilo lo explico ). Sí que se puede. yo lo hago, el € está en muchos mas charset además del utf8, iso8859_15 sin ir mas lejos se creó para ello. mira la posición 164 de éste.

Lo que no puedes hacer es imprimir el €  con el fnt interno que trae bennu por defecto, por lo que dices, todas las imágenes son cp437, hasta ahí deacuerdo.

Pero en todos los fntedit, y fntmake anteriores fallaba eso, creaba fnx, con charset iso8859_15 poniendo el campo de charset a cp850, por lo que si codificabas en iso8859_15 el .prg, te iba perfectamente el euro y otros caracteres :D .

[SplinterGU]

pero a menos que quieras emular, tu tienes que crear tus prg en la misma codificacion que los fonts que usas... no puedes pretender usar un font cp437 escribiendo los textos con iso8859-15... ahi esta gran parte del problema... diria yo el problema inicial... luego pueden existir otros, pero eso es lo mas basico que debes hacer.

[DCelso]

Muy cierto.
En casos normales debe ser así, estoy deacuerdísimo contigo, habrá que documentarlo. espero que osk tome buena nota para futuras versiones de su documento :D

En casos raros, las simulaciones estas te pueden servir para crear tus propias codificaciones o caracteres raros, sabiendo que escribes en una codificacion real, digamos cp850 tu .prg, y luego dibujas grafos inventados para cada letra del cp850 en su posición en el fnx.

[DCelso]

Como digo, actualmente bennu va muy  bien para cualquier codificación de 8 bits, programas tu .prg en la codificación que quieras (de 8 bits). Creas tu fnx de esa codifiación  exacta y le pones en su cabecera de charset un 1 (lo que llamabamos mal dicho cp850, en verdad bennu cuando ve esto no hace nada ni mapea ni nada pasa directamente el valor leido al fnx para buscar la imagen) y usará la codificación de tu .prg.

Es justo lo que comentas de programar en la misma codificación de tu .fnt. :D

[FreeYourMind]

Buenas,
me he vuelto loco con tanta conversión, llevo 2 dias cambiando código...

Afinal la conversion automatica de pascal a c# usando la tool Delphi2CS era una mierda, y he tenido que ir creando codigo equivalente a lo loco, ya queda menos, pero tengo una duda a ver si me la resuelves porque ni mirando el codigo original encuentro donde se hace.

Te resumo, en FPG_Load, cargas un FPG en memoria, o sea rellenas la estructura, por lo menos las variables file_type, fpg_code y version, pero lo que no encuentro es donde les el contenido de las imagenes, mas concretamente, donde rellenas la variable FPG_images.bmp con los bitmaps que tienes en el fichero fpg (haciendo un f.Read por ejemplo), para despues leerlas de la memoria y pintarlas en tu form usando la funcion lvFPG_Load_Images...

Porque ahora mismo tengo una lectura con bmp nulls y la variable FPG_add_pos = 0;

[DCelso]

pues justo justito esa carga la cambié en fpgedit lazarus :D.
Antes había un switch que dependiendo del tipo de fgp leía una línea entera .en el fpgedit actual, creé una función para leer el bitmap, y abstraer un poco la lógica de lectura del switch case.

https://code.google.com/p/fpg-editor/source/browse/trunk/uFPG/uFPG.pas#576

Si lees, aqui loaddatabitmap, es justo lo que hacía para leer el bmp en el fpg-edit delphi. Te hago saber que en pascal hay una instrucción super rara que en otros lenguajes no existe, quizás esa sea quien te genera tu confusión. width http://www.delphibasics.co.uk/RTL.asp?Name=With

https://code.google.com/p/fpg-editor/source/browse/trunk/uMap/uMap.pas#69

[FreeYourMind]

ya veo, afinal la lectura la tenias en la propria funcion y despues la pasaste a la funcion loaddatabitmap, el tema es que me habia comido esa parte de codigo en fpg_load xD posiblemente porque borré la llamada, pero ya tenia la funcion en uMAp medio portada, bueno pues nada, lo que me interesa es saber en que posiciones leer del buffer, ya me pondré con ello, gracias  ;D

[DCelso]

;), de nada, esto lo hice para eliminar código redundante, antes estaba la carga tanto en los maps como en los fpgs, y si había que corregir algo y se te olvidaba en uno de los dos la gerías gorda :D, con ésto, solo debes cambiar en loaddatabitmap y corriges tanto maps como fpgs. ;).

[FreeYourMind]

Lo que si podrias hacer mientras no llega la noche xD, es decirme que hacen exactamente estas funciones en el loaddatabitmap, porque no encuentro equivalencia y tengo que saber que hacen exactamente para buscar otra forma de implementarlo:

1) Que tipo de controles de imagen son estos ?

a) lazBMP : TLazIntfImage;

b) result := TBitMap.Create;


2)

que hace esta llamada ?

p_bytearray := lazBMP.GetDataLineStart(k);


Sólo devuelve una imagen del fpg la funcion cierto ?

[FreeYourMind]

Bueno, voy avanzando, tengo que encontrar las funciones Calculate_RGB y Calculate_BGR a secas, que parece que son nuevas, voy a ver si las tienes tambien en uTools.

[FreeYourMind]

bueno ya esta portado, ahora sólo falta ir debugueando e ir arreglado errores hasta que funcione, mañana más xDD

[DCelso]

Guais, pues sí, estaba ahí.

Lo que si podrias hacer mientras no llega la noche xD, es decirme que hacen exactamente estas funciones en el loaddatabitmap, porque no encuentro equivalencia y tengo que saber que hacen exactamente para buscar otra forma de implementarlo:

1) Que tipo de controles de imagen son estos ?

a) lazBMP : TLazIntfImage;

b) result := TBitMap.Create;


2)

que hace esta llamada ?

p_bytearray := lazBMP.GetDataLineStart(k);


Sólo devuelve una imagen del fpg la funcion cierto ?

Sí, solo devuelve 1, si te das cuenta está en el umap, y los maps son para una imagen nada mas. :)
pero hay un for, para leer todas en el ufpg.

lo de lazbmp y tal, es de lazarus, en lazarus los tbitmaps no tienen el método scanline de delphi, y se simulan convirtiendolos a lazintfimage y usando el método getdatalinestart
que te devuelve el offset de una linea en los datos de la imagen. así vas trabajando línea a línea la imagen, en vez de pixel a pixel, lo que acelera mucho algunos procesos, como por ejemplo el de guardar o leer en archivo.

[FreeYourMind]

ya me he dado cuenta, ya he convertido todo a c# para que compile, pero me falta descubrir valores, de momento tengo que descubrir el offset en el array para recuperar cada dato de la estructura, ya que el f.read en c# necesita la posicion inicial del buffer en que se va leer cada dato y tus f.readbyte no disponen de esa informacion, aqui sólo me interesa la posicion del buffer para cada imagen del fpg y de paso ya paso los bits a otro tipo de datos como los bitmaps.
Resumiendo sólo me falta conocer las posiciones exactas del array en cada for, lo demas ya tengo su equivalente en c#.

[DCelso]

que raro, en c# el  f.read no avanza el buffer del fichero?. no me lo creo, totalmente ilógico en informática, en todos los lenguajes que he visto la lectura de archivos es secuencial, seguro que debe haber alternativa viable en c#. Es un poco extraño el tener que ir reposicionando el cursor del fichero para ir leyendo datos.

[FreeYourMind]

como que no avanza ? tienes start position y lenght, puedes leer de cualquier posicion, lo que pasa es que imagina esto, en tu array tienes 2 objetos, uno empieza en la posicion 0 y termina en la 10 y el otro empieza en la 11 y termina en la 15. Pues cuando leas el segundo objeto tienes que saber que el primero a terminado en la posicion 10, es esto que me falta, en tus freads no tengo información de inicio directamente, sólo el tamaño de cada uno, y para saberlo tengo que sumar sus tamaños en la strucutra y hacer lectura secuencial, pero es cosa que ya no me apetece hacer hoy ...