Eclipseme Contra Netbeans Mobility Pack

[zupervaca]

 veamos yo el sistema que uso es otro completamente distinto, es meter en el jar una imagen completa y particionarla cuando se ejecuta el juego o lo que sea, en memoria no ocupa mas ya que cuando los pngs son leidos usan la paleta del sistema del movil y no una propia, como mucho ocuparemos unos 8 bytes de mas por imagen, pero ... ¿que supone perder 8 bytes por imagen si ganamos un 70% de velocidad? hay que pensar en todo ;), ademas cuantas imagenes al mismo tiempo puedes tener leidas en el movil, unas 100 diciendo una cifra exageradamente alta, como ves el clip no es la mejor solucion en el midp 1.0

saludos

[_XUTI_H_]

 ¿Particionar una imagen cuando se ejecuta el juego?

Puede que sea una buena idea, hace tiempo (cuando intenté convertir el juego q habia hecho en MIDP 2.0 a MIDP 1.0) pensé en hacer algo parecido ...

Hay una funciones por ahí (en la docu del MIDP 1) que es algo parecido a esto:

Código [Seleccionar] Expand


Image createImage(byte[] imageData, int imageOffset, int imageLength)


Pero no sé hasta que punto podria idearse una función que pudiera utilizar esto para particionar una imagen.
Entonces, la segunda solución que propongo (y la que me parece más obvia) es la siguiente:

1º) Cargamos la imagen (suponemos PNG) con el avión reventando de Zaelsius, con esto obtendremos una objeto Image con todos los frames. Notar que esta imagen es "inmutable".
2º) Creamos una imagen "mutable" de rollo off-screen con el tamaño de un frame.
3º) Utilizamos el Setclip sobre el Graphics q obtenemos de la imagen completa para seleccionar que trozo ocupa el frame que queremos recortar.
4º) Dibujamos en la imagen "mutable" la imagen completa clipeada (obteniendo el frame deseado).
5º) Obtenemos un objeto Image "inmutable" con la funcion CreateImage(Image source) a partir de la imagen "mutable" en la que habiamos dibujado en el paso anterior.
6º) Si ya tenemos todos los frames hemos acabado, sino volvemos al paso 3 y recortamos otro frame.


Con esto tendriamos cada frame en un objeto Image individual (con lo que nos ahorrariamos el clip durante el juego), y la imagen guardada en el jar seria un solo archivo PNG.

¿Que os parece, puede funcionar, creeis q se mantendria la transparencia en las imagenes finales con los frames?
Creo que voy a intentar implementar algunas funciones y haré una pequeña libreria de clases. Puede q sea un buen COTW :P

Hasta luego.

[Zaelsius]

 

¿Que os parece, puede funcionar, creeis q se mantendria la transparencia en las imagenes finales con los frames?

En los foros de J2ME.org he escuchado que se suele perder la transparencia en la mayoría de móviles, pero nunca lo he probado. De todas formas cúrrate el COTW, que para mapas de tiles sin tranparencias puede venir bien :)

[zupervaca]

 efectivamente se pierde la mascara de color y como el midp 1.0 no deja indicarsela solo vale para imagenes sin mascara, si tienes mascara no queda mas remedio que usar el clipen tiempo de ejecucion, pero hay que tener en mente que las imagenes con mascara son pocas, el avion y cuatro enemigos en pantalla, por que si metes muchos mas la cagas ;), lo mas importante es que el mapa del fondo se pinta de forma rapidisima y normalmente sus bloques no tienen color de mascara, ¿doble fondo en moviles? juaz

saludos

[AgeR]

 Cuando se crea una imagen "mutable" se crea de color blanco (por lo menos eso pone en la documentación). No sé si para algunos móviles será distinto, pero al menos en midp1.0 standard creo que no me equivoco. Si luego copias una imagen con transparencia encima, lo que obtienes es esa imagen pero en vez de transparencia, tienes un bonito color blanco de fondo.

Por lo visto, habrá que usar Images distintas para cada tile cargado a partir de un unico fichero, si no usan transparencia, y una misma Image para todos los frames de un archivo, e ir haciendo clipping. Supongo que es el modo en el que mejor balance velocidad/espacio se alcanza. Obviamente dependiendo del móvil y/o juego será más recomendable una cosa o la otra.

Total, que al final obtenemos lo mismo de siempre: Todo depende de la gama de móviles para la que compiles.  (grrr)  

[sés]

 Efectivamente, la transparencia se pierde y solo se podría hacer para gráficos que no la utilicen.

Respecto a que son pocos los gráficos que la usan... ejem... ¿qué juego quieres hacer? Porque, salvo decorado y poco más, absolutamente todo usa transparencia. Desde el sprite más tonto de un enemigo, al personaje principal, la fuente que utilices (si la utilizas...).

Por cierto, que probé a pintar un mapa de tiles con setClip() y con imágenes sueltas y tampoco es un aumento de velocidad tan exagerado (pasaba de unos 30 fps a unos 35). Así que solo lo usaría cuando no se utilizan muchos gráficos.
No sé cuál es el límite de imágenes, pero suponiendo que fuera de unas 100... el EdV tenía 40 tiles y era un juego muy sencillo.

En fin, lo de siempre. Todo depende del límite que tengas de memoria y tamaño del JAR.

P.D.: He visto juegos comerciales que con un poco de cuidado se pueden reducir en unas 100Kb, y no exagero.

[Zaelsius]

 Por cierto, he estado mirando la lista de dispositivos en J2MEPolish, y la mayoria de termianles no soportan más de 100kb, ¿cual es el tamaño de JAR máximo recomendado?

http://www.j2mepolish.org/devices/devices-vendor.html

[zupervaca]

 ses no debes de probarlo en el ordenador, debes de probarlo en un movil, yo las pruebas de velocidad las hago sobre un nokia 3650, tambien tienes otra solucion, desde el ktoolbar de sun hay una opcion para emular la velocidad de los moviles, desde el netbeans no se como se hara, veras como mas o menos se come el 50%

saludos

editado: el juego que hice hace años del rockman tiene unos cuantos niveles y muchos dibujitos sueltos, podeis descargarlo de la web y ver el contenido con el winrar mismo ocupa sobre 25kb, tampoco me luci mucho a optimizar ni codigo ni graficos ni nada con lo que si me pusiera a ello seguro que se podria bajar mucho mas

[sés]

 ZaelSiuS:
De nuevo: depende.

Depende del tipo de móviles al que vaya dirigido o de dónde lo pienses distribuir. Creo que en China, por ejemplo, si pasas de 64Kb no te lo venden.


zupervaca:
<_< Evidentemente lo probé en diferentes móviles. Y como dije, depende de los límites que tengas. Si es un juego muy sencillo, con pocos gráficos,  puedes permitirte el "lujo" de tener imágenes separadas, pero en cuanto tengas muchos gráficos verás como te crece el JAR.

[zupervaca]

 ses aun no has entendido la metodologia que sigo para los moviles, en el jar se tiene una imagen muy grande con todos las imagenes de un mapa por ejemplo, luego cuando se ejecuta el juego y es necesaria esa imagen se particiona en varias, asi cuando se necesita pintar alguna zona de esa imagen al estar particionada no hace falta hacerle el clip, si la imagen tiene mascara hay dos alternativas, hacer el clip en tiempo de ejecucion mientras el jugador esta dandole o tener una imagen separada en el jar, todo esto queda oculto al programador con una clase que es la que se encarga de realizar todo

saludos

[sés]

 zupervaca, lo entiendo perfectamente. De hecho, si miras mis mensajes verás que hablo de ello.

Lo que decía es que no sirve de mucho porque la gran mayoría usan transparencia. Así que te toca ponerlos separados en el JAR o usar setClip(). Solo sirve para algunos tiles y poco más.

[zupervaca]

 en los juegos que has hecho ... ¿cuantos tiles tiene mascara y cuantos no?

[sés]

 - EdV -
Pantalla de título: Sin transparencia.
40 tiles: Sin transparenceia.
55 gráficos: Con transparencia.

- Puzzmaniac -
Pantallas de título (varias): Con transparencia.
Chicas (varias): Sin transparencia.
Resto (100+): Con transparencia.


¿Qué juego en condiciones se puede hacer sin utilizar transparencia? ¿Un tetris?

[zupervaca]

 pero ... ¿cuanto ocupa cada juego que tienes? es que por muy poco que ocupen las imagenes superas los 100kb :blink:?

me imagino que el escape del volcan tendra muchas transparencias por la nave que rota, pero no creo que sean necesarias ya que si no recuerdo mal la nave iva siempre por el fondo negro y si colisiona con las paredes es cuando petaba, bueno tampoco lo pude descargar con lo que no estoy muy seguro

saludos

editado: se me olvidaba, me imagino que esas 40 imagenes del edv seran los del fondo y por encima estara la nave y varios objetos que no creo que sean muchos al mismo tiempo, con lo que mas puede tardar a pintar es el fondo y si utilizas el clip estas tardando el doble, a esto mas que nada me refiero

[_XUTI_H_]

 ¡Vaya!, si lo que decis es cierto para hacer un juego para mobiles no podemos superar los 100kb (64kb si queremos que nos lo distribuyan en China).

Mi demo (que solo consta de 1 nivel) ya ocupaba 84kb, pero en un principio no creia que fuera tan importante el tamaño del jar!!!!!

Que sabeis de la memoria del mòbil, quiero decir de si vale la pena contruirse unas clases y todo para ahorrar espacio en el JAR, aunque luego lo pierdas en la memoria principal.

Otra pregunta que se me ocurre, ahora que estoy trabajando en las clases estas, es si merece la pena crear objetos, que a partir de una imagen en el jar, construyan dos Images (por ejemplo) diferentes, una como la original y otra con un espejado (todavía no he probado a implementarlo, :P), para poder utilizar las caracteristicas del espejado de la MIDP 2.0 con la 1.0.

Bueno, son solo especulaciones, todavía estoy trabajando en la fragmentación de los PNG ...

Salu2.