la aplicación se bloquea cuando alcanza 1.5Gb.
Esto sugiere fuertemente que no está representando sus mosaicos correctamente, ya que esto significaría que cada mosaico tiene un tamaño de ~ 80 bytes.
Lo que debes entender es que debe haber una separación entre el concepto de juego de un mosaico y el mosaico visual que ve el usuario. Estos dos conceptos no son lo mismo .
Toma Terraria por ejemplo. El mundo más pequeño de Terraria ocupa 4200x1200 fichas, que son 5 millones de fichas. Ahora, ¿cuánto recuerdo se necesita para representar ese mundo?
Bueno, cada mosaico tiene una capa de primer plano, una capa de fondo (las paredes de fondo), una "capa de alambre" donde van los cables y una "capa de muebles" donde van los muebles. ¿Cuánta memoria ocupa cada mosaico? Nuevamente, solo estamos hablando conceptualmente, no visualmente.
Un mosaico en primer plano podría almacenarse fácilmente en un corto sin firmar. No hay más de 65536 tipos de mosaicos en primer plano, por lo que no tiene sentido usar más memoria que esta. Los mosaicos de fondo podrían estar fácilmente en un byte sin signo, ya que hay menos de 256 tipos diferentes de mosaicos de fondo. La capa de cable es puramente binaria: o un mosaico tiene un cable o no. Eso es un bit por ficha. Y la capa de muebles podría volver a ser un byte sin firmar, dependiendo de la cantidad de muebles posibles que haya.
Tamaño de memoria total por mosaico: 2 bytes + 1 byte + 1 bit + 1 byte: 4 bytes + 1 bit. Por lo tanto, el tamaño total para un pequeño mapa de Terraria es 20790000 bytes, o ~ 20 MB. (nota: estos cálculos se basan en Terraria 1.1. El juego se ha expandido mucho desde entonces, pero incluso los Terraria modernos podrían caber dentro de 8 bytes por ubicación de mosaico, o ~ 40 MB. Todavía es bastante tolerable).
Usted debe no tener esta representación almacenada como matrices de clases de C #. Deben ser matrices de enteros o algo similar. AC # struct también funcionaría.
Ahora, cuando llega el momento de dibujar parte de un mapa (tenga en cuenta el énfasis), Terraria necesita convertir estos mosaicos conceptuales en mosaicos reales . Cada mosaico debe elegir una imagen de primer plano, una imagen de fondo, una imagen de muebles opcional y una imagen de alambre. Aquí es donde entra XNA con sus diversas hojas de sprites y demás.
Lo que debe hacer es convertir la parte visible de su mapa conceptual en mosaicos de hojas de sprites XNA reales. No deberías intentar convertir todo de una vez . Cada mosaico que almacene debería ser un índice que diga "Soy un mosaico tipo X", donde X es un número entero. Utiliza ese índice entero para buscar qué sprite usa para mostrarlo. Y usa las hojas de sprites de XNA para hacer esto más rápido que solo dibujar quads individuales.
Ahora, la región visible de los mosaicos debe dividirse en varios trozos, de modo que no esté constantemente construyendo láminas de sprites cuando la cámara se mueva. Por lo tanto, es posible que tenga trozos de 64x64 del mundo como hojas de sprites. Cualesquiera trozos de 64x64 del mundo visibles desde la posición actual de la cámara del jugador son los trozos que dibujas. Cualquier otro trozo ni siquiera tiene hojas de sprites; si un trozo se cae de la pantalla, tira esa hoja (nota: en realidad no la borras; la guardas y la respetas para un nuevo trozo que pueda ser visible más adelante).
Me gustaría tener un mapa completo procesado al menos en la aplicación del servidor (y en el cliente si es posible).
Su servidor no necesita saber ni preocuparse por la representación visual de los mosaicos. Todo lo que necesita preocuparse es la representación conceptual. El usuario agrega un mosaico aquí, por lo que cambia ese índice de mosaico.