Avances, Diario de...

[SplinterGU]

el parametro de ser agregado seria opcional... no es requerimiento, sino opcional... si no esta se comportaria como hasta ahora...

[SplinterGU]

La verdad es que  me parece que lo mas comodo seria que dependa del modo de video.. pero si no se puede me inclino mas por un parametro opcional. Me parece mas prolijo.

no es que no se pueda hacer, pero en esta version me preocupe porque los graficos no esten restringidos al modo de video actual, para de esta forma poder manipular mapas de cualquier resolucion sin preocuparse por conversiones automaticas y cosas raras segun el modo de video, por ejempo, para un conversor de png a fpg... o cualquier manipulacion de imagenes...

[Packo_z007]

Bueno.. podrias hacer que los graficos se carguen en el modo de video actual con el load_png comun y corriente.. y poner un parametro opcional para cargarlos con una profundidad diferente.

[TYCO]

Code Select Expand

Program Pruebas;

Global

int fpg1;
int fpg2;

Begin
    set_mode(320,200,8);

// CARGAMOS VARIOS FPG EN EL JUEGO
    fpg1=load_fpg("test.fpg");
    fpg2=load_fpg("test.fpg");

// INICIAMOS UN SCROLL CON UN FPG QUE NO SEA EL "PRIMERO" CARGADO
    start_scroll(0,fpg2,1,0,0,0);

    graph=new_map(10,10,8);
// SEGUN LA FENIXWIKI MAP_XPUT SOLO SE PUEDE UTILIZAR EN UN MISMO FPG Y DICE USAR "MAP_CLONE"
// PARA ESTOS CASOS, AUN ASI PARECE NO FUNCIONAR EL MAP_XPUT
    graph=map_clone(0,graph);
    map_clear(0,graph,rgb(255,255,255));

say(fpg1);
say(fpg2);

    x=160;
    y=100;

    While (NOT key(_esc))
        IF (key(_right))
            x+=5;
            map_xput(fpg2,1,graph,x,y,angle,60,0);
        END
        IF (key(_left))
            x-=5;
            map_xput(fpg2,1,graph,x,y,angle,60,0);
        END
        IF (key(_down))
            y+=5;
            map_xput(fpg2,1,graph,x,y,angle,60,0);
        END
        IF (key(_up))
            y-=5;
            map_xput(fpg2,1,graph,x,y,angle,60,0);
        END
        Frame;
    End
End

Este codigo si no me equivoco deberia dejar un rastro.
Solo funciona bien (el cuadradito blanco deja un rastro tras de si) si eliminamos la linea: "fpg1=load_fpg("test.fpg");"
Habia otro tema de problemas con los fpg, el numero de graficos y tal, no tendra nada que ver???

PD: El "test.fpg" sigue siendo el del ejemplo "scroll.prg", que es un fpg de 8bits.

---------------------------------

Con respecto a lo que hablais de la profundidad de color....

Seria logico que si tienes seteado a "set_mode(640,480,16)" no te dejara cargar FPG/MAP/PNG de 32Bits, asi bennu no tendria que cargar por ejemplo uno de 24Bits como si fuera uno de 16Bits no???

[SplinterGU]

no, no deberia dejar nada... el funcionamiento es correcto... ya que estas haciendo un map_xput sobre fpg2 con un grafico que no existe en fpg2... tenes 2 formas de que esto te de el resultado que vos esperas...

forma 1 (usando fpg_add)

Code Select Expand


Program Pruebas;

#ifdef COMPILER_VERSION
import "mod_key";
#endif

#ifdef __VERSION__
import "mod_say";
import "mod_wm";
import "mod_video";
import "mod_screen";
import "mod_map";
import "mod_text";
import "mod_scroll";
#else
#ifdef COMPILER_VERSION
import "mod_sdlevthandler";
#endif
#endif


Global

int fpg1;
int fpg2;

Begin
    set_mode(320,200,8);

// CARGAMOS VARIOS FPG EN EL JUEGO
    fpg1=load_fpg("test.fpg");
    fpg2=load_fpg("test.fpg");

// INICIAMOS UN SCROLL CON UN FPG QUE NO SEA EL "PRIMERO" CARGADO
    start_scroll(0,fpg2,1,0,0,0);

    graph=new_map(10,10,8);
// SEGUN LA FENIXWIKI MAP_XPUT SOLO SE PUEDE UTILIZAR EN UN MISMO FPG Y DICE USAR "MAP_CLONE"
// PARA ESTOS CASOS, AUN ASI PARECE NO FUNCIONAR EL MAP_XPUT
    graph=map_clone(0,graph);
    map_clear(0,graph,rgb(255,255,255));

    fpg_add(fpg2,10,0,graph);

say(fpg1);
say(fpg2);

    x=160;
    y=100;

    While (NOT key(_esc))
        IF (key(_right))
            x+=5;
            map_xput(fpg2,1,10,x,y,angle,60,0);
        END
        IF (key(_left))
            x-=5;
            map_xput(fpg2,1,10,x,y,angle,60,0);
        END
        IF (key(_down))
            y+=5;
            map_xput(fpg2,1,10,x,y,angle,60,0);
        END
        IF (key(_up))
            y-=5;
            map_xput(fpg2,1,10,x,y,angle,60,0);
        END
        Frame;
    End
End



forma 2 (usando map_xputnp)

Code Select Expand


Program Pruebas;

#ifdef COMPILER_VERSION
import "mod_key";
#endif

#ifdef __VERSION__
import "mod_say";
import "mod_wm";
import "mod_video";
import "mod_screen";
import "mod_map";
import "mod_text";
import "mod_scroll";
#else
#ifdef COMPILER_VERSION
import "mod_sdlevthandler";
#endif
#endif


Global

int fpg1;
int fpg2;

Begin
    set_mode(320,200,8);

// CARGAMOS VARIOS FPG EN EL JUEGO
    fpg1=load_fpg("test.fpg");
    fpg2=load_fpg("test.fpg");

// INICIAMOS UN SCROLL CON UN FPG QUE NO SEA EL "PRIMERO" CARGADO
    start_scroll(0,fpg2,1,0,0,0);

    graph=new_map(10,10,8);
// SEGUN LA FENIXWIKI MAP_XPUT SOLO SE PUEDE UTILIZAR EN UN MISMO FPG Y DICE USAR "MAP_CLONE"
// PARA ESTOS CASOS, AUN ASI PARECE NO FUNCIONAR EL MAP_XPUT
    graph=map_clone(0,graph);
    map_clear(0,graph,rgb(255,255,255));

say(fpg1);
say(fpg2);

    x=160;
    y=100;

    While (NOT key(_esc))
        IF (key(_right))
            x+=5;
            map_xputnp(fpg2,1,0,graph,x,y,angle,60,60,0);
        END
        IF (key(_left))
            x-=5;
            map_xputnp(fpg2,1,0,graph,x,y,angle,60,60,0);
        END
        IF (key(_down))
            y+=5;
            map_xputnp(fpg2,1,0,graph,x,y,angle,60,60,0);
        END
        IF (key(_up))
            y-=5;
            map_xputnp(fpg2,1,0,graph,x,y,angle,60,60,0);
        END
        Frame;
    End
End


con respecto a los mapas 32, la idea como ya dije es que siempre se pueda cargar cualquier grafico independiente del modo de video, y uno tenga libertad luego para usarlo a su antojo...

[TYCO]

Luego miro las propuestas que me comentas a ver si me sirven, pero entonces... porque ese codigo si deja un "rastro" en Bennu WIP2??? era un bug???

[SplinterGU]

ummm... ahora que lo pienso, si el codigo del grafico es mayor a 999 deberia tomarlo del fpg 0... aunque quizas no es tan correcto... bien...

ahora lo cambio, gracias...

[SplinterGU]

ya esta corregido, gracias...
ahora lo que veo es que el rgb(255,255,255) en wip2 da un color marron, y en la ultima bennu da blanco (correcto)

[TYCO]

Se supone que un FPG cargado contiene hasta un maximo de 999 graficos no???, entonces los new_map, map_clone, etc deberan tener un numero de 1000 en adelante que se almacenaran en el FPG "0", es decir... el fpg del sistema... o del primer fpg que has cargado.

PD: En mi caso solo serviria "map_xputnp" ya que el ancho de "graph" varia dependiendo de la velocidad de los coches.

[SplinterGU]

si, claro, hasta 999, los de arriba de 999 en el fpg 0 (no fichero sino libreria en memoria) son los mapas del sistema... busca unas paginas atras en este thread, se explica como se comporta...

gracias.

[Danielo515]

Splinter,no se si lo que digo es una varbaridad, pero ¿no se podría eliminar, tarde o temprano, la limitación de los map_put, y map_xput, y similares, de que ambos mapas estén en la misma librería? Es que es un poco coñazo andar con map_clone y unload map todo el rato, al menos para mí.
Un saludo.

[SplinterGU]

Splinter,no se si lo que digo es una varbaridad, pero ¿no se podría eliminar, tarde o temprano, la limitación de los map_put, y map_xput, y similares, de que ambos mapas estén en la misma librería? Es que es un poco coñazo andar con map_clone y unload map todo el rato, al menos para mí.
Un saludo.

map_xputnp

[SplinterGU]

Soporte de modos 32 bits...

- modos: 1 a 32, 8 a 32, 16 a 32, 32 a 32
- normal, translucent, ablend, sblend, nocolorkey, alphas sobre todos los modos anteriores (salvo nocolorkey, obviamente)
- alphas por pixel (solo 32 a 32 y modos diferentes a nocolorkey)

- Optimizados los algoritmos de ablend y sblend del blitter...

Limitaciones:

- blendop no soportado en 32 bits, usar el metodo de tablas requeriria 24mb de memoria por tabla, una locura... y demasiado procesamiento...

- Fade 32, no soportados aun...

Otros cambios

- mejoras en los translucent sobre cualquier otro efecto, ahora es 50% sobre lo que sea (antes no lo era en todos los casos, en algunos si y en otros no...)

Los resultados de performance con respecto a la primera version ya no son tan significativos, mejoro significativamente los xblend sobre 16, pero decayo en 32bits... la cosa es que en la primera version no tuve en cuenta los alphas...

Todavia queda intentar optimizar mucho mas los algoritmos... pero bueno, ya hay una version funcional en desarrollo.

[Rincewind]

Soporte de modos 32 bits...

Cool, thanks. :)

[SplinterGU]

Bien, al final hice algo que no queria pero bien, quizas no es la mas prolija o la mejor de las formas...

- load_png, pngs con alphas son cargados en mapas de 32 bits salvo si el modo de pantalla seteado es de 16 bits, caso en el que el png es creado como de 16 bits...

Voy a armar un ejemplo y voy a subir una version asi la testean y me comentan...