[GAME]: Super SMASH KeI V.0.03 Creando... [GP2X Wiz y PC]

[simulatorone]

Si en windows eso me funciona, lo normal es un wav con formato interno de PCM tipico sin comprimir... pues hay mas y esos si comprimen!
pero no se si funciona en Wiz y en linux... pero lo uncio que hace es que el tamaño de archivo es mas pekeño.

hay que probarlo....

[simulatorone]

Hola

E subido la version actual 0.03, para que la proveis, en modo Wiz y PC

La diferencia esta en que en modo PC usa realmente 32bits a 640x480
hay una variable que permite elejir este modo de 32bits y el modo 16 con escaladoX2(como se veria en la Wiz)

10MB - Descarga
http://www.mediafire.com/?mmh1qgn0gxc

Y funciona con el tactil/mouse

pero solo esta echo asta el menu de nuevo juego... la subi para saber si hay algun problema...

[simulatorone]

Hola

Quiero comentaros el como va con mi trabajo del juego:

Sigo haciendo cosas, e adjuntado el historial de trabajo del juego .txt

Ademas adjunto nuevas caputas, ya que tiene un nuevo aspecto grafico, mas bien texto.
Y ya se esta haciendo los menus de juego...






-Ademas estoy trabajando en los cuerpos compuestos.
Ya esta en marca, la estructura y las animaciones y los cuerpos.
De ambos sexos.
Ya hay las primeras prendas,pelos,ojos,bocas...etc.

Lista de aplicaiones creadas:
---=Por crear...
>>=en ello
<<------------------------------------------->>

Code Select Expand


Modular/compuestos:son que estan compuestos por piezas/processos, ocupan muy poca memoria ram/grafica, pero usa mucha CPU para calcular todas las piezas compuestas(muchos procesos).
Sprites: son galeria de graficos ya creados desde los cuerpos compuestos, ya que es mucho mas facil de manipular(solo un proceso),usa muy poca CPU, pero comsume mucho más memoria ram/grafica.

<Editores Esenciales para el Juego>[son modulares]{Editor/Creador/Modificar}
1-Editor_de_Huesos(crea archivos <Nombre>.os,Estructura osea)
2-Editor_de_Poses(crea archivos poses\<Nombre>.pos,Crea poses de cuerpo estaticas,por angulos)
3-Editor_de_Animaciones(crea archivos animaciones\<Nombre>.anm,Crea secuencia de animaciones por Poses.pos)
7-Editor_Piezas_Conjuntas[modular->sprite](crea conjuntos preparados para el juego,por piezas,añadiendo precio,categoria...etc,al finalizar te la genera en sprite para jugar/test....)
>>7-Editor_Piezas_Conjuntas_Int[modular](Version Facil uso, con interfaz grafica 100% ,crea conjuntos preparados para el juego,por piezas,añadiendo precio,categoria...etc)
----9-Editor_de_PersonajesPre[modular->sprite](Crea todo el cuerpo de un personaje,pone nombre,edad,altura,peso y sexo,Y Gabrarlo en Prediseñado .Al finalizar te la genera en sprite para jugar/test...)

<Test de pruebas>(Pruebas entre modular y Sprites){Diagnostico Grafico/CPU y jugabilidad}
4-Test_de_Manipulacion[modular](Test de manipulacion(size,angulo,flags,alpha y cordenadas) del cuerpo por processos, no soporta size_xy)
5-Test_de_Sprites[modular->sprite](Crea en memoria todos los sprites(fotogramas) de una animacion, y las grava en memoria (añadiendo puntos de control))
6-Test_de_Sprite_Mov[sprite](Test a modo juego, de manipulacion total de sprites, por personas)

<Test de Vestidor>(pelo,ropa,piel,cara...){Test de Prendas/acesorios...etc}
----8-Test_de_Vestidor_Complejo[modular->sprite](Test que eliges por Prendas enteras(con descripcion,precio...),la ropa para poner,al finalizar te la genera en sprite para jugar/test....)

<Test de Personaje>{Test de jugabilidad como personaje}
----10-Test_de_Jugador_Prediseñados(Elige el personaje prediseñado,Modifica nombre,sexo,peso,altura... Despues carga un mapa modo7, y pruebas de gravar partida)
----11-Test_de_Jugador_Continuar(Elige la partida existente, la cargara totalmente como lo dejastes:"10-Test_de_Jugador_Prediseñados")

<<------------------------------------------------>>



Solo tengo 2 modelos genericos de prueba, chico y chica:
Capturas:
Modo 16bits.(baja calidad de imagen,rapido)

Modo 32bits;(falla map_xput y es lento)


2 modelos generados, por el editor de conjuntos y editor de animaciones





El problema esta en que Bennu, es lento en processar los 32bits, ademas que muchas operaciones graficas tipo FX Colos que no lo soporta, entre otras de manipulacion de imagenes.

Al final lo dejare en 16bits de calidad, para todo el juego.
la resolucion sera 320x240 para WiZ
y para modo Windows/Linux 640x480.
pero sera en 16bits ya que si se pone en 32bits, funciona mas lento FPS...

Y si hay una version 32bits(con FX Colors) a 640x480, pero esta es solo para Win....(no comento mas.)


De todas maneras sigo trabajando para 2 sistemas diferentes multi plataformas.

[SplinterGU]

32bits es lento porque es por soft... ya pronto vas a tener una version 32bits rapida, con acceleracion...

por otro lado, veo que es mas lento porque no estas haciendo el correcto uso de los recursos... segun se ve en tu captura el grafico es muy grande, tiene mucho de bordes negros... demasiados... el grafico debe ser del tamaño del dibujo...

si estas haciendo otra cosa diferente a lo que se entiende por la captura, seria bueno que lo comentes aqui...

saludos.

ahhh, otra cosa, funciona mas lento el modo 32bits si tenes el escritorio a 16bits o 24bits... si tenes el escritorio a 32bits deberia ir mas rapido que modo 16... esto ya se comento muchas veces.

[simulatorone]

Valla!! por Soft, no... por Mxx, ok...

El borde??? que borde??
te refieres a "ese" cuadro negro... pues es fallo del map_xput usando 32bits....
con graficos png puramente 32bits  :)

Pues me funciona bien en 16bits.
Es cierto! que contra mas size > 100 afecta gravemente el rendimiento
añadiendo los flags + alpha y angle....

Aun a ciencia cierta no lo se... pero si lo pongo en el juego juego, se vera el resultado final.

[SplinterGU]

no entiendo que dices con eso de "Valla!! por Soft, no... por Mxx, ok...", podrias explicar?

a ver... el personaje parece que ocupa realmente 1/7 del recuadro negro, por ende, supongo que estas haciendo un map_put de un grafico es 7 veces mas grande de lo que realmente ocupa el personaje... y eso no es correcto... que funcione en 16, no implica que este bien hecho eso de tener un grafico 7 veces mas grande de lo que ocupa realmente...

que queres decir con "mas size >"?

quizas no es eso lo que estas haciendo, pero como no pones ejemplo en codigo y recursos, no puedo saberlo realmente... pero deduzco que eso es lo que estas haciendo... si me equivoco agradeceria pongas un ejemplo, codigo+graficos... asi lo vemos claramente.

por otro lado, para que queres hacer el map_xput? que efecto estas buscando? mientras no este lo del modo 32bits quizas puedas hacerlo de otra forma...

pero como sea, una solucion por soft de 32bits no lo hara mas rapido a todo el proceso... pensa que el 32bits tiene un manejo extra, ya que por cada pixel se calcula la mezcla de colores basada en el alpha... asi que nunca puede ser mas rapido que el procesamiento 16bits... pero sin embargo, si usas 16 bits en escritorio 32bits va mas lento que si usas 32bits sobre 32bits... y lo mismo para el caso contrario... si tenes el escritorio de 16bits y trabajas en modo 32bits desde tu juego va a ser mas lento que si lo haces 16 sobre 16... asi que cuidado con las conclusiones apresuradas...

[simulatorone]

los graficos son de ese tamaño, y son correctos. 100% son de alta definicion.
Son para luego pasarlo al codigo Super SMASH KeI que usa 640x480(el doble que este editor de cuerpos)

Ya te digo que en 16bits funciona bien, en 32 se nota....(agregando el fallo de map_put)

Si, lo del size mayores al 100%, se afecta mucho... es decir, cuanto sea el grafico más grande; va mas lento, usa mas CPU, si el grafico es pequeño usa poca CPU.


En processar graficos con el nucleo del processador llamado: MMX, hay mas....
SSE,SSE2,3DNow!....

bueno.... es que mi ordenador, es un portatil que usa el intel ATOM de 1,6GHz y en reaidad son 2 nucleos de 900MHz

En la WiZ se reduce un poco mas los FPS... sin overclokear su CPU.


Te adunto mi Aplicacion/Editor/Test de Cuerpos compuestos Generico
http://www.megaupload.com/?d=6GZKXEI6

De paso comento, que hay archivos de txt y un poco de ayuda de como utilizar los editores y test.
Lo podeis aplicarlos en vuestros juegos!! ;)
Los controles son en royo apto para WiZ... el archivo jkeys.lib esta modificado ;)

Intenta cambiar el variable de los colores de 16, y ponerlo a 32, y el set_mode tambien + combinarlo con el SCALEX2

Esta bien la aplicacion!


PD: uso la ultima version del bennu:  bgd-1.0.0RC11(r131)

[SplinterGU]

que un mapa sea de 640x480 y el grafico sea de 64x400, no lo hace de alta definicion... podes usar un grafico de 64x400 y da el mismo resultado...

uses mmx, sse, sse2, 3dnow, lo que sea... si usas graficos mas grandes va a consumir mas cpu... creo que eso lo tenemos claro...

se lo del map_xput, no es el map_xput, sino el render que hace los calculos en base al alpha y luego aplica ese alpha a 255, porque ya la mezcla fue hecha... no digo que la aplicacion este mal hecha, esta mal que uses graficos mas alla del tamaño que necesita el dibujo... nadie hace eso... eso es derrochar... pero me imagino que tenes algun motivo para hacerlo, y me gustaria saber cual es? ademas, para que necesitas hacer el map_xput?

[simulatorone]

El por que los mapas son tan grandes, si los graficos son mas pequeños de 50% sin recortar.
La razon es que los prefiero del mismo tamaño todos los graficos, para cualquier usuario pueda pintar hasta ese limite que tiene.

Ademas que los png, comprimen mucho, depende de lo que hayas pintado, pesan mas o menos.
Lo que desconozco que cuando lo carga bennu se transforma siempre en la misma memoria ocupada por el grafico o es variable como el png.

Si es así, de que ocupa todos los graficos por igual... es lo que tu dices:"Estas desaprobechando tamaño del grafico".

PEro el problema es que le asigna un punto de control central, cual si el grafico es mas pequeño que el punto central habra problemas.

Ejemplo:
Todos los graficos son de este tamaño: 259x266
y el grafico pintado dentro; es super pequeño.

Pues resulta que al cargalo añade/centra el punto de control 0, en unas cordenadas fijas...
Es decir añade el punto de control en un sitio SIEMPRE fijo de esa pieza cargada.(sea un png,map,fpg)

Lo bueno de esto que el usuario no debe preocuparse de añadir ese punto de control de forma "Fuera de la programacion", si no que asigna siempre el punto 0 fijo, en esas cordenadas fijas.

O creado un blok de notas.txt/ini que diga donde esta el punto central XY, junto con el grafico .png


El map_xput, es para poder tener mas MANIPULACION del grafico a la hora de Generar los Sprites en memoria y sí.....

Consume mucha memoria ram(Genera un monton de new_maps del mismo tamaño), y solo es 1 grafico por pose y fotogramas de animacion.
A la CPU le cuesta mucho menos proccesar 1 grafico de un processo solo.
Que no de un cuerpo que usa mas de 15 procesos por pieza de ropa y capa!!!
Eso se nota!

[SplinterGU]

eso es un error...

ni en bennu ni en fenix ni en div el grafico ocupa menos en memoria... los graficos en memoria estan descomprimidos...

los puntos de control automaticos siempre se ubican en el centro del grafico no importa el tamaño de este... que pasa si alguien dibuja un personaje en un extremo de ese rectangulo gigante? por otro lado, lo ideal es que ubiques el punto de control en tu editor y guardes tu creacion como map o fpg... aunque si no quieres usar estos formatos, puedes usar el metodo que usaron en apagame, donde el punto de control y el id del grafico dentro de la coleccion en memoria (fpg) son parte del nombre de archivo... y cargan los archivos barriendo el directorio...

cuidado, no siempre a la cpu le cuesta menos 1 solo grafico que 15 procesos pieza por pieza... si tienes graficos gigantes sin necesidad entonces puede consumir mas 1 solo grafico... piensa que por soft cada pixel es procesado...

[simulatorone]

Sigo programando... mas lento, pero poco a poco.

Actualmente estoy liado con el editor de cuerpos, esta mucho mejor que antes.
Se an convertido en solo visores de momento... ya que el editor de conjuntos, no puede aplicar efectos especiales "FXcolors" ya que no existe en este codigo.

Tambien sea corregido unos bugs de controles y rendimiento general.
Y se sigue probando para la wiZ puramente.

[Mr Matsusaka]

Esta bien que le des un cuadro grande al jugador para que edite a su antojo, pero lo ideal seria que una vez se guarde el grafico, se recorten los bordes transparentes. Dejarlo asi me parece un derroche de memoria heap excesiva. En PC todavia puede que funcione pero en Wiz no se yo si va a aguantar...

[simulatorone]

Si es cierto.
De momento solo e cargado 1 cuerpo, con 50 sprites aproximadamente...

no sabria programar el autorecorte de imagenes...

Y prefiero usar sprites, por que es mas rapido, que usar muchos processos.

[Mr Matsusaka]

Pues... yo tampoco XD
Estoy mirando en la wiki y parece que no hay ninguna funcion que sirva para obtener el color de un pixel determinado de un mapa. Sin eso la verdad es que no se me ocurre ninguna manera

Por cierto, podrias subirte la demo en su version para pc.

[Rein (K´)ah Al-Ghul]

...
Estoy mirando en la wiki y parece que no hay ninguna funcion que sirva para obtener el color de un pixel determinado de un mapa. Sin eso la verdad es que no se me ocurre ninguna manera
...

sin eso no se podrian hacer mapas de durezas, por ejemplo...

http://wiki.bennugd.org/index.php?title=Map_get_pixel