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
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.
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...
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?
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.
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: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í:
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.
Efectivamente hace tiempo mire una web en la que decia que codigos como este sirven para ahorrar espacio en el jar:
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.
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).
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.
Piensa antes si te compensa tener algo como esto:
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:
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):
public static int[] Point_Point( int x, int y )
{
return new int[] { x, y };
}
Cita de: "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...
Cita de: "MrK"Cita de: "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...
StringBufferY, sobre todo, evitar cosas del tipo
g.drawString( "Score: " + score, 0, 0, 0 )Mejor crear la cadena SOLO cuando cambie la puntuación y luego hacer
g.drawString( strScore, 0, 0, 0 )
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?
Cita de: "zupervaca"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
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.
Funciona por que realmente el juego no llega a superar los 100KB en memoria, si le das al boton de "Run GC" (comenzar el recolector de basura) de vez en cuando, veras como el juego se pone en 40KB, mas que aceptable para cualquier cutre-movil, ¿y por que sube a 400KB? sencillo, mientras exista memoria java nunca ejecutara el recolector de basura, cuando se necesite memoria y no este disponible java automaticamente lanza el recolector de basura. (No obstante si que es bueno lanzarlo nosotros mismos de vez en cuando, yo lo hago cuando el estado de la aplicacion cambia.)
La unica pega es lo que mencionas de que algunos moviles tiene recolectores de basura cutres y se petan, pero no se a que te refieres exactamente por que me imagino que sera la misma rutina de recolector de basura para todos los moviles ya que es el j2me de sun.
Cita de: "zupervaca"La unica pega es lo que mencionas de que algunos moviles tiene recolectores de basura cutres y se petan, pero no se a que te refieres exactamente por que me imagino que sera la misma rutina de recolector de basura para todos los moviles ya que es el j2me de sun.
X'DDDDDDDDDDDDDD
Cada uno hace lo que le da la gana e implementa las funciones como le sale del pijo. Es más, muchos móviles ni siquiera llaman al recolector. O le llamas tú, o te da una excepción al quedarse sin memoria. Así de "simple".
Eso debería ser... tener todos la misma implementación de las cosas. Je... que bonito suena XD
He creado tambien en codeplex una web de proyecto para la dib de moviles, podeis visitarla desde aqui: http://www.codeplex.com/Wiki/View.aspx?ProjectName=dibMe
Tienes un fallo en esa web zupervaza. En la página inicial donde salen las características has escrito: Contrador de FPS, supongo que querrás decir Contador de FPS :D
codeplex no era para proyectos que utilicen tecnologias de MS?
Nop, hay unos cuantos proyectos de Linux por allí también. Un saludo!
Vicente
Cita de: "yEnS"Tienes un fallo en esa web zupervaza. En la página inicial donde salen las características has escrito: Contrador de FPS, supongo que querrás decir Contador de FPS :D
ye, vaya fallo jeje, gracias por el aviso.