Test de mi gameEngine en processing.

Todo aquello que no está relacionado con Gemix Studio ni con la programación DIV en general.

Re: Test de mi gameEngine en processing.

Postby erkosone » Wed Jun 27, 2018 7:09 am

Hokuto gracias por recordarme lo del flikering en los sprites con las colisiones, ya lo he arreglado.

Lo que me pasaba era que cuando hacia un signal(id, s_kill); eliminaba el sprite de la lista de sprites , pero claro.. la lista se acorta en 1.. y el ultimo sprite de la lista no se renderizaba XD..

He tenido que modificar el core para que primero haga un barrido y borre los sprites que mueren y luego otro barrido para que renderize y arreglado! gracias tio!
Ahora queda mucho mejor jeje..

Estoy liado con el motor de scroll para poder hacer una nueva demo de otras funciones. ;)
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en processing.

Postby OskarG » Wed Jun 27, 2018 8:17 am

Cuando lo tengas pulido el engine si ves que es competitivo ,me haría una página propio y cuidaría de que el potencial de viera fácilmente ,donde cada función tiene su ejemplo tipo div o phaser e incluir minijuegos ya creados en otros engines ,sin complicarse la vida ni tener que hacer los gráficos....
User avatar
OskarG
 
Posts: 612
Joined: Tue Jan 12, 2010 2:12 am

Re: Test de mi gameEngine en processing.

Postby Hokuto7 » Wed Jun 27, 2018 3:35 pm

De nada erkozone,pero mejor en español que he tenido que buscar esa palabrita y no sabia lo que me estabas diciendo :lol:

Cictec ya tengo la prueba de rendimiento de gemix y me ha decepcionado un poco,pongo el codigo que he usado y explico todo.
Code: Select all
       program prueba_velocidad;

global
   int fuente,graficos,mi_jugador,mi_enemigo;
end
//proceso principal--------------------------------------
begin
   mode_set(640,480,32);
   set_fps(60,0);
   fuente = load_fnt("fuente.fnt");
   graficos = load_fpg("graficos.fpg");
   file = graficos;
   graph = 4;
   tiled = 1;
   mi_jugador = jugador();
   write(fuente,38,16,4,"fps:");
   write(fuente,84,16,4,&fps);
   loop
      //salir
      if(key(_esc))
         exit("salir",0);
      end
      enemigo();
      frame;
   end
end
//jugador------------------------------------------------
process jugador()
private
   int velocidad = 5;
end
begin
   file = graficos;
   graph = 1;
   x = 320; y = 420;
   loop
      graph = 1;
      //movimiento
      if(key(_left) and x > 32)
         x -= velocidad;
         graph = 2;
      end
      if(key(_right) and x < 608)
         x += velocidad;
         graph = 3;
      end
      if(key(_up) and y > 32)
         y -= velocidad;
      end
      if(key(_down) and y < 448)
         y += velocidad;
      end
      frame;
   end
end
//enemigo------------------------------------------------
process enemigo()
private
   int velocidad = 2;
end
begin
   file = graficos;
   graph = 5;
   x = rand(32,608); y = 96;
   loop
      angle = fget_angle(x,y,mi_jugador.x,mi_jugador.y);
      //mover
      if(y < 340)
         //y++;
         advance(velocidad);
      end
      frame;
   end
end


El codigo lo que tiene es una nave jugador que se puede mover,un fondo y una nave enemiga que se desplaza hacia la nave del jugador hasta un limite y hay se para.

He hecho muchas pruebas,eliminando los enemigos,sin eliminar los enemigos,a 60 fps,a 30fps,con la funcion advance y fget_angle,sin la funcion fget_angle.Te pongo los resultados:

------------------------------------------------------------------------------------------------------------
-sin eliminar de enemigos y con fget_angle,advance

30 fps = 16 segundos y despues caen los fps y 520 enemigos aproximadamente
60 fps = 5 segundos y despues caen los fps y 270 enemigos aproximadamente

-con eliminacion de enemigos y con fget_angle,advance

30 fps = estable siempre
60 fps = baja a 50 y se queda siempre en 50 y 270 enemigos aproximadamente

-sin eliminar enemigos y sin fget_angle,advance

30 fps = 55 segundos y despues caen los fps y 1700 enemigos aproximadamente
60 fps = 13 segundos y despues caen los fps y 850 enemigos aproximadamente

-con eliminacion enemigos y sin fget_angle,advance

30 fps = estable siempre
60 fps = estable siempre
----------------------------------------------------------------------------------------
Me parece curioso que placas recreativas de los 90 como la cps 2,neo geo,cave etc..
Estas placas tienen procesadores que van a 12 mhz,y pueden poner graficos enormes y poner un moton de objetos en pantalla y todo se mueve muy fluido.

Sin embargo los super pc de hoy en dia,cuando intentas hacer algo similar a los juegos de esas placas ,se van arrastrando por el suelo porque no pueden mover tanto objeto,no entender :blind:
Last edited by Hokuto7 on Wed Jun 27, 2018 7:38 pm, edited 1 time in total.
User avatar
Hokuto7
 
Posts: 1397
Joined: Mon Aug 28, 2017 10:14 am

Re: Test de mi gameEngine en processing.

Postby Hokuto7 » Wed Jun 27, 2018 3:41 pm

erkosone wrote:
Estoy liado con el motor de scroll para poder hacer una nueva demo de otras funciones. ;)


Muy bien,pero no hagas otro video,si vas hacer algun tutorial,mejor algo basico y empezando desde el principio,porque todavia no se por donde meterle mano a la libreria. ;)
User avatar
Hokuto7
 
Posts: 1397
Joined: Mon Aug 28, 2017 10:14 am

Re: Test de mi gameEngine en processing.

Postby CicTec » Wed Jun 27, 2018 6:01 pm

Hokuto7 wrote:De nada erkozone,pero mejor en español que he tenido que buscar esa palabrita y no sabia lo que me estabas diciendo :lol:

Cictec ya tengo la prueba de rendimiento de gemix y me ha decepcionado un poco,pongo el codigo que he usado y explico todo.
Code: Select all
       program prueba_velocidad;

global
   int fuente,graficos,mi_jugador,mi_enemigo;
end
//proceso principal--------------------------------------
begin
   mode_set(640,480,32);
   set_fps(60,0);
   fuente = load_fnt("fuente.fnt");
   graficos = load_fpg("graficos.fpg");
   file = graficos;
   graph = 4;
   tiled = 1;
   mi_jugador = jugador();
   write(fuente,38,16,4,"fps:");
   write(fuente,84,16,4,&fps);
   loop
      //salir
      if(key(_esc))
         exit("salir",0);
      end
      enemigo();
      frame;
   end
end
//jugador------------------------------------------------
process jugador()
private
   int velocidad = 5;
end
begin
   file = graficos;
   graph = 1;
   x = 320; y = 420;
   loop
      graph = 1;
      //movimiento
      if(key(_left) and x > 32)
         x -= velocidad;
         graph = 2;
      end
      if(key(_right) and x < 608)
         x += velocidad;
         graph = 3;
      end
      if(key(_up) and y > 32)
         y -= velocidad;
      end
      if(key(_down) and y < 448)
         y += velocidad;
      end
      frame;
   end
end
//enemigo------------------------------------------------
process enemigo()
private
   int velocidad = 2;
end
begin
   file = graficos;
   graph = 5;
   x = rand(32,608); y = 96;
   loop
      angle = fget_angle(x,y,mi_jugador.x,mi_jugador.y);
      //mover
      if(y < 340)
         //y++;
         advance(velocidad);
      end
      frame;
   end
end


El codigo lo que tiene es una nave jugador que se puede mover,un fondo y una nave enemiga que se desplaza hacia la nave del jugador hasta un limite y hay se para.

He hecho muchas pruebas,eliminando los enemigos,sin eliminar los enemigos,a 60 fps,a 30fps,con la funcion advance y fget_angle,sin la funcion fget_angle.Te pongo los resultados:

------------------------------------------------------------------------------------------------------------
-sin eliminar de enemigos y con fget_angle,advance

30 fps = 16 segundos y despues caen los fps
60 fps = 5 segundos y despues caen los fps

-con eliminacion de enemigos y con fget_angle,advance

30 fps = estable siempre
60 fps = baja a 50 y se queda siempre en 50

-sin eliminar enemigos y sin fget_angle,advance

30 fps = 55 segundos y despues caen los fps
60 fps = 13 segundos y despues caen los fps

-con eliminacion enemigos y sin fget_angle,advance

30 fps = estable siempre
60 fps = estable siempre
----------------------------------------------------------------------------------------
Me parece curioso que placas recreativas de los 90 como la cps 2,neo geo,cave etc..
Estas placas tienen procesadores que van a 12 mhz,y pueden poner graficos enormes y poner un moton de objetos en pantalla y todo se mueve muy fluido.

Sin embargo los super pc de hoy en dia,cuando intentas hacer algo similar a los juegos de esas placas ,se van arrastrando por el suelo porque no pueden mover tanto objeto,no entender :blind:

Hola Hokuto7,

Gracias por el test....

Por lo que veo el juego va creando indefinitamente siempre enemigos, cada uno ejecutando determinado codigo, el test deberia pero indicar el numero de enemigos creados hasta que se produce la caida, por favor podrias modificar algunas partes del test en el siguiente modo:
Source Code (Gemix) [ Download ] [ Hide ]
  • global
  •         int fuente,graficos,mi_jugador,mi_enemigo;
  •         int num_enemigos;
  • end
  • //proceso principal--------------------------------------
  • begin
  •         mode_set(640,480,32);
  •         set_fps(60,0);
  •         fuente = load_fnt("fuente.fnt");
  •         graficos = load_fpg("graficos.fpg");
  •         file = graficos;
  •         graph = 4;
  •         tiled = 1;
  •         mi_jugador = jugador();
  •         write(fuente,38,16,4,"fps:");
  •         write(fuente,84,16,4,&fps);
  •         write(fuente,48,16,3,&num_enemigos);
  • ....
  •  
  •  
  • //enemigo------------------------------------------------
  • process enemigo()
  • private
  •         int velocidad = 2;
  • end
  • begin
  •         num_enemigos++;
  •         file = graficos;
  •         graph = 5;
  •  


Y de aqui repetir los tests ? porque asi esto imprime en pantalla el numero de procesos que se encuentran en ejecucion hasta que se produce la caida (o no).

Sobre los viejos hardware, tienes en cuenta que estaban programados en assembly y se difrutaba hasta las narices el minimo pelin de potencia de la maquina, hoy los engines modernos desperdician muchos FPS para hacer calculos innecesarios por el tipo del juego o porque son implementados en modo ineficiente, perdiendo de hecho toda la potencia de la maquina, si haces el mismo juego en assembly el resultado seria 100 veces mejor, asi que no debes maravillarte de eso.
User avatar
CicTec
 
Posts: 16554
Joined: Thu Jul 31, 2008 10:18 pm

Re: Test de mi gameEngine en processing.

Postby Hokuto7 » Wed Jun 27, 2018 7:44 pm

Cictec, he actualizado la informacion con lo que me pedias,tambien he probado poniendo set_fps(30,1) y set_fps(60,1),es decir ,poniendo 1 en el segundo paramentro y gracias a esto se duplica los resultados,es decir ,que los enemigos se multipilcan por 2.

Y lo de los juegos antiguos,sabia que se utilizaba assembly,pero lo curioso es que con el tiempo en vez de ir para adelante vamos para atras,porque no se inventa un nuevo lenguaje para aprovechar los ordenadores actuales .
User avatar
Hokuto7
 
Posts: 1397
Joined: Mon Aug 28, 2017 10:14 am

Re: Test de mi gameEngine en processing.

Postby erkosone » Wed Jun 27, 2018 7:58 pm

los juegos retro de las recreativas eran en 16 bits, y aunque mucha gente no lo sabe.. estaban acelerados por hardware, existia algo llamado "blitter" que era un chip que se dedicaba esclusivamente al volcado grafico de los sprites en un canvas o "mapa de memoria" y tenian varias instrucciones.

Hoy en dia nos pensamos que un arcade retro como neogeo era pura CPU y eso no es así. Tenian su blitter que es el antepasado de las actuales GPU.

Estos blitters eran muy potentes para la epoca ya que estaban especializados en toracion de matrices y movimiento de bloques de memoria muy eficientes, lo que hacia posible los scroll y los efectos que vemos en las arcade que son alucinantes, pero no nos engañemos, era acelerado por hardware jeje..
User avatar
erkosone
 
Posts: 10654
Joined: Tue Feb 24, 2009 2:13 pm
Location: Barcelona.

Re: Test de mi gameEngine en processing.

Postby DoZ » Wed Jun 27, 2018 8:41 pm

Interesante lo que comentáis de la aceleración de las arcade. Yo en mi ignorancia siempre pensé que sencillamente eran placas basadas en mucha ram y CPU y diseñadas solo para esos motores. En parte no me equivocaba, pero no tenía ni idea de que era una aceleración por hardware. La verdad es que la suavidad de los scrolls, el mover esos sprites enormes y cargarlos con tanta soltura era acojonante para la época.
User avatar
DoZ
 
Posts: 416
Joined: Thu Apr 08, 2010 11:16 pm
Location: Buscando el Big Whoop

Re: Test de mi gameEngine en processing.

Postby CicTec » Wed Jun 27, 2018 11:07 pm

Hokuto7 wrote:Cictec, he actualizado la informacion con lo que me pedias,tambien he probado poniendo set_fps(30,1) y set_fps(60,1),es decir ,poniendo 1 en el segundo paramentro y gracias a esto se duplica los resultados,es decir ,que los enemigos se multipilcan por 2.

Gracias, luego los analizare con un poco de calma y en caso te comentare indicare otro.

Hokuto7 wrote:Y lo de los juegos antiguos,sabia que se utilizaba assembly,pero lo curioso es que con el tiempo en vez de ir para adelante vamos para atras,porque no se inventa un nuevo lenguaje para aprovechar los ordenadores actuales .

Porque no es posible, es la diferencia que pasa entre un ser humano y una maquina, el ser humano entiende por medio de palabras, numeros, frases, etc... la maquina solo entiene secuencias de 0 y 1, por ende, mas alto es el nivel del lenguaje para facilitar el humano, mas es el trabajo que debe hacer la CPU para una misma cosa, mas se acerca el lenguaje a la maquina, mayor es la dificuldad para realizar algo para el ser humano, te hago un ejemplo muy basico, toma un lenguaje como C/C++/Java/Gemix o cualquier de esos similares y haz una simple operacion de adicion donde tomas dos valores de variables A y B y los asignas a otra llamada C, qual es la istrucion ? pues:
Source Code (Gemix) [ Download ] [ Hide ]
  • c = a + b;
  •  

Muy simple no, para un ser humano, ahora escribimos la misma operacion en Assembly que es el lenguaje mas cercano a la maquina (o sea istrucciones que la CPU tiene incorporadas y entiende y que luego traduce da pseudo-nombres a numeros, hasta secuencia de 0 y 1):
Source Code (Gemix) [ Download ] [ Hide ]
  • mov eax, dword ptr [a]  # ordena a la CPU de coger el valor de la locacion de memoria nombrada "a" y memorizarlo en el regitro EAX de la CPU
  • mov ecx, dword ptr [b] # ordena a la CPU de coger el valor de la locacion de memoria nombrada "b" y memorizarlo en el regitro ECX de la CPU
  • add eax, ecx # ordena a la CPU de coger el valor del registro EAX y sumarlo con el valor del registro ECX y el resultato memorizarlo nuevamente en el registro EAX
  • mov dword ptr [c], eax # ordena a la CPU de coger el valor memorizado en el registro EAX y memorizarlo en la locacion de memoria nombrada "c"
  •  

Los comentarios despues el # indicano la operacion que comple cada istrucion, eso que he escrito es un formato assembly de sintaxis intel para procesadores con architectura x86 (32bit), y cada architectura o tipo de sintaxis puede variar de CPU a CPU.

Mira eso, ahora piensa a hacer un simple juego del pong en un lenguaje de alto nivel o medio nivel como el C o hacer el equivalente con el assembly con este nivel de sintaxis... mañana cuando te pasa el dolor de cabeza generado me contestas.
User avatar
CicTec
 
Posts: 16554
Joined: Thu Jul 31, 2008 10:18 pm

Re: Test de mi gameEngine en processing.

Postby Hokuto7 » Thu Jun 28, 2018 11:15 am

Cictec,para eso estan los ingenieros,para hacer un motor con assembly y luego los demas que hagan los juegos con el motor de una manera sencilla.

Erkozone,ya sabia que estas placas tenian chip de video dedicado.Las consolas tambien lo tienen,de hecho la megadrive,mastersistem,super nintendo etc..,tambien lo tienen y para mas informacion la nintendo y super nintendo se les añadia chip extras en los cartuchos para mover algunos juegos.

El super mario world 2 tiene un chip para mover 3 d y el street figther alpha 2 de la super tienen un chip que es un nuevo procesador para mover el juego y la nes tiene un chip de sonido que se le añadio al castlevania 3 y si buscas informacion veras la cantidad de juegos que usan chip extras.

La tecnologia japonesa estaba a años luz de la americana y europea,fijate que mucha gente flipaba con el commodere amiga en su epoca y en esa misma epoca habia un ordenador japones que estaba a años lus del amiga,el ordenador es el sharp x68000,busca videos o mejor prueba el emulador porque vas a flipar con juegos como el stree figther 2 o final fight,es una pena que la tecnologia japonesa se cambiara por la americana.
----------------------------------------------------------------------------------------------------------------
Comentar que ya a salido la inscripcion para el examen de correos,por lo tanto ya quedan 2 o 3 meses para el examen y ahora tengo que estar al 100 % estudiando.

Estare menos activo en el foro durante unos meses hasta que acabe el examen,pero seguire de cerca el progreso de gemix y gamelibzerojs. :)
User avatar
Hokuto7
 
Posts: 1397
Joined: Mon Aug 28, 2017 10:14 am

PreviousNext

Return to Offtopic

Who is online

Users browsing this forum: No registered users and 22 guests