Avances, Diario de...

[SplinterGU]

he agregado nuevas funciones de collision y mejorado la que ya existia (ahora colisiona bien con mapas de 1x1).

Se agregan las siguiente funciones:

- Collision_Box(p)
- Collision_Circle(p)

funcionan con type y con procesos, como la collision, comparten tambien el contexto en el caso de usar type, por eso tener cuidado con esto y recordarlo, no digan despues que no avise.
estas funciones son mas rapidas que la collision actual, pero no son tan rapidas como un calculo de distancias (quizas al ser en C lo sean), ya que se tiene en cuenta tamaño, angulo, espejado, etc.
para el caso del box, el box se calcula en base a los extremos, o sea, que si hay rotacion, el tamaño del area de colision varia.
para el caso del circle, se promedia el alto y el ancho (tambien del box del grafico rotado o escalado) y esa es el area circular de colision, que puede salir fuera del box del grafico o estar dentro de este, si el grafico no es igual el alto y el ancho.
puede tambien que el centro del grafico (punto de control) no se ajuste a todos los casos que necesitamos, aunque se necesitarian hacer mas pruebas.

[FreeYourMind]

Me huele a que esa colision en circulo me va venir de perlas para el pinball action 

[Drumpi]

Y las collision box para reducir el uso de recursos.
Lo que no acabo de entender ¿la caja está siempre con los lados paralelos a los bordes de la pantalla? ¿aunque se rote el gráfico?

[SplinterGU]

no, ya lo dije, esta en los bordes, a 90 grados y 180 con respecto a la pantalla, por eso dije que el area de colision varia.

con respecto a los pixelperfect de 1x1, si esta rotado o hay un size, no lo detecta, puedo hacerlo como estaba antes, pero no quiero, quiero resolverlo adecuadamente, vamos a ver si se puede.

[SplinterGU]

por fin, solucionado el tema de los graficos de pixel 1x1, o mejor dicho de ancho 1, el problema era el blitter, espero que esto no traiga nuevamente los problemas de dibujado de lineass raras en las rotaciones.

[SplinterGU]

bien, corregido un tema con el resolution y el collision_circle, tambien ahora solo colisionan procesos del mismo ctype (cosa que debio ser siempre), y tambien colisionan con el mouse, claro.

he hecho pruebas de performance, y la verdad que no hay muchas mejoras, debido a todo el tema que tenemos de rotaciones, sizes, etc.

se ganan unos 20fps en numeros de 230 fps mas o menos, no es algo grandioso.

[Drumpi]

Preguntaba porque creía que las collision box detectaban la colisión con el cuadrado del gráfico, es decir, también le afectaría la rotación y el escalado, porque de la otra forma se podía hacer por código. Era sólo una duda que tenía.

Mmmm, si eso que dices del bliter es cierto, tendré que volver a probar las rotaciones con gráficos de 1 pixel de ancho, que a un ángulo desaparecían y a otro eran el doble de anchos.

Y oye, 20 de 230 es casi un 10%, yo creo que es un gran avance, eso se va a notar, sobre todo en la negrita.

[SplinterGU]

si, las rotaciones y el size afectan el tamaño del area de colision, la cosa es simple, rotas un grafico y los extremos del grafico (no solo el era pintada, sino que se incluye el area transparente), y por cada extremo trazas rectas y paraleleas de 90° y 180°, con respecto a los ejes x e y de la PANTALLA.

el tema de que no se veia el grafico de 1px de ancho, ya se soluciono, ahora que sea vea segun la rotacion de 1px mas, a simple vista me parece que sigue, pero eso es por los calculos,

yo sigo pensando que no es importante la mejora, si se pudiese evitar todo el tema de las rotaciones, escalado y resolution, este tipo de colisiones seria muy rapido.

quizas se podria implementar un par de funciones que no consideren estos valores, algo asi como un collision_circle_fast y collision_box_fast, que se basen solamente en el alto y ancho del grafico con respecto a su centro, sin chequear rotaciones, escalado ni demas cosas, quizas el resolution no afecta mucho.

tambien quiza estas funciones puedan tener un parametro extra que indique radio de accion de la colision o quizas agregar una variable local que indique radio de accion para casos de colision circular y podria ser alto y ancho para casos box.

no esta mal, y creo que esto ameritaria un modulo de colisiones exclusivos, y para evitar el problema de lo que ya esta hecho (que usa mod_grproc), puedo hacer que mod_grproc cargue automaticamente este nuevo modulo (dependencia), y asi seria transparente para lo que ya actualmente lo use.

lo que tambien afecta mucho es el comparar en cada collision toda la lista de procesos (en el caso del type, si hay muchos de este tipo, o de collision ALL_PROCESS), collision directo a un proceso, supongo que va muy rapido, pero tambien lo ira en el collision normal.

la cosa es que estuve pensando, y no se puede hacer un cache de las colisiones, ya que uno de los procesos que previamente fue chequeado por colision en otro proceso, en el actual proceso pudo haber cambiado sus datos, por ende, no se puede asumir que la info anterior es valida.

[Drumpi]

No, si yo la collision box me refería a que al rotar el gráfico, los lados también rotaban, vamos, que no siempre son paralelos a los bordes de la pantalla, sino que delimitan los bordes del gráfico (ignorando las transparencias).

La idea de un módulo con diversas colisiones estaría muy bien,y para no romper la compatibilidad podrías dejar las colisiones "básicas" donde están, y crear las nuevas en el módulo aparte, o meter también las antiguas de manera que "tapen" las del mod_grproc.
Hombre, un cache de procesos sería útil con los procesos que permanezcan quietos, es cierto que suelen estar en movimiento pero ¿no hay una variable que los marque como "dirty" para actualizar sus valores o decir que hay que redibujarlo?
También es verdad que una cache come recursos, y si estamos usando colisiones simples por falta de los mismos, estaría interesante tener una variable para activarlas/desactivarlas, igual que hay para el volcado total/parcial de pantalla.

[SplinterGU]

hacer un box que tambien el box rote es ridiculo, seria tan complejo como hacer el pixelperfect o quizas mas.

no, el dirty se chequea en el frame final o cuando un grafico se modifica su contenido, pero eso solo se le setea un flag que indica que debe ser analizado. ademas cambiar el grafico es lo de menos, hay muchas cosas mas que hacen cambiar a lo que se dibuja, coordenadas, angulos, tamaño, etc, y hacer chequeos por todas esas cosas, haria al asunto mas lento, y muchas cosas internas que no tienen sentido discutir.

olvidate drumpi, es mucho mas complicado o elaborado que lo que decis.

[blostec]

Después de un tiempo desconectado, veo que el desarrollo de Bennu sigue imparable, gran trabajo Juan. Ahora mismo actualizo a la ultima versión. Sobra decir que te añado otro karma (no se que haras con tantos!). Saludos!

[SplinterGU]

ja, gracias blostec, estos ultimos cambios que voy mencionando (collision y funcion de la mixer) estan solo en el svn, aun no genere version binaria.

los karmas? disfrutarlos.

[l1nk3rn3l]

excelente




karma up..

[Drumpi]

Oye, L1nk, ya que estás aquí, ¿Estás ayudando a Splinter con el problema que tiene con la vibración en los mandos para plataformas no-WIZ? si no, échale una mano, por favor

[l1nk3rn3l]

BUENO comentame, y publica los binarios de la ultima bennu xfavor que estoy por sacar
el proximo bennupack..

exactamente cual es el problema con los mandos? haber si soy util en algo