2012-05-15 19 views
7

Estoy trabajando en un juego y hemos estado almacenando nuestra información de nivel en formato JSON. Estos niveles son bastante grandes, por lo que cambió a simplemente almacenarlos en C plano #:Compilador MonoTouch AOT: los métodos grandes fallan

  • Un método de nivel superior tiene una sentencia switch para el nombre del nivel/objeto
  • Existen varios métodos generadas automáticamente que "nuevo hasta" nuestro árbol de objetos con inititalizers propiedad estándar

Ejemplo:

private OurObject Autogenerated_Object1() 
{ 
    return new OurObject { Name = "Object1", X = 1, Y = 2, Width = 200, Height = 100 }; 
} 

Excepto estos métodos son muy grandes y tienen listas anidadas/dicción aries de otros objetos, etc.

Esto ha acelerado el tiempo de carga de un nivel de 2-3 segundos a fracciones de segundo (en Windows). El tamaño de nuestros datos también es considerablemente más pequeño, como IL compilado en comparación con JSON.

El problema es cuando compilamos estos en MonoDevelop para MonoTouch, obtenemos:

mtouch exited with code 1

Con -v -v -v encendido, podemos ver el error:

MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/monotouch.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/monotouch.dll" 
AOT Compilation exited with code 134, command: 
MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/DrawAStickmanCore.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll" 
Mono Ahead of Time compiler - compiling assembly /Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll 
* Assertion: should not be reached at ../../../../../mono/mono/mini/mini-arm.c:2758 

¿Hay un límite al número de líneas en un método, al compilar para AOT? ¿Hay algún argumento que podamos pasar al mtouch para arreglar esto? Algunos archivos funcionan bien, pero uno en particular que causa el error tiene un método de 3.000 líneas. Compilar para el simulador funciona bien sin importar qué.

Esto sigue siendo un experimento, así que nos damos cuenta de que esta es una situación bastante loca.

+0

¿Funciona con niveles pequeños? –

+0

Sí, funciona bien con niveles más pequeños. Tan pronto como agrego un arbusto o árbol en particular, comienza el problema, y ​​el simulador funciona bien. – jonathanpeppers

+0

Complete un informe de error :) – poupou

Respuesta

4

Esas afirmaciones se producen cuando se alcanza una condición que debe nunca en el compilador AOT. Por favor, informe a estos casos http://bugzilla.xamarin.com

Is there some argument we can pass to mtouch to fix this?

Usted puede ser capaz de solucionar esto usando LLVM (o no usarlo), ya que es un motor de generación de código diferente. Dependiendo de la etapa en que esto ocurra (algunos son compartidos), es posible que no se encuentre en la misma condición.

Por supuesto, las compilaciones de LLVM son más lentas y no admiten la depuración, por lo que esta no es una solución ideal para cada circunstancia.

+0

Haré un proyecto de muestra e informaré el error. Aparece un error similar al compilar con LLVM: '* Afirmación en ../../../../../mono/mono/mini/ssa.c:243, condición' stack_history_len jonathanpeppers

+0

El error está aquí: https://bugzilla.xamarin.com/show_bug.cgi?id = 5093 – jonathanpeppers

+0

Zoltan dice que está arreglado, no estoy seguro por cuánto tiempo hasta que esté en el canal alfa/beta para probarlo. – jonathanpeppers

1

Sólo una recomendación para el almacenamiento de los niveles. ¿Has considerado almacenar los niveles en un formato binario muy rápido, como los Buffers de Protocolo? .NET tiene una maravillosa biblioteca de búferes de protocolo llamada Protobuf-net que es posible que desee verificar.

+0

Lo he visto, el problema es que tengo listas/diccionarios anidados, más clase con múltiples listas (matrices irregulares) y no tiene soporte para eso. – jonathanpeppers

+0

Es posible que pueda envolver las matrices/listas internas como clases y serializar de esa manera. Pero probablemente ya has explorado esa opción. – tamaslnagy

+0

MsgPack es otra opción. Lo estoy usando para serializar a través de la red y en algún momento puedo usarlo para reemplazar a Json para una serialización más rápida en el disco. –

Cuestiones relacionadas