petern/OpenTTD
1
0
Fork 0
forked from mirror/OpenTTD
Code Pull Requests Activity

(svn r6381) -Cleanup: make the '/* */' comments that span multiple lines more uniform.

Browse Source 
-Cleanup: whitespace alignment of a few tables.
This commit is contained in:
rubidium
2006-09-04 20:40:33 +00:00
parent a7cfb80c40
commit 63687763e9
59 changed files with 694 additions and 700 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
table/autorail.h
View File

@@ -1,12 +1,12 @@
/* $Id$ */
/* Rail selection types (directions):
/ \ / \ / \ / \ / \ / \
/ /\ /\ \ /===\ / \ /| \ / |\
\/ / \ \/ \ / \===/ \| / \ |/
\ / \ / \ / \ / \ / \ /
0 1 2 3 4 5
*/
* / \ / \ / \ / \ / \ / \
* / /\ /\ \ /===\ / \ /| \ / |\
* \/ / \ \/ \ / \===/ \| / \ |/
* \ / \ / \ / \ / \ / \ /
* 0 1 2 3 4 5
*/
// mark invalid tiles red
#define RED(c) c | PALETTE_SEL_TILE_RED

42
table/bridge_land.h
View File

@@ -1,27 +1,27 @@
/* $Id$ */
/** @file bridge_land.h This file contains all the sprites for bridges
* It consists of a number of arrays.
* <ul><li>_bridge_sprite_table_n_m. Defines all the sprites of a bridge besides the pylons.
* n defines the number of the bridge type, m the number of the section. the highest m for
* each bridge set defines the heads.<br>
* Sprites for middle secionts are arranged in groups of four, the elements are:
* <ol><li>Element containing the track. This element is logically behind the vehicle.</li>
* <li>Element containing the structure that is logically between the vehicle and the camera</li>
* <li>Element containing the pylons.</li></ol>
* First group is for railway in X direction, second for railway in Y direction, two groups each follow for road, monorail and maglev<p>
* <br>Elements for heads are arranged in groups of eight:
* <ol><li>X direction, north end, flat</li>
* <li>Y direction, north end, flat</li>
* <li>X direction, south end, flat</li>
* <li>Y direction, south end, flat</li>
* <li>X direction, north end, sloped</li>
* <li>Y direction, north end, sloped</li>
* <li>X direction, south end, sloped</li>
* <li>Y direction, south end, sloped</li></ol>
* This is repeated 4 times, for rail, road, monorail, maglev</li>
* </ul>
*/
* It consists of a number of arrays.
* <ul><li>_bridge_sprite_table_n_m. Defines all the sprites of a bridge besides the pylons.
* n defines the number of the bridge type, m the number of the section. the highest m for
* each bridge set defines the heads.<br>
* Sprites for middle secionts are arranged in groups of four, the elements are:
* <ol><li>Element containing the track. This element is logically behind the vehicle.</li>
* <li>Element containing the structure that is logically between the vehicle and the camera</li>
* <li>Element containing the pylons.</li></ol>
* First group is for railway in X direction, second for railway in Y direction, two groups each follow for road, monorail and maglev<p>
* <br>Elements for heads are arranged in groups of eight:
* <ol><li>X direction, north end, flat</li>
* <li>Y direction, north end, flat</li>
* <li>X direction, south end, flat</li>
* <li>Y direction, south end, flat</li>
* <li>X direction, north end, sloped</li>
* <li>Y direction, north end, sloped</li>
* <li>X direction, south end, sloped</li>
* <li>Y direction, south end, sloped</li></ol>
* This is repeated 4 times, for rail, road, monorail, maglev</li>
* </ul>
*/
static const PalSpriteID _bridge_sprite_table_2_0[] = {
0x9C3, 0x9C7, 0x9C9, 0x0, 0x9C4, 0x9C8, 0x9CA, 0x0,

58
table/elrail_data.h
View File

@@ -1,12 +1,12 @@
/* $Id */
/** @file elrail_data.h Stores all the data for overhead wire and pylon drawing.
@see elrail.c */
* @see elrail.c */
#ifndef ELRAIL_DATA_H
#define ELRAIL_DATA_H
/** Tile Location group.
This defines whether the X and or Y coordinate of a tile is even */
* This defines whether the X and or Y coordinate of a tile is even */
typedef enum TLG {
XEVEN_YEVEN = 0,
XEVEN_YODD = 1,
@@ -16,8 +16,8 @@ typedef enum TLG {
} TLG;
/** When determining the pylon configuration on the edge, two tiles are taken
into account: the tile being drawn itself (the home tile, the one in
ti->tile), and the neighbouring tile */
* into account: the tile being drawn itself (the home tile, the one in
* ti->tile), and the neighbouring tile */
typedef enum {
TS_HOME = 0,
TS_NEIGHBOUR = 1,
@@ -38,8 +38,8 @@ static byte AllowedPPPonPCP[DIAGDIR_END] = {
};
/** Which of the PPPs are inside the tile. For the two PPPs on the tile border
the following system is used: if you rotate the PCP so that it is in the
north, the eastern PPP belongs to the tile. */
* the following system is used: if you rotate the PCP so that it is in the
* north, the eastern PPP belongs to the tile. */
static byte OwnedPPPonPCP[DIAGDIR_END] = {
1 << DIR_SE | 1 << DIR_S | 1 << DIR_SW | 1 << DIR_W,
1 << DIR_N | 1 << DIR_SW | 1 << DIR_W | 1 << DIR_NW,
@@ -59,9 +59,9 @@ static const DiagDirection PCPpositions[TRACK_END][2] = {
#define PCP_NOT_ON_TRACK 0xFF
/** Preferred points of each trackbit. Those are the ones perpendicular to the
track, plus the point in extension of the track (to mark end-of-track). PCPs
which are not on either end of the track are fully preferred.
@see PCPpositions */
* track, plus the point in extension of the track (to mark end-of-track). PCPs
* which are not on either end of the track are fully preferred.
* @see PCPpositions */
static byte PreferredPPPofTrackAtPCP[TRACK_END][DIAGDIR_END] = {
{ /* X */
1 << DIR_NE | 1 << DIR_SE | 1 << DIR_NW, /* NE */
@@ -101,8 +101,8 @@ static byte PreferredPPPofTrackAtPCP[TRACK_END][DIAGDIR_END] = {
#define NUM_IGNORE_GROUPS 3
#define IGNORE_NONE 0xFF
/** In case we have a staight line, we place pylon only every two tiles,
so there are certain tiles which we ignore. A straight line is found if
we have exactly two PPPs. */
* so there are certain tiles which we ignore. A straight line is found if
* we have exactly two PPPs. */
static byte IgnoredPCP[NUM_IGNORE_GROUPS][TLG_END][DIAGDIR_END] = {
{ /* Ignore group 1, X and Y tracks */
{ /* X even, Y even */
@@ -196,7 +196,7 @@ static const Track TracksAtPCP[DIAGDIR_END][NUM_TRACKS_AT_PCP] = {
};
/* takes each of the 6 track bits from the array above and
assigns it to the home tile or neighbour tile */
* assigns it to the home tile or neighbour tile */
static const TileSource TrackSourceTile[DIAGDIR_END][NUM_TRACKS_AT_PCP] = {
{TS_HOME, TS_NEIGHBOUR, TS_HOME , TS_NEIGHBOUR, TS_NEIGHBOUR, TS_HOME },
{TS_HOME, TS_NEIGHBOUR, TS_NEIGHBOUR, TS_HOME , TS_NEIGHBOUR, TS_HOME },
@@ -232,8 +232,8 @@ static const Direction PPPorder[DIAGDIR_END][TLG_END][DIR_END] = { /* X -
static const int8 x_pcp_offsets[DIAGDIR_END] = {0, 8, 15, 8};
static const int8 y_pcp_offsets[DIAGDIR_END] = {8, 15, 8, 0};
/* Geometric placement of the PPP relative to the PCP*/
static const int8 x_ppp_offsets[DIR_END] = {-3, -4, -3, 0, +3, +4, +3, 0};
static const int8 y_ppp_offsets[DIR_END] = {-3, 0, +3, +4, +3, 0, -3, -4};
static const int8 x_ppp_offsets[DIR_END] = {-3, -4, -3, 0, 3, 4, 3, 0};
static const int8 y_ppp_offsets[DIR_END] = {-3, 0, 3, 4, 3, 0, -3, -4};
/* The type of pylon to draw at each PPP */
static const SpriteID pylons_normal[] = {
SPR_PYLON_EW_N,
@@ -341,16 +341,16 @@ static const SortableSpriteStruct CatenarySpriteData_Depot[] = {
};
/** Refers to a certain element of the catenary.
* Identifiers for Wires:
* <ol><li>Direction of the wire</li>
* <li>Slope of the tile for diagonals, placement inside the track for horiz/vertical pieces</li>
* <li>Place where a pylon shoule be</li></ol>
* Identifiers for Pylons:
* <ol><li>Direction of the wire</li>
* <li>Slope of the tile</li>
* <li>Position of the Pylon relative to the track</li>
* <li>Position of the Pylon inside the tile</li></ol>
*/
* Identifiers for Wires:
* <ol><li>Direction of the wire</li>
* <li>Slope of the tile for diagonals, placement inside the track for horiz/vertical pieces</li>
* <li>Place where a pylon shoule be</li></ol>
* Identifiers for Pylons:
* <ol><li>Direction of the wire</li>
* <li>Slope of the tile</li>
* <li>Position of the Pylon relative to the track</li>
* <li>Position of the Pylon inside the tile</li></ol>
*/
typedef enum {
WIRE_X_FLAT_SW,
WIRE_X_FLAT_NE,
@@ -398,11 +398,11 @@ typedef enum {
} CatenarySprite;
/* Selects a Wire (with white and grey ends) depending on whether:
a) none (should never happen)
b) the first
c) the second
d) both
PCP exists.*/
* a) none (should never happen)
* b) the first
* c) the second
* d) both
* PCP exists.*/
static const CatenarySprite Wires[5][TRACK_END][4] = {
{ /* Tileh == 0 */
{INVALID_CATENARY, WIRE_X_FLAT_NE, WIRE_X_FLAT_SW, WIRE_X_FLAT_BOTH},

26
table/engines.h
View File

@@ -4,25 +4,25 @@
#define ENGINES_H
/** @file table/engines.h
* This file contains all the data for vehicles
*/
* This file contains all the data for vehicles
*/
#include "../sound.h"
/** Writes the properties of a vehicle into the EngineInfo struct.
* @see EngineInfo
* @param a Introduction date
* @param e Rail Type of the vehicle
* @param f Bitmask of the climates
*/
* @see EngineInfo
* @param a Introduction date
* @param e Rail Type of the vehicle
* @param f Bitmask of the climates
*/
#define MK(a, b, c, d, e, f) { DAYS_TILL_ORIGINAL_BASE_YEAR + a, b, c, d, e, f, 0, 8, 0, 0 }
/** Writes the properties of a train carriage into the EngineInfo struct.
* @see EngineInfo
* @param a Introduction date
* @param e Rail Type of the vehicle
* @param f Bitmask of the climates
* @note the 0x80 in parameter b sets the "is carriage bit"
*/
* @see EngineInfo
* @param a Introduction date
* @param e Rail Type of the vehicle
* @param f Bitmask of the climates
* @note the 0x80 in parameter b sets the "is carriage bit"
*/
#define MW(a, b, c, d, e, f) { DAYS_TILL_ORIGINAL_BASE_YEAR + a, b | 0x80, c, d, e, f, 0, 8, 0, 0 }
// Rail types

97
table/sprites.h
View File

@@ -4,36 +4,36 @@
#define SPRITES_H
/** @file sprites.h
This file contails all sprite-related enums and defines. These consist mainly of
the sprite numbers and a bunch of masks and macros to handle sprites and to get
rid of all the magic numbers in the code.
@NOTE:
ALL SPRITE NUMBERS BELOW 5126 are in the main files
SPR_CANALS_BASE is in canalsw.grf
SPR_SLOPES_BASE is in trkfoundw.grf
SPR_OPENTTD_BASE is in openttd.grf
All elements which consist of two elements should
have the same name and then suffixes
_GROUND and _BUILD for building-type sprites
_REAR and _FRONT for transport-type sprites (tiles where vehicles are on)
These sprites are split because of the Z order of the elements
(like some parts of a bridge are behind the vehicle, while others are before)
All sprites which are described here are referenced only one to a handful of times
throughout the code. When introducing new sprite enums, use meaningful names.
Don't be lazy and typing, and only use abbrevations when their meaning is clear or
the length of the enum would get out of hand. In that case EXPLAIN THE ABBREVATION
IN THIS FILE, and perhaps add some comments in the code where it is used.
Now, don't whine about this being too much typing work if the enums are like
30 characters in length. If your editor doen't help you simplifying your work,
get a proper editor. If your Operating Systems don't have any decent editors,
get a proper Operating System.
@todo Split the "Sprites" enum into smaller chunks and document them
*/
* This file contails all sprite-related enums and defines. These consist mainly of
* the sprite numbers and a bunch of masks and macros to handle sprites and to get
* rid of all the magic numbers in the code.
*
* @NOTE:
* ALL SPRITE NUMBERS BELOW 5126 are in the main files
* SPR_CANALS_BASE is in canalsw.grf
* SPR_SLOPES_BASE is in trkfoundw.grf
* SPR_OPENTTD_BASE is in openttd.grf
*
* All elements which consist of two elements should
* have the same name and then suffixes
* _GROUND and _BUILD for building-type sprites
* _REAR and _FRONT for transport-type sprites (tiles where vehicles are on)
* These sprites are split because of the Z order of the elements
* (like some parts of a bridge are behind the vehicle, while others are before)
*
*
* All sprites which are described here are referenced only one to a handful of times
* throughout the code. When introducing new sprite enums, use meaningful names.
* Don't be lazy and typing, and only use abbrevations when their meaning is clear or
* the length of the enum would get out of hand. In that case EXPLAIN THE ABBREVATION
* IN THIS FILE, and perhaps add some comments in the code where it is used.
* Now, don't whine about this being too much typing work if the enums are like
* 30 characters in length. If your editor doen't help you simplifying your work,
* get a proper editor. If your Operating Systems don't have any decent editors,
* get a proper Operating System.
*
* @todo Split the "Sprites" enum into smaller chunks and document them
*/
enum Sprites {
@@ -226,8 +226,8 @@ enum Sprites {
/* Elrail stuff */
/* Wires. First identifier is the direction of the track, second is the required placement of the pylon.
"short" denotes a wire that requires a pylon on each end. Third identifier is the direction of the slope
(in positive coordinate direction) */
* "short" denotes a wire that requires a pylon on each end. Third identifier is the direction of the slope
* (in positive coordinate direction) */
SPR_WIRE_X_SHORT = SPR_ELRAIL_BASE + 3,
SPR_WIRE_Y_SHORT = SPR_ELRAIL_BASE + 4,
SPR_WIRE_EW_SHORT = SPR_ELRAIL_BASE + 5,
@@ -561,19 +561,18 @@ enum Sprites {
/* BTSUS == Suspension bridge */
/* TILE_* denotes the different tiles a suspension bridge
can have
TILE_A and TILE_B are the "beginnings" and "ends" of the
suspension system. they have small rectangluar endcaps
TILE_C and TILE_D look almost identical to TILE_A and
TILE_B, but they do not have the "endcaps". They form the
middle part
TILE_E is a condensed configuration of two pillars. while they
are usually 2 pillars apart, they only have 1 pillar separation
here
TILE_F is an extended configuration of pillars. they are
plugged in when pillars should be 3 tiles apart
*/
* can have
* TILE_A and TILE_B are the "beginnings" and "ends" of the
* suspension system. they have small rectangluar endcaps
* TILE_C and TILE_D look almost identical to TILE_A and
* TILE_B, but they do not have the "endcaps". They form the
* middle part
* TILE_E is a condensed configuration of two pillars. while they
* are usually 2 pillars apart, they only have 1 pillar separation
* here
* TILE_F is an extended configuration of pillars. they are
* plugged in when pillars should be 3 tiles apart
*/
SPR_BTSUS_ROAD_Y_REAR_TILE_A = 2453,
SPR_BTSUS_ROAD_Y_REAR_TILE_B = 2454,
SPR_BTSUS_Y_FRONT_TILE_A = 2455,
@@ -713,10 +712,10 @@ enum Sprites {
/* tubular bridges */
/* tubular bridges have 3 kinds of tiles:
a start tile (with only half a tube on the far side, marked _BEG
a middle tile (full tunnel), marked _MID
and an end tile (half a tube on the near side, maked _END
*/
* a start tile (with only half a tube on the far side, marked _BEG
* a middle tile (full tunnel), marked _MID
* and an end tile (half a tube on the near side, maked _END
*/
SPR_BTTUB_X_FRONT_BEG = 2559,
SPR_BTTUB_X_FRONT_MID = 2660,
SPR_BTTUB_X_FRONT_END = 2561,

79
table/town_land.h
View File

@@ -1,7 +1,6 @@
/* $Id$ */
/** @file town_land.h
*/
/** @file town_land.h */
enum {
HOUSE_TEMP_CHURCH = 0x03,
@@ -16,16 +15,16 @@ enum {
};
/** Writes the data into the Town Tile Drawing Struct
* @param s1 The first sprite of the building, mostly the ground sprite
* @param s2 The second sprite of the building.
* @param sx The x-position of the sprite within the tile
* @param xy the y-position of the sprite within the tile
* @param w the width of the sprite
* @param h the height of the sprite
* @param dz the virtual height of the sprite
* @param p set to 1 if a lift is present
* @see DrawTownTileStruct
*/
* @param s1 The first sprite of the building, mostly the ground sprite
* @param s2 The second sprite of the building.
* @param sx The x-position of the sprite within the tile
* @param xy the y-position of the sprite within the tile
* @param w the width of the sprite
* @param h the height of the sprite
* @param dz the virtual height of the sprite
* @param p set to 1 if a lift is present
* @see DrawTownTileStruct
*/
#define M(s1, s2, sx, sy, w, h, dz, p) {s1, s2, sx, sy, w - 1, h - 1, dz, p}
static const DrawBuildingsTileStruct _town_draw_tile_data[] = {
@@ -1928,20 +1927,20 @@ static const uint16 _housetype_flags[] = {
assert_compile(lengthof(_housetype_flags) == HOUSE_MAX);
static const byte _housetype_extra_flags[] = {
0, 0, 0, 0,32,32, 0, 8,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0,16, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
16, 0, 0, 0, 0, 0, 0, 0,
16, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 8, 0, 8, 0, 0, 0,
0, 0, 4, 0, 4, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 4,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 8, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 32, 32, 0, 8,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 16, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
16, 0, 0, 0, 0, 0, 0, 0,
16, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 8, 0, 8, 0, 0, 0,
0, 0, 4, 0, 4, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 4,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 8, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0,
};
assert_compile(lengthof(_housetype_extra_flags) == HOUSE_MAX);
@@ -2137,20 +2136,20 @@ static const HousetypeYear _housetype_years[] = {
assert_compile(lengthof(_housetype_years) == HOUSE_MAX);
static const byte _housetype_cargo_passengers[] = {
8, 8, 8, 2, 10,10,4, 6,
6, 2, 2, 2, 2, 8, 6, 6,
6, 10,6, 6, 4, 4, 4, 4,
3, 3, 3, 7, 8, 6, 8, 8,
4, 4, 4, 4, 8, 3, 3, 8,
8, 8, 8, 8, 5, 5, 3, 3,
3, 3, 8, 8, 9, 9,10, 10,
2, 2, 3, 3, 2, 2, 3, 3,
6, 6, 6, 6, 6, 6, 7, 7,
9, 9, 7, 7, 7, 7, 3, 3,
3, 3, 6, 2, 3, 6, 6, 8,
8, 6, 8, 2, 6, 3, 3, 3,
3, 3, 8, 4, 4, 8, 3, 3,
8, 8, 8, 4, 3, 3,
8, 8, 8, 2, 10, 10, 4, 6,
6, 2, 2, 2, 2, 8, 6, 6,
6, 10, 6, 6, 4, 4, 4, 4,
3, 3, 3, 7, 8, 6, 8, 8,
4, 4, 4, 4, 8, 3, 3, 8,
8, 8, 8, 8, 5, 5, 3, 3,
3, 3, 8, 8, 9, 9, 10, 10,
2, 2, 3, 3, 2, 2, 3, 3,
6, 6, 6, 6, 6, 6, 7, 7,
9, 9, 7, 7, 7, 7, 3, 3,
3, 3, 6, 2, 3, 6, 6, 8,
8, 6, 8, 2, 6, 3, 3, 3,
3, 3, 8, 4, 4, 8, 3, 3,
8, 8, 8, 4, 3, 3,
};
assert_compile(lengthof(_housetype_cargo_passengers) == HOUSE_MAX);