l'application se bloque lorsqu'elle atteint 1,5 Go.
Cela suggère fortement que vous ne représentez pas correctement vos tuiles, car cela signifierait que chaque tuile a une taille d'environ 80 octets.
Ce que vous devez comprendre, c'est qu'il doit y avoir une séparation entre le concept de gameplay d'une tuile et la tuile visuelle que l'utilisateur voit. Ces deux concepts ne sont pas la même chose .
Prenez Terraria par exemple. Le plus petit monde Terraria occupe 4200x1200 tuiles, soit 5 millions de tuiles. Maintenant, combien de mémoire faut-il pour représenter ce monde?
Eh bien, chaque carreau a une couche de premier plan, une couche d'arrière-plan (les murs d'arrière-plan), une "couche de fils" où vont les fils et une "couche de meubles" où vont les meubles. Combien de mémoire prend chaque tuile? Encore une fois, nous parlons simplement conceptuellement, pas visuellement.
Une tuile de premier plan pourrait facilement être stockée dans un court non signé. Il n'y a pas plus de 65536 types de tuiles de premier plan, il est donc inutile d'utiliser plus de mémoire que cela. Les tuiles d'arrière-plan peuvent facilement être dans un octet non signé, car il existe moins de 256 types différents de tuiles d'arrière-plan. La couche de fil est purement binaire: soit une tuile contient un fil, soit elle n'en a pas. C'est donc un bit par tuile. Et la couche de meubles pourrait à nouveau être un octet non signé, selon le nombre possible de meubles différents.
Taille totale de la mémoire par tuile: 2 octets + 1 octet + 1 bit + 1 octet: 4 octets + 1 bit. Ainsi, la taille totale d'une petite carte Terraria est de 20790000 octets, soit ~ 20 Mo. (Remarque: ces calculs sont basés sur Terraria 1.1. Le jeu s'est beaucoup développé depuis lors, mais même Terraria moderne pourrait tenir dans les 8 octets par emplacement de tuile, soit ~ 40 Mo. Toujours tout à fait tolérable).
Vous ne devriez jamais avoir cette représentation stockée sous forme de tableaux de classes C #. Ils doivent être des tableaux d'entiers ou quelque chose de similaire. La structure AC # fonctionnerait également.
Maintenant, quand vient le temps de dessiner une partie d'une carte (notez l'accent), Terraria doit convertir ces tuiles conceptuelles en tuiles réelles . Chaque tuile doit réellement choisir une image de premier plan, une image d'arrière-plan, une image de meuble en option et avoir une image filaire. C'est là que XNA entre en scène avec ses diverses feuilles de sprites et autres.
Ce que vous devez faire est de convertir la partie visible de votre carte conceptuelle en tuiles de feuille de sprite XNA réelles. Vous ne devriez pas essayer de convertir le tout en une seule fois . Chaque tuile que vous stockez doit simplement être un index indiquant que «Je suis de type tuile X», où X est un entier. Vous utilisez cet index entier pour récupérer le sprite que vous utilisez pour l'afficher. Et vous utilisez les feuilles de sprite de XNA pour rendre cela plus rapide que de simplement dessiner des quads individuels.
Maintenant, la zone visible des tuiles doit être divisée en différents morceaux, de sorte que vous ne construisez pas constamment de feuilles de sprites chaque fois que la caméra se déplace. Donc, vous pourriez avoir des morceaux 64x64 du monde sous forme de feuilles de sprite. Quels que soient les morceaux 64x64 du monde visibles depuis la position actuelle de la caméra du joueur, ce sont les morceaux que vous dessinez. Tous les autres morceaux n'ont même pas de feuilles de sprite; si un morceau tombe de l'écran, vous jetez cette feuille (remarque: vous ne le supprimez pas vraiment; vous le conservez et le spécifiez pour un nouveau morceau qui peut devenir visible plus tard).
J'aimerais que toute la carte soit traitée au moins sur l'application serveur (et sur le client si possible).
Votre serveur n'a pas besoin de connaître ou de se soucier de la représentation visuelle des tuiles. Il lui suffit de se soucier de la représentation conceptuelle. L'utilisateur ajoute une tuile ici, donc il change cet index de tuile.