[GAME] Super SMASH KeI

[SimulatorOne]

lo hare poco a poco, por diferentes campos.
pero valla sin prisas, para poder pensar bien.

De momento me esta quedandome chulo.

Si quieres probar algo, existe esto:
SMT-Remake-Menuv1.rar - 4.55 MB
http://www.mediafire.com/?fs5dke15e7c1290

Es como tengo creado actualmente el menu principal, y el sistema de texto historietas, pero valla le falta el contenido.
Y aun no esta terminado, pero si en esa ocasion publico el PRG no contiene ningun pasword.

Y aqui: http://www.gemixstudio.com/forums/viewt ... 073#p23073
Es lo mismo que tiene Lolita Land, pero con el extra de ser de otra tematica , ademas de agregar mas animaciones y poses.
+ extra de las pelotas XD

[SimulatorOne]

Programando de nuevo en la parte de los cuerpos humanos...

Esta vez e decidido por NO usar SPRITES generados, si es aquello que tenemos que esperar unos segundos para que nos genere los Sprites.
Ademas los Sprites es algo engorroso de gestionarlo.

Pues ya e conseguido que en vez que guarde un file.fpg con un monton de sprites....
Ahora solo guarda un file.fpg SOLO y SIEMPRE con 11 graficos, ni uno mas, ni uno menos!!
En esos 11 graficos se almacena las partes del cuerpo de la persona, y ya viene montadas.
Si mira, exsactamente guarda estos graficos, y SOLO estos!

Ademas estan recortados (Trim, como el MAP Editor)
Conservando el punto central del eje de angulo.



Esta pruebas de momento las hago en 32bits...
en 16 bits, hay cosas que se pierden por ejemplo el efecto del pelo.

Despues programare un sencillo test de como debe montar esta piezas, usando la estrucura osea + poses +animaciones.
De momento lo pondre en pantalla 2D plano, despues usare un Scroll 2D
y finalmente el Modo7.

Siempre es mas rapido el 2D plano(sin scroll), que antes un scroll.
Y es mas rapido un SCroll que un modo7.

Lo que intento es equilibrar entre: calidad grafica(16,32bist) y Rendimiento(FPS)


-------------
Termine de programar de manera exitosa el cuerpo compuesto de solo 11 processos/graficos.
Y funciona muy bien.


Perdonad por la captura, pero de momento lo estoy probando sin scroll y sin modo7.
Y me da 60FPS constantes.

Ahora me queda pulir el codigo de gestion de poses,animaciones y osea por cada persona, ya que solo actualmente estaba pensado para 1 persona solamente.

[CicTec]

Buen avance, sigue asi.

[SimulatorOne]

Puliendo MAS el codigo, para reducir la carga pesada de: cantidad de graficos cargados en memoria, processos
Hasta resolucion de pantalla!


Esta captura es de tamaño REAL en pixeles: 640x400 a 32bits.
(aun debo ajustar la posicion de los 2 botones de la herramientas,LOOK y FULL EDITOR)

Pues ahora TODO el Editor completo(Salvo el EDC-Wizard el editor de conjuntos) Todos utilizan el MISMO cuerpo, es decir
El mismo numero de processos minimos 11, y solo 11.

antiguamente creaba hasta 33 processos, uno encimas de otros,(prenda por prenda,piel,boca,ojos...etc)

ahora lo que hace es hace la conversion, el montaje de todas esas piezas de cuerpo(prenda por prenda,piel,boca,ojos...etc)
Crea(o carga) en memoria un FPG con solo 7 graficos, SI 7 y solo 7
Antes eran 11.
Con 7 es lo mas minimo!!Miren:


Lo que si, NO estan recortados automaticamente, por que si activo el recorte, tarda casi 1segundo en crearlos.
Si lo desactivo es mas que INSTANTANEO!!SUPER RAPIDO!

Esa pantalla de Espera, cuando le damos a TEST ya no existe, Prepara el modo7 de manera directa y aprobecha que ya esta cargado el FPG del personaje para solo crear solo 11 processos.

En memoria ram muuuuy poca, en CPU consume un poco mas que no el metodo sprites.
pero lo estoy calibrando...

Parece que la resolucion de 640x400(Panoramico) parece ir siempre a 30FPS (eso estando en modo TEST modo7)
Os parece bien que reduzca la resolucion de juego? de antes de usar 1024x600 ->>>> 600x400 (sin ningun filtro)
Y pensad que ya NO son sprites, es puro calculos matematicos, usando files de: Estructura osea,poses y animaciones.
Tiene muuuchas ventajas este sistema, ya que permite modificar 1 parte concreta del cuerpo y obtener todos los detalles de una parte.
Ademas se puede programar que se puedan mutilar , si le dan con una hacha o algo bestia.

O quien sabe!
si fueran robots, no humanos, son capazes de ROBAR piezas a OTROS ROBOTS, y REMPLAZARlas por las suyas.
CREANDO un robot MIXTO y diferente!
Es lo bueno de usar piezas.

Hay algunos juegos antiguos 3D de la epoca(2003) de: PS1,N64 y DreamCast que usan ese sistema de "Piezas" en un cuerpo humano(o robotico)
Y tiene ventajas, pero tambien tiene desventajas (fallos graficos)

Un ejemplo: ONI (PC y PS2)


Admiro mucho a este juego, por que tiene "esa" cosa que te da "esa" libertad de movimientos.
cominando controlotes de 3ª persona, tipo GTA3....

un ejemplo antiguo: Cyborg Justice (Megadrive)

Aun que os parezcan sprites, tengo la sospecha de que usa "piezas" para mover e interactuar con los movimientos del robot.
Y sí, existe una manera de Robar un brazo al rival y remplazarlo por tu brazo. Eso me llamo mucho la atencion.(y hay más)
Me gusto mucho este juego cuando era niño, me viecie mucho a ese juego.
Pero lo considero dificl de controles(da la sensacion de ser pesados y lentos)
Lo bueno que solo se utiliza 3 botones para jugar y la cantidad de movimientos que posee.

--------------
volviendo al proyecto:

Aun tengo que terminar de pulir el codigo que monta y genera esos 7 graficos de las partes humanas que os enseñado anterior mente.
Por que aun tiene esa cosa al cual lo usaba como metodo de "capturar" los graficos, usando los 33 processos, y es solo para capturar.
Pero creo y pienso que NO es necesario crear ningun processo, eso permite que se pueda generar los 7 graficos aun mas rapido que lo actual.
Actualmente creo que tarda unos 0.700milesimas de segundos en crearlos(aproximadamente) eso en un notebook.
Si pulo ese codigo, prodria reducir esas milesimas de segundos, y asi sufrir menos el kore(el corazon) de Gemix, para crear operaciones y processos inecesarios, ademas de variable y tablas que sobran.

Tambien puedo ganar mas optimizacion de animacion y jugabilidad, (cuando estamos en modo7)
Si pulo y gestiono de manera mas optima la manera de organizar "esa" galeria de poses y animaciones que usarian los personajes a lo largo del juego, esto lo mantiene en memoria los que mas se usan, las animaciones especiales poco usadas, lo cargaria directamente(el file) y lo añade en la galeria de poses y animaciones en memoria (es una struct)
Tendrá un limite de el numero de poses y animaciones que se puede llegar almacenar en memoria, con 9 a la vez, es suficiente.
Por que no es bueno que en cada movimiento este cargando el file, pose o animacion para mover el personaje....
eso percute el rendimiento de Gemix, es usar constantemente funciones de LOAD() para cargar los datos de una pose o animacion.
Actualmente Aun lo tengo, asi, lo sorprendente que aun no noto que percute el rendimiento.... pero aun asi, no me quedo tranquilo y prefiero ser detallista y perfecionista en lo posible.

----------------------------------------------------------------------
Sugerencia: Para Optimizacion de los datos, al compilar:
Estaria bien que hubiera una manera alternatiba de compilar un programa y que te liste; las varialbes,tablas y estructuras, funciones y processos que no se usan, o no se usaran en la ejecucion del programa.
Esto evita que consuma mas memoria ram, por culpa de varialbes y datos que jamas se usaran.
se puede decir que son variables,tablas y datos struct, hasta funciones y processos :
Avandonados y que jamas seran usados.

Que mas adelante lo usaremos? ,si seguro.
Pero esta claro que actualmente no lo usara...hasta que llege el dia que le demos uso dentro de la ejecucion.

Lo que no me parece bien que carge y cree en memoria un .exe con datos que jamas usaria en la ejecucion del programa.
Variables que jamas usara, solo estan para ocupar memoria expresamente.

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• Program test_mem;
• global
• int mi_variable[10];
• int mi_variable2[10];
• begin
• from x=0 to 10;
• mi_variable2[x]=rand(0,100);
• end
• //realizo los calculos que quiera
• //y jamas llamo e inserto esta tabla mi_variable
• end
•  

Lo que quiero decir con esto, es que la tabla int mi_variable[10];
y que en NINGUN MOMENTO LO USAMOS la tabla mi_variable[10]
Solo esta asignado "ahí" y ese "ahí" esta ocupando memoria SIN USO, solo ocupando memoria.
Estaria bien que a la hora de compilar y crear el .exe que SOLO añadiera DATOS Funcionales,
Es tonteria Añadir variables,tablas ... funciones y processos que JAMAS SERAN LLAMADOS en la ejecucion.exe.
Lo unico que hace es ocupar memoria RAM y puede que perjudique a la ejecucion....

A veces no ha pasado que tenemos tantos variables, estructuras y tal, que no sabemos con exsactitud si los estamos usando para alguna parte del codigo funcional.

Hasta algun processo o funcion, podemos dejarlo solo y nunca llamarlo en ninguna parte del codigo.

Yo creo que se gana mas memoria ram y un performance de gestion. a la hora de ejecutar.

[CicTec]

Puliendo MAS el codigo, para reducir la carga pesada de: cantidad de graficos cargados en memoria, processos
Hasta resolucion de pantalla!


Esta captura es de tamaño REAL en pixeles: 640x400 a 32bits.
(aun debo ajustar la posicion de los 2 botones de la herramientas,LOOK y FULL EDITOR)

Pues ahora TODO el Editor completo(Salvo el EDC-Wizard el editor de conjuntos) Todos utilizan el MISMO cuerpo, es decir
El mismo numero de processos minimos 11, y solo 11.

antiguamente creaba hasta 33 processos, uno encimas de otros,(prenda por prenda,piel,boca,ojos...etc)

ahora lo que hace es hace la conversion, el montaje de todas esas piezas de cuerpo(prenda por prenda,piel,boca,ojos...etc)
Crea(o carga) en memoria un FPG con solo 7 graficos, SI 7 y solo 7
Antes eran 11.
Con 7 es lo mas minimo!!Miren:


Lo que si, NO estan recortados automaticamente, por que si activo el recorte, tarda casi 1segundo en crearlos.
Si lo desactivo es mas que INSTANTANEO!!SUPER RAPIDO!

Esa pantalla de Espera, cuando le damos a TEST ya no existe, Prepara el modo7 de manera directa y aprobecha que ya esta cargado el FPG del personaje para solo crear solo 11 processos.

En memoria ram muuuuy poca, en CPU consume un poco mas que no el metodo sprites.
pero lo estoy calibrando...

Parece que la resolucion de 640x400(Panoramico) parece ir siempre a 30FPS (eso estando en modo TEST modo7)
Os parece bien que reduzca la resolucion de juego? de antes de usar 1024x600 ->>>> 600x400 (sin ningun filtro)
Y pensad que ya NO son sprites, es puro calculos matematicos, usando files de: Estructura osea,poses y animaciones.
Tiene muuuchas ventajas este sistema, ya que permite modificar 1 parte concreta del cuerpo y obtener todos los detalles de una parte.
Ademas se puede programar que se puedan mutilar , si le dan con una hacha o algo bestia.

O quien sabe!
si fueran robots, no humanos, son capazes de ROBAR piezas a OTROS ROBOTS, y REMPLAZARlas por las suyas.
CREANDO un robot MIXTO y diferente!
Es lo bueno de usar piezas.

Hay algunos juegos antiguos 3D de la epoca(2003) de: PS1,N64 y DreamCast que usan ese sistema de "Piezas" en un cuerpo humano(o robotico)
Y tiene ventajas, pero tambien tiene desventajas (fallos graficos)

Un ejemplo: ONI (PC y PS2)


Admiro mucho a este juego, por que tiene "esa" cosa que te da "esa" libertad de movimientos.
cominando controlotes de 3ª persona, tipo GTA3....

un ejemplo antiguo: Cyborg Justice (Megadrive)

Aun que os parezcan sprites, tengo la sospecha de que usa "piezas" para mover e interactuar con los movimientos del robot.
Y sí, existe una manera de Robar un brazo al rival y remplazarlo por tu brazo. Eso me llamo mucho la atencion.(y hay más)
Me gusto mucho este juego cuando era niño, me viecie mucho a ese juego.
Pero lo considero dificl de controles(da la sensacion de ser pesados y lentos)
Lo bueno que solo se utiliza 3 botones para jugar y la cantidad de movimientos que posee.

--------------
volviendo al proyecto:

Aun tengo que terminar de pulir el codigo que monta y genera esos 7 graficos de las partes humanas que os enseñado anterior mente.
Por que aun tiene esa cosa al cual lo usaba como metodo de "capturar" los graficos, usando los 33 processos, y es solo para capturar.
Pero creo y pienso que NO es necesario crear ningun processo, eso permite que se pueda generar los 7 graficos aun mas rapido que lo actual.
Actualmente creo que tarda unos 0.700milesimas de segundos en crearlos(aproximadamente) eso en un notebook.
Si pulo ese codigo, prodria reducir esas milesimas de segundos, y asi sufrir menos el kore(el corazon) de Gemix, para crear operaciones y processos inecesarios, ademas de variable y tablas que sobran.

Tambien puedo ganar mas optimizacion de animacion y jugabilidad, (cuando estamos en modo7)
Si pulo y gestiono de manera mas optima la manera de organizar "esa" galeria de poses y animaciones que usarian los personajes a lo largo del juego, esto lo mantiene en memoria los que mas se usan, las animaciones especiales poco usadas, lo cargaria directamente(el file) y lo añade en la galeria de poses y animaciones en memoria (es una struct)
Tendrá un limite de el numero de poses y animaciones que se puede llegar almacenar en memoria, con 9 a la vez, es suficiente.
Por que no es bueno que en cada movimiento este cargando el file, pose o animacion para mover el personaje....
eso percute el rendimiento de Gemix, es usar constantemente funciones de LOAD() para cargar los datos de una pose o animacion.
Actualmente Aun lo tengo, asi, lo sorprendente que aun no noto que percute el rendimiento.... pero aun asi, no me quedo tranquilo y prefiero ser detallista y perfecionista en lo posible.

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

Con usar 640x400 creo que ya es suficiente (sin filtros).

Sugerencia: Para Optimizacion de los datos, al compilar:
Estaria bien que hubiera una manera alternatiba de compilar un programa y que te liste; las varialbes,tablas y estructuras, funciones y processos que no se usan, o no se usaran en la ejecucion del programa.
Esto evita que consuma mas memoria ram, por culpa de varialbes y datos que jamas se usaran.
se puede decir que son variables,tablas y datos struct, hasta funciones y processos :
Avandonados y que jamas seran usados.

Que mas adelante lo usaremos? ,si seguro.
Pero esta claro que actualmente no lo usara...hasta que llege el dia que le demos uso dentro de la ejecucion.

Lo que no me parece bien que carge y cree en memoria un .exe con datos que jamas usaria en la ejecucion del programa.
Variables que jamas usara, solo estan para ocupar memoria expresamente.

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• Program test_mem;
• global
• int mi_variable[10];
• int mi_variable2[10];
• begin
• from x=0 to 10;
• mi_variable2[x]=rand(0,100);
• end
• //realizo los calculos que quiera
• //y jamas llamo e inserto esta tabla mi_variable
• end
•  

Lo que quiero decir con esto, es que la tabla int mi_variable[10];
y que en NINGUN MOMENTO LO USAMOS la tabla mi_variable[10]
Solo esta asignado "ahí" y ese "ahí" esta ocupando memoria SIN USO, solo ocupando memoria.
Estaria bien que a la hora de compilar y crear el .exe que SOLO añadiera DATOS Funcionales,
Es tonteria Añadir variables,tablas ... funciones y processos que JAMAS SERAN LLAMADOS en la ejecucion.exe.
Lo unico que hace es ocupar memoria RAM y puede que perjudique a la ejecucion....

A veces no ha pasado que tenemos tantos variables, estructuras y tal, que no sabemos con exsactitud si los estamos usando para alguna parte del codigo funcional.

Hasta algun processo o funcion, podemos dejarlo solo y nunca llamarlo en ninguna parte del codigo.

Yo creo que se gana mas memoria ram y un performance de gestion. a la hora de ejecutar.

Seria una opcion util de añadir, pero hay algunas cosas que no se pueden quitar/optimizar en todo caso.

[SimulatorOne]

Este tema se puede mover a la categoria WIP

[CicTec]

Hola Simulatorone,

Ok ya he movido el hilo aqui.

[SimulatorOne]

gracias, esta claro que este juego esta por los principios, este juego viene de tras del lolita land.

[CicTec]

De nada, no hay problema poco a poco se iran completando todos.