[GAME] Lolita Land [Gran Proyecto Activo]

[erkosone]

Yo de ti, para optimizar bien bien el código y que no te hagan falta los "SPRITES" sino las "piezas del cuerpo..

Dale un vistazo a la Cinemática inversa tio, esto te va genial para tu juego, y así de paso vas tanteando el tema, es muy buen sistema para lo que tu quieres hacer, pero bastante mas trabajoso de hacer el motor..

Yo te garantizo que con este sistema los FPG de cada personaje se limitarian a:

Piernas, cabeza, cuerpo, brazos, y todo esto "articulado o no.. eso ya lo decides tu..


Para tu juego es un sistema a tener en cuenta.

-- La cinematica inversa así a groso modo trata sobre como situar en un plano ya sea 2d o 3d una serie de cuerpos, conectados entre si, y que realiza de forma automatica el movimiento de todos en función del movimiento de uno de ellos.

Osea, que moviendo los "zapatos" o "pies" consiges que todo el sistema locomotriz del cuerpo actúe de una forma natural al movimiento, es lo que hace el cuerpo humano.

[SimulatorOne]

en memoria ram me ahora muuuuchisimo... pero
La CPU tendria un imacto de rendimiento bestial, son muchos processos (muchas piezas)

De echo en las herramientas SIEMPRE ves los cuerpos en modo Processos, NO sprites.
Solo lo convierte en SPrites para verlo en el modo7.

Que es mejor.... casi 30 processos X cuerpo, o 1 processo x cuerpo...
Tiene mejor rendimiento 1 processo que no 30.

Si e quitaria de los sprites y seria mas sencillo.
pero mas lento a la hora de jugar SI.
Yo no podria jugarlo en un Intel ATOM aun que valla a 30, me iria a 15FPS y usando el parametro de saltos de frames entre 2 y 4 U_U

Sufre mucho la CPU.

Con un solo cuerpo ya lo noto. esos 30 processos, cada uno con sus calculos de xget_angle y angles
Puede que esos 30 porcessos se reduzcan solo a los necesarios del cuerpo.
1-cuerpo inf
2-Cuerpo sup
3-cabeza
5-Hombo L y R (2 processos, pero mismo grafico)
7-Manos/brazos L y R (2 processos, pero mismo grafico)
9-Pierna superior Muslo L y R (2 processos, pero mismo grafico)
11-Pies y gemelos L y R (2 processos, pero mismo grafico)
Hace un total de: 11 Processos como minimo, necesarios.

Puedo probarlo a parte, dentro de un modo7. aver que tal el rendimiento con un solo cuerpo.
Pero ya te digo que me iria mas lento. lo normal y fluido es 30FPS jugando. creo que es justo.
pero cuando la cosa va a 15 o peor a 10.... pffff es desesperante y tengo que recurrir a la fuerza el segundo parametro de SET_FPS(30,X); tengo que probar entre 1 hasta 4.... U_U un royo..

Por eso me hace falta ya o casi ya mismo la aceleracion OpenGL, saves?


Pues hay una pega de NO usar Sprites....
no puedo estirar el cuerpo como un grafico entero size_x,size_y.... no podria hacer eso.
Ya que cada processo tiene su propio angulo

Me haria falta un especie de size_xy especial:
Es decir que omite el angulo del grafico, y siempre estirando de las 4 partes como si estubiera en angle=0

pero mira U_U, para cambiar el aspecto fisico de una persona, si es delgada ,gorda, enana o alta.
Mas bien deberia retocar los puntos de union de los huesos(esos files .os) ademas estirar size_y(si es alto o enano) todas las partes, y size_x(si es gorda o delgada).

PEro gracias por la observacion y el consejo erkos.
Intentare hacer este invento de librarme de los sprites, y usar directamente ya los processos, en un mapa modo7.

En si el sistema ya lo tengo echo, solo que no esta aplicado para un modo7.

Deberia sustituir la variable local Y por la Height que es la que usa el modo 7 para la altura.

[erkosone]

Pero no te engañes, el rendimiento baja por la resolución y por que está en 32 bits que es innecesario totalmente.

En mi opinión claro está, con 16 bits te sobra para ese juego.



Sobre los procesos.. te puedo dar una ayuda muy grande..


CicTec en su dia me ayudó a optimizar un juego que tengo que hacia efecto nieve.. y los copos de nieve interactuaban con el personaje cubriendolo si estabas un rato parado.. eran 8.000 procesos.. imagínate..
CicTec le hechó un vistazo y me cambio una sola linea de código y gane un 80.000 % de velocidad..

Vamos, que de no andar nada a andar sobradísimo.. es muy importante no utilizar esto del TYPE en las colisiones.. eso solo usalo cuando sea extrictamente necesario, sobrecarga una brutalidad.

No es coña, aveces usar COLLISION y OVERLAP con el famoso "TYPE" te hace perder toda la velocidad por el gran numero de procesos, yo supongo que si se te ralentiza el juego.. debe ser por algo así..
En un P3 a 600 hago pruebas normalmente para comparar velocidad entre lenguajes.. y te digo que Gemix a 16 bits puede con bastante mas de 200 procesos a toda maquina.. 60 fps a 640x480.


No se porque se te ralentiza la verdad, pero vaya, que el primer cambio directo que yo le hacia a tu proyecto es hacerlo en 16 bits, que para esos gráficos sobra.
Solo con trabajar a 16 bits ya tienes el doble de velocidad, la verdad es que es un desperdicio de cpu brutal.

[SimulatorOne]

No puedo o no quiero usar los 16bits
tengo demasiados graficos que dependen del canal alpha

queda feo esos pixelotes o es 100% opacos o 100% transparentes.
no podria crear ciertos efectos graficos.

Yo ya lo probe para la Wiz, y queda bastante feo la verdad. U_U

...secreto para el publico...

Si dejo de usar los 32bits, ya me puedo estar olvidandome de RGBA, efectos de resplandor, sombras, efectos de tela de thul, pelos, difuminado...
Es decir estas 2 opciones que marcado: en el photoshop


y LUEGO tener cuidado con el color negro, ya que si es 100% siempre sera transparentes >___<
eso es dificil de calibrar

[erkosone]

Hombre.. siendo así pues tiene su lógica, espero que el modulo por hard para gemix no se retrase mucho, porque la verdad es que para estas cosas hace falta como el comer.
Será tener paciencia un poco mas, cada vez queda menos

[GINO]

Tranquilo Simu que esto esperemos que se arregle con el opengl.

[SimulatorOne]

no es facil de llevar los 16bits.... es mejor que 8bits? si

no se, cada uno tiene sus pros y contras

esta claro que 8bits es mas rapido de 16,
y que 16 es mas rapido que 32.
32 es lo mas extremo que hay

Quizas abuso demasiado, ademas de trabjarlo en un portatil con un procesador lento para algo tan hevy como los 32 bits.

De todas formas, creare una copia de la carpeta del proyecto y empezare conviertiendo mapas de 32=> 16bits.
Poco a poco

Si esto me funciona y se ve bien, aceptable.
probare eso de los 11 processos x cuerpo humano, aver que tal.
Seguro que es mucho mas rapido ^_^

[erkosone]

Por eso mis programas son a 32 bits pero nunca pasan de 320x200 panoramico o 320x240 cuadrado.

Más resolución que esto ya es un poco pesado si quieres hacer juegos sin optimizarlos.

[SimulatorOne]

tengo una duda:

se que si estoy en modo 16bits la funcion RGB me devuelve estos valores de color:
0 to 65535 on 16bits or values returned by RGB function

pero dentro de los parametros RGB funcionan igual que en 32bits?
es decir

valores de 0 a 255: RGB(255,255,255) === igual a Blanco puro.

No?

Ya e terminado de convertir todos los graficos a 16bits, no tiene canal alpha ninguno.
Me a sido facil gracias a MAP Editor, me a sido de gran ayuda... aun que e tenido que hacerlo de uno en uno....

Ya solo me queda ajustar el PRG a modo 16bits y revisar esos valores RPG

[SimulatorOne]

otra ayuda!!

Necesito esta operacion, pero adaptada en 16bits(sin aplha), como seria?
...secreto para el publico...