Avances, Diario de...

[SplinterGU]

necesito ejemplo.

sin un load_pal o sin un new_pal, es correcto.

la otra pregunta es porque una trabaja con paletas individuales y otra con la del sistema.

.------------

volviendo al tema de los 32bits, funciona perfecto (bueno, a medias), es que ahora el render tambien considera el alpha de la pantalla donde se hace el render y entonces al tener este 0, no dibuja, si en el proceso esfera ponemos flags = b_nocolorkey; vamos a ver que se dibuja todo tal cual era en la anterior version, pero el map_put funciono perfectamente, aunque esto funciona perfecto, ahora van a surgir problemas al dibujar sobre la pantalla. diablos!

[Drumpi]

Pues te mando el código: es un programa que a partir de un fichero TMF (mi formato de mapas de tiles), genera un FPG de durezas de 8 bits (cada pixel equivale al número del tile en esa posición) usando como paleta un BMP "especial", y después un BMP del propio mapa de tiles para usarlo como textura.

Lo primero es lo de la linea 113 de tmf2mode7.prg, no puedo hacer set_colors (a la paleta del sistema) sin usar load_pal.
Lo importante está entre las líneas 116 y 129: en la línea 122 generamos un mapa de 8 bits, la función se encuentra en tmf_conv.inc. En ese fichero, verás la línea 16 comentada. Si quitas las //, cuando salga por pantalla se verá todo negro (salvo la paleta), pero si lo pegas en el paint y rellenas de blanco, verás un mini cuadrado negro en el centro, que no es realmente negro puro, se puede usar la herramienta de relleno y se notarán los diversos colores.
La línea 17 era una prueba para ver si el mapa estaba bién, como proceso el mapa de 8 bits se muestra con los colores de la paleta.

Y ya, si alguien puede decirme por qué tmf_dur.fpg, a pesar de estar bien creado y de tener bien la paleta (comprobado con editor hexadecimal) lo que debería verse gris se ve negro con el FPGedit viejuno...

[SplinterGU]

si estas en modo 16 bits, no tenes paleta del sistema hasta que hagas un load_pal, como sea, en 16bits, todos los graficos de 8 bits tiene su paleta propia, si queres que usen la del sistema tenes que eliminar la paleta de cada un de los graficos de 8bits.

[SplinterGU]

corregi un nuevo bug, con collision con type mouse, si el grafico del proceso que se quiere testear tiene un tamaño diferente a 100 y supongo que tambien si tiene angle.
no pasaba con las nuevas de collision (box, circle).

esto se debe a que aun se ve que existe el tema que si es de 1px de ancho no pinta bien, no se en que circunstancias, ya que la que dibuja rotado/escalado y la que no son diferentes.

bueno, lo parche, haciendo que el area de colision del mouse sea 2x1, en vez de 1x1, aunque para la comprobaion se testea solo 1x1, asi que no afecta.

en estos dias subo ejecutables, ya que considero este un bug importante.

disculpen las molestias.

[SplinterGU]

finalmente corregido el tema de los 32bits...

( sera cierto? :D )

bueno, svn actualizado, debo binarios.

[Windgate]

Nosotros con el Paper podemos hacer buena prueba, es todo 32 bits, incluso efectos bastante raros que mezclan una especie de foco de linterna en 32 bits con un fade_off. En cuanto estén los binarios avisa, sobre probar los write_in_map, map_block_copy, etc. Todavía no te puedo prometer nada pero lo intentaré :P

[SplinterGU]

lo del paper eso que cuando pones un grafico con alpha sobre un blanco total, no va, y esta bien que asi sea, porque ya el fondo esta al maximo del alpha, y ponerle otro del mismo color con mas alpha, no va a hacer que el alpha baje, tenes que cambiar de color o poner en el original un alpha mas bajo.

[DCelso]

SplinterGU, mira, he estado hechándole un ojo al asunto del png de 24 bits de profundidad de color por pixel y con un color de pixel RGB a tratar como transparente y he visto que los visores como acdsee o eye of GNOME trabajan bien con el transparente y bennu no los cargaba bien. Así que explorando el código fuente de mod_map y el formato PNG he descubierto que metiendo este código podemos dar soporte a imágenes RGB de 24 bits con un pixel a tratar como transparente (es decir sin usar canales alfa)

Code Select Expand


  else
   {
       Rshift = 8;
       Gshift = 5;
       Bshift = 3;

       Rmask = 0xF80000 ; // 3
       Gmask = 0x00FC00 ; // 2
       Bmask = 0x0000F8 ; // 3
       for ( n = 0 ; n < height ; n++ )
       {
           rowpointers[0] = ( void * )row ;
           png_read_rows( png_ptr, rowpointers, 0, 1 ) ;

           ptr = ( uint16_t* )((( uint8_t * )bitmap->data ) + n * bitmap->pitch );
           orig = row ;
           for ( x = 0 ; x < width ; x++ )
           {
               ARRANGE_DWORD( orig );

               if (( *orig ) & 0x80000000 )
               {
                   *ptr = (( *orig & Rmask ) >> Rshift ) | (( *orig & Gmask ) >> Gshift ) | (( *orig & Bmask ) >> Bshift )  ;
                   if ( !*ptr )( *ptr )++ ;
               }
               else
                   *ptr = 0 ;
             
     <b> if ((color==PNG_COLOR_TYPE_RGB)&& (info_ptr->pixel_depth=24)&& (info_ptr->valid & PNG_INFO_tRNS)){
                uint8_t * ptr8 = (uint8_t *)orig;
        if(
        (ptr8[0]==info_ptr->trans_values.red) &&
        (ptr8[1]==info_ptr->trans_values.green) &&
        (ptr8[2]==info_ptr->trans_values.blue)
        )
        *ptr = 0;
               }
   </b>
               ptr++, orig++ ;
           }
       }

   }

como ejemplo pongo la imagen que nos pasó el muchacho este deetee,
La imagen adjunta si la abres con un visor cualquiera de imágenes verás que tiene fondo transparente, pero
Si la intentas cargar con el mod_map original no carga la información de transparente y es debido a que no es un formato png  que estemos acostumbrados a usar no es un png de 32 bits sino un png de 24 bits con tratamiento de un color como transparente.
Con esta modificación a mod_map ya sí trata bien este tipo de pngs.
Si quieres ver las diferencias puedes verlas con el siguiente ejemplo:

Code Select Expand


import "mod_key";
import "mod_map";
import "mod_screen";

process main()
private
int escape=0;
int square, pic6;
begin
 square=new_map(300,220,16);
 map_clear(0,square,rgb(0,255,0));
 pic6=png_load("A24b.png");
repeat
 put(0,square,100,100);
 put(0,pic6,100,100);
 if(key(_ESC)) escape=1; end
 frame;
until(escape);
unload_map(0,pic6);

end


[SplinterGU]

muchas gracias DCelso, karma!

[SplinterGU]

pregunta, aca creo que cometiste un error, cierto?

     if ((color==PNG_COLOR_TYPE_RGB)&& (info_ptr->pixel_depth =  24)&& (info_ptr->valid & PNG_INFO_tRNS)){

es ==, si?

[DCelso]

:D, sips, que bueno que no probé con otras imágenes, sino me petaría :D.
Menos mal que estás al loro y fijo que tienes ya ideas de como optimizarlo :D.

[SplinterGU]

por ahora queda como lo pusiste.

gracias.

[DCelso]

splinter ese arreglo solo funciona para cuando el modo de pantalla es 16 bits, para poder cargar también la información de transparencia de esos PNGS en modo 32 bits hay que poner en la parte de arriba de ese condicional algo parecido.

Code Select Expand


   else if ( depth == 8 && sys_pixel_format->depth != 16 )
   {
       for ( n = 0 ; n < height ; n++ )
       {
           rowpointers[0] = ( void * )row ;
           png_read_rows( png_ptr, rowpointers, 0, 1 ) ;

           ptr32 = ( uint32_t* )((( uint8_t * )bitmap->data ) + n * bitmap->pitch );
           orig = row ;
           for ( x = 0 ; x < width ; x++ )
           {
               ARRANGE_DWORD( orig );
               *ptr32 = *orig ;
              <b> if ((color==PNG_COLOR_TYPE_RGB)&& (info_ptr->pixel_depth==24)&& (info_ptr->valid & PNG_INFO_tRNS)){
                  uint8_t * ptr8 = (uint8_t *)orig;
if(
(ptr8[0]==info_ptr->trans_values.red) &&
(ptr8[1]==info_ptr->trans_values.green) &&
(ptr8[2]==info_ptr->trans_values.blue)
)
*ptr32 = 0;

              }</b>
               ptr32++, orig++ ;
           }
       }
   }

Ahora he probado con otras imágenes pa no volverla a cagar :d.

[DCelso]

splinter, haciendo probatinas si uso pantalla de 32 bits y creo imágnes de 16 bits, luego al usarlas no van bien los colores, por ejemplo, este ejemplillo me da un cuadrado amarillo en vez de verde

Code Select Expand


import "mod_key";
import "mod_map";
import "mod_screen";
import "mod_video";

process main()
private
int escape=0;
int square, pic6;
begin
  set_mode(320,240,32);
  square=new_map(300,220,16);
  map_clear(0,square,rgb(0,255,0));
repeat
  put(0,square,140,140);
  if(key(_ESC)) escape=1; end
  frame;
until(escape);
unload_map(0,pic6);

end

No se si es por culpa de los últimos cambios de alphas para soporte 32 bits de las últimas versiones de bennu, ¿Puede ser?

[SplinterGU]

es probable, voy a volver atras tu cambio, ya que me decis no va bien, debo estar seguro que funciona en todos los casos, aunque me imagino porque no va bien, si lo corregis pasame el cambio, pero asegurate que funcione bien...

gracias...

ahora chequeo el otro tema, a mi tambien me da amarillo, voy a revisar por que.

EDIT: Ahhh, claro, es obvio, el RGB esta trabajando sobre 32bits no sobre 16bits.

proba cambiando el set_mode a 16 y luego poner un set_mode a 32, luego del map_clear, no lo probe aun, pero seguro es eso.

EDIT2: es eso.