1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
/* Copyright (C) 2012 Wildfire Games.
* This file is part of 0 A.D.
*
* 0 A.D. is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 2 of the License, or
* (at your option) any later version.
*
* 0 A.D. is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with 0 A.D. If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef INCLUDED_TERRITORYBOUNDARY
#define INCLUDED_TERRITORYBOUNDARY
#include <vector>
#include "maths/Vector2D.h"
#include "simulation2/helpers/Player.h"
template<typename T>
class Grid;
/**
* Describes an outline of a territory, where the latter are understood to mean the largest sets of mutually connected tiles
* ('connected' as in the mathematical sense from graph theory) that are either all reachable or all unreachable from a root
* influence entity.
*
* Note that the latter property is also called the 'connected' flag in the territory manager terminology, because for tiles
* to be reachable from a root influence entity they must in fact be mathematically connected. Hence, you should not confuse
* the 'connected' flag with the pure mathematical concept of connectedness, because in the former it is implicitly
* understood that the connection is to a root influence entity.
*/
struct STerritoryBoundary
{
/// Set if this boundary should blink
bool blinking;
player_id_t owner;
/// The boundary points, in clockwise order for inner boundaries and counter-clockwise order for outer boundaries.
/// Note: if you need a way to explicitly find out which winding order these are in, you can have
/// CTerritoryBoundCalculator::ComputeBoundaries set it during computation -- see its implementation for details.
std::vector<CVector2D> points;
};
/**
* Responsible for calculating territory boundaries, given an input territory map. Factored out for testing.
*/
class CTerritoryBoundaryCalculator
{
private:
CTerritoryBoundaryCalculator(){} // private ctor
public:
/**
* Computes and returns all territory boundaries on the provided territory map (see STerritoryBoundary for a definition).
* The result includes both inner and outer territory boundaries. Outer boundaries have their points in CCW order, inner
* boundaries have them in CW order (because this matches the winding orders needed by the renderer to offset them
* inwards/outwards appropriately).
*/
static std::vector<STerritoryBoundary> ComputeBoundaries(const Grid<u8>* territories);
};
#endif // INCLUDED_TERRITORYBOUNDARY
|
