Eclipseme Contra Netbeans Mobility Pack

[zupervaca]

 pues en principio si es para uso comercial y se paga al grafista deberia hacerlo, ahora si no es para uso comercial los puedo hacer yo mismo :P

si usas los mismos entonces estas pintando mas de la cuenta en vertical en algunos modelos, he de decirte que cambiar el clip es lentisimo en algunos moviles, ten cuidado con eso

[sés]

 Sí, puede hacerlo si se lo mandan, pero no compensa.

Lo del setClip() ya lo sé, pero sin el gastas mucha más memoria ;)

[Zaelsius]

 

cambiar el clip es lentisimo en algunos moviles, ten cuidado con eso

Pues no lo sabía.. habrá que tenerlo en cuenta  (rules)

[_XUTI_H_]

 Ufff, parece que hacer juegos con el J2ME es más complicado de lo que creia ...

Yo he hecho un par, uno en MIDP 2.0 y otro en MIDP 1.0.
El de MIDP 2.0 no funciona en ningun móvil de los que he probado (supongo q porque todos tendrán la 1.0)

Queria saber si me recomendais que gaste librerias especificas de cada plataforma (si realmente las hay) para dibujar y todo eso, como las puedo conseguir, y como las puedo probar en algun emulador. Es que las de dibujado de la MIDP 1.0 dejan bastante que desear en relación con las de la 2.0.

De momento todavía estoy probando e intentando aprender, pero parece q esto cuesta bastante :S

Salu2 a todos.

[Zaelsius]

 Los Nokia tienen algunas clases extra y mejoras. La libreria se llama Nokia UI, y puedes encontrar las descargas de SDK's y documentación en forum.nokia.com(quizá te haga falta registrarte, gratuitamente).

Casi todas las marcas importantes tienen extensiones para J2ME, o SDK's personalizados. Esta es la URL de Sony-Ericsson: http://developer.sonyericsson.com/site/glo...p_java_0906.jsp

Sobre emuladores.. mejor que te aconseje alguien de Windows o Linux. Por lo visto en IDE's lo mejorcito es NetBeans + Mobility Pack.

PD: Tenemos MIDP1.0 para rato.. quizá en 2 años se pueda a empezar a desarrollar en exclusiva para MIDP2.0.(Asia es otra historia)

[_XUTI_H_]

 Vale, he estado investigando y ... , por si a alguien, le interesa me contesto a mi mismo (solo una parte de la pregunta).

Ya he encontrado, d momento en Siemens solo, documentación de las caracteristicas de cada serie y modelo. También la versión del MIDP que soportan. Parece que los que soportan la versión 1.0 del MIDP tienen también una API especial para juegos (en este caso Game Color API o algo así).

Pero los que soportan la MIDP 2.0 no tienen  esta API especial para juegos.

Ahora, las preguntas:

- Para realizar un juego que funcionará (por ejemplo) en varios telefonos Siemens .... usariais la API de Siemens para los que soporten MIDP 1, y la MIDP 2.0 para los dispositivos que la soporten directamente??

- Que opinais de intentar hacer un wrap para las funciones de dibujado y las típicas y diseñar un pequeño motor/api personalizada que soporte varias APIs de varios dispositivos con un interfaz comun????, se perderia mucha eficiencia ???

- De que c**o irán estas APis: JSR 184 3D API, JSR 185 JTWI 1.0, JSR 179 Location API, JSR 185 JTWI 1.0, JSR 184 3D API, JSR 179 Location API, JSR 82 Bluetooth API???
(Solo las tiene algunos modelos, y parece que a parte de ofrecer BlueTooth, y más historiashay algunas para 3d como la JSR 184 3D API, que opinais o sabeis al respecto del 3D en móviles???)


( Estoy aprendiendo, o al menos eso intento, así que no considero de momento los diferentes tipos de formatos gráficos, o de sonido, ni las resoluciones que puedan tener los diferentes dispositivos, ...)

Muchas gracias por la información 10 últimos mensajes [ en orden inverso ]
_XUTI_H_ Escrito el 09/09/05, 17:14
--------------------------------------------------------------------------------
Vale, he estado investigando y ... , por si a alguien, le interesa me contesto a mi mismo (solo una parte de la pregunta).

Ya he encontrado, d momento en Siemens solo, documentación de las caracteristicas de cada serie y modelo. También la versión del MIDP que soportan. Parece que los que soportan la versión 1.0 del MIDP tienen también una API especial para juegos (en este caso Game Color API o algo así).

Pero los que soportan la MIDP 2.0 no tienen esta API especial para juegos.

Ahora, las preguntas:

- Para realizar un juego que funcionará (por ejemplo) en varios telefonos Siemens .... usariais la API de Siemens para los que soporten MIDP 1, y la MIDP 2.0 para los dispositivos que la soporten directamente??

- Que opinais de intentar hacer un wrap para las funciones de dibujado y las típicas y diseñar un pequeño motor/api personalizada que soporte varias APIs de varios dispositivos con un interfaz comun????, se perderia mucha eficiencia ???

- De que c**o irán estas APis: JSR 184 3D API, JSR 185 JTWI 1.0, JSR 179 Location API, JSR 185 JTWI 1.0, JSR 184 3D API, JSR 179 Location API, JSR 82 Bluetooth API???
(Solo las tiene algunos modelos, y parece que a parte de ofrecer BlueTooth, y más historiashay algunas para 3d como la JSR 184 3D API, que opinais o sabeis al respecto del 3D en móviles???)


( Estoy aprendiendo, o al menos eso intento, así que no considero de momento los diferentes tipos de formatos gráficos, o de sonido, ni las resoluciones que puedan tener los diferentes dispositivos, ...)


Muchas gracias por la información ZaelSiuS :)



Bueno, ale, ya teneis pa contestar si quereis.
Hasta luego lukas.
Gracias.

[zupervaca]

 realmente puedes hacer lo mismo con midp 1.0 que con el 2.0, salvo para reproducir sonidos y activar la pantalla completa, esto ultimo falla en algunos moviles con el 2.0 osea que ya ves, la unica ventaja que tiene el 2.0 es lo de siempre, tiene una clase preparada para controlar juegos, pero realmente puedes hacerla tu mismo con la 1.0, mucha gente me dice que el midp 1.0 es imposible hacer que aguantando una tecla un dibujo se mueva por la pantalla del movil y yo les digo que aprendan algo de metodologia ;)

saludos

[_XUTI_H_]

 Veo que para mi es complicado hasta modificar los mensajes sin cagarla XDDDDDDDD

Siento la kagada del mensaje de antes. :(

Solo queria añadir gracias a Zaelsius.

ED: Mi principal problema con la MIDP 1.0 es no poder hacer animaciones de los sprites con un solo PNG. No hay funciones que te recorten un rectangulo de una imagen y lo dibujen en la pantalla, el uncio drawimage que existe dibuja una imagen entera. Se que puedo utilizar un png para cada frame en vez de uno para todos e ir recortandolo, pero ...

[Zaelsius]

 

- De que c**o irán estas APis: JSR 184 3D API, JSR 185 JTWI 1.0, JSR 179 Location API, JSR 185 JTWI 1.0, JSR 184 3D API, JSR 179 Location API, JSR 82 Bluetooth API???
(Solo las tiene algunos modelos, y parece que a parte de ofrecer BlueTooth, y más historiashay algunas para 3d como la JSR 184 3D API, que opinais o sabeis al respecto del 3D en móviles???)

Las JSR son extensiones que pueden estar implementadas por el terminal o no. Las que yo conozco son:

- JSR 135: Permite reproducir multimedia. Segun el terminal, soportará vídeo(3GP), wav, midi o algun formato propietario.
- JSR 82: Conectividad Bluetooth. Se podrán hacer más o menos cosas dependiendo del teléfono.
- JSR 184: Java 3D. Personalmente nunca lo he probado :ph34r: ... pero por ahora no es rentable hacer juegos 3D, por el esfuerzo adicional que representa, y la ausencia de demanda. Algunos analistas llevan varios años diciendo que la siguiente temporada sería "el año de las 3D", pero por ahora nada de nada. Como curiosidad, 3DX Max 6 ya lleva un exportador para el formato de escenas de JSR 184

[zupervaca]

cambiar el clip es lentisimo en algunos moviles, ten cuidado con eso

Pues no lo sabía.. habrá que tenerlo en cuenta  (rules)

yo lo descubri por que en principio queria que de un unico png sacara todos las imagenes para un mapa (el clasico sistema de tiles), y vi como desde el profiler perdia tanto el clip como dibujar la imagen, por eso le decia a ses que tuviera cuidado con usarlo, ya que si emula cosas del 2.0 podria estar emulado la clase sprite (me parece que se llama asi, pero no estoy seguro) y perdiendo mas del 50% de velocidad en todos los moviles

lo que no entiendo es por que dice que se gana memoria si con el profiler me sale lo contrario

saludos

[sés]

 zupervaca:
Se te olvida una de las más importantes: el poder hacer espejos de imágenes, que te ahorra un montón de memoria.

_XUTI_H_:
Sobre lo de utilizar las APIs específicas de cada móvil, la respuesta es sencilla: solo si es necesario.

Sobre lo del wrap... depende. Lo suyo es hacer un código que te sirva para la mayor parte de los móviles. Hacer un wrap para todo no creo que te convenga. Hazlo solo con las cosas realmente necesarias.

Las APIs esas "raras", pues no sé, solo conozco algunas, y precisamente por su nombre (JSR xxx). De 3D aun no he visto nada, pero ya va tocando.

[_XUTI_H_]

 Primero que nada: Gracias a los 3, flipo con lo rápido que contesta la penya, jeje :)

Seguiré investigando, y ya comentaré más cosas sobre mis progresos.

Gracias de nuevo.

[sés]

 

lo que no entiendo es por que dice que se gana memoria si con el profiler me sale lo contrario

1 PNG con 3 imágenes de 32x32 = 96x32
Supongamos 3 bytes por pixel: 96x32x3 = 9216 bytes + objeto Image

3 PNG de 32x32
Cada una: 32x32x3 = 3072 + objeto Image
Total: 9216 bytes + 3 objetos Image

Eso en memoria, que no es tan importante (que si que lo es cuando son muchas).


Lo más importante es el tamaño del JAR. Mete en un JAR 3 PNGs de 32x32 y luego 1 PNG de 96x32 con las mismas imágenes. ¿Ves la diferencia de tamaño?

Ahora multiplica por las imágenes que utilices y mira el espacio y memoria que estás perdiendo.

[AgeR]

 A ver si me aclaro que también soy nuevo en esto  :rolleyes:

La cabecera de un PNG si no tengo mal entendido son unos 200 bytes, de ahí que contra menos imágenes distintas, más ahorras en espacio del JAR.

La idea, a ver si lo pillo, sería meter por ejemplo los tiles sin transparencia en un mismo archivo, tener solo una imagen e ir dibujando partes de ella (según el tile que se quiera dibujar) en el backbuffer. Se supone que es mejor esto que teniendo el PNG grande, hacer por ejemplo 32 imagenes cada una con un tile.

Por otra parte, en MIDP1 las transparencias son una putada gorda para los sprites, ya que estos han de estar necesariamente en archivos separados o pierden la transparencia.... hmmm o pueden estar todos en una misma imagen y luego dibujar uno u otro indicando el offset dentro de la imagen original? (No recuerdo si así se perdía la transparencia).

Hmmmm no se si tiene sentido algo de lo que he puesto  :ph34r:

Por cierto, yo uso NetBeans+mobility pack y aunque no he hecho ninguna virguería aún, el entorno me parece una absoluta pasada.  (ole)  

[Zaelsius]

 Lo forma usual de proceder(para mí al menos) es meter en un sólo fichero PNG todas los frames de una animación, por ejemplo:



Cargamos la imagen entera en un objeto Image, y entonces restringimos la zona a pintar mediante Graphics.setClip(), de manera que sólo dibujamos el frame deseado. La razón de poner los sprites en vertical en vez de en horizontal, es  para aprovechar la coherencia de caché(memoria lineal, etc..).