8) Hi people! paso por aca a ver cual de los padres de la criatura me explica esto please!
import "mod_say";
import "mod_text";
import "mod_video";
import "mod_screen";
import "mod_scroll";
import "mod_proc";
import "mod_grproc";
import "mod_wm";
import "mod_key";
import "mod_joy";
import "mod_map";
import "mod_draw";
import "mod_mouse";
import "mod_multi";
import "mod_math";
import "mod_sound";
import "mod_rand";
//import "mod_file";
//import "mod_regex";
import "mod_string";
//import "mod_curl";
estos son los mods que estoy usando, y cuando exporto a android el juego hace crash! y ni siquiera logro ver la primera pantalla del juego, que rayos pasara???
trate de hacer un testeo de los modes desde bluestacks pero no corrio en lo mas minimo! alguien puede explicarme cual de esos mods pudiera estar matando la app?? saludos
las mods que estan comentadas fueron porque pense de momento que pudieran ser pues nunca las habia testeado en android!
link del demo para pc: https://www.youtube.com/watch?v=fEiVZXt2iew (https://www.youtube.com/watch?v=fEiVZXt2iew)
nota: cabe acotar que antes usaba una res de 400x400, actualmente usa una de 640x400, pero igual no me anda, he probado en modo landscape y en portrait, y nada!!! como ven he comentado algunos modulos que pudieran estar crasheando al app pero tampoco! ya el apk pesa 64Mb aprox, no se si eso tenga que ver! saludos!
muy bueno el video...
asi como esta, funciona en otras plataformas no android?
Quote from: SplinterGU on July 15, 2016, 02:43:44 PM
muy bueno el video...
asi como esta, funciona en otras plataformas no android?
afirmativo!! bueno solo he compilado para windows!! estoy viendo para sacar una version linux!!
pero en cuanto al windows mola bien!!!
pense que era por lo de las fuentes a 32bpp, no era eso
pense que era por las mods
por include que tenia
por una rutina mia mal empleada con mod_multi
las resoluciones de video
el modo de escala
he intentado practicamente todo lo que por sospecha creo tenga relacion con que no pueda ejecutarse el juego!!! :( madre mia!!!
El juego mola, pero el AVGN te iba a pegar un tirón de orejas por usar un arma con trayectoria en arco descendente (la roca del Friday 13rd...) :D :D :D
Lo que suelo decir en estos casos es que no es culpa de los mod ni de Bennu en general. Primero tienes que descartar que no tienes algún puntero suelto por ahí haciendo lo que no debe, o un FPG que no se ha cargado y causa problemas al usar algún graphic_info, map_get_pixel o cualquier cosa así. Deberías hacer una traza del programa a ver dónde falla, por ejemplo, poniendo un comando debug en la línea 1, y ver qué tan lejos llega.
Si no llegase a ese debug de primera línea o a algún say, entonces sí que se le puede echar la culpa a Bennu.
A no ser que el APK, descomprimido, pese muchísimo más, y estés probando en un dispositivo con la memoria muy justa. 64MB podría llegar a pesar 256MB porque los APK son ficheros comprimidos ZIP, y los FPG normalmente se crean sin compresión, pero para que con 256MB falle, tu dispositivo debería tener menos de 400MB de RAM y tu cargar todos los recursos a la vez.
Quote from: Drumpi on July 15, 2016, 04:04:10 PM
El juego mola, pero el AVGN te iba a pegar un tirón de orejas por usar un arma con trayectoria en arco descendente (la roca del Friday 13rd...) :D :D :D
Lo que suelo decir en estos casos es que no es culpa de los mod ni de Bennu en general. Primero tienes que descartar que no tienes algún puntero suelto por ahí haciendo lo que no debe, o un FPG que no se ha cargado y causa problemas al usar algún graphic_info, map_get_pixel o cualquier cosa así. Deberías hacer una traza del programa a ver dónde falla, por ejemplo, poniendo un comando debug en la línea 1, y ver qué tan lejos llega.
Si no llegase a ese debug de primera línea o a algún say, entonces sí que se le puede echar la culpa a Bennu.
A no ser que el APK, descomprimido, pese muchísimo más, y estés probando en un dispositivo con la memoria muy justa. 64MB podría llegar a pesar 256MB porque los APK son ficheros comprimidos ZIP, y los FPG normalmente se crean sin compresión, pero para que con 256MB falle, tu dispositivo debería tener menos de 400MB de RAM y tu cargar todos los recursos a la vez.
puntos importantes los que has tocado! bueno en cuanto a los primeros si que todo va bien, de ser asi no me hubiese hecho un walkthrough del juego anoche, ayer me lo jugue de principio a fin y grabe una demo de la que edite dos videos que estan en mi instagram! pero en cuanto al peso de los archivos pues si, los fpg son mas o menos pesados!! cuando hice las primeras pruebas pues el fichero no pesaba tanto, actualmente uno pesa
200Mb el stage 1, y el otro es del stage 2 pesa
154Mb, crees que pueda ser eso??? ::) ???
Que te funcione el juego en una plataforma no significa que en otra no te falle. Yo he estado jugando a mis juegos mil veces, y ha sido al portarlos a Wiz o a Linux que he visto algún puntero mal puesto (de hecho, hace dos semanas con el propio Echo, y el juego lleva publicado unos 6 años ya). incluso al añadir algo nuevo.
El problema de los punteros es que en ocasiones parece que todo funciona porque no tocan nada importante a la vista, pero en algún momento eso puede cambiar y ser una hecatombe. Por eso son tan difíciles de programar bien, y por eso es imprescindible un control exahustivo de los mismos, y que sólo puedan acceder a ellos un grupo muy limitado de funciones (por eso me gustan las clases de Java).
Respecto al peso del juego, pues depende de varios factores. Por ejemplo ¿cargas esos mapas al principio del programa o sólo cuando los vas a usar? ¿coincide el crash del juego con el momento de la carga? ¿Cuanta RAM tiene el dispositivo en el que lo estás probando y cuánto es, más o menos, el tamaño de lo que has cargado en el momento del crash? (hablando siempre de los ficheros en tu sistema Linux, sin comprimir, claro).
Ten en cuenta que Android es un SO muy pesado, exige una máquina el doble de potente que el mínimo recomendable en PC para hacer lo mismo, y sólo en RAM ya necesita más de 200MB sólo para el sistema (aparte de lo que necesiten las aplicaciones abiertas en segundo plano, como facebook, los SMS, whasapp...).
Por ejemplo, en Wiz tu juego no va a funcionar nunca, porque no cabe en la RAM.
PD: normalmente, cuando voy a hacer un juego para Wiz, pienso que lo voy a hacer para Wiz, no lo hago para PC y luego intento meterlo en la consola, porque por lo general no me cabe. Es mejor ir programando e ir probando en la consola de vez en cuando para ir viendo dónde están los límites, si no, te pasa como me pasó a mi con el port de Venturer, que no cabía en la portátil y me tiré seis meses intentando reducirlo para al final acabar cancelando el proyecto completado al 90%, y ahora es un desastre de ficheros fragmentados :S
No digo que no lo intentes, un dispositivo Android supera en 8 veces la potencia de la GP2X y es muy probable que consigas que te funcione, pero para otra vez, intenta hacerlo así y no ser tan ambicioso (¡200MB de nivel! ¡ni en el juego más bestia que tengo consumo tanta memoria!).
Quote from: Drumpi on July 15, 2016, 05:02:50 PM
Que te funcione el juego en una plataforma no significa que en otra no te falle. Yo he estado jugando a mis juegos mil veces, y ha sido al portarlos a Wiz o a Linux que he visto algún puntero mal puesto (de hecho, hace dos semanas con el propio Echo, y el juego lleva publicado unos 6 años ya). incluso al añadir algo nuevo.
El problema de los punteros es que en ocasiones parece que todo funciona porque no tocan nada importante a la vista, pero en algún momento eso puede cambiar y ser una hecatombe. Por eso son tan difíciles de programar bien, y por eso es imprescindible un control exahustivo de los mismos, y que sólo puedan acceder a ellos un grupo muy limitado de funciones (por eso me gustan las clases de Java).
Respecto al peso del juego, pues depende de varios factores. Por ejemplo ¿cargas esos mapas al principio del programa o sólo cuando los vas a usar? ¿coincide el crash del juego con el momento de la carga? ¿Cuanta RAM tiene el dispositivo en el que lo estás probando y cuánto es, más o menos, el tamaño de lo que has cargado en el momento del crash? (hablando siempre de los ficheros en tu sistema Linux, sin comprimir, claro).
Ten en cuenta que Android es un SO muy pesado, exige una máquina el doble de potente que el mínimo recomendable en PC para hacer lo mismo, y sólo en RAM ya necesita más de 200MB sólo para el sistema (aparte de lo que necesiten las aplicaciones abiertas en segundo plano, como facebook, los SMS, whasapp...).
Por ejemplo, en Wiz tu juego no va a funcionar nunca, porque no cabe en la RAM.
PD: normalmente, cuando voy a hacer un juego para Wiz, pienso que lo voy a hacer para Wiz, no lo hago para PC y luego intento meterlo en la consola, porque por lo general no me cabe. Es mejor ir programando e ir probando en la consola de vez en cuando para ir viendo dónde están los límites, si no, te pasa como me pasó a mi con el port de Venturer, que no cabía en la portátil y me tiré seis meses intentando reducirlo para al final acabar cancelando el proyecto completado al 90%, y ahora es un desastre de ficheros fragmentados :S
No digo que no lo intentes, un dispositivo Android supera en 8 veces la potencia de la GP2X y es muy probable que consigas que te funcione, pero para otra vez, intenta hacerlo así y no ser tan ambicioso (¡200MB de nivel! ¡ni en el juego más bestia que tengo consumo tanta memoria!).
es que ni siquiera abre!! jajajaja voy a tener que hacer un build linea alinea hasta conseguir la falla, o un trazado xD
este es el reporte!! no se si ustedes puedan ver algo que yo por mi inexperiencia! , adjunto imagen de reporte del pixStudio
he comentado las lineas a los fpg, he movido los fpg, coloque unos textos al inicio antes de cargar varios recursos!! y aun se cae!! :( que triste es mi vida jajajajaa
:o he clonado la carpeta y me he borrado todos los procesos dejando solo una funcion que al tocar la esquina superior derecha haga que el juego salga, he comentado la carga de los recursos fpg, en su mayoria he dejado el codigo casi que como en un principio y en mandado a andar el builder y noto algo con bastante intriga, aunque he comentado lineas de codigo y he borrado mas de 3000, aun persiste esto error que ni siquiera deja que el juego corra!! ahora si me ha ganado la intriga, porque aun sigue pesando casi 70.000MB??? a que se debe???
Quote from: fulgorelizz on July 15, 2016, 09:39:32 PM
:o he clonado la carpeta y me he borrado todos los procesos dejando solo una funcion que al tocar la esquina superior derecha haga que el juego salga, he comentado la carga de los recursos fpg, en su mayoria he dejado el codigo casi que como en un principio y en mandado a andar el builder y noto algo con bastante intriga, aunque he comentado lineas de codigo y he borrado mas de 3000, aun persiste esto error que ni siquiera deja que el juego corra!! ahora si me ha ganado la intriga, porque aun sigue pesando casi 70.000MB??? a que se debe???
Lo primero.... ¡Se ve muy bien tu juego!
Respecto al peso.... A mí me pasa que si defino arrays muy gordos, el dcb sube como la espuma.
Y el crack, pues me ha pasado desde un puntero mal 'apuntado', hasta intentar leer en un array fuera del rango.
¡Suerte!
Quote from: Fede on July 15, 2016, 11:08:31 PM
Quote from: fulgorelizz on July 15, 2016, 09:39:32 PM
:o he clonado la carpeta y me he borrado todos los procesos dejando solo una funcion que al tocar la esquina superior derecha haga que el juego salga, he comentado la carga de los recursos fpg, en su mayoria he dejado el codigo casi que como en un principio y en mandado a andar el builder y noto algo con bastante intriga, aunque he comentado lineas de codigo y he borrado mas de 3000, aun persiste esto error que ni siquiera deja que el juego corra!! ahora si me ha ganado la intriga, porque aun sigue pesando casi 70.000MB??? a que se debe???
Lo primero.... ¡Se ve muy bien tu juego!
Respecto al peso.... A mí me pasa que si defino arrays muy gordos, el dcb sube como la espuma.
Y el crack, pues me ha pasado desde un puntero mal 'apuntado', hasta intentar leer en un array fuera del rango.
¡Suerte!
saludos!! gracias!! bueno como comente anteriormente me he bajado mas de 3000 lineas de codigos he desaparecido los vectores bidimensionales o matrices, la reduccion en todo ha sido considerable! al punto de dejar solo unos textos que imprimo de manera de debbugear al app desde bluestacks, estoy viendo si puedo leer algun registro de errores desde bluestacks pero aun no consigo nada!!! gracias por el aporte!! en cuando a los apuntadores pues ya no tengo nada con graphic_info (de momento pense que seria esto) tampoco tengo algun write_int , ni mucho menos algun pointer que por mi cuenta haya declarado, no he tenido la necesidad de usarlos por ahora!!!
??? lo que he empezado a hacer es crear paso a paso el esqueleto del programa e ir incluyendo paulatinamente los mods, hasta tener la totalidad del esqueleto armado, incluyendo bloque de presentacion, cargas de recursos, y todas estas cosas hasta lograr ver si se hace crash el juego o no! hasta el momento todo bien! si consigo algo se los dejo saber! saludos
:-X pues el mod_curl para android es una de las causas del crash!
pero aun cuando saco el mod_curl y las lineas de codigo vinculada a las funciones del mod, pues sigue el problema!! al culminar el esqueleto, pasare paulatinamente los procesos del primer codigo a este nuevo esqueleto para ver que me consigo jejejeje estare en contacto! suficiente por hoy!!!
no se si en pixtudio para android hay compilacion con -g y ejecucion con -d, si es asi, y podes crearte un script, ejecutalo con -d de debug y redirecciona la salida a un archivo, asi vemos donde muere.
Pregunta tonta: ¿Has compilado algún "Hello world" con Android antes de ponerte a saco con tu juego? A ver si lo que falla es tu compilador...
Si no, ve añadiéndole módulos al "hola mundo" hasta que falle.
¡¡¡¿¿70000MB??!!! ¿70 GB de juego tienes hecho? ¿Pero qué has programado? ¿el GTA20?
Quote from: Drumpi on July 16, 2016, 02:56:12 AM
Pregunta tonta: ¿Has compilado algún "Hello world" con Android antes de ponerte a saco con tu juego? A ver si lo que falla es tu compilador...
Si no, ve añadiéndole módulos al "hola mundo" hasta que falle.
¡¡¡¿¿70000MB??!!! ¿70 GB de juego tienes hecho? ¿Pero qué has programado? ¿el GTA20?
jajajajajaja dije 70.000Mb?? madre mia!!! pues si eso que dijiste es lo que hice precisamente, me he creado un esqueleto que ha estado corriendo bien en android y fue donde consegui el problema con el mod_curl! mañana continuo, aqui en venezuela ya empieza a hacerse tarde y debo hacer otras cosillas!!! llo que sugiere el maestro pues, desde que programo en bennu nunca he usado el debbuger, jaja xD sorry!!!
y como venia diciendo, ire pasando paulatinamente los procesos hasta que logre disipar el crash o que se yo, el juego inicialmente corria en android pero luego me dispare en el desarrollo y deje de testearlo en android y bueno, he aqui el problema!!! pero de seguro tiene solucion
no es el debugger lo que sugiero es el trace de ejecucion, no podes debuguear nada, simplemente capturas a un archivo (o a salida de consola si aplica) por donde va pasando el puntero de ejecucion del motor.
si no pasa por ningun lado es porque te faltan permisos, quizas estas usando binarios android intel en lugar de arm o a la inversa, o vaya a saber que otro problema.
pero en ningun momento hablo de mod_debug
Quote from: SplinterGU on July 16, 2016, 05:30:38 PM
no es el debugger lo que sugiero es el trace de ejecucion, no podes debuguear nada, simplemente capturas a un archivo (o a salida de consola si aplica) por donde va pasando el puntero de ejecucion del motor.
si no pasa por ningun lado es porque te faltan permisos, quizas estas usando binarios android intel en lugar de arm o a la inversa, o vaya a saber que otro problema.
pero en ningun momento hablo de mod_debug
maestro me estoy reescribiendo el codigo de cero!!! hasta ahora va bien, uno de los problemas viene al cargar el fichero del nivel 1, muy pesado, en el emulador va bien pero en mi cell dura tres milenios en abrir!!! asi que estoy en otra movida para ponerle vida a mi juego, ya los controles y todo va bien!! mañana o el lunes me cuelgo unas funciones genericas que sirven para tres de las entradas: keyboard, joy y touch! esta bien chula!! luego la subo pero primero salir de esto!!! jeje saludos
Es que viendo tu juego te sale más a cuenta crearte un motor de scroll tileado o usar alguno de los que hay. 70MB sigue siendo una pasada (te lo dice uno que ha usado 3 mapas de 10MB para un circuito en modo7 con tres plantas :D).
Y si no quieres usar tiles, usa trozos de mapa más pequeños y los vas cargando a medida que vaya avanzando el jugador. Con 9 trozos que tengas en memoria del tamaño de la pantalla ya te vale.
Y lo del crash ya, si es en el arranque, y no es con la carga de recursos, sigue los consejos de SplinterGU y de Pixel, que son los que mejor se conocen el tema.
Quote from: Drumpi on July 17, 2016, 02:21:55 AM
Es que viendo tu juego te sale más a cuenta crearte un motor de scroll tileado o usar alguno de los que hay. 70MB sigue siendo una pasada (te lo dice uno que ha usado 3 mapas de 10MB para un circuito en modo7 con tres plantas :D ).
Y si no quieres usar tiles, usa trozos de mapa más pequeños y los vas cargando a medida que vaya avanzando el jugador. Con 9 trozos que tengas en memoria del tamaño de la pantalla ya te vale.
Y lo del crash ya, si es en el arranque, y no es con la carga de recursos, sigue los consejos de SplinterGU y de Pixel, que son los que mejor se conocen el tema.
ya me puse en eso, ya cree una utilidad para tilear, cree en php un slicer de alta precision en el corte, y pues ya me anda corriendo, el unico problemita que no es gran cosas es que tengo que hacer practicamente todos los mapas con la utilidad ajajajaja lol pero bueh!!! menos mal iba apenas por el 2do nivel, saludos
viento en popa!!! va para android y windows!
ya he hecho bastantes ajustes al juego pero ahora que esta corriendo algo muy basico tengo una duda!! el que pixstudio compile para androids 4.4 hace que mi juego corra mas lento en mi android 4.2???
Quote from: fulgorelizz on July 16, 2016, 11:13:07 PM
Quote from: SplinterGU on July 16, 2016, 05:30:38 PM
no es el debugger lo que sugiero es el trace de ejecucion, no podes debuguear nada, simplemente capturas a un archivo (o a salida de consola si aplica) por donde va pasando el puntero de ejecucion del motor.
si no pasa por ningun lado es porque te faltan permisos, quizas estas usando binarios android intel en lugar de arm o a la inversa, o vaya a saber que otro problema.
pero en ningun momento hablo de mod_debug
maestro me estoy reescribiendo el codigo de cero!!! hasta ahora va bien, uno de los problemas viene al cargar el fichero del nivel 1, muy pesado, en el emulador va bien pero en mi cell dura tres milenios en abrir!!! asi que estoy en otra movida para ponerle vida a mi juego, ya los controles y todo va bien!! mañana o el lunes me cuelgo unas funciones genericas que sirven para tres de las entradas: keyboard, joy y touch! esta bien chula!! luego la subo pero primero salir de esto!!! jeje saludos
genial entonces... :)
Quote from: fulgorelizz on July 18, 2016, 02:04:36 AM
ya he hecho bastantes ajustes al juego pero ahora que esta corriendo algo muy basico tengo una duda!! el que pixstudio compile para androids 4.4 hace que mi juego corra mas lento en mi android 4.2???
Hasta donde yo he entendido, que lo compiles para 4.4 lo hace INCOMPATIBLE con todos los Android anteriores. A menos que tengas la suerte de que el compilador no haga uso de ninguna característica exclusiva de 4.4. Tienes que compilarlo en el Android más antiguo que lo vaya a ejecutar, que suele ser 2.3 o 4.0, y cualquier equipo con ese Android o superior podrá ejecutar tu juego... salvo que haya cualquiera de las 2728 incompatibilidades existentes para los 4625 diferentes modelos de móviles, tablets, consolas Android, Android TVs, etc, etc... ^^U
Sí, la compatibilidad de Android es muy similar a lo que había hace años con Symbian y Java.
definitivamente vais a salir en los creditos tios!! estan aqui en la batalla!!
el juego ya anda chulo en pc, la diferencia de velocidad es notoria, creo que todo era asunto de memoria, el juego hacia colapsar la memoria de 512 de mi celular y por eso se caia, evidentemente si habia lios con mod_curl, asi que de momento hare una version sin rankeo mientra veo como solvento ese asunto!!
lo unico que ha surgido y a quien debo echarle la culpa porque no hay de otra es a mod_multi, deben haber unas cosas que no estan del todo bien en esa libreria, deberia aparecer josebita por aca! la mod mola de maravilla en el emulador de mi pc pero al llevarla al celular sucede lo siguiente:
los toques estan perfectos y los estatus de cada punto del tactil, el asunto inicia aqui, tras jugar un poco note que el juego se ponia lento, y a medida que andaba andaba cada vez mas lento
me pregunte; podria ser que estoy usando demasiados procesos?? veamos, optimice el codigo de tiles y pinte el mapa usando como referencias el array donde guardaba los graficos, asi que me he pintado mapas de manera automatica, creo que se supones que eso hacen los tiles maps! jaja y en fin ya mi juego pesa mucho menos!! venga, ya con eso el juego habia acelerado bastante!! pero persistia el asunto
dije vamos a sacar todos los procesos y dejo solo al protagonista con sus controladores
y seguia lo mismo, a lo que deduje, quizas los procesos en bennu al llegar a su ultimo end no estan siendo liberados de memoria, asi que me hice un #define para colocarlo antes del ultimo end y liberar la lista de los procesos activos en memoria (solo por precaucion)
al final solo quedaban las funciones del tactil y el protagonista, si dejas el juego correr solo, sin mover al personaje todo mola bien!!! empieza a ponerse lento a medida que haces touch y touch al juego!!! los fps en el celular caen a 21! imaginense, 50 fps por debajo xD simplemente desesperante!! jajajaja pero de resto ya se que el juego anda!!
me he reescrito el codigo de los mandos como de 4 formas distintas pensando que el proceso que lleva los controles del juego estaba sobre cargando la memoria pero no es asi!!! santos cielos!!
Para poder ver por qué falla, ¿podrías mandar un logcat (https://developer.android.com/studio/command-line/logcat.html) de lo que ocurre cuando ejecutas en Android?
Puede que no ayude mucho, o sí. A saber.
Si quieres, puedes mandarme el APK de alguna forma y le echo un ojo yo también.
Y sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
Quote from: josebita on July 20, 2016, 01:22:39 PMY sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
¿Y eso? Cuando me descargué el SDK para el 4.1, el tutorial decía lo contrario, que la versión indicaba la mínima que se iba a usar. ¿Lo habrán cambiado o es que tengo un manual muy malo?
Quote from: Drumpi on July 20, 2016, 04:50:33 PM
Quote from: josebita on July 20, 2016, 01:22:39 PMY sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
¿Y eso? Cuando me descargué el SDK para el 4.1, el tutorial decía lo contrario, que la versión indicaba la mínima que se iba a usar. ¿Lo habrán cambiado o es que tengo un manual muy malo?
si mal no recuerdo, el SDK te permite especificar la lista de compatibilidad de operativos android en el proyecto que genera el binario... pero quizas me confunda.
Quote from: josebita on July 20, 2016, 01:22:39 PM
Para poder ver por qué falla, ¿podrías mandar un logcat (https://developer.android.com/studio/command-line/logcat.html) de lo que ocurre cuando ejecutas en Android?
Puede que no ayude mucho, o sí. A saber.
Si quieres, puedes mandarme el APK de alguna forma y le echo un ojo yo también.
Y sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
te hare llegar la apk!
Quote from: Drumpi on July 20, 2016, 04:50:33 PM
Quote from: josebita on July 20, 2016, 01:22:39 PMY sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
¿Y eso? Cuando me descargué el SDK para el 4.1, el tutorial decía lo contrario, que la versión indicaba la mínima que se iba a usar. ¿Lo habrán cambiado o es que tengo un manual muy malo?
De las sessiones que uno define en el "manifiesto (https://developer.android.com/guide/topics/manifest/manifest-intro.html)" del paquete apk (AndroidManifest.xml) hay una que especifica la compatibilidad de tu paquete con las distintas versiones de Android y que se llama
<uses-sdk> (https://developer.android.com/guide/topics/manifest/uses-sdk-element.html). Tiene tres parámetros:
- android:minSdkVersion: La versión mínima de Android (por su número de SDK) en la que la aplicación puede funcionar.
- android:targetSdkVersion: La versión para la que la aplicación está diseñada. Normalmente coincidirá con la versión del SDK usado para compilar.
- android:maxSdkVersion: No se me ocurre un caso de uso válido para ésto, la verdad...
La idea es que uno puede crear una aplicación que, si está en una versión de Android se comporte de una forma y que si está en otra se comporte de otra.
Poniendo como ejemplo de uso el código de PixTudio (heredado de SDL). Resulta que para versiones de Android < 12, el soporte para joysticks era bastante pobre y luego mejoró. Pues en código se puede poner una comprobación adecuada para tener una u otra funcionalidad en función de la versión del cliente, como se muestra aquí (https://bitbucket.org/josebagar/pixtudio/src/e684576c0a01114316dce75b5d3957c7440cfc38/projects/android/src/org/libsdl/app/SDLActivity.java?at=bigmap&fileviewer=file-view-default#SDLActivity.java-168):
// Set up the surface
mSurface = new SDLSurface(getApplication());
if(Build.VERSION.SDK_INT >= 12) {
mJoystickHandler = new SDLJoystickHandler_API12();
}
else {
mJoystickHandler = new SDLJoystickHandler();
}
// If we're on Android >= 19, display the game in immersive view
if(Build.VERSION.SDK_INT >= 19) {
mSurface.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_STABLE
| View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
| View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
| View.SYSTEM_UI_FLAG_HIDE_NAVIGATION // hide nav bar
| View.SYSTEM_UI_FLAG_FULLSCREEN // hide status bar
| View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY);
}
¡Ojo! la constante Build.VERSION.SDK_INT (https://developer.android.com/reference/android/os/Build.VERSION.html#SDK_INT) es la versión de Android en la que se está ejecutando el código, ¡no con la que se está compilando!
PERO a la hora de compilar se usan constantes y métodos que no están definidas para Android < 19 (como ese View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY) de forma que para compilar se debe compilar con el SDK "máximo" cuyas características se vayan a usar.
Una vez que se va a ejecutar el código, siempre y cuando no se llame a métodos no disponibles en la versión de Android donde se esté ejecutando, todo irá bien. De ahí que el código tenga unas buenas cuantas salvaguardas como esta (https://bitbucket.org/josebagar/pixtudio/src/e684576c0a01114316dce75b5d3957c7440cfc38/projects/android/src/org/libsdl/app/SDLActivity.java?at=bigmap&fileviewer=file-view-default#SDLActivity.java-1226):
if (event.getSource() == InputDevice.SOURCE_MOUSE && SDLActivity.mSeparateMouseAndTouch) {
if (Build.VERSION.SDK_INT < 14) {
mouseButton = 1; // For Android==12 all mouse buttons are the left button
} else {
try {
mouseButton = (Integer) event.getClass().getMethod("getButtonState").invoke(event);
} catch(Exception e) {
mouseButton = 1; // oh well.
}
}
SDLActivity.onNativeMouse(mouseButton, action, event.getX(0), event.getY(0));Ésta es la causa de la diferencia de comportamiento de PixTudio/BennuGD en Android en función de la versión que describí aquí (http://bennugd-mobile.blogspot.com.es/2013/07/new-release-coming-this-time-for-ios-too.html).
Eso de la versión mínima y target ya me suena más :D
Lo que sí necesito son unas clases de Android :P. Empecé un tutorial y lo dejé tras la primera lección porque era todo XML :S No llegué a leer nada en Java (y java más o menos sé).
Quote from: josebita on July 21, 2016, 11:49:48 AM
Quote from: Drumpi on July 20, 2016, 04:50:33 PM
Quote from: josebita on July 20, 2016, 01:22:39 PMY sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
¿Y eso? Cuando me descargué el SDK para el 4.1, el tutorial decía lo contrario, que la versión indicaba la mínima que se iba a usar. ¿Lo habrán cambiado o es que tengo un manual muy malo?
De las sessiones que uno define en el "manifiesto (https://developer.android.com/guide/topics/manifest/manifest-intro.html)" del paquete apk (AndroidManifest.xml) hay una que especifica la compatibilidad de tu paquete con las distintas versiones de Android y que se llama <uses-sdk> (https://developer.android.com/guide/topics/manifest/uses-sdk-element.html). Tiene tres parámetros:
- android:minSdkVersion: La versión mínima de Android (por su número de SDK) en la que la aplicación puede funcionar.
- android:targetSdkVersion: La versión para la que la aplicación está diseñada. Normalmente coincidirá con la versión del SDK usado para compilar.
- android:maxSdkVersion: No se me ocurre un caso de uso válido para ésto, la verdad...
La idea es que uno puede crear una aplicación que, si está en una versión de Android se comporte de una forma y que si está en otra se comporte de otra.
Poniendo como ejemplo de uso el código de PixTudio (heredado de SDL). Resulta que para versiones de Android < 12, el soporte para joysticks era bastante pobre y luego mejoró. Pues en código se puede poner una comprobación adecuada para tener una u otra funcionalidad en función de la versión del cliente, como se muestra aquí (https://bitbucket.org/josebagar/pixtudio/src/e684576c0a01114316dce75b5d3957c7440cfc38/projects/android/src/org/libsdl/app/SDLActivity.java?at=bigmap&fileviewer=file-view-default#SDLActivity.java-168):
// Set up the surface
mSurface = new SDLSurface(getApplication());
if(Build.VERSION.SDK_INT >= 12) {
mJoystickHandler = new SDLJoystickHandler_API12();
}
else {
mJoystickHandler = new SDLJoystickHandler();
}
// If we're on Android >= 19, display the game in immersive view
if(Build.VERSION.SDK_INT >= 19) {
mSurface.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_STABLE
| View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
| View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
| View.SYSTEM_UI_FLAG_HIDE_NAVIGATION // hide nav bar
| View.SYSTEM_UI_FLAG_FULLSCREEN // hide status bar
| View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY);
}
¡Ojo! la constante Build.VERSION.SDK_INT (https://developer.android.com/reference/android/os/Build.VERSION.html#SDK_INT) es la versión de Android en la que se está ejecutando el código, ¡no con la que se está compilando!
PERO a la hora de compilar se usan constantes y métodos que no están definidas para Android < 19 (como ese View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY) de forma que para compilar se debe compilar con el SDK "máximo" cuyas características se vayan a usar.
Una vez que se va a ejecutar el código, siempre y cuando no se llame a métodos no disponibles en la versión de Android donde se esté ejecutando, todo irá bien. De ahí que el código tenga unas buenas cuantas salvaguardas como esta (https://bitbucket.org/josebagar/pixtudio/src/e684576c0a01114316dce75b5d3957c7440cfc38/projects/android/src/org/libsdl/app/SDLActivity.java?at=bigmap&fileviewer=file-view-default#SDLActivity.java-1226):
if (event.getSource() == InputDevice.SOURCE_MOUSE && SDLActivity.mSeparateMouseAndTouch) {
if (Build.VERSION.SDK_INT < 14) {
mouseButton = 1; // For Android==12 all mouse buttons are the left button
} else {
try {
mouseButton = (Integer) event.getClass().getMethod("getButtonState").invoke(event);
} catch(Exception e) {
mouseButton = 1; // oh well.
}
}
SDLActivity.onNativeMouse(mouseButton, action, event.getX(0), event.getY(0));
Ésta es la causa de la diferencia de comportamiento de PixTudio/BennuGD en Android en función de la versión que describí aquí (http://bennugd-mobile.blogspot.com.es/2013/07/new-release-coming-this-time-for-ios-too.html).
excelente, pero PREGUNTAAAA!! estos codigos no se generan de forma automatica?? quiero decir, si los modifico, a la hora de empaquetar de nuevo mi juego, no borrarias estas modificaciones que le haria y pondria nuevamentes las que genera de forma automatica?? ya he localizado esos bloques que me indicas!! bueno probare a ver que tal!! leere un poco sobre las versiones sdk a ver que tal andan y vuelvo a empaquetar y te aviso!! :D saludos!!
Quote from: josebita on July 21, 2016, 11:49:48 AM
Quote from: Drumpi on July 20, 2016, 04:50:33 PM
Quote from: josebita on July 20, 2016, 01:22:39 PMY sobre la versión del SDK de Android: hace falta porque si se está ejecutando en una versión más reciente de Android hace más cosas, pero se puede ejecutar en versiones anteriores.
¿Y eso? Cuando me descargué el SDK para el 4.1, el tutorial decía lo contrario, que la versión indicaba la mínima que se iba a usar. ¿Lo habrán cambiado o es que tengo un manual muy malo?
De las sessiones que uno define en el "manifiesto (https://developer.android.com/guide/topics/manifest/manifest-intro.html)" del paquete apk (AndroidManifest.xml) hay una que especifica la compatibilidad de tu paquete con las distintas versiones de Android y que se llama <uses-sdk> (https://developer.android.com/guide/topics/manifest/uses-sdk-element.html). Tiene tres parámetros:
- android:minSdkVersion: La versión mínima de Android (por su número de SDK) en la que la aplicación puede funcionar.
- android:targetSdkVersion: La versión para la que la aplicación está diseñada. Normalmente coincidirá con la versión del SDK usado para compilar.
- android:maxSdkVersion: No se me ocurre un caso de uso válido para ésto, la verdad...
La idea es que uno puede crear una aplicación que, si está en una versión de Android se comporte de una forma y que si está en otra se comporte de otra.
Poniendo como ejemplo de uso el código de PixTudio (heredado de SDL). Resulta que para versiones de Android < 12, el soporte para joysticks era bastante pobre y luego mejoró. Pues en código se puede poner una comprobación adecuada para tener una u otra funcionalidad en función de la versión del cliente, como se muestra aquí (https://bitbucket.org/josebagar/pixtudio/src/e684576c0a01114316dce75b5d3957c7440cfc38/projects/android/src/org/libsdl/app/SDLActivity.java?at=bigmap&fileviewer=file-view-default#SDLActivity.java-168):
// Set up the surface
mSurface = new SDLSurface(getApplication());
if(Build.VERSION.SDK_INT >= 12) {
mJoystickHandler = new SDLJoystickHandler_API12();
}
else {
mJoystickHandler = new SDLJoystickHandler();
}
// If we're on Android >= 19, display the game in immersive view
if(Build.VERSION.SDK_INT >= 19) {
mSurface.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_STABLE
| View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
| View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
| View.SYSTEM_UI_FLAG_HIDE_NAVIGATION // hide nav bar
| View.SYSTEM_UI_FLAG_FULLSCREEN // hide status bar
| View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY);
}
¡Ojo! la constante Build.VERSION.SDK_INT (https://developer.android.com/reference/android/os/Build.VERSION.html#SDK_INT) es la versión de Android en la que se está ejecutando el código, ¡no con la que se está compilando!
PERO a la hora de compilar se usan constantes y métodos que no están definidas para Android < 19 (como ese View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY) de forma que para compilar se debe compilar con el SDK "máximo" cuyas características se vayan a usar.
Una vez que se va a ejecutar el código, siempre y cuando no se llame a métodos no disponibles en la versión de Android donde se esté ejecutando, todo irá bien. De ahí que el código tenga unas buenas cuantas salvaguardas como esta (https://bitbucket.org/josebagar/pixtudio/src/e684576c0a01114316dce75b5d3957c7440cfc38/projects/android/src/org/libsdl/app/SDLActivity.java?at=bigmap&fileviewer=file-view-default#SDLActivity.java-1226):
if (event.getSource() == InputDevice.SOURCE_MOUSE && SDLActivity.mSeparateMouseAndTouch) {
if (Build.VERSION.SDK_INT < 14) {
mouseButton = 1; // For Android==12 all mouse buttons are the left button
} else {
try {
mouseButton = (Integer) event.getClass().getMethod("getButtonState").invoke(event);
} catch(Exception e) {
mouseButton = 1; // oh well.
}
}
SDLActivity.onNativeMouse(mouseButton, action, event.getX(0), event.getY(0));
Ésta es la causa de la diferencia de comportamiento de PixTudio/BennuGD en Android en función de la versión que describí aquí (http://bennugd-mobile.blogspot.com.es/2013/07/new-release-coming-this-time-for-ios-too.html).
::) releyendo el codigo y la exposicion que has hecho, y googleando muy a la vista rapida!! creo que todo deberia andar perfectamente bien, las llamadas estan bien correspondidas a sus versiones!
yo tengo una version 4.2 jelly bean, la api 19 se usa a partir de kit kat! quiere decir que mi juego andaria de pelos en un android con estas especificaciones, cierto??? es por esa razon que en el emulador de mi pc anda de mi l maravillas pero en mi dispositivo movil se hace cada vez ma pesado!! tan sencillo como que todo el mundo no podra jugar mi juego xD o quizza si, quien sabe xD jaja seguire leyendo mas a fondo ciertos aspectos de este codigo a ver que puedo hacer de manera de bajar la version a un android menor y hacerlo compatible!!
me gusta aprender ;D
gracias gracias
Saludos de nuevo! oigan no me dejen solo ajajajaja miren, he pensado en otra cosa, ya he probado muchisimas cosas , llevo casi 80 compilaciones probando cosas distintas y me encontre con lo siiguiente, quizas ustedes puedan ayudar
tengo 2 structcs con dimensiones[100][100] para crear los tile maps y otro similar para colocar los procesos enemigos adornitos y que se yo,
para colocar el tile uso un proceso que usa la funcion load que manda a los structs los datos, mi pregunta es, que pasa cada vez que ejecuto un load??? porque el problema de lentitud se empieza a manifestar ahora cuando voy pasando de nivel, a estas alturas de la depuracion no creo que sea el mod_multi, he hecho una prueba de memoria y pues a medida que carga cada nivel se pone lento, intente usar mem_free pero con esas lineas se creashea en android, mientras que en win anda normal con esa linea de codigo!!
quien me aporta alguna idea??? como hago para descargar esa informacion de memoria?? algun codiguillo de ejemplo??? ;D
estamos terminando el pack que incluye funciones de depuracion para android
ya en breve,,,
Quote from: l1nk3rn3l on August 03, 2016, 02:49:10 AM
estamos terminando el pack que incluye funciones de depuracion para android
ya en breve,,,
excelente!! esperare pacientemente