un crash de la madre

[Drumpi]

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é).

[fulgorelizz]

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.

¿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" 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>. 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í:

Code Select Expand


        // 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 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:

Code Select Expand

        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í.

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!!

[fulgorelizz]

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.

¿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" 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>. 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í:

Code Select Expand


        // 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 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:

Code Select Expand

        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í.

::) 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

[fulgorelizz]

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

[l1nk3rn3l]

estamos terminando el pack que incluye funciones de depuracion para android
ya en breve,,,

[fulgorelizz]

estamos terminando el pack que incluye funciones de depuracion para android
ya en breve,,,

excelente!! esperare pacientemente