Wydajność: zmienne statyczne dla każdej podklasy czy wskaźniki

Witam. Mam problem, otóż potrzebuję zrobić mapę, która będzie składać się z powiedzmy miliona małych obszarów. Niektóre z nich będą bardzo często się powtarzać (np. ok 0,5 mln). Jednak mapa będzie mogła być zapisywana, dlatego potrzebuję ID każdego obszaru. Tu zaczynają się schody, bo pomyślałem, że skoro mamy obszar np. trawiasty i występuje 200k razy, to nie ma sensu, by wczytywać dla każdego teksturę, tylko zrobić to tak:

Sposób 1:

abstrakcyjna klasa podstawowa, zawiera metody czysto wirtualne pozwalające na dalszą prace z obszarami.
klasy konkretnych obszarów po niej dziedziczą, np. obszar 'trawiasty' posiada  która będzie używana, dla wszystkich obszarów oraz wspomniane . Jedyny mankament tego sposobu to to, że przy kilkudziesięciu obszarach muszę tworzyć kilkadziesiąt klas (nowy obszar = nowa klasa). Jest to złe, bo te klasy niczym się nie różnią jeśli chodzi o składniki, różnią się tylko zawartością składników statycznych

Sposób 2:

Tworze klasę "obszar" która posiada wskaźniki do tekstury, ID, itp. a potem w programie tworzę sobie tablice tekstur i konkretnemu obszarowi przypisuje konkretną teksturę. Ten sposób jest jak mniemam bardziej zasobożerny (przypominam, ok miliona obiektów).


Który sposób jest lepszy? A może zaproponujecie własny? Z góry dzięki.

Dla zasady dodam, że nie zamierzam ich wszystkich na raz wyświetlać ;)

Pomysłów jest wiele... może taki...

Zrób ResourceManager'a który po podaniu ID (może nim być nawet string) w wywołaniu z klasy klienckiej, wczyta teksturę i ją zwróci (np. przez referencję stałą). Jeśli dana tekstura już była wczytywana, nie będzie czytana ponownie. Mapa kojarzeń ID->plik_tekstury.png (png dla przykładu, może być inny), zapisz w pliku konfiguracji który będzie czytany na początku życia ResourceManager'a.

Czyli np.


Z tym problemu nie będzie.

PS. co to klasa kliencka :P?

Klasa kliencka czyli ta "która pyta o teksturę i chce by była nią prezentowana".
Raczej nie switch/case a struktura mapy/unordered_map'y. Coś co będzie trzymało odwzorowanie klucz_id->tekstura. Przez klucz_id zapytasz o np. "trawa" i dostaniesz jej teksturę :-)
Później jeszcze zaimplementujesz sprawdzenie czy przypadkiem dana tekstura już nie jest wczytana na rzecz innej klasy. Ale tu nie wiem czy będziesz miał takie przypadki różnych klas z tą samą teksturą.

Ok, dzięki, popatrzę za tą mapą. A masz jakieś pomysły odnośnie tego, czy ID powinno być przechowywane w każdej osobnej klasie jako zmienna statyczna (tak samo tekstura), czy jedna klasa dla wszystkich obszarów, ale niestatyczne ID i niestatyczny wskaźnik na teksturę?

Jedna klasa powinna wystarczyć.

Ok, ale wziąłeś pod uwagę milion intów i wskaźników pod uwagę? :P

PS. A jeśli pewny rodzaj pola może porosnąć trawą, i zrobie tak:

pole<-----PoleMogąceZarosnąć

I mam powiedzmy tablicę wskaźników do pól, to jak mam sprawdzić, czy jest to zwykłe pole, czy to mogące zarosnąć? Myślałem, by zrobić w klasie pole metodę wirtualną "CzyMozeZarosnac()" i zwracać false a w klasie dziedziczącej PoleMogąceZarosnąć zwracać true, ale na tej zasadzie musiałbym zrobić metodę wirtualną WzrostTrawy() bo mogę zrobić tylko tak:

wziąłeś pod uwagę milion intów i wskaźników pod uwagę?

Dlaczego chcesz to tak zapisywać? Możesz inaczej zdefiniować format, aby dane były nieco bardziej skompresowane. Na przykład jeśli obszary tego samego typu występują obok siebie, to możesz podzielić to na podobszary opisane prostokątami.