Penguin PUSH [Pixtudio Android&Windows] Alpha

Started by alicesimu, December 09, 2016, 01:06:26 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

l1nk3rn3l

#30
tengo un movil con procesador Mediatek a 1.3GHz de cuatro núcleos

y si de 50 fps cae a 30 fps ....   hay algo mal en el codigo ...

mira ver .. de pronto vuelves a llamar a set_fps en otro lugar...

o intenta colocar set_fps(60,0) antes de cada cambio de nivel...

o aun mas .. un set_fps y luego un set_mode


la verdad es raro he hecho varias pruebas y en mi movil corren otros ejemplos
muy rapido.. pero el tuyo siempre cae a 30fps... el de benchmark siempre es 60fps hacia arriba

la verdad ni idea...

post data: puedes compartir el codigo del control del joystick en android
para adicionarlo en el proximo pack como un ejemplo nuevo , claro los créditos serán incluidos? 
teclas de direccion mas el boton fire .. 




alicesimu

Si desean ayudarme con la programación del proyecto, les estaria muy agradecida.
Reconozco que puede ser un poco caótico el programa, pero intento ordenar todas las cosas.
Ademas dentro del codigo contiene una clave de seguridad, para que no puedan añadir mapas de modo Aventura(AV_ZON), editadas por cualquier usuario. Para eso esta la carpeta probia de EDIT_ZON.
Ademas el porpio formato de los ficheros de las zonas.

Si estáis interesados en ayudarme, os añadiré como colaboradores del proyecto, os tendré en una lista del Team de confianza.

A Drumpi me esta ayudando mucho, si tienes tiempo libre te apetece analizar mi proyecto de las entrañas, te lo agradeceria.
y Linkernel por el soporte concreto a Android que da gracias a pixstudio, pude hacer este proyetco.
Tambien me ayudas mucho!

Me gusta testear la capacidad de ello.

Tengo una carpeta de trabajo en la nube, en mega. siempre dispongo de una copia de seguridad, por si deseo trabajar en otro equipo.

Os enviaria el Link de la descarga del paquete por privado, contiene el juego completo(compatible con windows)(sin menus) y la carpeta preparada para empaquetar a android apk.

--------------------------------------------------------------
Te adjunto el codigo + grafico del stick digital de 4 direciones  + boton juego.
de fondo aparece un pescadito se tiene control de el con el imput.

Este codigo soporta de 2 dedos maximos.
Tiene un sistema que evita de forma acidental pulsar el segundo dedo, cuando el primer dedo ya tiene el stick digital abierto.

la parte izquierda es para el stick digital, la derecha mitad inferior la del boton de fuego.

Drumpi

Pues mira, dos cosas:

- He probado el juego (por fin), la apk que subistes, en una tablet Intenso TAB 814 (doble núcleo a 1.5GHz, con 1GB de RAM y Android 4.1) y la he tenido abierta durante más de 20 minutos funcionando (o sea, me he pasado dos niveles y en el tercero lo he dejado quieto tras matar a todos los enemigos) y no ha bajado de 60FPS (ocasionalmente ha pasado a 59 o 61 FPS, pero nada, apenas un segundo)... hasta que accidentalmente le he dado a atrás y se ha salido ^^U
Luego he intentado pasarme tantos niveles como he podido. Soy un negado con los controles táctiles (^^U), y que la cruceta cambie de posición, personalmente, no me ayuda. Aparte de que no me dejaba moverme y atacar a la vez, sólo me reconocía un dedo cada vez (o eso me ha parecido ^^U). Tras cinco o seis niveles, los FPS se han mantenido estables a 60. Los únicos bajones de velocidad se han dado al construir el nivel y justo en el momento de la colisión con la puerta.

- Lo segundo. Puedo echarle un vistazo al código, si no es muy grande y está medianamente comentado :P No te prometo nada, porque no tengo el entorno para hacer pruebas y no sé lo que podría tardar, ya que llevo unos días de locos :D :D :D O con que me señales dónde están la carga y descargas de recursos, lo puedo mirar ;)
Ya lo de los créditos como tu quieras. Yo suelo añadir a los creadores de los DIV-like como "programación adicional" y doy las gracias a la comunidad en general por su ayuda... pero como nunca nadie se pasa el juego (o al menos no se leen los créditos... :D :D :D).
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

alicesimu

Aaahh que bien, genial tus pruebas.

Quizás sea dependiendo del S.O. android. Es lo único diferente que podría tener en rendimiento.
El mio es un doble núcleo de 1,7Ghz de 1Ram, pantalla de 720p y el android 7.1 custom ROM de cyanogenmod 14.1

Y si te confirmo que se puede pulsar 2 dedos a la vez, ir a una dirección y pulsar fuego a la vez.
Colge el ejemplo del stick digital anteriormente, para quien quiera.

Si se necesita preparar la mesa de trabajo para compilar y pasar el juego a apk android.
Es entretenido.
Si el código es largo, muchas variables de control, algunas temporales para rápidas operaciones.
Globales hay unas cuantas, locales solo 3.

Yo te puedo indicar las lineas o nombre de un proceso y de variables.

El juego contiene:
Proceso juego_base es el mas importante, llama a la función de pintado de zona(por archivo o aleatorio)
Proceso jugador es único
Proceso enemigos pingüinos

Yo en mi juego además de añadir un leeme.txt con toda información del juego y el team.
Y añadir un botón de información, para visitar la web, facebook, este hilo, y ver el team.

El menú principal aun no lo tengo terminado, esta en pañales.
Ahora deseo enfocarme en el motor base del juego, el por que esa bajada de fps...

l1nk3rn3l

#34
Gracias ... seria genial ayudar..

y lo del gamepad virtual esta interesante... lo habia visto en construct2 y unity ... pero ya que te lo
has currado esta muy bueno... para compartirlo.. y mejorarlo... se daran creditos gracias Alicia

DCelso

pero si viene en el pixtudiopm, pff, verás pixel cuando se entere ...
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Drumpi

¿¿¿Android 7.1??? Si creía que el último era el 5.1 ^^U
Supongo que la numeración de los custom kernels es diferente a la oficial :D

Tengo el entorno de Android, pero el oficial, de cuando empecé a estudiarlo (y lo dejé tras la primera lección, dichoso lenguaje de etiquetas :P). Supongo que añadir el resto para que funcione Pixtudio no será difícil. Lo difícil será seleccionar lo que necesito del Pixtudio Pack ^^U
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

alicesimu

Bueno, es la ultima que hacian los del cyanogenmod 14.1 pero esta empresa cierran y se mudan a una nueva con otro nombre.

Android 7 esta verde...
Prefiero la version 6, es estable, CM13

Grave un video gameplay(sin audio) de una partida en modo aventura
https://youtu.be/I8EruOcTB-s

alicesimu

He subido tambien el ultimo APK con la maxima optimizacion, pero activando el sistema de particulas, sonidos, musica, y visible los controles tactiles.

Es el mismo del video que he subido el gameplay.

Aqui esta el APK.
https://mega.nz/#!RQs2xD4A!KmMTSaMag2yNgOnuCgdsAL8TuMA7geBP30WyfKJPJag

alicesimu

Use una app para monitorizar la cpu
Y no llega al 100% como mucho al 50% en algunas ocasiones.

Es multinucleo los juegos que hacemos con pixstudio? Parece que solo use un core...

alicesimu

Descubri que tiene un fuerte impacto de rendimiento al usar SCROLL.

Desactive el scroll por completo, ahora todo se pinta en pantalla normal c_screen.
A esto, me quede sin fondo tileado texturizado, claro se ve toda negra. y sin seguimiento de camara(por que no existe)

pero el rendimiento es de 60-58FPS!!! en todas las ZONAS! pero en un 75% esa en 60,  25% esta en 58FPS.

Es constante al 100% todo el rato que quiera!

los procesos, van minimos de 6 hasta 40aprx(activado las particulas de copos de nieve, sangre)...
esas particulas se autodestrullen al terminar de su animacion.

Ahora me falta programar un fondo de terreno tileado, la textura... como la repito en el fondo de pantalla?
y como programo el movimiento de camara como si fuese un scroll?

ahora no tengo camara automatica, ni fondo tileado.

SplinterGU

Quote from: alicesimu on December 31, 2016, 12:38:24 PM
Use una app para monitorizar la cpu
Y no llega al 100% como mucho al 50% en algunas ocasiones.

Es multinucleo los juegos que hacemos con pixstudio? Parece que solo use un core...

tengo entendido que 1 solo core.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Drumpi

Hasta donde sé, si Pixtudio hace uso de código Bennu, sólo se usa un núcleo. Creo que las optimizaciones van por el lado de la aceleración gráfica, es decir, el pintado por pantalla y manejo de gráficos.

El scroll... No es particularmente rápido, pero ¿Tanto como para que te de los problemas que te está dando? Sé que tanto en Fenix 0.84 como en los inicios de Bennu, se le dio un buen lavado de cara porque el rendimiento era peor que coger una imágen fija, asignarla a un proceso, y moverla por la pantalla (mira, puedes usar eso, haz un mapa del tamaño de la pantalla, lo rellenas de los tiles, y le añades una fila y una columna extra, después sólo tienes que irla desplazando y cuando llegue al final, colocarla en su posición inicial y hecre de nuevo el desplazamiento). Diría que incluso mi motor de scroll tileado original era más rápido que el scroll de Fenix 0.83b

Pero me extraña que ahora consuma tanto, a menos de Josebita le haya hecho algo y tengamos que castigarlo de cara a la pared :D
De hecho, ya digo, el añadir los fondos de scroll al "juego del chavalín de 7 años" sólo me ha supuesto perder entre dos o tres FPS en Wiz.

Ahora que caigo ¿estás poniendo todos los procesos dentro del scroll? ¿Para qué? Ponlos en pantalla, y crea un proceso que modifique los valores de scroll[0].x0 y scroll[0].y0. A lo mejor el ctype=c_scroll es lo que te consume tantos recursos (aunque no debería).

Si aun así quieres dejar el fondo fijo, tendrás que usar un bucle doble, para recorrer filas y columnas, y usar alguno de los comandos PUT para ir rellenando la pantalla.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

alicesimu

la cosa del rendimiento, creo que es por 2 cosas:
1-las dimsiones del grafico que tiene el proceso metido en c_scroll.

o bien...2- el numero de procesos por cientos o mas...

aun asi, los fps han ido a peor igualmente... por usar SCROLL sencillamente ir creando procesos y eliminandolos, asi de sencillo.

y si, todo elemento metido en scroll: pinguinos, bloque moviles(solo cuando se mueve), partículas y 2 procesos congelados(que pinta la zona, con el map tileado).
son pocos procesos... aun asi el rendimiento baja en cuestion de tiempo y numero de zonas cargadas...

Sinceramente note un rendimiento brutal cuando elimine el scroll.
y ahora todo son procesos normales c_screen.

y el rendimiento es bastante bueno, 60-58FPS.

Si solo me queda crear mi sistema de "camara" para simular el deslpazamiento(hay que mover todos los elementos de juego, hasta el terreno de zona)

el terreno de zona, siguie siendo 2 procesos: 1- bloques solidos, 2-elementos de suelo:punto de salida, salida, sangre,items...

no tengo problema con ello, soy consciente de todos los procesos que existen en todo momento.
PEro ya no es un problema cuando me quite el scroll....

lo probare eso:
Quote from: Drumpi on January 02, 2017, 01:06:37 PM
Ahora que caigo ¿estás poniendo todos los procesos dentro del scroll? ¿Para qué? Ponlos en pantalla, y crea un proceso que modifique los valores de scroll[0].x0 y scroll[0].y0. A lo mejor el ctype=c_scroll es lo que te consume tantos recursos (aunque no debería).
actual mente ya los tengo en pantalla tradicional, me falta de terminar de programar "un camara"
para que tenga el efecto de que siga el jugador(siempre en medio de pantalla), el resto de elemento se deben colocarse en las coordenadas finales.
despues del FRAME
debo restaurarlas, a las cordenadas reales... y no liarla...

recomiendas usar cordenadas locales definidas por ti: X1,Y1
para esos procesos, serian las cordenadas reales

y las cordenadas de pantalla final x,y se aplican al final.
El resto de operaciones del rollo GET_DIST (necesitan un ID) tendre que cambiarlas por FGET_DIST (coordenadas X,Y).

a veces los pinguinos y bloques moviles, necesitan comprobar las cordenadas entre ellos, no solo la orientacion.

Drumpi

Será que no he avanzado lo suficiente en el juego, pero siempre he visto pantallas estáticas (o me ha parecido verlo). Por eso te decía, que no me parece lógico que procesos que se mueven dentro de una pantalla estática se metan dentro del scroll.

Prueba a crearte tu scroll manual a ver qué tal funciona. Lo mismo te llevas una sorpresa y todo :D :D :D
No es difícil mientras tengas un proceso cámara que modifique unas variables (coordenadas) que puedan leer todos los procesos (recomiendo globales) y que se ejecute después del movimiento del proceso a seguir (prota, que se mantendrá en el centro) y antes que el resto (para que aparezcan en su posición actulizada, su posición real se calcula con una simple suma/resta respecto su X1/Y1 y las variables coordenadas de la cámara, de ahí que se tenga que poder leer desde fuera del proceso cámara).
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)