Cambiar el Z de PUT_PIXEL

Started by proteo, March 17, 2014, 12:03:46 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

proteo

Buenas, como va? estoy teniendo un problema, en definitiva lo que necesito es dibujar en pantalla solo una porción de una imagen almacenada en un .fpg, lo que hice para realizarlo fue



ancho = map_info(graficos, graphIni, G_WIDTH);
rx = ancho / 2;
ry = largo / 2;

loop

from grafico = graphIni to graphIni + cantFrames - 1;

from j = 0 to largo;

from i = 0 to ancho;

pixel = map_get_pixel(graficos, grafico, i, j);
put_pixel(x + i - rx, y + j - ry, pixel);

end

end
frame;

end


end



Y esto funciona, el problema es que, por lo que lei en el manual de Osk, la instruccion PUT_PIXEL dibuja sobre el fondo, entonces, en mi juego, en cada iteraccion se hace PUT_SCREEN con un fondo y un PUT de una imagen con transparencias y objetos pasando, así como nubes. A pesar que el proceso que dibuja esta porción de imagen es llamado a lo ultimo de todo, igualmente lo pinta en el fondo, por lo cual, el PUT_SCREEN lo pisa. Hay alguna forma de que lo que dibujo con PUT_PIXEL aparezca encima? O mejor aun, hay alguna forma de que un proceso solo dibuje una porcion de su GRAPH?

Muchas gracias.
Saludos.

master

#1
mmm, creo que la función que necesitas es map_put_pixel, solo le indicas el ID del fpg, el ID del map, la X y Y, y el color
en tu caso, en file iría 0, y en map pondrías graph

proteo

Quote from: master on March 17, 2014, 12:22:07 AM
mmm, creo que la función que necesitas es map_put_pixel, solo le indicas el ID del fpg, el ID del map, la X y Y, y el color
en tu caso, en file iría 0, y en map pondrías graph

Muchas gracias por tu respuesta, digamos que en parte funciona, el problema es que el proceso tiene x = 100 e y = 100 y yo hago MAP_PUT_PIXEL en la posicion 0,0, y en lugar de dibujar relativo a las posiciones x-y del proceso lo dibuja en la posicion real, esto tambien me hace pensar que no va a servir para utilizarlo en deteccion de colisiones.

Vamos al grano, lo que necesito hacer es el rayo que dispara esta nave

http://www.youtube.com/watch?v=cDU78nevsf4

tengo una imagen con el rayo entero, de 480 px de largo, entonces la dibujo entera a partir de las coordenadas x e y de la punta de la nave como si estuviera siendo emitido por la misma. En cuanto esta imagen entra en collision con un enemigo calculo la distancia que hay entre la punta de la nave y el enemigo, esta es una cantidad en pixeles, por ejemplo 300, entonces yo necesito dibujar la imagen del rayo hasta el pixel 300 y colocando una animacion de colision en el extremo del rayo que toca con el enmigo.

Espero haberme explicado bien. Estoy abierto a escuchar otras soluciones para realizar este efecto.

Muchas gracias.
Saludos.

proteo

Ya lo pude mas o menos solucionar. Creo un mapa con el tamaño deseado, le dibujo la imagne con map_xputnp, le asigno al GRAPH del proceso el mapa nuevo y listo, veo una porción de la imagen igual al tamaño del mapa nuevo. El problema ahora lo estoy teniendo con los colores en el mapa destino, pero eso lo abro en una tema nuevo porque ya se trata de otro problema.

Muchas gracias, tu pista del map_put_pixel me sirvio para encontrar el map_xputnp.

Saludos.

master

para cambiar el tamaño del rayo yo usaría regiones, no se si puedas sacarle partido a las regiones para el efecto, o en todo caso puedes usar map_info_set para cambiar el tamaño en x o y sin deformar el gráfico cargado, sino cortándolo, el inconveniente es la animación, que tal vez no se vea tan bien cuando se corte el grafico. Definitivamente creo que regiones es la mejor opción

proteo

Quote from: master on March 17, 2014, 05:27:02 PM
para cambiar el tamaño del rayo yo usaría regiones, no se si puedas sacarle partido a las regiones para el efecto, o en todo caso puedes usar map_info_set para cambiar el tamaño en x o y sin deformar el gráfico cargado, sino cortándolo, el inconveniente es la animación, que tal vez no se vea tan bien cuando se corte el grafico. Definitivamente creo que regiones es la mejor opción

Gracias nuevamente, Ya habia probado con lo de las regiones pero ya lo prove y no podia detectar colisiones. Y algun enemigo entra en colision con el rectangulo que es el rayo, el rayo debe ser tan largo como la distancia sobre el Eje Y que hay entre el enemigo y el jugador. Ya he logrado dicho efecto creando mapas temporales pero con un percance, el cual todavia no he podido solucionar. El mismo es que luego de crear el mapa temporal con NEW_MAP(), sino no hago un MAP_CLEAR(0,mapa,rgb(255,255,255)) antes de hacer el MAP_XPUTNP, no aparece la imagen. Haciendo el MAP_CLEAR si aparece que aparece toda la imagen blanquecina, incluso el fondo que deberia ser transparente. Ya he probado hacer MAP_CLEAR(0, mapa, 0) y solo aparece el rectangulo negro. No creo que sea problema de la imagen del cuerpo del rayo ya que si cargo la misma directamente a la variable GRAPH la muestra sin problemas. Alguna idea de porque se puede estar produciendo este efecto? El codigo seria


           mapa = new_map(50, 300, 32);
           map_xputnp(0, mapa, graficos, cuadro, 0, 0, 0, 100, 100, 100);


de esta forma no veo el grafico


           mapa = new_map(50, 300, 32);
           map_clear(0,mapa,rgb(255,255,255));
           map_xputnp(0, mapa, graficos, cuadro, 0, 0, 0, 100, 100, 100);


de esta forma si lo veo pero mal como te explique arriba. Si vario los distintos valores de RGB se ve todo en variaciones del color obtenido por dichas combinaciones.

Adjunto la imagen que contiene el cuerpo del rayo y una  en como se ve en la ejecución del programa.


Desde ya agradezco tu ayuda.

FreeYourMind

si estas empezando con bennu, dejaria de lado esas funciones, y usaria sóolo procesos para pintar graficos, ya con la z controlas la profundidad del grafico y al matar el proceso eliminas la imagen, es lo mas facil de usar y entender

proteo

#7
Quote from: FreeYourMind on March 17, 2014, 10:54:13 PM
si estas empezando con bennu, dejaria de lado esas funciones, y usaria sóolo procesos para pintar graficos, ya con la z controlas la profundidad del grafico y al matar el proceso eliminas la imagen, es lo mas facil de usar y entender

Muchas gracias por tu recomendación, la verdad que si rencien empiezo con Bennu pero ya habia programado bastante con DIV2 en su momento. Basicamente lo que necesito hacer es dibujar de un grafico solo una seccion. En otros entornos como Game Maker, Java con LibGdx o Java para android puro pude hacer esto sin problemas y de forma sencilla. Por eso busque como manejar mapas temporales y mas o menos tuve resultados, pero no se porque motivo, sencillamente luego de crear el mapa, no aparece la imagen que le estoy dibujando con el MAP_XPUTNP y si aparece si previamente le hago un MAP_CLEAR(), el problema que este ultimo hace desastres con los colores. En fin, seguire investigando.

Muchas gracias Denuevo.
Saludos.

Drumpi

Yo opino como Free: no te compliques y usa tres procesos diferentes, uno para la nave, otro para las llamaradas del final del cañón y por último el gráfico del rayo, que lo puedes animar creando varias imágenes en un FPG, con el tamaño de la pantalla; aunque se salga de la zona visible, no afectará al juego ¿o sí?
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

proteo

Quote from: Drumpi on March 27, 2014, 08:48:18 PM
Yo opino como Free: no te compliques y usa tres procesos diferentes, uno para la nave, otro para las llamaradas del final del cañón y por último el gráfico del rayo, que lo puedes animar creando varias imágenes en un FPG, con el tamaño de la pantalla; aunque se salga de la zona visible, no afectará al juego ¿o sí?

Muchas gracias, lo pude resolver con MAP_XPUTNP, estaba colocando mal el ultimo parametro (FLAGS). Luego me colgue con otras cosas y me olvide de avisar por aca que el problema estaba resuelto. Muchas gracias denuevo.

Drumpi

De todas formas, te digo lo mismo que me dijeron cuando empecé con Java: ahora no estás en C, saca provecho de las ventajas que tiene el nuevo lenguaje.
En java tenía la orientación a objetos, aquí tienes los procesos. Las funciones PUT son "lentas", cambiar de gráfico no.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

proteo

Quote from: Drumpi on March 28, 2014, 01:42:09 AM
De todas formas, te digo lo mismo que me dijeron cuando empecé con Java: ahora no estás en C, saca provecho de las ventajas que tiene el nuevo lenguaje.
En java tenía la orientación a objetos, aquí tienes los procesos. Las funciones PUT son "lentas", cambiar de gráfico no.

Tenes razon, en un momento intente hacer el rayo por un lado y el estallido del choque por el otro, pero ambos deberían estar siempre alineados (mantener el mismo X), esto lo hice haciendo x = father.x; en el proceso del estallido, pero asi y todo, cuando había movimiento, osea, movía la nave sobre el Eje X, es como que el proceso de estallido iba siempre un paso atrás y quedaba desfasado. Por otro lado, no llegue a probar bien, pero intente utilizar regiones para regular el largo del rayo pero o no servia para colisiones o hice algo mal. Puede ser que los gráficos de dos regiones distintas no entren en colision?

Denuevo muchas gracias, por tu respuesta.

Saludos.

gecko

Sobre el grafico un frame atrasado eso se debe a que uno se ejecuta primero que el otro, podes corregirlo asignandole mayor prioridad (variable local PRIORITY) a uno sobre el otro, o cambiando el orden en que se llaman los procesos (llamar a uno antes que el otro).

Aunque este tipo de soluciones cuando hay mucha cantidad de procesos que dependen de un orden en especial, puede ser algo complicado de mantener.
Torres Baldi Studio
http://torresbaldi.com

Drumpi

Para lo del desfase, aparte de la prioridad, también viene bien analizar cuándo un proceso sigue al otro o es al revés. No es lo mismo ponerse a la X del padre a que el padre te ponga a su X. Al final la mejor solución es que sea el padre el que establezca la posición, y por eso suelo tener procesos que sólo se autocongelan y no hacen nada más, dejando al padre que controle sus variables locales (X, Y, GRAPH...).
Aunque no hay que menospreciar la fuerza de PRIORITY = father.PRIORITY + 1

Dato curioso: PRIORITY fue en DIV y casi que en Fenix, una herramienta de uso avanzado.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)