1 proceso por cada "disparo" ?? baja performance....

[Gabysantof]

Hola chicos.
Les dejo esta inquietud.
Hace tiempo hice un juego en bennu del estilo shoot em up y mi objetivo final era tenerlo disponible para Dreamcast.
Para PC funcionaba muy bien, sin embargo al intentar portear a dreamcast tuve muchos problemas con la resolución de los sprites, los scrolls, la música, los FPS, etc... varios temas de novato que fueron apareciendo y pude ir solucionando.
Sin embargo tuve un problema que nunca pude solucionar y me dejó el proyecto truncado... y es la performance del juego.

Aqui viene mi pregunta... en mi juego, un shoot em up clásico sabrán que siempre hay muchas "balas" tanto de tus propios disparos como de los enemigos... y tuve que hacer un proceso por cada "bala", controlando en cada frame la trayectoria de cada disparo en un proceso separado por cada uno....
Es decir... cada disparo enemigo y cada disparo de mi nave era un proceso que nacía y moría al colisionar contra algo o bien al irse de los limites de la pantalla.

En estos días intenté retomar el proyecto y se me ocurrió una idea que quizás no sea posible y por eso pregunto...
Es posible que 1 proceso controle a mas de 1 sprite?? es decir... una bala enemiga es una bala enemiga, todas las balas cumplen la misma función... si te toca te mueres... entonces pensé si de alguna manera podría existir la posibilidad de controlar varias balas de un enemigo en un mismo proceso en lugar de tenerlas todas por separado (y arruinar la performance).
Quizás estoy diciendo pavadas o quizás hay otra solución a mi problema.... veo de repente juegos como "dodopachi" y me pregunto...
Como pueden haber tantas "balas"... no puede ser posible que sea 1 proceso por cada una... tiene que haber otra solución que se me escapa de mis habilitades jajja.

Abrazo! Aguardo comentarios!! todo es bienvenido!
Gabriel

[panreyes]

La forma en la que funciona BennuGD es 1 proceso, 1 sprite. El objetivo no es optimizar, sino simplificar la programación.
Cada proceso es como un actor, y su código es su parte del guión.

No hay mucha solución: En Dreamcast la potencia es muy baja para aguantar un juego con muchos procesos de BennuGD. No sé cuál es el límite, pero recuerdo que en la consola GP32, que usaba un procesador similar, teníamos que optimizar bastante para que funcionase correctamente.

[FreeYourMind]

Que resolución tienes ? Si bajas la resolución de todo a la mitad, o sea resolucion y tamaño de los sprites a la mitad y coordenadas adaptadas a la nueva posicion pues tendrás el dobre de rendimiento, ya depende si la nueva resolucion es aceptable o se queda ya todo muy pixelado.
No se si controlas tambien si los disparos/procesos estan visibles en pantalla, si salen de la pantalla los matarias automaticamente, o controlar grupos de sprites que puedan estar en el mismo proceso sin que se note, etc.

[Gabysantof]

La resolución que usaba al principio era de 640x480 que era la máxima de dreamcast y era imposible. Después baje a 320x240 y mejoró mucho pero aparte de verse "feo" ahí empecé a tener este problema de muchos "disparos" muchos "procesos" y empeorar la performance. No entendí eso de "grupos de sprites en un mismo proceso". Cómo sería eso?
Algo que se me ocurrió es hacer que en cada Frame una bala vaya cambiando la posición x,y en la pantalla y quizás así simular que haya muchas balas y en realidad es una sola.. pero no sé si se notaría mucho... lo que sería genial es poder dibujar con un proceso una bala en varias posiciones de la pantalla. Con respecto a si la bala se va de la pantalla el proceso se termina automáticamente por lo que no sabría cómo optimizarlo más.

[FreeYourMind]

por ejemplo imagina varios niveles de power en el disparo, imagina que tiras 1 bala, despues dos balas juntas, despues 3 balas, el grupo de 2 balas y el de 3 podrian ser solo un sprite y no las 3, el unico incoveniente es en la colision de una de ellas matarias las 3 porque son el mismo sprite.Esta tecnica se puede usar dependiendo de la situacion, por ejemplo en animaciones de varias partes que sean parte de una nave, pueden ir todas las animaciones en un mismo sprite animado y colocado con partes transparentes sobre el grafico principal, por ejemplo, etc

[panreyes]

Sobre performance, es muy probable que tu problema no sea la cantidad de procesos, sino lo que hacen dichos procesos.
- Si se rotan, se cambia el tamaño o tienen algo de transparencia, producen un impacto de rendimiento.
- Si hacen comprobaciones de colisión con collision, también producen un impacto de rendimiento.

Prueba dichas balas sin usar angle, size, size_x, size_y y alpha, y usando colisiones tipo collision_circle o collision_box.

Ya nos cuentas el resultado :)

[SplinterGU]

hola, las balas si son muchas (mas balas que enemigos) no deben hacer collision, sino que son los enemigos quienes deben hacer el collision...
por otro lado, si, es posible con bennugd2 controlar los collision desde un proceso diferente... no puede poner mas de 1 sprite por proceso... a menos que hagas un map_put... y no sea el motor quien dibuje, sino tu...
pero reduciendo la cantidad de collision como te dije al inicio va a mejorar la performance... ademas, el collision no debe ser por 0, sino por un tipo determinado de proceso... collision( type disparo ) por ejemplo

[Gabysantof]

Muchas gracias chicos.
Con los consejos que me dieron pude mejorar bastante la performance.
Me quedan 2 temas para terminar de tener mejores expectativas.

1) Hasta ahora estaba tomando una imagen bastante "larga" y usándola como fondo para el scroll, vi que eso también afectaba mucho la performance por ser una imagen tan grande.
Lo que hice fue armar la imagen de fondo con pequeños fragmentos de "lo que sigue" y cargándolos a medida que avanza el scroll. Esto funcionó mucho mejor, pero ya no usé la función de scroll, sinó que hice un proceso "scrollManual". Parece poco ortodoxo, pero va bien! si hay otra forma los escucho!

2) Mejorar la performance me entusiasmó mucho y hacer estos "fragmentos" para el fondo me hicieron pensar que podría armar una imagen muchisimo mas grande en cada nivel y aumentar los niveles y la dificultad. Perooooo, teniamos una limitación en BennuGD y es que no podemos cargar mas de 16 megas (con suerte) en total porque no funciona bien la liberación de memoria... o al menos eso sucedía. Hay un hilo con este tema que dejo acá para no mezclar y estoy planteando mi problema... que al menos a mi.. no me libera....
Tomé el mismo código que se habla en el hilo para hacer una prueba y ahi dice que si funciona, pero lo estoy probando con mas imágenes y no me anda ..... algo debo hacer mal, me ayudannnnnnnnn
https://forum.bennugd.org/index.php/topic,4810.0.html

Abrazos a todos!