[GAME] Penguin PUSH [En Desarollo]

[SimulatorOne]

Pues lo que te sea mas cómodo, la verdad es que usar grillas de cualquier tamaño de celda no es problema si usas las formulas correctas y lo estructuras todo.
La pega de gemix es que las variables X e Y son INT y eso limita hasta el inifinito.. porque tienes que andar usando variables intermedias y luego cuando quieres conocer la posicion "en coma flotante" de un objeto.. no te sirve con mirar su X o su Y.. en fin.. que es un horror.. creo que esto está solucionado ya por fin en la version openGL.

de momento me es suficiente para este tipo de juego en formato INT, necesito numeros enteros, calculos sin coma flotante para esto.
y te confirmo que SERA FLOAT las nuevas X,Y(no se si algo mas) en OpenGL, ya me aviso Cictec de ello.

jajaj "limita hasta el infinito", siempre existen limites, pero debes resolverlas tu mismo, mira Minecraft parece infinito los mapas, cuando existe un limite de cordenadas...

Yo siempre pensé que resolution es una verguenza XD.. da verguenza desde sus origenes en Div..

jamas lo use, es liarte mucho.

Haber.. lo que yo haría es hacer una grilla de 100x100, y usar size para rellenar el hueco a un tamaño de sprite ideal, pero por dios.. no uses map_get_pixel() ni nada que tenga que ver con eso, yo lo desaconsejo completamente porque eso trabaja a nivel de pixel.. y eso está completamente desfasado y obsoleto.

tranquilo, ni loca se me ocurio usar esas tecnicas, ni tengo un mapa/grafico de fondo que ocupe toda la zona del nivel, ni eso.
ni mapa de durezas ni hostias, eso es consumo de memoria Ram y aumento de CPU tontamente.

pero podria haber un mapa de busqueda(clasico Div2, blanco y negro) para los enemigos(hacia el jugador), a nivel de pixel mininuto.
pero es algo experimental eso, y actualmente no lo tengo en mente ponerlo, podria perjudicar eso.

Actualmente en un intel Atom 1,6Ghz, solo usa un 10% de consumo de CPU. por que funciona a 10FPS...
de momento cumple el rendimiento deseado....

ya digo la grilla de juego: de momento esta entre minimos de 10 hasta 30...casillas. naturalmente puedo aumentarlo, pero aumentaria el uso de CPU por los enemigos/bloques en movimiento.

La targeta grafica entiende de texturas y de mover texturas, y la cpu con las librerías de físicas que hay ahora.. funcionan mas rapido las cosas por física que por mapas de durezas..
Em mi humilde opinión.. cualquier cosa que no sea con física.. y mas al nivel que lo has llevado tu en este juego.. va a sufrir las consecuencias en openGL.. y es una bajada brutal de performance.

Deberías intentar rehacer el juego usando chipmunk o box2D

no se como sera en openGL, pero solo deseo que el funcionamiento sea mejor, no peor.

de momento solo uso OVERLAP y GET_DIST, los pingunos y bloques en movimiento.
intento usarlo lo minimo esas dos funciones, podria sacrificar el OVERLAP(colision por caja grafica) y usar solamente GET_DIST(Radio), o montarme una funcion para calcular una AREA RECTANGULAR, SI esta dentro ese proceso con sus XY, si esta dentro devuelve TRUE, asi de facil. pero si o si DEBO recorrer los procesos GET_ID(TYPE pinguinos) o GET_ID(TYPE Bloque_mov).


sinceramente estas semanas, siempre he podido optimizar poco a poco mas, el codigo. se llega a notar mejoria de CPU.
puliendo apurando, compactar codigo...
uso los SWITCH, WHILE,FOR,FROM,BREAK, RETURN... segun vea necesario,
a veces ni si quiera con solo llamar SIGNAL(ID,S_KILL); es suficiene, soy muy bruta hago directamente RETURN; lo reventamos de la memoria brutalmente.


usar fisicas, necesitaria guia para aprender a usarlo, y definir unas reglas de comportamiento, no pueden moverse libremente a 360º al estilo AngryBirds.

[SimulatorOne]

bueno, a partir de ahora, que ha salido la nueva beta de gemix 0.7.5 con la opcion Modern, con OpenGL...

debo pasar poco a poco el codigo, a la nueva version, Modern, ademas, de usar nuevos estilos de programacion, dejar de usar las antiguas Div2/Legacy... y pasar a usar TYPEDEFS, Metodos y mejorar la organizacion.

tendre que ir probando poco a poco. aprendiendo la version Modern.


Lo ultimo que os puedo enseñar, la ultima vez que programe, en la 7.0, fue el multijugador de pantalla unica(sin pantalla dividida,sin scroll)

Penguin-PUSH_11-02-2016_19.14.34.png

este menu es temporal de diseño, les faltan botones: de momento funciona por cursores: aumentar y reducir las dimesiones de mapa de juego x bloques, a como tope la pantalla de nuestro monitor/escritorio.

Penguin-PUSH_11-02-2016_19.10.13.png

Acapara las dimensiones selecionadas anteriormente, de momento se colocan a la zar los jugadores, pero se visualiza al inicio su punto de partida.
debajo de ella, se localiza su punto de partida, con el numero de jugador(multijugador)

cada jugador tiene un control de juego selecionado: 0=teclado1,1=teclado2,2=>Joysticks...
se creara el menu de opciones de control, para multijugador.

Existen 2 Razas, nuevas de pinguinos:
-Adelie

per3.png

-Gentoo

per1.png

de momento los jugadores son Adelie
los enemigos Gentoo.

[shao]

Yo tengo mi juego con la versión legacy y y así se va a quedar, ya lo he dicho otras veces, no necesito aceleración gráfica a parte del enorme trabajo que me llevaría adaptar el código a la versión acelerada.

Por otra parte leí que el código, la lógica del juego, representa sobre un 20% de los recursos, es decir, que la parte gráfica es lo que más consume en la ejecución del juego, si tienes muchos efectos y cosas por el estilo y tienes que el juego te está consumiendo demasiado, olvídate del código por que no ganarás mucho optimizandolo y perdiendo tu tiempo en él, reduce los efectos o ingeniatelo para optimizar esa parte.

[erkosone]

Sabias palabras Shao, en android es otro mundo, tienes que rizar el rizo para poder ejecutar las cosas a una buena velocidad
Yo me pongo en la situación de Simulatorone y la verdad es que se me ponen los pelos de punta jeje.. este juego es muy guapo pero tiene un problema de base, cada cubo es un proceso, y eso en android no puedes hacerlo así.
Por ponerte un ejemplo que nadie ha tenido nunca en cuenta y que hahora con la nueva versión de gemix acelerada y con los FX por separado se podrá optimizar mucho mas que actualmente..
El ejemplo es una chorrada pero no veas lo que cambia tio..

Escribes 30 textos en pantalla.. 15 con una fuente y 15 con otra fuente.. vale..
hasta ahora con gemix legacy no podias seleccionar la fuente de texto para pintar y luego simplemente pintar texto.. tenias que especificarla en cada llamada de screenDrawText()..

Se supone que ahora con la nueva versión que saldrá podras hacer:
setFont(fnt_1);
for(i=0; i<30; i++)
screenDrawText( !! aquí no especificar la fuente de texto !! );
..
..
Son esas pequeñas cosas las que en gemix/div hasta ahora no teniamos en cuenta pero que marcan la diferencia y mucho.
El juego este del pinguino a Alice le va a costar sudar sangre para portarlo a android a 60 fps, aunque a 20 o así si es jugable ya sirve.. aunque ahora creo recordar que Alice dijo que no quería dejarlo a 60fps que funcionaba a un fps mas bajo creo.

Y lo que nos falta son los threads para poder procesar en segundo plano funciones demasiado costosas..

Imaginate que tienes una función en gemix que comprueba todas las colisiones y deja un flag en cada proceso indicando si colisiona con el player o no.. madre mia... son un montón de llamadas a overlap o collision o get_dist... PERO..

imagina que llamas a esta función con un thread y pones un gatillo a true.. y ahora pintas todos los procesos.. y al siguiente frame esperas simplemente a que la función que está con las colisiones te deje el gatillo a false y vuelves a pintar..

Estas pintando y comprobando colisiones a la vez.. y esto hace falta si o si en Android, aunque todos sabemos que Gemix está muy optimizado y que es bastante mas rapido que casi todos los demas DivLike, en android todo cambia y vamos a tener que cambiar la forma en que programamos nos guste o no jeje

[CicTec]

Yo me pongo en la situación de Simulatorone y la verdad es que se me ponen los pelos de punta jeje.. este juego es muy guapo pero tiene un problema de base, cada cubo es un proceso, y eso en android no puedes hacerlo así.

Debe hacerlo asi, cada cubo tiene interaccion de colision con otros cubos y/o personajes/elementos en pantalla, no se puede permitir de crearse un sistema de colisiones en script cuando ya lo tiene nativo.

Escribes 30 textos en pantalla.. 15 con una fuente y 15 con otra fuente.. vale..
hasta ahora con gemix legacy no podias seleccionar la fuente de texto para pintar y luego simplemente pintar texto.. tenias que especificarla en cada llamada de screenDrawText()..

Se supone que ahora con la nueva versión que saldrá podras hacer:
setFont(fnt_1);
for(i=0; i<30; i++)
screenDrawText( !! aquí no especificar la fuente de texto !! );
..
..
Son esas pequeñas cosas las que en gemix/div hasta ahora no teniamos en cuenta pero que marcan la diferencia y mucho.

Con la 7.0 no era posible, como has dicho, pero ya con la 7.5 que ha salido es posible, la nueva API sirve para solucionar tambien estos problemas, como ya dije varias veces, la API de DIV es obsoleda y no adapta para las nuevas tecnologias, hay cosas que deben quedar, otras que deben desaparecer (almenos en la Modern).

El juego este del pinguino a Alice le va a costar sudar sangre para portarlo a android a 60 fps, aunque a 20 o así si es jugable ya sirve.. aunque ahora creo recordar que Alice dijo que no quería dejarlo a 60fps que funcionaba a un fps mas bajo creo.

No para tanto, lo que debe hacer (y lo que le sugerido) es que elimine de en medio los bloque FUNCTION y STRUCT, y usar los metodos y los TYPE's, que son mucho mas rapidos y flexibles, FUNCTION solo en caso de extrema necesidad, el coste que tendra, sera el cambio de API, da puro estilo DIV a mas moderno.
En todo caso el problema con la legacy era que el rendering era hecho por la CPU, con la modern va por GPU (gracias a OpenGL ES, etc...), per

Y lo que nos falta son los threads para poder procesar en segundo plano funciones demasiado costosas..

Imaginate que tienes una función en gemix que comprueba todas las colisiones y deja un flag en cada proceso indicando si colisiona con el player o no.. madre mia... son un montón de llamadas a overlap o collision o get_dist... PERO..

imagina que llamas a esta función con un thread y pones un gatillo a true.. y ahora pintas todos los procesos.. y al siguiente frame esperas simplemente a que la función que está con las colisiones te deje el gatillo a false y vuelves a pintar..

No para tanto, en realidad no se deberia utilizar mas de uno-dos threads, tambien considera que hay plataforma donde hay un maximo de 16 threads de ejecucion, ademas, utilizar mas threads de lo necesario puede portar a un decremento de la performance, en lugar de un incremento.

Estas pintando y comprobando colisiones a la vez.. y esto hace falta si o si en Android, aunque todos sabemos que Gemix está muy optimizado y que es bastante mas rapido que casi todos los demas DivLike, en android todo cambia y vamos a tener que cambiar la forma en que programamos nos guste o no jeje

Realmente habria aun posibilidad de hacer muchas optimizaciones en Gemix, pero de momento deberia poderse usar sin problemas.
Sobre lo de cambiar la forma, no para tanto, depende mucho dal juego, mas que de la plataforma en si.

[erkosone]

Te veo muy convencido de la potencia de Gemix en Adroid CicTec, esto es bueno, si lo tienes tan claro es que va a funcionar muy muy bien.
Haber cuando hay algo para probar código y vemos que tal anda

[shao]

¿Y por qué no hacerlo como un tablero o array? , de modo que los cubos solo sean procesos cuando se estén moviendo, para lo demás a base de puts.
Es decir, si el cubo va a moverse creas un proceso con el gráfico del cubo y lo mueves, cuando termine lo eliminas y haces un put.

También las colisiones, ¿es necesario comprobar colisiones a cada frame? ¿o se podría hacer cada dos frames?.

[erkosone]

Claro, es buena idea, hacer una cuadricula de tiles que se pinta al principio y solo los procesos que estan dentro de la region cero "pantalla" y en movimiento deberían crear un proceso.

[SimulatorOne]

Yo me pongo en la situación de Simulatorone y la verdad es que se me ponen los pelos de punta jeje.. este juego es muy guapo pero tiene un problema de base, cada cubo es un proceso, y eso en android no puedes hacerlo así.

Debe hacerlo asi, cada cubo tiene interaccion de colision con otros cubos y/o personajes/elementos en pantalla, no se puede permitir de crearse un sistema de colisiones en script cuando ya lo tiene nativo.

Solo los cubos en movimiento acivos, comprueban elementos solidos (esten quietos o en movimiento). uso overlap solamente.
El resto de elementos que estan quietos estan congelados S_freeze;

Escribes 30 textos en pantalla.. 15 con una fuente y 15 con otra fuente.. vale..
hasta ahora con gemix legacy no podias seleccionar la fuente de texto para pintar y luego simplemente pintar texto.. tenias que especificarla en cada llamada de screenDrawText()..

Se supone que ahora con la nueva versión que saldrá podras hacer:
setFont(fnt_1);
for(i=0; i<30; i++)
screenDrawText( !! aquí no especificar la fuente de texto !! );
..
..
Son esas pequeñas cosas las que en gemix/div hasta ahora no teniamos en cuenta pero que marcan la diferencia y mucho.

Con la 7.0 no era posible, como has dicho, pero ya con la 7.5 que ha salido es posible, la nueva API sirve para solucionar tambien estos problemas, como ya dije varias veces, la API de DIV es obsoleda y no adapta para las nuevas tecnologias, hay cosas que deben quedar, otras que deben desaparecer (almenos en la Modern).

la verdad es que mola mucho usar los typedefs , con solo mirar el ejemplo modern de:
_GMX_render_text.prg
_GMX_render_graphic.prg

El juego este del pinguino a Alice le va a costar sudar sangre para portarlo a android a 60 fps, aunque a 20 o así si es jugable ya sirve.. aunque ahora creo recordar que Alice dijo que no quería dejarlo a 60fps que funcionaba a un fps mas bajo creo.

No para tanto, lo que debe hacer (y lo que le sugerido) es que elimine de en medio los bloque FUNCTION y STRUCT, y usar los metodos y los TYPE's, que son mucho mas rapidos y flexibles, FUNCTION solo en caso de extrema necesidad, el coste que tendra, sera el cambio de API, da puro estilo DIV a mas moderno.
En todo caso el problema con la legacy era que el rendering era hecho por la CPU, con la modern va por GPU (gracias a OpenGL ES, etc...), per

Deje de usar functions, structs y hasta el clasico LOCAL.
Ahora ya empiezo a manejar los metodos y typedefs, y las publics de los procesos.

realmente estoy disfrutando de estos nuevos metodos de programacion, poco a poco voy practicando y aprendiendo.

[SimulatorOne]

Bueno, os dejo con un par de capturas de pantalla:

he decidido por hacer 2 versiones:
-Modern (Nos aprovechamos del filtro Liniear, algunos FX...)
-Legacy (por compatiblidad para PC/Portatiles que no soporten OpenGL 2.0+)

por el momento, creo poder hacer la version Legacy (parece una locura)
si o si, seguire haciendo la Modern. sin duda.

a todo esto:
el truquillo es jugar con el include:
Esta seria para Modern...

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• PROGRAM Penguin_PUSH;
• include "MODERN.prg";
• //include "LEGACY.prg";
• ...

Esta seria para Legacy...

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• PROGRAM Penguin_PUSH;
• //include "MODERN.prg";
• include "LEGACY.prg";
• ...

Naturalmente la version Modern, dispone de algunas características graficas extra: el que mas me gusta es el filtro Liniear.
Tambien transformaciones extras: por ejemplo usar: rotation.x y rotation.y :solo en Modern, en LEgacy no hace nada.

y bueno, nos dijo Cictec las diverencias entre los dos:
viewtopic.php?p=65577#p65577
gracias nos deja mas claro.

Realmente me resulta muy interesante desarroyar el juego, en version moderna en todo el codigo(sin usar funciones/variables "Alias" y Legacy), y despues ajustar la Legacy dentro del include(en lo que se pueda).

Legacy se pierde el filtro Liniear, las transformaciones extras y algunos FX mode... alguna función se debe adaptar.
todo eso se ajusta en el include "LEGACY.prg".

Sinceramente me gustaria que mi juego version LEGACY, fuera compatible con PC/Portatiles/Netbooks mas viejos, o los que usan GPU Intel,
o incluso usarlo en VirtualBOX instalando el paquete: Extension Pack(en modo prueba de errores) el driver Direct3D del paquete. sea en Windows XP/7 ...

Dejo las capturas de las diverencias graficas: Solo tengo programados los primeros menus.

Penguin-PUSH_07-03-2016_22.08.07.png

Penguin-PUSH_07-03-2016_22.01.53.png

Se puede apreciar en las estrellas de nieve de fondo:
Modern: se precia el filtro suavizado , la trasnformaciones de rotacion x ,y , z
Legacy: es justo lo contrario, se aprecia el dentado pixelado, solo pueden usar rotacion z. las demas no funcionan.


Mi CPU: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz
Consumo de CPU:
Modern 2,3%
Legacy 7,5%

Por acabar, seguire trabajando con ello, y por desgracia me he topado con algun bug de Gemix 7.5 extraño por el camino, voy reportando los bugs y cosas que me parecen que no funcionan.
Cictec me ayuda bastante.

Y aprendo mucho de uso de los Methodos, Typedefs, Publics...

Gracias.