Solo quería decir que he estado probando un poco EclipseME y... bueno.
Por lo poco que he visto, si creo un proyecto J2ME en Eclipse, puedo generar un JAR. La pregunta es: ¿solo uno?
¿Alguien que lo conozca puede aclararme esto?
Si es así, supongo que la única solución es usar Ant+Antenna. Lo que quiere decir que Netbeans me parece infinitamente mejor para J2ME.
Saludos Sés:
Yo he usado de forma bastante básica el EclipseME, pero no se si entiendo bien tu pregunta:
¿A qué te refieres exactamente con que solo permite general un jar? O_O
Por cierto, ya que el Netbeans Mobility Pack está tan bien...¿podrías pasarme algún enlace para descargarlo? (ole)
Ta luegor (twist)
Me refiero a que creas un proyecto, le das a "build" (o como se llame) y compila y genera UN JAR.
¿Hay posibilidad de crear varios o hay que crear diferentes proyectos?
Aquí tienes unos enlaces de NetBeans:
NetBeansNetBeans 5.0 Release InfoEn este último enlace tienes a la derecha "Download development build". Ahí selecciona Q-Build y el SO que quieras. Bájate los dos primeros enlaces (23 August), que son NetBeans y su correspondiente Mobility Pack.
Información sobre lo nuevo de esta versión del Mobility Pack
aquí.
Ya se a qué te refieres y por lo que yo conozco, para obtener distintos jar tienes que crear distintos proyectos.
Gracias por los enlaces, la verdad es que el NetBeans tiene buena pinta.
Lo utilizaré en cuanto pueda y ya te contaré.
Salu2
yo desde que dijiste que netbeans esta muy bien para programar en moviles me lo he descargado y hechado un vistazo, pero por lo que veo realmente no te solucionan el problema de asegurarte que funcionara en los moviles ya que por ejemplo para el nokia 3650 que tengo aqui poniendo midp 1.0 y clcd 1.0 he compilado un ejemplo que trae y se me cierra la app y desde el emulador va de perlas, me parece que sigo prefiriendo el block de notas :lol:
saludos
Pues yo me c*** en Sun y en su política de ignorar Mac OS X como sistema de desarrollo. Sólo sacan paquetes para Windows y Linux. Lo mismo para el Mobility Pack de NetBeans <_< .
Tendré que seguir con
Xcode +
MPP +
Antenna
Es que NetBeans no hace magia ^_^
Te da lo necesario para que TÚ puedas hacer que funcione en diferentes móviles. NetBeans no hace nada porque tú digas MIDP-1.0 en vez de MIDP-2.0.
Lo que sí que tiene es la posiblidad de definir varias configuraciones (cada una genera un JAR), donde puedes definir TODAS las propiedades de cada de cada JAR (JDK, fuentes y recursos a utilizar...) y preprocesador. Cualquiera que haya programado en C sabe lo que eso significa.
Ais... tanto huir del preprocesado...
Siempre ha sido útil y siempre lo será. No sé a qué esa manía de olvidar todo lo bueno que tenía C. Al final han tenido que implementarlo.
Ses, muchisimas gracias por esos enlaces y toda la info, la verdad es que me pica mucho la curiosidad....
esto...y la base grafica, me refiero a GetPixel() y demas.... te lo ofrece Java o hay una minilib para los moviles??
PD: quien dice grafica...dice sonido, teclas, etc.. todo el bajo nivel vamos
CitarEs que NetBeans no hace magia ^_^
hace todo lo contrario ya que desde el block de notas hago apps que funcionan correctamente desde el nokia 3650 con el ktoolbar y con el netbeans sus propios ejemplos fallan
CitarLo que sí que tiene es la posiblidad de definir varias configuraciones (cada una genera un JAR), donde puedes definir TODAS las propiedades de cada de cada JAR (JDK, fuentes y recursos a utilizar...) y preprocesador. Cualquiera que haya programado en C sabe lo que eso significa.
yo estoy acostumbrado a usar el preprocesador para compilar directx u opengl para windows y linux y no se que tiene que ver para compilar con midp 1.0 si es un standard para todos los moviles que usan java, si usara cosas de midp 2.0 que no rualran en el midp 1.0 todavia, pero es que son ejemplos del propio netbeans con el midp 1.0
la verdad es que me ha decepcionado mucho el netbeans, no logro entender como es que sigue siendo mejor usar el block de notas y el ktoolbar para compilar para midp 1.0
saludos
pd: ses no estoy no estoy criticando lo que has puesto, tus frases las pongo por que apartir de ellas puedo aclarar mejor mis opiniones sobre el netbeans
editado: con esto podemos solucionar todos los problemas de compatibilidad
http://www.j2mepolish.org/
El preprocesador su utiliza (igual que en C), para compilar ciertas partes según unos parámetros. Así, si es MIDP-1.0, puedes compialr un código y si es MIDP-2.0, otro distinto. Pero eso es algo que haces tú, no el NetBeans.
Y que los ejemplo de "una beta" no funcionen en un determinado móvil no veo importancia puede tener.
Otra cosa que tienes que tener en cuenta es que los Reyes Magos no existen.. .digo... ^_^ Que eso de "estándar MIDP 1.0" suena muy bonito, pero no es cierto. Hay cosas que, por muy estándar que sean, no te van a funcionar en algunos móviles.
¿Y qué tiene de bueno el NetBeans?
Prueba a hacer un juego normalito, que funcione en todos los móviles y que aproveche sus características.
Haz un .java para pantallas pequeñas, otro para pantallas medianas, otro para pantallas grandes... y cada uno de esos para MIDP-1.0, MIDP-2.0... ¿y qué tal una versión para i-mode? lo que ya hacen 12 códigos diferentes. Multiplica por las clases adicionales que uses y que puedan cambiar. Luego compila y empaqueta cada uno con sus recursos (con gráficos grandes, pequeños, medianos... unos con sonido, otros sin sonido, unos con midi, otros con mp3, otros con wav....). Y no olvides los iconos (12x12, 24x24...).
¡Uy!, se me olvidaba que algunos usan JDKs propias... adiós el "estándar". Usas su JDK para sonido y demás u olvídate.
...y ese modelo que anda escaso de memoria... y ese otro que no tiene softkeys... y ese que tiene el fallo X y tienes que hacer nosequé para que funcione una tontería...
:lol: Bienvenido al "maravilloso" mundo de los móviles.
Esto lo resuelves con NetBeans con diferentes configuraciones y unas instrucciones de preprocesador. Ahora dime cómo lo resuelves con el Bloc de Notas :P
CitarEl preprocesador su utiliza (igual que en C), para compilar ciertas partes según unos parámetros. Así, si es MIDP-1.0, puedes compialr un código y si es MIDP-2.0, otro distinto. Pero eso es algo que haces tú, no el NetBeans
ya lo se, pero te estoy diciendo que si el codigo solo es midp 1.0 no hace falta
la mejor solucion que veo por el momento es el polish que tiene una base de datos con casi todos los moviles (segun ellos unos 300 y se puede ampliar) y diciendole para que lo quieres compilar ya se ruca el para que funcione
he estado mirando paginas web de juegos para moviles y hay muy pocos ya para el nokia 3650, ¿cuantos moviles usan aun el midp 1.0? por que no se que me da que le quedan dos dias
Cita de: "zupervaca"con esto podemos solucionar todos los problemas de compatibilidad http://www.j2mepolish.org/
Ya lo estuve mirando, pero más que facilitar las cosas me da la impresión de que las complica. En el sentido de que tienes que hacer las cosas como el te dice.
Los recursos, por ejemplo, me parece un asco como lo organiza.
Según su bonita base de datos, tienes que meter los recursos para pantallas de 176x208 en resources/ScreenSize.176x208.
¿Y qué pasa con los de 176x220? O sea, que si tengo un móvil que tiene un pixel más por algún sitio, me obliga a copiarme todos los recursos en otro directorio, o no me los coge.
De verdad, no creo que valga la pena el tener tantas separaciones pro modelos y tanto tocar en XMLs.
En NetBeans, si quiero un modelo (o grupo de modelo similares), creo una configuración del tipo: MIDP2_176x200 (tamaño informativo, sirve para todos los similares).
* Le digo que recursos quiero:
- res/sounds
- res/spr176
* Le digo la JDK: WTK 2.2 (opr ejemplo)
Y poco más.
Con tener unos "defines" en cada configuración que indican sus características, yastá. Solo he tenido que pinchar unos botones.
Ya te digo, J2ME Polish me parecía muy bonito hasta que intenté usarlo para compilar las versiones que necesitamos y vi que perdía mucho tiempo en instalar lo que pide, leerse la documentación, organizarlo en SUS directorios, etc.
Al final me hice 3 ó 4 proyectos con JBuilder y obtuve las versiones que viene en la página de Movilenio.
Citarya lo se, pero te estoy diciendo que si el codigo solo es midp 1.0 no hace falta
Como te he dicho: olvídate de eso de que es un estándar.
Por muy MIDP-1.0 que sea, vas a tener diferencias en un modelo a otro.
Citar¿cuantos moviles usan aun el midp 1.0? por que no se que me da que le quedan dos dias
Y te sorprenderías de la cantidad de móviles con MIDP-1.0 que quedan :P
no entiendo el por que se dice que el midp 1.0 no es tan estandar, el juego que hice yo para moviles hace ya un par de años funciono en todos los moviles que se probo y eran de diferentes marcas y modelos, aun tengo amigos que lo descargan a sus nuevos moviles y dicen que les va de maravilla
si una resolucion es de 176x208 y otra es de 176x220 veo muy importante que sean recursos diferentes ya que por ejemplo en el ultimo juego que has hecho que el fondo es una imagen que no debe de estirarse ni adaptarse de ningun modo no valdria para los dos y se tendria que decir al grafista que le toca currar en esos dos modos, ya lo se, todos sabemos que el grafista se va a hechar las manos a la cabeza, pero por suerte en los moviles hay juegos que se pueden hacer sin grafistas (twist)
saludos
Cita de: "zupervaca"no entiendo el por que se dice que el midp 1.0 no es tan estandar...
Si es un juego sencillo, no habrá mayores problemas, pero en cuanto hagas cosas más complejas verás cómo te llevas palos por confiar en ese "estándar". Por ejemplo: Excepción porque en cierto terminal tienes un tamaño máx. de imagen (o ancho máximo...), métodos que no devuelven lo que deberían o no los tienen implementados...
Cita de: "zupervaca"si una resolucion es de 176x208 y otra es de 176x220 veo muy importante que sean recursos diferentes ya que por ejemplo en el ultimo juego que has hecho que el fondo es una imagen que no debe de estirarse ni adaptarse de ningun modo no valdria para los dos
^_^ Me gustaría ver cómo se lo dices a un dibujante. ¿Y para 176x196 hace otra versión?
En mi juego sirven los mismo gráficos para esas versiones.
Cita de: "zupervaca"por suerte en los moviles hay juegos que se pueden hacer sin grafistas
Eso solo sirve si:
- no piensas venderlo (o venderlo mucho).
- es realmente sencillo.
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í, puede hacerlo si se lo mandan, pero no compensa.
Lo del setClip() ya lo sé, pero sin el gastas mucha más memoria ;)
Cita de: "zupervaca"cambiar el clip es lentisimo en algunos moviles, ten cuidado con eso
Pues no lo sabía.. habrá que tenerlo en cuenta (rules)
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.
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.jspSobre 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)
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.
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
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 ...
Citar- 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
Cita de: "ZaelSiuS"Cita de: "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
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.
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.
Cita de: "zupervaca"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.
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)
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:
(http://www.alu.ua.es/j/jgf8/blog/jet.png)
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..).
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
¿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:
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.
Citar¿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 :)
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
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)
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.
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
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
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.
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
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.
en los juegos que has hecho ... ¿cuantos tiles tiene mascara y cuantos no?
- 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?
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
¡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.
En principio he de decirte que un juego de un movil no suele ser gran cosa, es decir, que su objetivo es entretener mas que nada durante un periodo de 30 minutos o asi, no es como un juego de ordenador que te puede durar una semana, partiendo de esto los graficos no deben de ser nada espectaculares y se premia lo original que sea y su jugabilidad (recuerda que se juega con las fastidiosas teclas de los moviles, a los 10 minutos tienes los dedos reventados), partiendo de toda esta parrafada que fijo que ya sabias yo creo que para muchos moviles lo mejor es tener las imagenes sueltas en el propio jar, tambien puedes hacer otra solucion y es utilizar la funcion createImage en la que indicas un array de bytes que puedes leer de un archivo, en ese archivo puedes tener todas las imagenes y un indice con todos los offsets de ellas, asi tienes todas las imagenes en un archivo y luego en memoria las tienes por separado, sobre la memoria de los moviles no se que decirte ya que no tengo ni idea
saludos
editado: para particionar los pngs puedes usar un codigo similar a este
Image imgOri = Image.createImage( strFileName );
Image imgDest = Image.createImage( nWidth, nHeight );
Graphics gDest = imgDest.getGraphics();
gDest.drawImage( imgOri, -nX, -nY, Graphics.TOP | Graphics.LEFT );
imgOri es la imagen origen, imgDest seria la imgen donde se guardara el recorte, nX y nY son las coordenadas x e y del origen de la imagen y nWidth y nHeight con el ancho y alto de la imagen
De esta manera copias un trozo de una imagen en otra del tamaño que le indiques, si tienes mas dudas dimelo
Si Zupervaca, es la idea que habia planteado antes para fragmentar, y la clase para los fondos con tiles ya está casi implementada. Pero, sigo sin poder conservar las transparencias!!!!!, arrggg
Bueno, creo que es imposible. Además tienes razón, los juegos para móviles son juegos de media hora, no creo que se pueda seguir "exprimiendo" mucho más el tema, ni lograr un gran juego, ni construir las librerias que soñamos y que funcionen en todos los móviles sin perder eficiencia, ...
Creo que relajaré un poco el tema del J2ME, pero el COWT lo acabo por mis c*j*n*s!!
Ale, saludos a tothom.
Cita de: "zupervaca"...un juego de un movil no suele ser gran cosa, es decir, que su objetivo es entretener mas que nada durante un periodo de 30 minutos o asi...
Cita de: "zupervaca"...partiendo de esto los graficos no deben de ser nada espectaculares...
Con esa mentalidad no me extraña que el mercado se sature de juegos basura.
Hoy en día se pueden hacer juegos bastante majos, solo es cuestión de currárselo un poco.
Evidentemente, si derrochas memoria (separando imágenes), espacio en el JAR (con imágenes sueltas) y además, aparentemente, no necesitas máscaras en las imágenes (¿ein?)... sí, efectivamente así se hacen juegos como dices.
"Tu" sistema lo he entendido desde el principio, y repito que no es que esté mal. Lo que digo es que solo sirve si no usas muchos gráficos y además no tienen transparencia. En cualquier juego en condiciones tienes bastantes gráficos, y muchos con transparencia.
Lo de las transparencia, por cierto, me ha dejado alucinado. Eso no se hace desde los inicios del Spectrum. ¿Pero qué juego se puede hacer sin usarla?
El EdV no tiene el fondo negro, eso quedaría fatal. Aunque lo tuviera, si ni el fondo ni la nave tuvieran transparencia, ¿qué pasaría cuando te acercases a una pared?
Seriedad, hombre, seriedad...
Cita de: "_XUTI_H_"Pero, sigo sin poder conservar las transparencias!!!!!, arrggg
Bueno, creo que es imposible.
:P Ya se ha dicho en varias ocasiones.
Cita de: "_XUTI_H_"...los juegos para móviles son juegos de media hora, no creo que se pueda seguir "exprimiendo" mucho más el tema, ni lograr un gran juego, ni construir las librerias que soñamos y que funcionen en todos los móviles sin perder eficiencia, ...
Todo eso es falso. No te rindas tan pronto y sigue dándole.
Los juegos para móviles no son paramedia hora.
El tema lo puedes exprimir lo que quieras ^_^.
Sí que se puede lograr un gran juego (Splinter Cell, Zuma...).
Y sí puedes contruir una librería. Puede que sea lo que te gustaría, pero algo se puede hacer.
El problema de los juegos para móviles es.. bueno, mejor abro otro hilo, que esto ya me parece demasiado fuera del tema.
bueno despues de un comentario asi ses esta claro que no se pueden dar ideas ni opiniones en los foros ya que no las lees sencillamente, no he leido siquiera tu post entero ya que me he quedado en esta linea
CitarEvidentemente, si derrochas memoria (separando imágenes), espacio en el JAR (con imágenes sueltas) y además, aparentemente, no necesitas máscaras en las imágenes (¿ein?)... sí, efectivamente así se hacen juegos como dices
yo nunca he dicho que se haga asi, si leyeras mis anteriores post no dirias estas cosas o pensarias antes de escribirlas, yo nunca he dicho que las imagenes esten sueltas en el jar, yo nunca he dicho que se hagan los juegos sin transparencies, la verdad es que en tu ultimo post te has lucido, esto no es tener razon o no, es aportar ideas nuevas para ahorrar espacio en el jar y ganar un 50% de velocidad, ¿no te lo crres? leete mi anterior post
saludos
Tú si que no lees.
He repetido hasta hartarme que
no está mal, pero que no sirve en un juego en condiciones.Solo sirve para algunos (y no todos) tiles y poco más.
También he repetido varias veces que depende de los límites que tengas de memoria y tamaño del JAR.
He razonado cada una de mis opiniones, te he dado cifras de juegos REALES, y aun así sigues en tus trece.
La frase (mía) que marcas... pues sí, es así. Tú mismo lo dijiste en tu anteriores mensajes:
Citar...pero hay que tener en mente que las imagenes con mascara son pocas...
Citar...un juego de un movil no suele ser gran cosa, es decir, que su objetivo es entretener mas que nada durante un periodo de 30 minutos o asi, no es como un juego de ordenador que te puede durar una semana, partiendo de esto los graficos no deben de ser nada espectaculares...
Resumido: los juegos de móviles han de ser una patata... [ironia]añado: a ser posible cuadrada (sin transparencia)[/ironia].
bueno esto es cansino, vamos a ver, ¿cuantas imagenes con mascara pintas en el juego y cuantas sin mascara? a que pintas mas sin mascara que con mascara, claro, todo el fondo del juego no tiene mascara, si estas perdiendo el 50% de velocidad en pintar el fondo quiere decir que con mi sistema podrias pintar dos fondos como el que pintas tu para que fuera a la misma velocidad del juego, ¿te gusta mas esta comparativa para saber lo que es un juego en condiciones o no?
te he puesto mil veces en varios posts que para los tiles del fondo se usa mi sistema y para los sprites con mascara el setclip, ¿entonces por que dices que mi sistema no sirve para hacer juegos en condiciones si es como el tuyo pero mejorado? creo que sigues sin entenderlo
saludos
Y dale con el 50%.
Te dije que comprobé la velocidad en varios móviles y solo ganaba unos pocos fotogramas. Pero la prueba era SOLO CON LOS TILES. En un juego completo eso prácticamente no lo notarás.
Además, puestos a ganar velocidad, y si no nos importa la memoria, hay otros métodos mejores.
pues no lo has probado en un nokia 3650 que es el que hago yo las pruebas, y los tiles ocupan todo el fondo, pintas mas tiles sin mascara que cualquier otra cosa