Arkaretro + dib

[zupervaca]

Despues de las peticiones masivas por correo del codigo fuente del arkaretro (me han llegado hasta en frances) me dispongo a liberar el codigo fuente del juego y de la mini-libreria dib para moviles que he hecho, espero que asi tenga dias mas tranquilos y serenos.
Como se ve el codigo no es nada del otro mundo, he intentado siempre hacerlo lo mas cercano a mi filosofica de programacion orientada a objetos, pero por desgracia (mas por tamaño) me he visto limitado a quitar capas de la libreria.

Me gustaria recibir criticas constructivas sobre el codigo de la libreria o por lo menos saber si las cosas se pueden hacer de otra forma mejor y sin aumentar mucho el tamaño final del jar.

Para descargar el juego y el fuente pasaros por mi web o directamente desde aqui: http://www.davidib.com/projects_2006.asp

[bnl]

Muchas gracias por compartir el código.
Le he estado echando un vistazo a algunas de las clases y me ha gustado mucho como lo tienes montado. El código esta muy clarito y legible. Todo encapsulado en la clase que le corresponde.

Lo miraré más detenidamente que seguro que encuentro cosas interesantes.

Como crítica constructiva yo haria un esfuerzo y pondría acentos en la documentación.

[sés]

No lo he visto todo, pero así de golpe te digo lo típico: Estaría muy bien... si fuera para PC

En móviles hay que cambiar el chip y evitar ciertas cosas. Básicamente consiste en volver a la época Spectrum.

- Mínimo número de clases posibles. Tampoco soy partidario de meter todo en una o dos, pero hacer clases por hacerlas no tiene sentido (por ejemplo, la clase Sound podría ir en Kernel o en IMidlet).

- El código en general consume burradas de memoria (activa el monitor de memoria y lo verás), eso jamás funcionaría en ciertos móviles.

- System.gc() es tu mejor amigo, aunque no hace milagros.

- Evita al máximo el uso de Strings... y sobre todo sumarlos; destroza la memoria.

- ¿XML? ¡AAAARRRGGGHHH! *muere*


En fin, creo que peca de todas las "malas" costumbres de la programación actual: código organizado sobre eficiencia, patrones (los odio... *vomita*), XML para todo...

[jazcks]

a mi el código me ha parecido estructurado y claro, gracias por dejarlo a todo el mundo, aunque no esté optimizado como dice sés, siempre es mejor que nada :P

zupervaca, sobre los fps, he probado el arkaretro y a 10 fps es injugable por lo lento que va, y a 60 fps va bien y fluido.
Me pregunto si no debería tardar lo mismo la bola en ir y venir? a 10fps no debería dar saltos mas grandes y tardar lo mismo que en 60fps?

[zupervaca]

jazcks creo que el problema es que lo explico mal, cuando se pone a 10fps es la logica de juego, es decir, en un movil lento bajandole la velocidad se podria jugar ya que no se saltaria imagenes para sincronizarse a 60fps.

Es cierto ses, al principio me puse a hacerlo como tu decias, pero me daba verguenza pensar que algun dia tenia que enseñar ese codigo, con lo que al final me decidi por hacerlo orientado a objetos, aunque al final tuve que saltar varias capas de las que habia hecho para ir directo al grano ya que si no el jar se me ponia en mas de 100KB, no obstante la velocidad de este juego y las optimizaciones que tiene en la parte del render es muy superior a las de muchos, ya que va a 60fps en casi todos los moviles que lo he probado.
El principal motivo de que chupe tanta memoria (~410KB) me parece que es por usar las tablas hash de j2me.

[sés]

Tampoco hace falta hacer un barullo ilegible. Tener (como tengo yo) una función playSound() en lugar de hacer una clase para las cosas de sonido no es ni ilegible ni malo.

En J2ME ya tienes un objeto para el sonido (Player), ¿realmente necesitas hacer un objeto Sound? Esas "malas" costumbres de PC de encapsular por encapsular no son buenas para móviles... ni muchas veces para PC.

En algunos casos sí es bueno hacerlo, pero muchas veces se puede evitar.

Ejemplo:

Código [Seleccionar] Expand

class Point {
   int x, y;

   public Point( int x, int y )
   {
       this.x = x;
       this.y = y;
   }
}

...

Point p = new Point( 10, 10 );


Muy bonito... pero se puede resolver así:

Código [Seleccionar] Expand

int p[] = new int[] { 10, 10 };

Tengo dos enteros y me he ahorrado una clase.

Con cosillas como esta y evitando hacer clases independientes, se ahorra bastante (de memoria y de JAR).


Sobre el ese consumo brutal de memoria... no sé si la Hash tendrá mucho que ver. Ni siquiera sé si tendrá algo que ver. Elimina todos los usos de String y sumarlo, te sorprenderás.

Haz un programa simple que haga un par de chorradas con cadenas (del tipo String s = "hola" + n;) y observa la memoria.
Luego multiplica por el uso de Strings que haces al leer los XML y otras cosas y verás dónde se va tu memoria.

[zupervaca]

Efectivamente hace tiempo mire una web en la que decia que codigos como este sirven para ahorrar espacio en el jar:

Código [Seleccionar] Expand


class OcupaMas
{
   int k, j, h, i, l;
}
class OcupaMenos
{
   int i[5];
}

Pero me parece un codigo ilegible.

Sobre el XML puedes usarlo o no ya que es una capa mas de la libreria para la lectura de recursos.

[sés]

Hombre, tampoco me refiero a eso XD

Me refiero a clases como la que he puesto, que te las ahorras (las clases) con un simple array.
"Ahorrarte" variables como el ejemplo que has puesto a mí también me parece estúpido. Además... yo no aseguraría que lo 1º ocupe más, ten en cuenta que en el 2º caso, para que sirva de algo, tienes que hacer un i = new int[5]. No sé yo cuánte se ahorraría (ni voy a perder el tiempo en comprobarlo XD).

[zupervaca]

Ah bueno, si es por ese tipo de clases es que aun no he agregado toda su funcionalidad, en la practica le faltan funciones tipo sumar, restar, multiplicar, distancia entre dos puntos, etc.

[sés]

Piensa antes si te compensa tener algo como esto:

Código [Seleccionar] Expand

class Point {
   int x, y;
   
   public Point( int x, int y )
   {
       this.x = x;
       this.y = y;
   }
   
   public void add( Point p )
   {
       x += p.x;
       y += p.y;
   }
}


O en alguna clase algo como:

Código [Seleccionar] Expand

public static void Point_add( int p1[], int p2[] )
{
   p1[0] += p2[0];
   p1[1] += p2[1];
}

Incluso puedes hacerte el "constructor" (aunque en este caso no es muy necesario, la verdad):

Código [Seleccionar] Expand

public static int[] Point_Point( int x, int y )
{
   return new int[] { x, y };
}

[MrK]

Haz un programa simple que haga un par de chorradas con cadenas (del tipo String s = "hola" + n;) y observa la memoria.

una pregunta, cual es la alternativa a sumar cadenas? no es que haga nada en java (hara 5 años que ni lo toco), pero en mi epoca yo leia lo mismo pero tampoco me daban una alternativa decente...

[sés]

Haz un programa simple que haga un par de chorradas con cadenas (del tipo String s = "hola" + n;) y observa la memoria.

una pregunta, cual es la alternativa a sumar cadenas? no es que haga nada en java (hara 5 años que ni lo toco), pero en mi epoca yo leia lo mismo pero tampoco me daban una alternativa decente...

StringBuffer


Y, sobre todo, evitar cosas del tipo

Código [Seleccionar] Expand

g.drawString( "Score: " + score, 0, 0, 0 )

Mejor crear la cadena SOLO cuando cambie la puntuación y luego hacer

Código [Seleccionar] Expand

g.drawString( strScore, 0, 0, 0 )

[zupervaca]

Pues ses no lo entiendo, lo he probado en un monton de moviles de amigos y a nadie le ha fallado ademas de irles a 60fps, de todos los juegos que he probado en mi movil el que yo he hecho es el unico que me ha ido a 60fps, los demas no van a mas de 10fps.
Creo que un movil es mas potente de lo que piensa la gente, pero lo que no saben hacer es optimizar la parte del render que es la que mas consume.
He estado mirando el codigo y tampoco uso tanto la clase string ni hago concatenaciones en plan bestia.

Una pregunta que se ve que estas puesto en el tema de moviles, ¿como haces para pintar un StringBuffer en pantalla?

[Vicente]

Una pregunta que se ve que estas puesto en el tema de moviles, ¿como haces para pintar un StringBuffer en pantalla?

Yo de móviles ni idea, pero lo que hará es llamar al toString() de la clase StringBuffer una vez tengas concatenadas las cosas que querías.

Un saludo!

Vicente

[sés]

El StringBuffer se utilizaría a la hora de concatenar, luego se pasaría a un String con toString() y esa cadena es la que se utilizaría en el paint().
Normalmente no se utiliza el StringBuffer a no ser que haya que concatenar muchas cosas.

No sé en qué móviles lo habrás probado, pero me extrañaría que funcionase en los más viejos (y que piden los distribuidores) como los Nokia 3120, 7650 o el SonyEricsson T610. Y hay modelos que, aunque sean potentes, tiene un colector de basura lamentable y se petan a la mínima.