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