Funcionamiento de alpha_steps

[Drumpi]

Hola a todos:

Me ha surgido una nueva duda. Lo he buscado por la wiki, el foro, etc, pero no lo he encontrado.
Para que se active el cambio de alpha_steps ¿Qué hay que hacer? Cambiar la variable no me ha hecho nada, y no sé si hay que hacer un set_mode o qué para que se actualice el cambio.

Ya de paso, si Bomber se pasa por aquí, he leido en un post viejo que para aumentar el rendimiento de Bennu en Wiz usas dump_type a 1 y ¿restore_type a -1?
http://forum.bennugd.org/index.php?topic=893.msg13972#msg13972
Con ambos a 1 he obtenido peores resultados de rendimiento con mi motor de scroll tileado que poniendo ambos a cero. Me extraña que se pueda poner el restore a -1.

[BoMbErLiNk]

Alpha_steps se inicializa con el primer proceso que usa alpha, verás el incremento de ram, tienes que ponerlo al principio del programa sino usará el valor por defecto, si no usas transiciones de alpha puedes dejarlo a 4 o así, el ahorro es poco más de 1MB.


En cuanto dump y restore hay que entender para que sirven y como funcionan:


- dump_type=1; restore_type=1; pinta y restaura todo, sirve para forzar el limpiado de pantalla, a veces al usar fondo 0 con otras combinaciones pueden salir artefactos.


- dump_type=0; restore_type=0; es para cuando no hay movimiento de cámara, no se limpia toda la pantalla ni tampoco se vuelve a pintar en zonas si no es necesario, esto es ideal para escenas de cámara parada donde hay unos cuantos objetos por la pantalla, hay cálculo adicional pero se compensa no renderizando zonas.


- dump_type=1; restore_type=-1; es para que todos los gráficos se pinten pero no limpia el buffer de pantalla, esto es ideal para cuando hay movimiento de scroll, se evitan cálculos innecesarios.

[Drumpi]

¿Entonces no se puede modificar el alpha_steps en mitad del programa? Mi idea era que durante el juego y cuando hay acción, mantener los alpha_steps por defecto, para usar menos RAM y porque no se nota tanto la falta de pasos. Pero cuando estoy en los créditos, en un evento o un momento en el que no hay uso intensivo de CPU, pero hay un for(alpha=0;alpha<255;alpha++) usar el cuádruple de pasos para que no se noten tanto los saltos, y luego volver a tener los 16 pasos normales.

Lo del dump y restore, ya digo, probando en el scroll tileado ambos a 1 daban peor resultado que ambos a 0. No había gran diferencia, pero creo haber comentado un máximo de 10% en los picos. Sin embargo no me fío de poner el restore a -1, porque con el scroll de tiles hay muchísimos huecos que es necesario que se borren... aunque eso mismo pasa con el scroll normal ¿En esos casos el scroll va bien?

[BoMbErLiNk]

Si usas 1,-1 tiene que estar el 100% de la pantalla cubierta, si vas con trozos de fondo 0 se te va a ver el rastro del buffer.


Aquí no te va a funcionar bien, fondo 0 = rastro.



Aquí sí, 100% = ningún problema



Y claro que 1,1 da peor resultado que 0,0, ese modo no deberías usarlo.


No recuerdo si los cambios en alpha_steps surgen efecto una vez se ha inicializado, eso Splinter  :P


De todas formas por 1MB de ahorro igual no te merece ni la pena.

[Drumpi]

No, la segunda imágen tampoco, porque, aunque lo parezca, ese fondo azul es estático y está pintado con put_screen, así que tendríamos el mismo problema con los rastros (a menos que haya entendido algo mal).
Teóricamente, un barrido total es más efectivo que una actualización parcial a partir de un porcentaje de pantalla que cambie, lo que no sé es cuál es el porcentaje ni el tamaño de los dirty rects. Quería comprobarlo, ya que aunque mi scroll usa muchas partes vacías, hay zonas del mapa que cubren el 80% o más de la misma, pero aun así, la media seguía siendo favorable a la actualización parcial.

Y no estoy intentando ahorrar espacio, al revés, quiero usar más alpha_steps que los que vienen por defecto. La pega es que ya estoy con un redimiento por debajo de lo aceptable en temas de velocidad, aunque el consumo de RAM actualmente es muy bajo: calculo que con el fondo más gordo, bastantes enemigos cargados, y con una música en OGG totalmente en memoria (que no es así, creo, gracias a "play_song") no llego ni a los 16MB. En Wiz voy sobrado con sus menos de 64MB de RAM, pero si quiero que siga "funcionando" en GP2X, ya voy un poco justo (aunque no recuerdo si la consola tenía 16MB, 32MB, ni cuánto estaba disponible por el tema de que la memoria se dividía para cada procesador y de que había trucs para poder aprovecharla casi toda).

De momento sé que con frame no se recalculan las tablas de transparencias, porque ya lo intenté y sigo teniendo 16 "tonos".

[BoMbErLiNk]

Ah, con put_screen no va a funcionar, pensaba que usabas 2 capas de scroll.


De todas formas podrías usar una o varias capas con flags 128 en lugar del put_screen y entonces probar el 1,-1 para ver que combinación te vale más la pena, no digo que uses solo 1,-1, sino que vayan cambiando para obtener todo el rato el mejor resultado, en cámara estática funciona mejor 0,0 que 1,-1.


Puedes usar os_id para modificar solo el alpha_steps de Wiz si te preocupa la memoria de gp2x, pero supongo que ya lo sabrás  :D

[Drumpi]

Ahí en realidad uso TRES capas de scroll, una por cada color de nubes del fondo (naturalmente son dos scrolles de Bennu diferentes... aunque ahora que lo pienso, debería haber usado 3, porque por lo visto, dos scrolls diferentes de una capa son más rápidos que un scroll de dos capas, a ver si alguien lo corrobora o es que Drumpi la está liando en mi ordenador),
:D :D :D

Pero no, ya lo he comprobado, los scrolls de este tipo tiran mejor con actualizaciones parciales, por el tema de los huecos. A lo mejor en el nivel 1-4 sí que me puede venir bien porque sí hay scroll a pantalla completa en el fondo, pero usando proceso target.

Lo cierto es que no recuerdo si añadí GP2X como constante de OS_ID en la compilación, pero tienes razón, puedo hacer que sea SO dependiente (para algo tenemos también los parámetros de entrada del BGDI (ARGV y ARGC)).
Me lo anoto para la 1.4. Muchas gracias.. por esta idea y por el resto del hilo ;)