El tamaño de mapa de bits supera el presupuesto de VM cuando el desarrollo de juegos

He tenido este problema también; No hay realmente ninguna solución aparte de reducir el número / tamaño de mapas de bits que ha cargado a la vez. Algunos dispositivos Android más antiguos sólo asignan 16 MB al montón para toda la aplicación y los mapas de bits se almacenan en la memoria descomprimida una vez que los cargas, por lo que no es difícil superar los 16 MB con fondos grandes, etc. (Un mapa de bits de 854×480 y 32 bits 1.6MB sin comprimir.)

En mi juego pude superarlo cargando mapas de bits que iba a usar en el nivel actual (por ejemplo, tengo un único objeto Bitmap para el fondo que se vuelve a cargar desde los recursos cada vez que cambia, en lugar de mantener varios Bitmaps En la memoria.Solo mantengo un int que las pistas que el recurso que he cargado actualmente.)

Tu hoja de sprite es enorme, así que creo que tienes razón que necesitas reducir el tamaño de tus animaciones. Por otra parte, la carga de recursos es decentemente rápida, por lo que puede ser capaz de salirse con la suya haciendo algo como cargar la tira de animación para la dirección actual del personaje, y hacer que se detenga un poco cuando se gira mientras se reemplaza con la nueva tira de animación. Eso puede ser complicado aunque.

Además, recomiendo probar su aplicación en el emulador con un montón de VM configurado en 16mb, para asegurarse de que ha arreglado el problema para todos los dispositivos. (El emulador por defecto a 24mb, por lo que es fácil para que no se prueban y generar algunas revisiones de 1 estrella después de la liberación.)

No soy un dev de juego sin embargo me gustaría pensar que sé Android suficiente.

Cargar imágenes del tamaño es casi seguro lanzar errores. ¿Por qué son las imágenes que el tamaño del archivo?

Hay un ejemplo en http://p-xr.com/android-tutorial-how-to-paint-animate-loop-and-remove-a-sprite/ . Si observa que tiene un sprite de explosión de sólo ~ 200Kb. Incluso una imagen más detallada no necesitaría mucho más espacio de archivo.

Aceptar algunas sugerencias:

• ¿Está cargando todas sus spritesheets en una sola hoja o cada spritesheet en un archivo separado? Si están todos en uno, los dividiría.

• Baje la resolución de las imágenes, un dispositivo Android es portátil y algunos sólo tienen una pantalla de baja resolución. Por ejemplo, el HTC Wildfire tiene una resolución de 240×320 (dispositivo LDPI) y es un dispositivo bastante común. Usted no ha indicado las dimensiones de la imagen por lo que no podemos estar seguros si esto es práctico.

Finalmente; Yo no soy un programador de juegos, pero he encontrado este tutorial (parte de la misma serie) bastante esclarecedor – http://p-xr.com/android-tutorial-2d-canvas-graphics/ . Me pregunto si usted está aplicando un patrón que no es apropiado para Android, sin embargo, sin código no puedo decir.

Derecho algo un poco fuera de tema, pero vale la pena anotar …

Las personas subestiman el poder de la Visión. Mientras que hay una cierta cantidad de lógica a usar un SurfaceView, la visión estándar hará absolutamente mucho en sus los propios. Un SurfaceView más a menudo requiere un subproceso subyacente para ejecutar (que tendrá que configurar usted mismo) con el fin de que funcione. A View sin embargo llama a onDraw (), que puede ser utilizado en una variedad de formas, incluyendo el método postinvalidate() ¿Qué hace postInvalidate ()? ).

En cualquier caso, podría valer la pena echar un vistazo a este tutorial http://mindtherobot.com/blog/272/android-custom-ui-making-a-vintage-thermometer/ . Personalmente, fue un excelente ejemplo de una vista personalizada y lo que puede hacer con ellos. Reescribí algunas secciones e hice una aplicación de reloj de bolsillo.