aplikacja ulega awarii, gdy osiągnie 1,5 Gb.
To zdecydowanie sugeruje, że nie reprezentujesz poprawnie swoich kafelków, ponieważ oznaczałoby to, że każdy kafelek ma rozmiar ~ 80 bajtów.
Musisz zrozumieć, że należy rozdzielić koncepcję gry kafelka od kafelka wizualnego, który widzi użytkownik. Te dwie koncepcje to nie to samo .
Weźmy na przykład Terraria. Najmniejszy świat Terraria zajmuje 4200 x 1200 płytek, czyli 5 milionów płytek. Ile pamięci zajmuje reprezentowanie tego świata?
Każda płytka ma warstwę pierwszoplanową, warstwę tła (ściany tła), „warstwę drutu”, do której prowadzą przewody, i „warstwę mebli”, do której prowadzą elementy mebli. Ile pamięci zajmuje każdy kafelek? Znowu mówimy tylko koncepcyjnie, a nie wizualnie.
Kafelek pierwszego planu można łatwo przechowywać w nieoznaczonym skrócie. Nie ma więcej niż 65536 rodzajów kafelków pierwszego planu, więc nie ma sensu używać więcej pamięci niż to. Kafelki tła mogą z łatwością zawierać bajt bez znaku, ponieważ istnieje mniej niż 256 różnych rodzajów kafelków tła. Warstwa drutu jest czysto binarna: albo płytka ma drut, albo nie. To jeden bit na płytkę. A warstwa mebli może znów być bajtem niepodpisanym, w zależności od liczby możliwych różnych mebli.
Całkowity rozmiar pamięci na kafelek: 2 bajty + 1 bajt + 1 bit + 1 bajt: 4 bajty + 1 bit. Tak więc całkowity rozmiar małej mapy Terraria wynosi 20790000 bajtów lub ~ 20 MB. (uwaga: obliczenia te oparte są na Terrarii 1.1. Od tego czasu gra znacznie się rozwinęła, ale nawet współczesna Terraria może zmieścić się w 8 bajtach na lokalizację kafelków, czyli ~ 40 MB. Nadal jest to całkiem znośne).
Nigdy nie należy przechowywać tej reprezentacji jako tablic klas C #. Powinny to być tablice liczb całkowitych lub coś podobnego. AC # struct też by działało.
Teraz, gdy nadchodzi czas na narysowanie części mapy (zwróć uwagę na nacisk), Terraria musi przekształcić te płytki koncepcyjne w rzeczywiste płytki. Każda płytka musi faktycznie wybrać obraz pierwszego planu, obraz tła, opcjonalny obraz mebli i mieć obraz z drutu. W tym miejscu pojawia się XNA z różnymi arkuszami sprite i tym podobne.
Musisz przekonwertować widoczną część mapy pojęciowej na rzeczywiste płytki arkuszy sprite XNA. Nie powinieneś próbować konwertować całej rzeczy naraz . Każdy przechowywany kafelek powinien być po prostu indeksem z napisem „Jestem kafelkiem typu X”, gdzie X jest liczbą całkowitą. Używasz tego indeksu liczb całkowitych, aby pobrać duszka, którego używasz do jego wyświetlenia. I używasz arkuszy sprite XNA, aby uczynić to szybszym niż tylko rysowanie pojedynczych quadów.
Teraz widoczny obszar kafelków musi zostać podzielony na różne części, abyś nie budował ciągle arkuszy duszka przy każdym ruchu kamery. Więc możesz mieć 64x64 kawałki świata jako arkusze sprite. Niezależnie od tego, które fragmenty świata 64x64 są widoczne z aktualnej pozycji kamery gracza, są to losowane fragmenty. Wszelkie inne fragmenty nie mają nawet arkuszy sprite; jeśli fragment spadnie z ekranu, wyrzucasz ten arkusz (uwaga: tak naprawdę go nie usuwasz; trzymasz go w pobliżu i określasz ponownie jako nowy fragment, który może być później widoczny).
Chciałbym, aby cała mapa była przetwarzana przynajmniej w aplikacji serwera (i na kliencie, jeśli to możliwe).
Twój serwer nie musi wiedzieć ani dbać o wizualną reprezentację kafelków. Jedyne, na czym trzeba się przejmować, to reprezentacja konceptualna. Użytkownik dodaje tutaj kafelek, więc zmienia on indeks kafelków.