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:
if ( x > 30 ) {
y = 30;
} else {
y = x;
}
equivale a esto:
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
Un saludo!
