Plantilla J2ME - Helius

[ethernet]

Aprovechando que la programación de juegos para móviles está cada día más presente en stratos y que más gente está interesada en la programación para estos dispositivos, Helius nos manda un código a modo de plantilla para crear un juego en J2ME. Nos hace un pequeño resumen del código:

Este COTW se trata de una plantilla para juegos sobre J2ME.

La plantilla está estructurada de tal manera que ya existe un thread con un bluce principal en el que se actualiza constántemente la pantalla del móvil.

Aparte, consta de algunas funciones de utilidad para responder al input y la capacidad de detectar si el móvil soporta o no doble buffer, en caso negativo lo realizará de forma manual.

Las funciones más relevantes están en la clase MainCanvas:

- private final static void MAIN_Render(Graphics g)

Aquí es dónde se deben pintar todos los gráficos del juego.


- private final static void MAIN_Loop()

Aquí es donde se debe actualizar toda la lógica del juego.


- private final static boolean INP_KeyDown(int key)

Esta función nos dice si una tecla está pulsada en este momento. Hay que usar las constantes que están definidads al principio de la clase (CONS_KEY_...) como parámetro.


- private final static boolean INP_AnyKeyDown()

Devolverá true si cualquiera de las teclas está pulsada.


- private final static boolean INP_KeyPress(int key)
- private final static boolean INP_AnyKeyPress()

Estas dos son iguales que las anteriores pero sólo devolverán true una vez, hasta que vuelva a soltarse y volverse a pulsar la tecla.


Otra de las características es que está pensada teniendo en cuanta la posibilidad de poder realizar la compilación, tanto para Nokias, como para móviles con MIDP 1 y móviles con MIDP 2, tan sólo cambiando unas directivas de preprocesador.

Si tenéis alguna duda podéis contactarme a través de los foros de Stratos (www.stratos-ad.com).

Código: Plantilla_J2ME


La imagen que general el proyecto:          



Otro artículo que puede interesar leer para preparar el entorno es el que escribió zupervaca en su tutoblog:
- Preparándose para programar en j2me
Esperemos que esto sirva como base para los cursos  y grupos de iniciación que se están montando ahora mismo


Código enviado por Nacho Sánchez (Helius), http://www.geardome.com



Si quieres enviar un COTW, puedes enviarlo a qualopec@gmail.com o por PM a ethernet.

[Helius]

Aprovecho para aclarar que se trata de un proyecto para Netbeans + Wireless Toolkit. Supongo que cogiendo los dos ficheros .java compilarán sin problemas en cualquier IDE.

Espero vuestros comentarios.

Saludos.

[Harko]

Otro artículo que puede interesar leer para preparar el entorno es el que escribió zupervaca en su tutoblog:
- Preparándose para programar en j2me
Esperemos que esto sirva como base para los cursos  y grupos de iniciación que se están montando ahora mismo

Hey! Justo lo que estaba buscando, muchas gracias :D

Harko.

[sés]

Un código estupendo para el que quiera emepzar a trastear con J2ME. Más de uno te lo agradecerá :)

[Mars Attacks]

Yo lo agradeceré :****************

[Lex]

...

[Helius]

he podido comprobar lo que tanto me advirtió y no le hice caso

Huir de Java mientras podáis bwahahahaha!!!!  :P

[TrOnTxU]

Lo que estaría bien es, hacer la lista de los 1001 trucos y advertencias de J2ME :twisted:

Yo haria la lista de los 1001 problemas y trucos de los móviles.
Comienzo con unos apuntes:

1- En principio s60 de Nokia no descargan bien los objetos Image. Dependiendo del dispositivo convine: igualar todas las refs a null, hacer un gc(), un sleep() de pocos milisegundos, y otro gc() ... a veces funciona.

2- TSM7 i G402i (DoJa no MIDP), fabricados por VitelCom, Murcia, tienen un error en el driver de "video". Pueden aparecer puntos blancos en el extremo inferior dererecho de las imagenes que tengan transparencia, dependiendo del numero de colores que tenga su paleta y el la imagen a la que están solapando.

3- [trick] Si quieres visualizar la memoria libre restante recuerda utilizar arrays de char "reservados previamente" y no objetos String, sino verás tu contador de memoria libre decreciendo en cada frame (por la memoria que se consume crear los String cada frame).

4- [trick] No confies nunca en j2me!!!!!!!! Es como la Ley de Murphy: si algo va bien, irá mal.

5- [trick] Busca la mayor compatibilidad posible!!!!! Utiliza solo MIDP1 siempre que puedas. Con directivas como las del tutorial puedes tener los trozos de código específico para cada plataforma. (FullCanvas, vibracion, ...)

6- [trick] Usa imagenes separadas para las animaciones de los sprites (te ahorraràs problemas con el clipping de MIDP1), incluso puedes probar a partir el sprite en trozos reutilizables en varios frames. Si lo que te preocupa es el tamaño la cabecera de los PNGs puedes crearte un archivo que contenga la paleta y la información común de las cabeceras de cada png de la animación, el resto lo construyes en tiempo de ejecución, lo metes en un array de bytes, lo creas como un stream (con "Image.CreateImage")  y a correr.

7- [ultra trick] AHORRO de epacio Jar: Resulta que existe la manera de crear un png con el maximo numero de Rows (es decir, cual pixmap o raw normal y corriente de 8 bits, un array de bytes con el numero de color de la paleta). De manera que si construyes bien la cabecera puedes cargar directamente una imagen en raw, lo que te permite tb crearla invirtiendo las filas y/o las columnas (bienvenidos a los flips/rots en MIDP1). Puedes creer que una imagen en raw ocupa más que un PNG ... pues haz la prueba, y metelo todo en un Jar ... resulta que, a veces, incluso se gana espacio respecto al png. Otras dos ventajas de esto son que te evitas cabeceras innecesarias (el punto 6), y que puedes tener varias paletas por imagen/sprite, solo mete en la cabecera los colores que quieres y listo.

8- El tamaño del código también suele ser problemático (sobretodo en DoJa donde su máximo tamaño es 20kB).
Recuerda comentar todos los xivatos (println) cuando no los necesites.
ProGuard suele hacer un buen trabajo por nosotros, pero debemos facilitarle la tarea. Cualquier clase que solo contenga variable del tipo " final public static ... " (siempre que no sea un array) será eliminada del código ofuscado y los valores de estas variables "inlineados". Así que (por comodidad y legibilidad de código) puedes crearte tus clases (DEF.java, por ejemplo) con tus constantes definidas, sin miedo a que ello implique mayor tamaño de código.
Otro truco es no utilizar bloques "if / else if" para asignaciones sencillas:
Esto:

Código [Seleccionar] Expand

if ( x > 30 ) {
   y = 30;
} else {
   y = x;
}
equivale a esto:

Código [Seleccionar] Expand

y = (x>30)?(30):(x);
[/list]
Bueno son solo algunas sugerencias que he podido aprender por ahi. Pero la más importante es que si haces un juego de móvil, intenta NO HACER nada más de los imprescindible, perderás tiempo que luego no cobrarás. A no ser que quieras hacerte tus herramientas y tenerlas "pa siempre" o venderlas, etc.

Por cierto, muy bueno el código, gracias por compartir :D

Un saludo!

[zheo]

Bueno, aprovecho para presentarme en esta vuestra comunidad con un primer comentario.

Ya que se está utilizando el preprocesador de NetBeans, ¿por qué no utilizarlo también para el log?
Es decir, en el método UTIL_OutputDebugString(String str), en vez de tener

Código [Seleccionar] Expand


if (DEBUG)
{
   System.out.println("DEBUG: " + str);
}

hacer

Código [Seleccionar] Expand


//#if _DEBUG
  System.out.println("DEBUG: " + str);
//#endif


Es una tontería, pero te ahorras el código del condicional, y una variable.

Por cierto, muy interesante el truco 8 TrOnTxU.

[sés]

Para NetBeans puedes hacer esto:

Código [Seleccionar] Expand

//#debug
System.out.println("DEBUG: " + str);

o esto para varias líneas:

Código [Seleccionar] Expand

//#mdebug
System.out.println("DEBUG: " + str);
//#enddebug


De todas formas no es mala idea el uso de constantes. Ese código lo elimina cualquier compilador si DEBUG==false y no dependes de ningún preprocesador.

[ethernet]

Cual es la razón por cual cual usas yield y no un sleep para ceder el hilo de ejecución a otro thread?

[Helius]

Cual es la razón por cual cual usas yield y no un sleep para ceder el hilo de ejecución a otro thread?

Pues simplemente por la definición de yield en la documentación:

Código [Seleccionar] Expand

public static void yield()

Causes the currently executing thread object to temporarily pause and allow other threads to execute.

Pero efectivamente podría usarse sleep(0). De todas formas creo que existían teléfonos que funcionaban mal con sleep y otros que funcionaban mal con yield...  :roll:

Saludos.

[sés]

Yo siempre uso sleep(0).

[chechocossa]

La gente que me hace el testing de Padre Carlos, me decía que en algunos Sony las teclas no les respondían correctamente:

"K700i, w550i

Las teclas de d-pad no responden bien. Tienes que sostener la tecla al menos un segundo antes que responda. Funciona bien el menú pero en el juego no.
Las teclas de números no funcionan tampoco. El 4 debe ser izquierda, el 2 arriba, el 6 derecho, etc."

Buscando en un foro de desarrolladores de Sony-Ericsson leí que una de las causas por la falta de respuestas de las teclas, es que hay que incluir el comando yield()
Cuando lo hice, los problemas en esos móviles desaparecieron.

Por eso, una parte de mi loop es:

Código [Seleccionar] Expand

// Demora para controlar los FPS
           if( loopTime < loopDelay )
           {
               try
               {
                   Thread.sleep(loopDelay - loopTime);
               }
               catch(java.lang.InterruptedException e)
               { }
           }
           else
               Thread.yield();