Penguin PUSH [Pixtudio Android&Windows] Alpha

[alicesimu]

Genial!!
gracias por el ejemplo y la explicación, se parece una struct, pero algo diferente no se.

la unica pega de usar el array bidimensional es que debo establecer un limite(una constante) de dimensiones x casilla de la zona.

99x99 o 999x999  por ejemplo...

lo malo que contra mas grande sea, mas bytes de memoria ram consume... es un sencillo calculo, ademas con sizeof te dice el total de elementos que contiene.

aun asi, me lo mirare cual es la mejor estrategia

[Drumpi]

Lo del tamaño fijo también tiene fácil solución: usa CALLOC para crear un array dinámico de memoria, con tantas posiciones como casillas haya en el juego.
Luego, para saber qué posición leer sólo tienes que buscar en:
mi_array_ptr[(posy * CTE_N_COLUMNAS) + posx]

Donde:
· posx y posy son las coordenadas de la posición que buscas, desde 0 a CTE_N_FILAS-1 o CTE_N_COLUMNAS-1.
· CTE_N_COLUMNAS es el número de elementos que hay en una fila. Puedes usar una constante o una variable.

Y lo dicho, haz tus cálculos. Hay un mapa de uno de mis juegos que mide 893x22 tiles (una WORD por cada posición) y me cabe en GP2X. Creo que tu mapa cabe de sobra en una Raspberry Pi Zero :D

[alicesimu]

estoy documentandome: http://wiki.bennugd.org/index.php?title=Calloc

es que me hago un lio, me es nuevo para mi, esto de usar TYPE, Calloc....
disculpa si soy lenta.

[Drumpi]

No hay nada que disculpar, estás aprendiendo, igual que lo hacemos todos. Unas cosas se aprenden antes y otras después :)
Ten en cuenta que aquí te damos consejos en función de los problemas que propongas, igual que algunos te los pediremos luego de lo que estás investigando por tu cuenta (es decir, que ya me cobraré los favores preguntándote por Android, PixTudio y todas esas librerías que estás usando :D :D :D).

[alicesimu]

Aun ando haciendo test de prueba,
Con la versión por map_get_pixel get_RGB.

Aun no lo deseo publicar en google play, pero si puedo subir el Apk por separado solo con fines de test de rendimiento, aun esta versión contiene algunos bugs de lógica con la nueva implantación del modo mal_get_pixel...
Una pequeña corrección de la tipografía de texto medio(aun por ajustar la altura y).

En este apk deseo enfocarme en Rendimiento en fps, sin uso de frameskip.
Puede que me vuelva loca, pero los fps parecen una montaña rusa de ir al principio a 60, y a los pocos segundos a 60-50
Al minuto 55_45
A los 5min a 50-35
A mas de 7mim 45-25.

Aun no entiendo este comportamiento, calculo que hay aproximadamente 5-7 procesos activos(proceso juego base, proceso de input, pingüinos, marcador) y 5-7congelado s_freeze

Deseo que los que tengáis físicamente un dispositivo android, smartphone y/o tablet.
Me pongáis el modelo y la ver de android s.o.
Y claro los fps, probarlo durante unos minutos, como si jugáis o dejarlo sin tocar(dejar que corra el juego)



Yo ya digo, yo en 5min a llegado a los 45-30aprx.

Quien vota por insertar frameskip a 1-2.(sin modificar la velocidad original de 60 y sus elementos)
Quien vota por dividir por 2 la velocidad de fps. Pasar de 60 a 30, eso es multiplicar la velocidad de los pingüinos,bloques por 2.

Tengo sospechas que se trate de un comportamiento "normal" en android... Por temas de servicios en segundo plano(wapsap, google servicios,...etc)

El Apk es la versión 0.46 no publicada en google play.
Podéis descargarla e instalarla.
Este Apk se salta el menú principal(ni carga esos recursos)va directo al modo maratón.
Contiene sistema de particulas activado(copos de nieve al caminar los pingüinos y sistema de sangre).

https://www.dropbox.com/s/iuj70y8t41glrhp/base.apk?dl=1

[Drumpi]

Haces bien en intentar mejorar el rendimiento sin frameskip ¡así es como debería hacerlo todo el mundo! El FS es el último recurso. Podrías intentar bajar los FPS, pero tampoco lo recomiendo, mientras puedas mejorar el rendimiento.
La caida progresiva de frames, en casos normales, suele deberse a la acumulación de procesos que no se han muerto. ¿Has abierto el debuger en PC para comprobarlo? A veces pensamos que tenemos 5 procesos pero no hemos visto que alguno no se ha muerto cuando debiera.
Si no, es cosa de memoria, que se van acumulando datos sin liberarlos y al final... La única forma que se me ocurre de mirarlo es con:
http://wiki.bennugd.org/index.php?title=Memory_free
Pero no sabrás quién se está quedando con la memoria.

Yo intentaré mirártelo en una tablet que he conseguido para estos menesteres. Es antigua, una dual core con Android 4.1, creo, que tiene problemas con el chip de video y hace cosas raras en la pantalla. Lo que no sé es cuando, porque hace dos semanas que tendría que haber emepezado mi web-blog y aun no tengo abierta ni la cuenta de hosting ^^U

[alicesimu]

si la que esta subida en google play 0.45 usa frameskip 2.
Puro por procesos esa funciona. sobre 115 - 170...

Pues las pruebas que hago ahora, son mas optimizadas,
uso dentro del bucle del juego_base, este contador de procesos(sin importar que esten congelados,dormidos...)

while(GET_ID(0));procesos++;end
Con esto controlo el numero de procesos en memoria.

A esto me puse a unificar y eliminar procesos...
unifique algún proceso en segundo plano, aunque sea de pintado...
por ejemplo, el marcador usaba 3 procesos 1 activo 2 congelados...
ahora el marcador, esta dentro del proceso juego_base, ahorrandome 3 procesos mas.
y el graph que muestra juego_base es parte del marcador, generado con new_map al principio.

Tambien tenia un proceso en segundo plano, que controla el input del jugador(teclado o/y touch android), este pintaba 3 elementos en pantalla para el input de android: stick direccional, elector rojo de dirección + boton fuego de la derecha.

Ahora esta unificado al proceso jugador pinguino directamente. otro proceso ahorrado.
El jugador tiene presente el boton de fuego azul que rota que es un proceso congelado tonto.(esta se puede desactivar en el futuro menu de opciones)

Actualmente....
solo hay en memoria de 6 procesos minimos,
y maximos puede ser ... dependiendo del numero de enemigos, placa hielo descongelante si hay, y bloques en movimiento)(hasta chocar) y otros procesos de efectos especiales que duran muy pocos segundos o menos de un segundo(sistema de particulas, fuegos, explosiones...).

cuenta: (Numero de procesos, minimos - maximos) - elemento descripcion.
(1-x)-pinguinos (cuenta tambien el jugador por supuesto)
(1)-juego base(controla el marcador, y logro superar o no la zona, control de animacion de powerup)
(2)-proceso congelados solo para pintar dentro del scroll (2 capas del map del tileado de bloques e items inmoviles)
(0-X)-placa de hielo, que se congela y descongela por tiempo(tiene un contador y aplica size_y + alpha)

Siempre que finaliza la zona:(por victoria o gameover...)
Paro el scroll stop_scroll, esto mata cualquier proceso metido dentro de el.
elimino cualquier proceso con let_me_alone(); un clasico de div
elimino todos los textos write
descargo en memoria los MAP generados de la Zona(son 4 en total: 2 de pintado de title, y 2 de durezas)

reseteo variables globales para la nueva zona.

Y ejecuto el juego_base(son) y se autoelimina el viejo padre(father).
prefiero cargarme el proceso que estaba usando como base y crear uno nuevo de 0, me quedo mas tranquila(la razon por las variables privadas y locales, no tengo ganas de resetearlas una a una)

Esto me pasa tambien, cuando el jugador muere por algun enemigo o bloque que nos aplasta.
prefiero que el jugador se autodestruya(return;), ajustando alguna variable global(vidas,poweup..) y crear un nuevo proceso jugador.


Despues de eliminar todo en memoria y estar con el nuevo proceso juego_base
solo crea en memoria los 4 MAPS de durezas y tiles
a esto... prepara la zona,y coloca solo los procesos activos:pinguinos, placa hielo descongelador.
añade 2 procesos congelados de pintado para el scroll.
pinta los textos write.
y ya se inicia el juego.

por ahora aun no declaró nuevas variables y espacios de memoria uso de calloc, type....
solo creo los procesos minimos y se eliminan.

no lo veo normal que al cabo de los 5min este por 30FPS aprx.

probare de consultar la memoria con memory_free gracias por la idea, eso me ayudara.

Si este caso no se soluciona, me vere forzada activar el frameskip y aun asi... podras jugar unos 10-15min mas de forma semi rapida... pero si o si creo que los FPS va abajo... al colapso.
considero que ya es problema del motor de pixstudio en android, algun bug de memoria podria tener algo...

[Drumpi]

Puede ser, pero no creas que por reducir el número de procesos vas a mejorar el rendimiento. No he hecho un estudio, supongo que tu sí, pero creo que el cambio de contexto de un proceso a otro podría ser menos costoso que las comprobaciones que añades a un proceso para unir su código al de otro. Recalco lo de PODRÍA.
Lo que ya no sé es cuánto usas el comando PUT o los DRAW. Aunque no lo parezca, estas funciones son muy costosas... al menos en Fenix y Bennu. No me hagas mucho caso, pero creo que un simple map_get_pixel equivalía a unas 7 sumas (tendría que hacer una comparativa para confirmarlo).

Y si, es posible que haya una fuga de memoria en el port de Pixtudio a Android, pero como he dicho en más de una ocasión: el 95% de los fallos del programa los comete el usuario, no el programa en sí. :D

[alicesimu]

Son mínimas las comprobaciones sencillas y intento usar menos las funciones del lenguaje.

Mal_get_pixel y get_RGB es lo que mas se usa en tiempo real, Solo cuando se mueven en el mapa. Pingüinos y bloques en movimiento.

Pues no uso DRAW,ni PUT. No hago operaciones de pintado en pantalla, solo pinto dentro de mapa, pero poco.

A todo esto no conozco otro juego hecho con pixtudio para android y se haga un test, en 5min a cuantos fps tira...

Sabes algo?

Aun asi voy trabajando en otros aspectos para avanzar y no quedarme atrás.

[l1nk3rn3l]

Hay una prueba de rendimiento
llamada en ejemplos 02_advance/benchmark

haber como va en android...

[alicesimu]

El benckmark al ser 1600 procesos activos, es evidente que va lento en mi son y xpiera sp con android 7.1. CM14.1
A 13-11FPS

Mi caso no son por procesos, uso una media de 12 procesos que la mitad están congelados.
5 son básicos, mínimos.

Zonas de tamaño medio de 37x25 aprox no es un problema.
Tampoco el numero de pingüinos en el mapa que pueden llegar a 16-20... No mas.
Zonas con un solo enemigo hasta docenas ...

Testeando los fps es una montaña rusa. De pocas veces llega a los 60 y tiene picos hasta de 30.
Pero la media es de 50
Ese comportamiento cuando estamos en la misma zona, se mantiene un rango de fps...

El problema serio viene al pasar a otra zona, esta la libera de la memoria, matando a todos los procesos y descargar los maps.
Se nota una bajada de unos 3-5fps, cada vez que superamos o no la zona.
El rango de fps baja de 60-30 a 45-28, 37-26, 32-25...
Así sucesivamente al cambiar de zona, sin importar las dimensiones de la zona y el numero de procesos.

Tengo 2 soluciones:
Usar frameskip a 1-2.
O
Dividir por 2 la velocidad de juego, y multiplicar por 2 los movimientos de pingüinos y bloques en movimiento y los sprites.

Por lo que veo tira a que funcionara de forma constante a 30Fps aprx.

[alicesimu]

Puede que exista un problema de eliminación de recursos en memoria/CPU en pixstudio.
Si los fps bajan cada vez que elimino y creo una zona nueva...
-stop_scroll(0)
-let_me_alone()
-delete_texto(0);
-map_unload (descargo los 4 mapa que se han usado para la zona).

Después se crea la nueva zona:
-Start_scroll
-Pinta_zona(crea los 4 mapa, y pinta en ella, también crea procesos: pingüinos)
-pinta los write de texto.
Y empieza el bucle del juego.

En algún proceso, debe provocar esa bajada de fps, baja el rango de fps por cada zona eliminada/cargada


No entiendo donde esta el fallo.
Haré un benckmark concretamente con esto, solo la creación y destrucciónde zonas.

[Drumpi]

Map_get_pixel pertenece a la familia de las funciones PUT. Todas las operaciones con los pixels de los mapas, tanto de lectura como de escritura, usan un código parecido y, teóricamente, son lentas (lentas en comparación con la lectura de un valor de memoria, por ejemplo, tampoco es que vaya a tardar 5 años en hacer la comprobación ^^U).

Pero veo que estás hilando muy fino. No creo que sea problema de número de procesos, porque si 1600 te van a unos 12 FPS, es raro que sólo 16 te consuman tanto. Ya te diría que comprobases dump_type y restore-type, a ver si es que estás usando valores incorrectos para tu juego, que es donde más rendimiento se te puede ir, pero aparte de eso, y sin ver el código, sólo te puedo decir cosas como que acceder a variables públicas es más lento que acceder a locales, y a su vez las locales son más lentas que las privadas (sin demostrar).

Si estás completamente segura de que entre nivel y nivel lo has descargado todo y has liberado la memoria, ya sólo puede significar que haya un bug en el port de Pixtudio, es lo único que se me ocurre. Eso, siempre que realmente se hayan descargado las cosas, es posible que le estés pasando un ID de imágenes no válido sin darte cuenta, porque se haya modificado por cualquier cosa (asegúrate con un SAY, por si acaso).

[alicesimu]

Ahora me haces pensar en esas variables locales, no uso publicas.
Pero si debería mirara al detalle sobre el uso de variables locales creo que me sobra alguno.

No he tocado las restore y dump esos modos de restauración de pantalla, se que existe. Las tengo por default.

Me asegurare usando say que se descarga todo todob y elimina los procesos.

Seguro que me planteare de dejar usar el sistema mal_get_pixel map_put_pixel y get_RGB
Y pasarme al uso de arrays. Como hablemos anteriormente si o si debe ser mas rápido.

[alicesimu]

Tengo algunas pruebas...

Code Select Expand


PixTudio Blender 1.0.0 (Dec 15 2016 16:09:14)
Pixtudio comes with ABSOLUTELY NO WARRANTY
See COPYING for copyright details


File D:\MEGA\PP\Penguin-PUSH_PXT\Penguin-PUSH.dcb compiled (172639 bytes):

  Processes                    24
  Global data                2828 bytes
  Local data                  236 bytes
  Private data               1088 bytes
  Public data                   0 bytes
  Code                      65348 bytes
  System processes            328
  Globals vars                112
  Locals vars                  34
  Private vars                247
  Publics vars                  0
  Identifiers                1030
  Structs                      10
  Strings                     137 (1754 bytes)

************** START ZONE MODE: 0 ********************
AV_ZON/Alice Simulator1-1.zon
15x13
70
Alice Simulator1-1
1057
1058
1059
1060
PINTA AUTOMURO
INICIO PINTA ZONA
FIN PINTA ZONA
PLAY ZONE:1
AV_ZON/Alice Simulator1-1.zon
15x13
70
Alice Simulator1-1
INICIO PINTA ZONA
FIN PINTA ZONA
FINALIZADO EN:00:21
TOTAL TIEMPO:00:21
PROCES:1
1057
1058
1059
1060
************** START ZONE MODE: 0 ********************
AV_ZON/Alice Simulator1-2.zon
18x12
68
Alice Simulator1-2
1061
1062
1063
1064
PINTA AUTOMURO
INICIO PINTA ZONA
FIN PINTA ZONA
PLAY ZONE:2


analizando, al crear la nueva zona:
crea los 4 maps:
1057
1058
1059
1060

juego funciona al llegar: PLAY ZONE:1

al matar a todos los pinguinos, necesita colocar la salida del mapa, accede de nuevo al archivo de la zona:
AV_ZON/Alice Simulator1-1.zon
solo para colocarla, no crea ningun map, solo la salida.

despues el juego finaliza al llegar a la meta:
FINALIZADO EN:00:21
TOTAL TIEMPO:00:21

despues elimina la zona de la memoria:
let_me_alone();
compruebo los procesos existentes:
PROCES:1  Solo existe 1 proceso en memoria, el juego_base
1057  Descarga los map_unload(0,mapa1);
1058  ..
1059  ..
1060  ..

y nos ponemos a cargar otra zona: Alice Simulator1-2.zon

Code Select Expand

************** START ZONE MODE: 0 ********************
AV_ZON/Alice Simulator1-2.zon
18x12 dimensiones en casillas de la zona
68 numero de elementos que contiene
Alice Simulator1-2
1061
1062
1063
1064
PINTA AUTOMURO
INICIO PINTA ZONA
FIN PINTA ZONA
PLAY ZONE:2