erkosone wrote:es solo a base de colisiones y recogiendo el angulo de cada proceso que ha colisionado con la bola, solo tienes que implementar con física real el rebote, esto sería factible siempre y cuando solo haya una pelota, así te ahorras la colisión entre bolas que es mas compleja de hacer, pero vaya, que solo sería calcular el nuevo angulo en función del triangulo que forma cada eje con la linea que se ha rebotado.
lo pense hacerlo a
collision/overlap ... pero me sale mas rapido usar
map_get_pixel en vez de usar colisiones entre processos.
ya sabes que es mas lento usar colisiones que solo consultar un pixel en un mapa.
y si cada color me indica el Angulo de la pared.
ademas, los processos pintados en el tablero los pinto con map_xput al mapa de tablero unico... asi me libro(no estan en memoria) de todos los processos que son fijos, que son solo para pintar.
tambien busco maximo performance.
-1 proceso bola(tiene su codigo interno y es activo) Z=-50;
-mapa de durezas a colores(no es visible,solo esta en memoria)
-mapa de tablero visible inferior(es una capa pintada, lo que es el fondo de tablero:sombras,pegatinas,luces...) esta capa se imprime primero Z=0;
-mapa de tablero visible superior(es una capa pintada, lo que es superior/solido del tablero:paredes,tuneles...) esta capa se imprime el ultimo Z=-100;
Processos activos: 2 : BOLA + JEFE de partida.
Processos Congelados: 1 Sombra de la Bola. Z=-5;
= 3 Processos, solamente...
de momento se trata de un mapa de tamaño fijo, contra mas grande sea el tablero en dimensiones XY mas memoria ram consume.
El numero de piezas en el tablero de momento es ... lo que aguante xD
Colision entre Bolas.... aun no me puesto a pensar... y no lo veo facil.
de momento se atraviesan.... como el juego de Virtual Pinball de Megadrive. u_u
Esta tarde colgare el test, es bastante importante.
y tambien viene junto el PRG, si alguien me puede echarme una mano con los calculos de rebote, o de colision se lo agradeceria mucho, yo llego hasta tal punto que no se como mejorar el codigo.