mini juego Deadly Eye port in progress desde DIV1

[SplinterGU]

mientras uses scroll sobre toda la pantalla, te suguiero que pongas dump_type a 1 y restore_type a -1.

[Drumpi]

Y para WIZ/CAANOO, usar collision lo menos posible, se nota bastante si se comprueba la distancia (por coordenadas, no con get_dist) antes de usar collision.

[SplinterGU]

se puede probar con las nuevas colisiones, las circulares creo que son las mas rapidas...

probar con las box y circle no esta mal.

[Noivern]

:o veamos veamos...
Voy a revisar lo del dump_type y restore_type, que no lo he tocado y no he leído la documentación sobre estas globales.
Segundo, no se me habia ocurrido medir distancia antes de hacer los collision, lo voy a probar. ¿Dices que no utilice el get_dist? ¿sirve con el fget_dist? ¿O debo calcular yo la distancia?
Las collision box y circle, ¿me puedes explicar o dar un link para leer como funcionan?
Me imagino que la box utiliza el area del grafico completo del sprite, pero la circular, ¿hay que dar el radio? o ¿lo calcula solo según el ancho y alto de la imagen?
A todo esto, Free la lanzó asi nomás, quería que fuera una sorpresa xD bueno en fin go nomás!

AAAh! una última cosa: probar por favor la version linux. Yo actualicé la carpeta de librerías a la última version, pero me olvide de actualizar el binario bgdi. Sin embargo, lo probé en el pc viejo que no tiene bennu instalado y funcionaba sin problemas, por eso lo subí. Recién ahora me acorde del bgdi ^^U

[SplinterGU]

box y circle no controlan por pixel, sino por areas.

la box es el area que forma el rectangulo dado por las esquinas del grafico teniendo en cuenta size y angle.
la circle es mas rapida, es el circulo determinado por el radio del grafico, teniendo en cuenta size, pero no angle.

en ninguna hay que poner ni radio ni tamaño, los calcula solas, lo unico es cambiar collision por collision_box o collision_circle.

no recuerdo, pero creo que tambien puse las sobrecargadas que permite especificar radio, pero no es necesario.

obviamente no son tan precisas como la collision a secas, pero son bastante mas rapidas.

[Noivern]

mmm ¿y el radio del gráfico para el circle es en base al lado menor?
¿El proceso con el que quiero verificar la colisión, también lo calcula en base a un radio?
Creo que no me sirven, ya que tengo algunos gráficos no centrados para cuadrar un par de animaciones, justamente la de los disparos de la nave y el fuego que dejan al chocar.
Ahora mismo estoy intentando la técnica del restore_type, dump_type y verificar distancias antes del collision, veremos que sale...
Gracias por la ayuda =)
Da gusto!!

--Edit--

Me olvidé preguntar : ¿el rectangle toma en cuenta el size_x y el size_y? o ¿solo el size?
Si toma en cuenta los size_x e size_y sirve para el láser, que no va rotado, solo reescalado (me salió verso :D)

Lo otro, si tengo:
[code language="bennu"]
while ((disparoRecibido = get_id(type disparo)))
    if (fget_dist(disparoRecibido.x, disparoRecibido.y, x, y) <= 35 && collision(disparoRecibido))
       //lógica
    end
end
[/code]

Ese if, supongo que al ser un Y lógico si el fget_dist() < 35 me da falso, no comprueba el collision() siguiente ¿verdad?
Que tengo bastante código de este tipo para ahorrarme ifs dentro de otros

[SplinterGU]

las colisiones circulars se centran respecto al medio del grafico, esto es (alto,ancho)/2, la menor de las 2 dimensiones es el radio de accion para ese proceso.

las circle son por distancia, el radio es ambos procesos que intervienen en la colision, se considera por radio.

toda colision colisiona por mismo metodo en ambos procesos, no tiene sentido que sea de otra forma.

para algo con muchos enemigos y disparos, la precision no importa mucho.

para maquinas con poca velocidad vale la pena y juegos de disparo, colisiones de este tipo justifican la perdida de precision.

no digo que lo dejes asi, solamente pruebalo.

[SplinterGU]

mmm ¿y el radio del gráfico para el circle es en base al lado menor?
¿El proceso con el que quiero verificar la colisión, también lo calcula en base a un radio?
Creo que no me sirven, ya que tengo algunos gráficos no centrados para cuadrar un par de animaciones, justamente la de los disparos de la nave y el fuego que dejan al chocar.
Ahora mismo estoy intentando la técnica del restore_type, dump_type y verificar distancias antes del collision, veremos que sale...
Gracias por la ayuda =)
Da gusto!!

--Edit--

Olvidé preguntar: ¿el rectangle toma en cuenta el size_x y el size_y? o ¿solo el size?
Si toma en cuenta los size_x e size_y sirve para el láser, que no va rotado, solo reescalado (me salió verso :D)

tiene en cuenta cualquier size.

pero en el caso del laser te conviene usar collision_box, collision_circle es para graficos que sean casi del mismo ancho y alto.

edit: todas las collison toman en cuenta la rotacion, salvo la circle.

[Noivern]

Ok, estoy probando, revisa por favor mi post anterior, añadí otra pregunta con un pequeño fragmento de código, soy muy voladó y se me olvido antes xD.
Voy a probar el collision_box con el laser, ese me tinca :D

--EDIT--

Utilicé todo: restore_type, dump_type, verificar primero distancia con fget_dist() y luego collision_box (ni se nota la diferencia visual).
Veamos que me dice Free del rendimiento en las portátiles con este experimento.  ::)

Añadido "last_changes" con el nuevo dcb en el primer post.
El mapa de tierra tiene en ciertas zonas el color rgb(0,0,0) asi que a veces quedan rastros de lo que pase encima, pero es un detalle, ahora hay que probar si mejora el rendimiento o no :P

[SplinterGU]

mmm ¿y el radio del gráfico para el circle es en base al lado menor?
¿El proceso con el que quiero verificar la colisión, también lo calcula en base a un radio?
Creo que no me sirven, ya que tengo algunos gráficos no centrados para cuadrar un par de animaciones, justamente la de los disparos de la nave y el fuego que dejan al chocar.
Ahora mismo estoy intentando la técnica del restore_type, dump_type y verificar distancias antes del collision, veremos que sale...
Gracias por la ayuda =)
Da gusto!!

--Edit--

Me olvidé preguntar : ¿el rectangle toma en cuenta el size_x y el size_y? o ¿solo el size?
Si toma en cuenta los size_x e size_y sirve para el láser, que no va rotado, solo reescalado (me salió verso :D)

Lo otro, si tengo:
[code language="bennu"]
while ((disparoRecibido = get_id(type disparo)))
    if (fget_dist(disparoRecibido.x, disparoRecibido.y, x, y) <= 35 && collision(disparoRecibido))
       //lógica
    end
end
[/code]

Ese if, supongo que al ser un Y lógico si el fget_dist() < 35 me da falso, no comprueba el collision() siguiente ¿verdad?
Que tengo bastante código de este tipo para ahorrarme ifs dentro de otros

exacto, es una de las mejoras que puse al lenguaje, antes se analizaban todas las condiciones sin importar el operador.

[blostec]

exacto, es una de las mejoras que puse al lenguaje, antes se analizaban todas las condiciones sin importar el operador.

Sin duda una gran mejora  :D

[SplinterGU]

exacto, es una de las mejoras que puse al lenguaje, antes se analizaban todas las condiciones sin importar el operador.

Sin duda una gran mejora  :D

creo que fue uno de los ultimos cambios que meti en fenix... gracias.

[Drumpi]

exacto, es una de las mejoras que puse al lenguaje, antes se analizaban todas las condiciones sin importar el operador.

Y también sin seguir el orden correcto. Me he dado cuenta cuando he trasteado con el código de FenixLand: había un par de líneas en cierto IF de la detección de durezas en las que no había paréntesis y por las cuales funcionaba distinto en Fenix y Bennu (hasta el punto de que cierta parte del nivel no podía pasarse en la versión Bennu por hacer bien la colisión con el techo).

Respecto a lo de la distancia, no digo que sustituyas GET_DIST por FGET_DIST, sino por:

IF ( (abs(x-otro_id.x) < distancia) && (abs(y-otro_id.y) < distancia) )

(Esto suponiendo gráficos centrados). No he hecho pruebas de rendimiento, pero según la documentación, GET_DIST y FGET_DIST hacen uso de la operación "raiz cuadrada" que es una operación lenta y supongo que es más rápido hacer dos restas y calcular su valor absoluto.

OFFTOPIC: hice pruebas de rendimiento con 1000 módulos (divisiones) por frame VS 1000 comprobaciones+resta. Las divisiones son un 10% más lentas que estas dos operaciones, por lo que si a/b da 1, el resto se calcula más rápidamente con el siguiente algoritmo:

IF (a > b) resto=a-b; end

Para a/b>1 es más rápido la operación módulo.

[SplinterGU]

exacto, es una de las mejoras que puse al lenguaje, antes se analizaban todas las condiciones sin importar el operador.

Y también sin seguir el orden correcto. Me he dado cuenta cuando he trasteado con el código de FenixLand: había un par de líneas en cierto IF de la detección de durezas en las que no había paréntesis y por las cuales funcionaba distinto en Fenix y Bennu (hasta el punto de que cierta parte del nivel no podía pasarse en la versión Bennu por hacer bien la colisión con el techo).

Respecto a lo de la distancia, no digo que sustituyas GET_DIST por FGET_DIST, sino por:

IF ( (abs(x-otro_id.x) < distancia) && (abs(y-otro_id.y) < distancia) )

(Esto suponiendo gráficos centrados). No he hecho pruebas de rendimiento, pero según la documentación, GET_DIST y FGET_DIST hacen uso de la operación "raiz cuadrada" que es una operación lenta y supongo que es más rápido hacer dos restas y calcular su valor absoluto.

OFFTOPIC: hice pruebas de rendimiento con 1000 módulos (divisiones) por frame VS 1000 comprobaciones+resta. Las divisiones son un 10% más lentas que estas dos operaciones, por lo que si a/b da 1, el resto se calcula más rápidamente con el siguiente algoritmo:

IF (a > b) resto=a-b; end

Para a/b>1 es más rápido la operación módulo.

si, la prioridad de los operadores en bennugd es correcta y de concuerda con cualquier lenguaje estandard.
Era un grave error que en fenix no sea asi, porque la logica de programacion deberia ser la misma en todos los lenguajes para evitar errores de programacion.

no compares lo que se hace desde C con lo que se hace desde codigo bennugd, quizas una resta desde bennugd puede ser mas lenta que una raiz cuadrada en C.
no digo que lo sea, pero puede ser, porque en bennugd para hacer una resta (o cualquier operacion) se ejecutan muchas cosas.

[Drumpi]

No comparo, he dicho que no he hecho pruebas, pero que parece lo más lógico, sobre todo teniendo en cuenta lo que cito sobre restas VS divisiones, que pese a la carga extra de la pseudointerpretación, un if+resta sigue siendo más rápido que un módulo.

Supuestamente hay circuitos integrados diseñados para realizar las divisiones en un ciclo, pero está visto que no se usan en las ALUs de las CPU. Tendría que analizar cuantos ciclos lleva realizar una raiz cuadrada, aunque sea por aproximación mediante series de fourier, y comparar:
-con una (resta+abs+comparación)*2+comparación en el peor de los casos.
-con una resta+abs+comparación en el mejor de los casos.

PD: esta forma de pensar ¿me convierte en analista programador junior? ;D