一個大對象或多個小對象

-1

我爲一個roguelike類型的遊戲創建了一個地圖系統，並且我問我瓷磚最好有哪一個大對象存儲項目，地形......或者我將它們分隔成多個對象。一個大對象或多個小對象

一個例子是比較容易理解：

一個大類：

class Tile { 
    unsigned char flags; 
    Terrain *terrain; 
    std::vector<Item> items; 
    std::vector<Object> objects; 
}; 

class Map { 
    Tile tiles[100][100]; 
};

或多個小的：

class Map { 
    unsigned char flags[100][100]; 
    Terrain terrains[100][100]; 
    std::vector<Item> items[100][100]; 
    std::vector<Object> objects[100][100]; 
};

有沒有在性能負載較小的對象長期任何優勢？大部分時間我不需要訪問同一個地方的所有列表。感謝您的幫助。

來源

2017-04-11 thoregan

就個人而言，我會使用第一個。 – NathanOliver

我不認爲沒有學習使用模型就可以回答。當然你希望有一個邏輯對象來收集'Tile'數據，但是如果你多次迭代某些屬性，你可能想要讓它們在內存中連續排列。你也可能想要有多個視圖，並且所有這些屬性都將是共享資源......再次難以分辨。在大多數情況下，第一個是首選的好設計。 – luk32

它完全取決於您的內存訪問模式。如果你發現自己遍歷所有flags，那麼所有terrains，那麼所有items，那麼所有objects比遍歷一個單一的瓷磚的flags，terrains，items更頻繁，並objects ...然後第二個佈局可能有比更好的性能第一個。

要確定的唯一方法是配置文件。

此外，您可以抽象的內存佈局與策略，這樣就可以很容易地改變它在你的測試/分析：

template <typename Storage> 
class Map 
{ 
    Storage _storage; 
    auto& getFlags(int x, int y); 
    auto& getTerrains(int x, int y); 
    auto& getItems(int x, int y); 
    auto& getObjects(int x, int y); 
}; 

struct TileStorage { /* ... approach 1 ... */ }; 
struct JaggedStorage { /* ... approach 2 ... */ };

來源

2017-04-11 12:52:13

好的，謝謝你，大多數時候我只能訪問標誌數組，所以第二種解決方案可能會更好，我會按照你的建議做一些分析。 – thoregan

一個大對象或多個小對象

回答

相關問題