Penguin PUSH [Pixtudio Android&Windows] Alpha

[alicesimu]

Ya va siendo hora que haga publico mi proyecto que llevo tanto tiempo si, incluso antes de usar pixtudio... etc etc...

Pido disculpas, por toda la parrafada que debo explicar, ya que tiene historia, para un juego sencillo. pero tiene mucho desarrollo...

Algunos de vosotros ya me conoceis de hace años, y algunos proyectos...

Hablare en concreto de uno muy viejo y esta en el Bennupack avanzado, llamado "PUSH".

PUSH, es un proyecto experimental para sacar el maximo partido al concepto de juego que viene del: "Pingu y No" de Div2 CD-Rom.
http://js.mikedx.co.uk/pingu.html
Sencillamente cuando di con este minijuego de Pingu y no, sabia que habia que sacarle aprobecho al concepto y sus personajes.


Realmente hice como 3 versiones llamado: "PUSH"
Este proyecto lo trabaje en 4 codigos Div: Div2, Fenix/BennuGD , [Pixtudio y Gemix]actualmente .

1ª version: PUSH de Div2,(Version niño pequeño) por los años 2004: fue el primero en tener un editor de zonas, sencillo. contenia modo Aventura con mapas editadas en serie.
90% del motor/codigo Pingu y No.
resolucion 640x480, 8bits a 10FPS
La primera en soportar 4 jugadores(compartir teclado 3 jugadores y un Gamepad 4º jugador)

2º version: PUSH Fenix/BennuGD para Wiz (La version menos seria y loca, la adolecente) 2010-2011
http://forum.bennugd.org/index.php?topic=1127.0
http://bennupack.blogspot.com.es/
resolucion: 320x240(Wiz)/640x480(windows), 16bits, 10FPS - 60FPS(Regulables de forma experimental)
Para Windows y GP32 Wiz
Para Windows tambien soporte multijugador a 4 pantallas divididas.
Se programó de 0, aun asi usando 80% del motor/codigo Pingu y No.
Solo contiene el modo Maraton sin fin, con mapas muy alocados de gran variedad de dificultad!!
No contiene ningun editor de zonas...
un monton de ajustes que te tirabas un buen rato revisarlas!! :o :o
El primero en usar sistema de particulas de sangre y charco
El Unico en usar Temas graficos, sonoros y musicales, para el juego. Contenia el tema basico PUSH y Torture Killer(Gore) opcional.
Modo Zoom, que se podia ajustar % de tamaño del zoom del juego, es muy experimental. :o :o :o :P
Un numero incontable de bugs en el motor, ya que el modo Maratón provocaba situaciones que el propio motor no es capaz de asimilar(no esta preparado).

3ª version: PUSH Gemix 6.5, Windows (Seguia siendo la version alocada, intentando ser mas estable) 2011
Contiene las mismas caracteristicas que la 2º version.
Pero contenia menos bugs y se elimino el codigo GP32Wiz.
usando 75% del motor/codigo Pingu y No.
Aun asi seguia igual de alocada version, aun abiendo serios bugs en el motor.
Se abandono el proyecto, por el alocado codigo,motor inestable....


4ª y última versión: Penguin PUSH Pixtudio y Gemix 7.5 [Windows y Android] (La version seria, madura 2016)
Estoy trabajando actualmente en ello, de hace como 1 año un poco mas.
http://penguinpush.co.nf/

En este proyecto, empecé a trabajar con Gemix, sobre 2015 en secreto, en 2016 empeze hacerlo mas serio.
Esta programado de 0 practicamente.
por decir que solo conservo el 1% del codigo original del Pingu y No. Solo para coger algun concepto basico como por ejemplo:

Code Select Expand

IF((X MOD 32)==0);
IF((Y MOD 32)==0);//SI TENEMOS UNA CORDENADA MULTIPLE 32
mantengo el nombre de algunas variables y nombre de proceso:

Code Select Expand


SWITCH (RAND(0,3));
  CASE 0: play_wav(s_desplaza1,0);END
  CASE 1: play_wav(s_desplaza2,0);END
  CASE 2: play_wav(s_desplaza3,0);END
  CASE 3: play_wav(s_desplaza4,0);END
END


Code Select Expand

o_bloque, o_jugador, o_enemigo, fuego, bonos.
n_arrastrados
HuboColision
y varaible de id de sonidos siguen siendo los mismos usados en PUSH.

Aun que al principio usaba la lista negra de o_bloque.
Esa lista negra SIEMPRE ha estado en todas las versiones PUSH y viene del Pingu y NO.
No me gusta la idea de esa lista limitada a x pinguinos que puede arrastrar, ademas de consumir bytes de memoria ram x bloque.

Graficamente 100% de 0 NUEVOS, graficos, fuentes, estilo, logo...
Los sonidos aun son de la vieja version de PUSH.

en el 2016, quise mas serio, mas con pies de plomo a la hora de programarlo.
La idea es llevarlo a un diseño más sobrio y moderno.
Al ser un proyecto serio, tenia que quitarme de tonterias de la serie PUSH.
Dejando claro sus modos, estilo grafico y diseño.
-1 jugador exclusivamente
-Diseño nuevo, Logo nuevo, Nuevo nombre.
-Modos de juegos: Aventura(Serie), Maraton(Infinito) y Niveles creados por el jugador/usuario.
-Reestructurar la jerarquía de menus, items, jugador...

Con Gemix pude hacerlo bastante bien, hasta un editor de Zonas hice con mucho esmero, bastante bueno.
Se considera el juego casi terminado, aun puede existir algunos bugs, Actualmente lo tengo pausado.







Hablamos de Aqui en BennuGD/Pixtudio:
Este año, hace poco tiempo decidi investigar, si es posible programar para Android.
Gracias a pixtudio pude hacerlo realidad.

Gracias a la comunidad del foro, me ayudaron para resolver mis problemas, reportar algun bug, y poder trabajar en este proyecto.
No es facil pasar el codigo de Gemix a pixtudio, he tenido que recortar muchas cosas.
No es copiar y pegar de golpe, NO.
Reviso linea por linea y poco a poco añado, y lo adapto...
lo que mas complejo me resulta ha sido el Marcador del juego, aparentemente es algo muy sencillo, pero debia adaptarlo lo maximo.

Por ejemplo no puedo Tintar tipo RGBscale un texto WRITE, para el marcador... Tambien para el propio jugador cuando coje algun powerup, crea un proceso con los mismos graficos que el personaje, y lo tinta rgbscale....
Pero aqui no es posible esas cosas...
Esto es lo maximo que he podido hacer:

Code Select Expand


SWITCH(inv_col);
CASE 2: f=GSCALE_B;end//bloques
CASE 3: f=GSCALE_R;end//pinguinos
CASE 4: f=GSCALE_RB;end//bloques + pinguinos
end

from i=1 to 9;
if(fpingufx[i-1]>999);map_unload(0,fpingufx[i-1]);end
fpingufx[i-1]=map_clone(0,RAZAS[0].fpingu[i-1]);
grayscale(0,fpingufx[i-1],f);
end

id_tonto[0].graph=fpingufx[id_jug.graph_f-1];


Solo he tenido que modificar un 15% del codigo para pasarlo de un lenguaje a otro.
los recursos graficos tambien cambiar el formato, y las FNT resolver la conversion del ASCII extendido, gracias a la tool FPG Editor V4 pude solucionarlo.
Decidi usar PNG en vez de usar FPG/MAP, por la razon de compresion principalmente para Android.
El Requisito para Android; es tener FPG/MAP/FNT sin comprimir, para que funcione.
La pega de eso, que pesa al 100% los graficos, sin comprimir, eso pesa mas a la hora de instalar la aplicacion en el dispositivo.

PNG siempre esta comprimido, y puede cargarlo en android, sin problema ahorrando espacio,cuando se instala la aplicación.


Resumiendo: este es el resultado:



Y me abri una cuenta(25$) desarrolladora de Google Play, para ir publicando la ALPHA Testing poco a poco:
https://play.google.com/store/apps/details?id=org.alisim1.penguinpushpix


Version 0.45:
Quiero explicar características técnicas actuales en Android:
-Controles tactiles: stick digital de 4 direciones + Boton de fuego azul
-Vibración en botones, explosion TNT y cuando te matan. (Se puede apagar y encender la vibracion)
-Pantalla rotativa 180º automatico.
-Pesa 10MB instalada la aplicación, solamente!
-Existe archivo de configuración, se puede borrar en "Datos" de informacion de la aplicación.
-Ancho de pantalla se autoajusta depende del aspecto ratio, previene que aparezca bandas negras sin usar.
-Boton "Atras"/"Menu", salimos del juego.

Caracteristica General de juego, Tanto en Windows y Android:
-Definicion de 480p a 60FPS 32bits. 16:9 panoramica.
-3 modos de Audio: Musica+Sonidos, Solo sonidos, OFF.
-Modo Maraton en fase pruebas(aun contiene algunos bugs de pintado de zonas)
-Enemigos de IA regulable (de los que solo se mueven a 4 direcciones, hasta los que empujan bloques por si mismos)
-Marcador operativo (aun contiene algun Bug)
-Se puede superar las zonas Maraton, contra mas alto el numero de Zona mas grande y dificultad hay.
-Es posible que sea imposible superar alguna Zona(no es accesible la Salida, no se puede matar algun pinguino...), carece del boton Saltar zona...
-Sistema de particulas(implementada) temporalmente apagada, para testing de rendimiento... (copos de nieve y particulas de sangre+charco)
-Existe mas de 1 salida en la zona, puede estar oculta debajo de algun bloque blando/movil
-Casi TODOS los elementos de juego Funcionan!
-Controles keyboards: Cursores o/y WASD Mover, Espacio o/y Enter = fuego, ESC/Alt+X = Salir del juego


Caracteristicas que FALTAN: Nueva version: En desarrollo..
-Rediseñar sistema de Menus
-Boton de Pausa: opciones de: Continuar, Saltar zona, salir
-Añadir mensaje mejorado de Game Over: Reiniciar, salir
-Añadir mensaje mejorado de Zona Superada: Siguiente Zona, salir
-Terminar de probar a fondo el Marcador, libre de bugs.
-[Actualmente]OPTIMIZANDO sistema de elementos en la Zona (Convertir procesos inmoviles en pintado en MAP)[GRAN AHORRO DE PROCESOS!!]
-Rediseñar sistema de pintado de Zonas Maraton(que funcione por numero de elementos, NO por % ya que a veces se olvida de pinguinos enemigos y salida(s))
-[Listo!]Implementado adicionalmente control con joystick/gamepad usb, Tambien soporte de keyboard para Android.

-------------------------------
Aclaraciones cuando programo con pixtudio para Android.
Este proyecto va dirigido para Android, si.
pero no quita que tambien funciona bajo Windows(seguramente para Linux tambien)
Por eso tiene implementado controles keyboards/mouse dentro del codigo Android.
La idea es dejar la version Android lo mas igual que Windows(Gemix).
Por que?
Este proyecto lo diseño para Android, principalmente. si tambien empaqueto esta version de pixtudio para windows, aqui... es un clon de la version movil, solo que solo funciona por keyboard/mouse/joystick.

Me gustaria que las zonas editadas con el Editor de Mapas, de la version Windows(Gemix), sea compatible, con esta de android. Tipo Mario Maker.
Creo que es posible. aun asi es muy pronto para ello.

Si la versión Android fuese mejor, algun dia que la Windows(gemix)... probablemente deje un lado esa.

??? ??? ??? ??? ???
Esto me hace cuestionar... eso decision mia, que div-like usar para plataforma Windows/linux....
Comparativas y pruebas hare, para saber cuál tiene mejor resultado, en rendimiento y gráficamente...

Me sabe mal tener que mencionar otro div-like que trabajado con este proyecto(está dividido en 2 realmente: Android(pixtudio) y Windows(pixtudio o gemix)).

Pido disculpas por el lio que he explicado, aun asi me gusta la experiencia para programar con pixtudio para android.

Sois libres de cuestionar mi organización con el proyecto.

[josebita]

Bueno, ¡menuda parrafada!

¡Felicidades por tu proyecto! Tiene muy buena pinta :)

Una cosa: dices que en pixtudio no existe eso de RGBscale. ¿Eso es modulación de color? Porque si lo es, puedes hacerlo mediante las locales modr, modg y modb de modulación del color, que van de 0 a 255.

Tienes un vídeo aquí:
https://vimeo.com/155582188

[Drumpi]

Yo no puedo criticar la parrafada por motivos obvios, pero mola ver cómo ha ido evolucionando.
Me encanta el lavado gráfico que le has dado al juego, está mucho mejor así que con los gráficos iniciales. Se nota que le has dedicado tiempo y cariño :)
Esperaremos a verlo terminado. Es uno de los juegos que tenía en mi GameGear (Pengo) y le tengo cierto cariño, y siempre he echado de menos aquella mecánica que tenía que, si empujabas la pared, esta "vibraba" y "atontaba" a los enemigos que hubiera pegados a ella (facilitaba mucho la vida, sore todo, cuando en el nivel 50 tenías que elimanr 20 enemigos :P).

[alicesimu]

no pretendo hacer un remake de pengo precisamente.

lo del royo de pegar el golpe en las paredes exteriores para atontar a los monstruos esos...
no lo tengo en mente.

El mio es como una lucha de pinguinos , no hay monstruos raros xD

[l1nk3rn3l]

excelente proyecto... ;D

[DCelso]

No se, a mi no me atrae mucho el juego, que no quiere decir que no esté bien.

Pero ... me gusta más la filosofía de kickle cubicle.

[Futu-block]

no es por ná pero me pido diseñar un nivel...
si se puede, claro

[alicesimu]

Bueno, ¡menuda parrafada!

¡Felicidades por tu proyecto! Tiene muy buena pinta :)

Una cosa: dices que en pixtudio no existe eso de RGBscale. ¿Eso es modulación de color? Porque si lo es, puedes hacerlo mediante las locales modr, modg y modb de modulación del color, que van de 0 a 255.

Tienes un vídeo aquí:
https://vimeo.com/155582188

Lo probare para usarlo en el marcador que controla el efecto de powerup sobre el personaje...

no es por ná pero me pido diseñar un nivel...
si se puede, claro

Si se puede, en la pagina web del juego, esta el acceso a la versión Windows, iras a parar a la otra comunidad al hilo del juego/editor.

El editor se incluye en versión Windows.
Esta avanzada y se puede probar lo editado como si fuese un Mario maker.

Los mapas guardados, se guaran en la carpeta independiente, estas se puede guardar para jugar después y compartir con añguien.

Tengo que programar que se pueda cargar estos mapas en la versión Android, se añadiría en la carpeta de almacenamiento externo.
Gracias al acceso de almacenamiento SD(aun que considera la interna)

Se llamaría contenido personalizando para el juego.
También se podrá añadir musica ogg personalizada.

[alicesimu]

Quieros hablaros del trabajo que estoy haciendo actualmente, me puse hace casi 2 dias...

-[Actualmente]OPTIMIZANDO sistema de elementos en la Zona (Convertir procesos inmoviles en pintado en MAP)[GRAN AHORRO DE PROCESOS!!]

Ha sido cambiar radicalmente casi todo el motor de los elementos en pantalla, tambien el funcionamiento de movimientos de los pinguinos y bloques (esos dos son los mas delicados de manejar)

En la version 0.45 usaban por procesos, todo cada uno de los elementos, aun que estubieran congelados s_freeze solo para pintar... pero claro... una zona de unos 15x15 aprox salian unos 150 processos como minimo... contando tambien con otros procesos secundarios del marcador y base(son unos 5-7)
Esto note el rendimiento en mi dispositivo movil que de 60FPS bajan a 45,30FPS.
Tuve que activar el frameskip de set_fps,  a 2.
LA version 45 usa frameskip de 2.

Pues hace 2 dias, decidi por optimizar, cambiar radicalmente el motor.
Quitandome de procesos...
Dejar lo minimo: pinguinos, bloques en movimiento(solo se mueven) y ese bloque congelador(que crece, atrapa cosas y tapa el camino).

El resultado fue:
de pasar de unos 150procesos...
a 15procesos aprox.
un ahorro de un 90%

y se nota el rendimiento.

YA uso menos el TYPE, para referirme algun tipo de proceso vivo, como los pinguinos y bloques vivos(movimiento)
evito usar collision a toda costa.
solo uso GET_DIST si fuese necesario.

casi nunca realmente, solo hago comprobaciones de ese tipo justo cuando es necesario.

meto muchos IFs para controlar cuando y como comprobar algo, aun que sea un color del mapa de durezas.

Por cierto uso 2 capas:
-durezas de altura bloque y items (los bloques pueden llevarse por encima los items)
-durezas de altura suelo - decorativas (placas de hielo, piedras, salida, punto de salida, sangre...)

Con esas 2 puedo controlar a la perfecion con quien tiene relacion cada elemento del juego.

Solo uso esas 2 MAP en memoria en tamaño pixel. si el mapa es de 15x15 es el tamaño del mapa.
DEspues hay el MAP de tamaño real a 32pixeles por cuadro, solo para pintar.

Enseño captura de pantalla, en modo DEbug y modo juego.
gracias a map_get_pixel y map_put_pixel y get_RGB puedo jugar con esos mapas.

[Drumpi]

Bueno, 150 procesos no me parece algo que sea alarmante, lo digo por experiencia :D
Wiz me está moviendo algo así... quizás menos, porque tengo el código del scroll tileado muy optimizado en ese aspecto, y apenas hay ralentizaciones. Y pintando a gráfico y usando el scroll de Bennu no he ganado mucha velocidad.

Pero sí, si puedes usar los tiles estáticos dibujados en un map, y usar procesos sólo cuando se mueven, mucho mejor (y más si usas una pantalla estática o un scroll con poco desplazamiento). Muy inteligente por tu parte.
Lo que ya no sé es si usar GET_DIST es más o menos rápido que medir la distancia por coordenadas (if (abs(x - prota.x) < 10)). Según la docmentación, hay una operación raiz cuadrada involucrada, y no es una operación que se realice en un ciclo de CPU (suele llevar muchos más, pero hablamos de centésimas de segundo). Habría que crear un código para comprobarlo.

Y también podrías probar si COLLISION_BOX te da un buen rendimiento o no. ¿Tanto consume la función TYPE?

[alicesimu]

Bueno, 150 procesos no me parece algo que sea alarmante, lo digo por experiencia :D
Wiz me está moviendo algo así... quizás menos, porque tengo el código del scroll tileado muy optimizado en ese aspecto, y apenas hay ralentizaciones. Y pintando a gráfico y usando el scroll de Bennu no he ganado mucha velocidad.

Pero sí, si puedes usar los tiles estáticos dibujados en un map, y usar procesos sólo cuando se mueven, mucho mejor (y más si usas una pantalla estática o un scroll con poco desplazamiento). Muy inteligente por tu parte.

Tenia miedo por abusar de tantos procesos, bajara los FPS y me viera obligada usar Frameskip.
Paso eso la verdad!
Y claro cada bloque movil comprobaba a cada uno de los bloques blandos y los Solidos inmoviles!!!

Cada pinguino(mas el jugador) tambien comprueba cada bloque, exsactamente igual que hace un bloque en movimiento.

Fue necesaria si o si, reemplantear el motor de bloques.

Lo que ya no sé es si usar GET_DIST es más o menos rápido que medir la distancia por coordenadas (if (abs(x - prota.x) < 10)). Según la docmentación, hay una operación raiz cuadrada involucrada, y no es una operación que se realice en un ciclo de CPU (suele llevar muchos más, pero hablamos de centésimas de segundo). Habría que crear un código para comprobarlo.

Y también podrías probar si COLLISION_BOX te da un buen rendimiento o no. ¿Tanto consume la función TYPE?

Sobre todo antiguamente, todo funcionaba por procesos, el impacto era mucho mayor.(como comente anterior mente, por uso de TYPE).

Actualmente: Procesos activos(vivos) cuando se mueven.
-Pinguinos enemigos, 1)comprueban mapa de colores, para durezas, bloques solidos y placa de hielo...
2) Solo tiene un if(id_jugador); que si el numero de identificado es 0, ya dejara de comprobar si el jugador se puede comprobar... para ver si estamos cerca GET_DIST(id_jugador)

-Pinguinos jugador, 1)comprueban mapa de colores, para durezas de bloques solidos, placa de hielo y items del suelo...etc

-Fuego azul, este lo crea los pinguinos... 1) comprueban el mapa de colores, si hay bloques blandos movibles que mover, Crea el proceso bloque movil activo, en la orientacion y tipo que es.
2) comprobacion: comprueba si existen bloques moviles (procesos uso type), si existieran, comprueba si esta cerca GET_DIST, de ser cierto, cambia la orientacion de movimiento de dicho bloque(efecto tenis).
Fase Beta Nº2.

-Bloques blandos moviles(SOLO moviles).
1)comprueban mapa de colores, para durezas de bloques solidos y items del suelo(se los carga esos items).
2)Comprueba si existen otros bloques moviles activos, si estan cerca, depende de la orientacion de ambos... se reposicionara o no...
Fase Alpha -> Beta(investigacion) Nº2
3)Comprueba si ha dado con algun pinguno enemigo(proceso type) o id_jugador(id) cerca de el, pero solo en la orientacion concreta, lo cazara, lo marca para ser arrastrado.(y futuramente muertos...).
Fase Beta de esta comprobacion Nº3.


-El resto de elementos visible; solo es pintado en un par de MAPs, 2 unicos proceso congelado s_freeze, solo para pintar en scroll la zona. Un Segundo MAP es para elementos del Suelo.
2 capas:
-Capa superior alto: Bloques (equivalente a la aultura de los pinguinos casi)
-Capa inferior suelo: placas de hielo, salida, items, piedras y efectos de particulas pinatadas(Sangre)

y 2 mini MAPs de durezas de colores RGB.(32bits)
-Capa superior: Son durezas, por bloques.
-Capa inferior: son para determinar que tipo de suelo pisa y el item conseguido.

-------------------------------

[Drumpi]

Pero si todos esos tiles móviles los metes en un array bidimensional, puedes saber su posición exacta y no necesitas usar get_dist, ni collision ni nada por el estilo. Además podrías usarlo de mapa de durezas, o si en lugar de guardar el ID en un int metes un type que definas tu, puedes almacenar el ID, un valor de dureza, e información extra que necesites. Y es posible que consultar ese array bidimensional sea hasta más rápido que MAP_GET_PIXEL :P

Pero vamos, eso es si andas corta de potencia. Si ya te funciona con el nuevo motor, sigue con él (a no ser que te aburras mucho y quieras ponerte a investigar y explorar :D ). Optimizar puede ser complicadísimo y requerir muchísimas pruebas que pueden no llevarte a nada ^^U

PD: obviamente, este esquema no te sirve para los bloques en movimiento, pero reduces el número de comprobaciones y cálculos, pues difícilmente tendrás más de dos o tres bloques en movimiento por jugador simultaneamente, en contraste de los posibles 150 que tenías antes :)

[alicesimu]

S pensé hacer esa tabla bidimensional durezas[][]
Y elegir el tipi de dato que necesitaría byte,word,int...

Pesa mas en memoria un map de 32bits rgba, que esa tabla bidimensional, claro

Solo que hay elementos del juego que tiene un atributo, una variable que almacena para saber el tipo de bloque, o el numero de casillas del bloque movilbe solido, o algún ítem en concreto.

No solo almacenar solo un numero de elemento que es menos del numero 255 con tipo byte tengo suficiente si.
Pero me falta la variable atributo del elemento.

[alicesimu]

Pero si todos esos tiles móviles los metes en un array bidimensional, puedes saber su posición exacta y no necesitas usar get_dist, ni collision ni nada por el estilo. Además podrías usarlo de mapa de durezas, o si en lugar de guardar el ID en un int metes un type que definas tu, puedes almacenar el ID, un valor de dureza, e información extra que necesites. Y es posible que consultar ese array bidimensional sea hasta más rápido que MAP_GET_PIXEL :P

Aah vale para procesos móviles!!
Pensaba que hablas de los que no se mueven.

En procesos móviles tenemos estos elementos
-bloques móviles(duros o blandos)
-pingüinos enemigo
-pingüino jugador

Los pingüinos se atraviesan entre si, no cambian de orientación si chocan con un compañero.
Cada raza de enemigo tiene una velocidad diferente:
2px x frame
2.1
2.2

Por ahora hay 3.
Me puede suponer un problema si deseo que los pingüinos se choquen entre si,no pudiendo dejar paso a cualquier pingüino. Es muy delicado controlar eso.
Aun así si todo se basa en una grilla de juego, y se sabe que todos los elementos están en x casilla,
Podría dejar de usar esos diminutos maps 32bits rgba, para solo usar arrays(me gusta llamarlos tablas) se ganaría mucho mas rendimiento y ahorro de memoria.

Sobre lo que se mueve si se podría controlar las posición es de cada proceso, por el array bidimensional, para saber en que casilla esta realmente, pero desconoce los píxeles reales de desplazamiento... Pero creo que no importa eso ultimo.

Para lla bloques que se mueven debe comprobar si hay otro bloque cerca concretamente en menos de 32pix, se considera colisión y se reposicióna o incluso cambia de orientación depente del atributo del bloque.
Siguiendo hablando del bloque en movimiento, creo que seria muy factible comprobarlo por array bidimensional, me ahorraría dolores de cabeza para programar la lógica de posiciones y orientación de ambos bloques que se han chocado y reposicionarlos correctamente.

También para cuando el bloque pilla un pingüino, tambien puede usarlo...
Y si un pingüino se topa con un bloque que se mueve en horizontal, pero el pingüino esta subiendo, se considera un muro solido y topa con un bloque que estaba pasando por delante del pinguino., como de un autobús fuera.

El pingüino enemigo mataría al jugador, si se encuentra en la misma casilla, así de sencillo.

Estos días me planeare de re-mejorar el sistema, dejando de lado esos 2maps de durezas. Y programarlo por array bidimensional.
Y poco a poco implementarlo por array el control de colisiones entre bloques y pingüinos. Y evitar usar type, mal_get_pixel get_rgb mal_put_pixel.

Es bastante interesante tu teoría, investigare.

Por cierto no se usar los datos de tipo TYPEque declaras arriba con global,local...etc
Tampoco se usar las PUBLICS parece una fusión de local y private.
Me cuesta entender su funcionamiento y beneficios.

Aun estoy a la antigua con uso de structs, local. De forma tradicional div2.

[Drumpi]

Bueno, y me refería más a meter los tiles (móviles o no) en un array bidimensional. Bueno, yo te dejo la idea y luego tu la valoras :D

Si quieres crear un tipo definido por tí, tienes que usar TYPE de la misma manera que usas STRUCT con dos diferencias: no puedes crear un array con el tipo directamente (es decir, puedes hacer STRUCT mi_struct[3], pero no hacer TYPE mi_type[3]), y debe declararse antes de cualquier tipo de variable, fuera de las zonas de declaración de variable.
Te pongo un ejemplo:

Code Select Expand

PROGRAM test_type:

type mi_tipo    //declaración de tipo
    int id_proceso;
    byte atributo;
    byte dureza;
end

GLOBAL
    mi_tipo array_de_tipos[3][4];    //Creo un array bidimensional usando mi_tipo
END

LOCAL
END

PRIVATE
END

process proceso_tile()
begin
    signal(id, s_freeze); frame;
end

BEGIN
    //Guardando un valor en una variable
    mi_array[2][1].id_proceso = proceso_tile();
    mi_array[2][1].atributo = 3;
    mi_array[2][1].dureza = 1;
END


Así, tu tipo puede contener tantos datos como quieras, de cualquier tamaño, incluso puedes definir arrays dentro del tipo. Antiguamente se usaban arrays de INTs o de BYTEs y se usaban máscaras de bits para almacenar, por ejemplo, el número de tile en los tres primeros bits, la dureza en los dos siguientes, y los atributos en los restantes. Aquí puedes definir tu tipo como 4 bytes y guardar una cosa diferente en cada una sin marearte con números binarios ;)

Las variables públicas son básicamente variables privadas que se pueden leer desde cualquier proceso, pero no las uso porque entonces, el ID del proceso, en lugar de guardarlo en una variable de tipo INT, debe guardarse en una variable cuyo tipo es el nombre del propio proceso que quiere almacenar. Es por un problema interno de Fenix a la hora de direccionar la memoria al espacio de las variables públicas.[/code]