Handhelds o Game & Watch, ¿hay algun ''estandart''?

[Futu-block]

estoy loquito por programar alguna lcd de estas como se llame, pero me gustaria saber si hay algunas pautas preestablecidas por las que guiarse, o por lo menos ponerse de acuerdo en el nombre, porque ya le he llamado de tres maneras a las ''maquinitas'' de toa la vida...




Lo que si se que hay es un (como yo le llamo) patron de pitidos, y es aproximadamente de cinco o seis por segundo donde podemos comprobar una serie de movimientos, por ejemplo en el basico de esquivar:
(foto mas parecia que he encontrao)
recuerdo en una parecida que el movimiento del personaje era siempre independiente de este patron, mientras que el patron seguia un ritmo de movimiento, algo como:

-mueve primer enemigo
-paso
-paso
-paso
-comprobamos



-mueve primer enemigo -mueve primer enemigo
-mueve segundo enemigo
-paso
-paso
-comprobamos




-paso -mueve primer enemigo -mueve primer enemigo
-paso -mueve segundo enemigo
-paso
-paso
-comprobamos

no se si me entendeis, pero es una frecuendia de movimiento que depende una de la otra...






·por otro lado, el tema de los graficos hay gente que se ha currado el muñequito con un bordecito blanco, no se si esta guapo porque destaca o mejor no usarlo, lo que si está claro que hay que hacer es que cada grafico sea lo mas diferente posible al anterior, por lo menos los del personaje principal al moverse, que apenas son cinco, y asi le dá una gracia al juego
Y por no hablar del fondo, una mezcla de dorados y plateados con colores brillantes de una pegatina que tenian las originales maquinitas, je je


·el tema de la musica es otra cosa, creo que se podria añadir una midi suave sin apenas mucha caña ni variacion de tono, para no monopolizar los famosos pitidos originales...
¿donde se encuentran, donde se pueden bajar?


y por ultimo y no menos importante:


¿alguien se ha currado una en Bennu???

[Drumpi]

Yo mismo... aunque no sé si llamarlo juego o qué :D
Se trataba de "Liquid counter" que tienes para Wiz y Caanoo, cuyo objetivo es contar cuantas veces podías pulsar un botón o tapear la pantalla en 10, 30 o 60 segundos... y competir hasta con tres amigos más en la misma consola :D

Hay muchas formas de programarlos: puedes tener los procesos creados previamente y sólo cambiar su gráfico, puedes hacerlo como cualquier juego... bueno, un G&W, no dista mucho de los demás juegos, pero es imprescindible tener en cuenta que estas máquinas dependían 100% del reloj, salvo el control del personaje principal.

Los gráficos yo los hice con paint y la lupa a x8 en 3 colores (transparente, activado y desactivado), y los sonidos los cogí de una web que emulaba juegos (grabé y seleccioné los que me interesaban)...  pero los sonidos originales se creaban usando una onda cuadrada (square wave) a distintas frecuencias (por lo general, a muy altas frecuencias, por eso siempre son pitidos :D). Ya tienes experiencia con el SRFX, así que si sabes manejar eso, es fácil que sepas cómo se modularía para obtener distintos sonidos y efectos sonoros ;)

Aparte de eso, poco más puedo decir hasta que haga uno de los juegos que tengo en la pila de proyectos :)

[Futu-block]

eso, el reloj, como vá eso del reloj??
quiero usar eso del reloj y no se como :D

[Drumpi]

Pues te comento:
Hay dos formas de usar el reloj: con los Timers o con contadores.

Con timers lo tienes fácil y no importa que la máquina se ralentice, siempre va a ir sincronizado. Lo malo es que eso es la teoría, porque he comprobado en la práctica que no es tan preciso como parece, porque al usarlo en el Liquid Counter, se me ha llegado a retrasar más de 10 segundos en tan sólo cinco minutos. Y no, no es que estuviese usando ==100 en el if (recordemos que cuenta centésimas de segundo cada timer), usaba >=100 y restaba 100 al timer cada frame.

Con los contadores corres el peligro de acumular retrasos si la máquina se ralentiza, pero si vas sobrado de recursos es la mejor opción.

La idea es tener una variable global que se incremente a cada frame una unidad. Si sabes que cada segundo tiene 50 frames, es fácil sincronizar todos los elementos usando la función módulo (si divides entre 50, sólo una vez por segundo valdrá cero). Lo único que tienen que hacer cada elemento que necesite sincronizarse es hacer ese cálculo.
Pero como sé que la función módulo es lenta (más que una resta+if), lo ideal es que el mismo proceso que se encarga de incrementar la variable (que se ejecuta al principio, que se queda ahí para siempre y que no depende de nadie, salvo del proceso main), tenga un contador propio que, al llegar al segundo (o al medio segundo, o al cuarto de segundo, según la velocidad de todos los elementos) se ponga a cero y ponga una variable global a 1 durante un frame, así, el resto de procesos sabrán que cuando dicha variable valga 1 deben moverse o actuar.
Esto sería mucho más sencillo si se pudieran mandar señales al resto de procesos (aunque puedes hacer que los procesos se congelen tras cada frame, y que sea el proceso de sincronización el que los despierte).

Este proceso puede dividirse en dos: uno que lleve el reloj global, y otro que vaya marcando el 1 cada vez que se tengan que mover, de esta forma, el segundo proceso puede marcar 1 con más o menos frecuencia dependiendo del nivel de dificultad.

Pero todo se reduce a tener un contador global que se pueda consultar desde todos los procesos, y que estos sepan cuándo deben actuar. Así de simple.

[Fuynfactory]

while (true)
if ((timer[9]==100) // <--- 100 es 1 segundo si quiere menos juega a la baja
.... // <--- codigo que se ejecuta cada 1 segundo
timer[9]=0;
end
frame ;
end



imaginate que quieres que se mueva al patrón que tu quiere
process timer
while (true)
if ((timer[9]==50) // cada medio segudno volvemos a empezar
.... //
timer[9]=0;
end
frame ;
end

process enemigo A
loop
if ((timer[9]==0)
... <codigo>
end
frame
end

process enemigo B
loop
if ((timer[9]==10)
... <codigo>
end
frame
end

personaje
loop
if (((timer[9]%5) ==0) < cada 5 centi segundos puedes mover
... <codigo> mover
end
if ((timer[9] ==50) < comprovar collisiion
... <codigo>if  collision (type enemigo) -> morir
end

frame ;
end


esa seria una estructura básica

[SplinterGU]

no uses == el tiempo no siempre puede ser exacto cuando se trata de milisegundos...

[Fuynfactory]

tienes razón SplinterGU

while (true)
if ((timer[9]>100) // <--- 100 es 1 segundo (pisha mas o huevo) si quiere menos juega a la baja
.... // <--- codigo que se ejecuta cada 1 segundo
timer[9]=0;
end
frame ;
end



imaginate que quieres que se mueva al patrón que tu quiere
process timer
while (true)
if ((timer[9]>50) // cada medio segudno volvemos a empezar
.... //
timer[9]=0;
end
frame ;
end

process enemigo A
private
bool st=true;
loop
if ((timer[9]>0) and (timer[9]<10) and (st)) <- rango de 100ms
... <codigo>
st=false;
elseif (timer[9]>10)
st=true;
end
frame
end


o tambien se puede usar  timer[9] en una sola función de forma de control por ejemplo
golbal
  // vars
  int control=0;
  //vars
  int CTRMAX=???
  int TIMEMAX=???
int
end
...
funcion timer()
loop
if (timer[9]>TIMEMAX)
control++;
if (control ==CTRMAX)
control=0;
end
end
frame ;
end

enemigo0()
private
bool exec = true;
end
loop
if ((control==0) and (exec))
.... <codigo>
exec=false;
elseif (control<>0)
exec = true;
end
frame ;
end


puedes intentar  cualquiera
es el compadre  SplinterGU tiene razón  cuando accedes al timer[9]  puede valores continuos y al truncar puede leer valores de momento por ejemplo estar esperando un 10 y leer esto .... 2,5,7,11,15 ... y no salir 10

se pretende una simulación de cuarzo pero no de un reloj el jugador cuando esta en la partida no va a medir si lo que esta pasando es 1 segundo exacto o 0.98 a 1.02 segundos, se conforma que pisha mas/o huevo sea un segundo

[Futu-block]

pues si, mas o menos sería así, ahora a intentar implementarlo, gracias