Gemix Studio

Soy yo o le has puesto falda a sonic? no tienes perdón de dios XD..

erkosone wrote:Soy yo o le has puesto falda a sonic? no tienes perdón de dios XD..

Es mujer! no es tan raro... o es que prefieres un short ajustado? XD, por cierto sigo esperando un email tuyo!

Además... están muy bonitos parece una mujer de verdad XD, si fuera un erizo... ainsss XD.

SimulatorOne wrote:A ver si para este fin de este mes de marzo puedo terminarlo.

Recuerda que éste sábado próximo se atrasa el reloj una hora... así que tienes una hora más extra XD.

erkosone wrote:Soy yo o le has puesto falda a sonic? no tienes perdón de dios XD..

Si, tenia curiosidad de ver los colores lo mas parecido a Sonic, sabia de alguna forma que es sonic travestido xDD

En realidad el diseño de la "Classic AMY" es la version travestido del Sonic, en realidad. xD
Solo lleva un vestido,otros zapatos, pestañas,una cinta en el pelo, y un flequillo.
jajaaja Sonic puede travestirse de "Classic AMY" tranquilamente.

de lo mismo pasa con Mikey Mouse ,con la Mini esa. solo lleva un vestido,unos zapatos,pestañas,y un lazo.
Y creo que el Pato donal y la Daisy , lo mismo.

Esa gente que diseñan personajes no se esfuerzan demasiado...

Menos mal que en Mario no existe una Peach travestido de Mario. si no una verdadera princesa ,guapa muy femenina!
Al menoss la gente de Nintendo se ha esforzado por pillar una princesa rubia de cuento xDDD

TYCO wrote:

SimulatorOne wrote:A ver si para este fin de este mes de marzo puedo terminarlo.

Recuerda que éste sábado próximo se atrasa el reloj una hora... así que tienes una hora más extra XD.

Es este domingo 25, 2:00am cuando adelantan 1 hora. me lo dice Windows 7 xDD

Si tío, yo le fiché el bulto a daisy ya hace tiempo, y me parecía sospechoso, ahora todo queda confirmado jajajaja..

He mejorado el motor de pintado del nivel... la gestion de procesos del scroll.

Os recuerdo que uso un SCROLL de verdad, de 1 sola capa/primer plano.(el fondo no cuenta como scroll)
ya que me resulta mas facil programarlo, que hacerme mi propio motor de scroll para ganar perormance.

El juego trabaja mas deprisa que antes,consume menos CPU.
Pero el consumo de memoria sigue estando igual.... unos 130MB de ram. :/


Lo que quiero decir es que ahora hace menos comprobaciones y omite de algunas para ganar rendimiento.
incluso congela y duerme mas procesos.

os explico como va:
Lo primero, es que desde que empeze a programar el juego, siempre ha pintado el nivel de una pasada.
Su capa de Scroll unica,su mapa de durezas,el fondo y los procesos metidos en el scroll.
y un 93% de los procesos estan en estado congelados/s_freeze

Pues he mejorado estas caracteristicas: hablo de los procesos del nivel.
Siguen estando presente en memoria TODOS los procesos/elementos del nivel,si.
-Pero Todos los procesos que estan fuera de la pantalla OUT_Region, estan Dormidos/S_SLEEP
-Al Estar Dormidos, se gana un importante mejora de rendimiento.
-Omite las comprobaciones de COLLISION/OVERLAP y tambien de GET_ID, esto mejora mucho el rendimiento.
-No pinta fuera de pantalla procesos dormidos, mejora de rendimiento.
-Segun GET_ID(ALL_PROCESS); dice que hay entre un minimo de 2, hasta aproximadamente 50 procesos, Activos y Congelados. (No cuenta los Dormidos).

El minimo es: 2. Jugador/personaje y proceso jefe que domina la gestion del juego.
Si el valor es superior a: 2 quiere decir que hay otro proceso Congelado o activo visible en pantalla o que esta cerca.
De procesos lo hay de estos: Activos y Congelados.
----------Los minimos obligatorios....
-(A)Jefe MAIN, que gestiona el procesado de procesos Congelados y dormidos, imprime en pantalla la puntuaciones,vidas...
-(A)Rosie, el jugador.(Es el proceso mas complejo de todo el juego,y motor de fisicas, tiene al rededor de 1400 linieas de codigo ,utiliza 5 funciones)
------------los que aparecen en el nivel--------
-(C)Escudos:Electro,normal o power Rosie invencible
-(C)Humo del Turbo,Spindash.
-(A)Humo de frenado
-(C)Muelles
-(C)Bloques de piedra duros
-(C)Parches del nivel, para tapar ciertas areas y poner una Z superior (para hacer tuneles,pilares,suelos profundos...)
-(A)Particulas de Sangre
-(A)Animalikos
-(C)Rings, (Solo se vuelven Activos cuando son anillos que saltan rebotando)
-(C) Cabinas de TV
-(A)Enemigos
-(A)Particulas de roca (Estas provienen de los bloques duros y de las estalactita gigante al caer)
-(C) Estalactita gigante
-(C) Meta de llegada

En mi ATOM de 1,6Ghz...
viendo el rendimeinto de uso de la CPU
del proceso del juego el .exe
consume al minimos de 10% hasta 21% de la CPU.

2 Procesos Activos:


4 Procesos Activos y Congelados:


5 Procesos Activos y Congelados:


ese numero que dice Procesos, chiva eso, cuantos Procesos Activos y congelados hay.
No cuentan los dormidos que hay en todo el nivel.

Me aventurado con el modulo NET en introdcirlo en el juego, en modo Multijugador.
De momento son pruebas basicas.

Y funciona muy bien
justo como lo queria. hasta 4 jugadores!

ahora viene lo mas dificil, interacion con objetos del nivel...
por que de momento en modo online, no carga ningun objeto: Rings,cabinas tv,enemigos,algunas trampas y la meta.

Los muelles puedo dejarlo... pero no hacen la animacion,cuando otro jugador salta sobre ella...

pero claro ahora queda lo mas dificil
y no se muy bien como hacerlo

de momento tengo esta STRUCT
[Codebox=gemix file=Untitled.gemix]STRUCT JUG_NET[TOP_JUG_NET];
GRAPH;
X,Y;
ANGLE;
FLAGS;
END[/Codebox]
Es bastante sencillo verdad?

Pues de momento aun no se bien como hacer que envíe la señal de que por ejemplo si algun jugador a cogido un Anillo.
Pero claro... hay MUCHOS anillos en el nivel...
Deberia enviar el Nº de Anillo que a cogido a los demas Clientes y servidor. para que autoeliminen ese Anillo.

Digamos que cada proceso de Anillo, tiene un Numero de creacion: Anillo 1,anillo 2, anillo 3....asi...
Es una variable local que dice el numero de objeto creado en el nivel.

Como el nivel siempre se crea con el mismo numero de objetos...
Pues si el jugador 2, coge el anillo numero 56, pues ese numero lo envia a los Clientes y servidor...
luego los clientes y servidor... comprueba que ese anillo Nº 56 es destruido, pues lo elimina.
El juego(en todos los clientes y servidor) comprueba si sigue estando presentes y que ningun jugador lo a destruido.

De momento lo programo de esa manera que se me a ocurrido...
de momento son primeras pruebas...

Seguro que existen de otros metodos para que la STRUCT contenga menos elementos. y pese menos.

Bueno menudo currazo! ese aumento de mejora de rendimiento es la leche, me gustaría probarlo en ese pc que tengo yo para ver si los juegos tiran bien o no, pero por lo que comentas está muy optimizado, por otro lado tiene que ser un subidon ver a tus personajes en online ya activos! yo ando tambien rompiendome la cabeza con el online ya que quiero incluirlo en el winter jumper, pero a parte de los personajes no consigo visualizar ningun objeto en pantalla, tengo varias ideas pero de momento nada, y es que tengo la mente estructurada de otra manera, ahora hay que desaprender como dicen mucho hoy en día, con el tema del online me siento como cuando empezé a programar, sin guias, sin ayudas, sin tutos ... gracias a dios tengo vuestra ayuda!
Pues eso, animo! yo flipo con cada mejora que haces, te lo estas currando a muerte! eres un ejm a seguir . saludetes! animo con ese online que va saliendo!

SimulatorOne wrote:Como el nivel siempre se crea con el mismo numero de objetos...
Pues si el jugador 2, coge el anillo numero 56, pues ese numero lo envia a los Clientes y servidor...
luego los clientes y servidor... comprueba que ese anillo Nº 56 es destruido, pues lo elimina.
El juego(en todos los clientes y servidor) comprueba si sigue estando presentes y que ningun jugador lo a destruido.

Ese método podría dar problemas si dos jugadores han cogido ese anillo sin comprobar previamente en un sitio central que estaba disponible para cogerlo.

Yo haría que una vez creados todos los anillos... antes de coger el anillo 56, el jugador 2 envía petición al servidor para coger ese anillo, el servidor comprueba que ese anillo aún existe y no lo ha cogido otro jugador, lo elimina, y se lo añade al jugador 2 que hizo la petición, al mismo tiempo envía al resto de jugadores que eliminen ese anillo 56 porque el jugador 2 lo cogió, si en es periodo el jugador 3 estaba cerca y quería coger el mismo anillo 56, al enviar la petición al servidor para cogerle, le dirá que no está disponible ya que lo cogió el jugador dos, y así aunque tengas LAG, el jugador 3 no puede coger un anillo que ya no está aunque por LAG aún lo lo sabe, y esa situación sólo se va a dar cuando estén muy muy cerca dos jugadores o más de un anillo concreto.

Por si te sirve de algo te pongo un ejemplo estructurado con acuse de recibo.

Esta es tu estructura de datos:

STRUCT JUG_NET[TOP_JUG_NET];
GRAPH;
X,Y;
ANGLE;
FLAGS;
END


Puedes usar esta otra todavía sencilla y un poco mas enfocada al tema de los anillos u otros objetos:
STRUCT JUG_NET[TOP_JUG_NET];
GRAPH;
X,Y;
ANGLE;
FLAGS;
String Msg_[6];
byte TX_;
byte RX_;
END


Vale, ahora tienes 3 campos mas, un mensaje de texto de 7 char y 3 byte´s para solicitar acciones..

Que significan rx y tx? son un clásico en programación por puerto serie, y se usan mucho como referencia en la industria ya que son dos palabras clave, tx significa Transmision o emision y rx significa recepción.

Entonces, como las uso?
Vale, para esto cada anillo dentro del juego ha de tener un ID bien claro y del estilo por ponerte un ejemplo: ID_Anillo[n], esto ha de ser así en todos los clientes, entonces en el servidor ha de existir la misma lista de anillos, lo mejor de todo es que hagas esto al inicio de la partida desde el servidor:

for(i=1; i<TOP_JUG_NET; i++) un sencillo bucle que va a recorrer la lista de players..
El paso siguiente es decirle a los players donde han de crear objetos..
Para esto usas los campos que he añadido a la estructura..
jug_net.msg_ = "anillo";
jug_net.tx_ = 0;
jug_net..rx_ = el numero del anillo..
jug_net.x = x del anillo..
jug_net.y = y del anillo..

y esperas a que todos los clientes tengan en su campo msg_ "OK!", esperas desde el servidor claro..
en este punto ya todos los clientes han creado los anillos en su partida local.. asignando el valor de rx_ recibido como posición de ID en una tabla local de id´s.
bien..

Cuando ya has enviado la lista de objetos a los clientes y ellos los han creado..
por cierto, una buena idea es crear una variable local en el objeto anillo como por ejemplo byte 'num_' que indicará el numero de anillo, entonces al llamar a los procesos anillo haces algo así:

desde el cliente..
si rx_ <> 0...
si msg_ es igual a "anillo"..
creo el proceso anillo..
anillo( jug_net.x, jug_net.y, jug_net..rx_ ); el proceso anillo --> anillo( x, y, num_ );
llamas al proceso anillo en local, osea, en los clientes.. y les dices que número de anillo les pertenece..






Al colisionar con un anillo en un cliente:
desde el proceso personaje..
if( collision (type anillo))..
ahora viene la comunicacion con el server..
jug_net.msg_ = "get ani";
jug_net..tx_ = num_
esperar a que el servidor de el ok..



Y basicamente es esto lo que tienes que hacer muchacho XD.. ya tienes faena!! haber si logras hacer algo funcional y nos hechamos una party, el server si queires lo cuelgo yo mismo en el mac mini.

Bueno lo he explicado bastante mango por hombro XD.. pero creo que se puede entender la idea.. luego hay que pulírlo y tal.. y como consejo, y esta ya es la parte compleja de programación.. todo el control de red que se haga desde un solo proceso, para evitar que 2 eventos se produzcan a la vez y solapar información.. es muy muy muy recomendable usar una variable global para poder controlar todo bien desde varios procesos, si estás comunicando desde algún sitio por red.. que la variable blobal por ejemplo "NET_BUSSY" esté a true.. y que el siguiente proceso que quiera comunicar algo al servidor espere hasta que valga false.

Espero que te ayude un poco a empezar, verás que es un puñetero comecocos esto XD..