Difference between revisions of "NML:Spriteset"
From GRFSpecs
Jump to navigationJump to searchPlanetmaker (talk | contribs) (Real sprites are only used in spritesets) |
Planetmaker (talk | contribs) (Undo revision 2630 by Planetmaker (Talk) but keep link fix) |
||
| Line 1: | Line 1: | ||
{{NMLNavBlocksyntax}} |
{{NMLNavBlocksyntax}} |
||
| − | |||
| − | == Spriteset == |
||
A spriteset associates a name with a number piece of an existing image file and describes the offsets with respect to some origin the graphics will be painted within the game. Different features and situations require that a single set has a certain amount of actual sprites associated. E.g. a vehicle usually requires eight sprites in order to provide on view for each of the eight possible ingame orientations of a vehicle. |
A spriteset associates a name with a number piece of an existing image file and describes the offsets with respect to some origin the graphics will be painted within the game. Different features and situations require that a single set has a certain amount of actual sprites associated. E.g. a vehicle usually requires eight sprites in order to provide on view for each of the eight possible ingame orientations of a vehicle. |
||
| Line 22: | Line 20: | ||
* Stations, houses, industry tiles, objects and airport tiles all define the look of a tile. This often requires more than one sprite, for example a concrete ground sprite with a building sprite on top of it. To combine and arrange these sprites a [[NML:Spritelayout|sprite layout]] is used, directly referring to sprite sets is not possible here |
* Stations, houses, industry tiles, objects and airport tiles all define the look of a tile. This often requires more than one sprite, for example a concrete ground sprite with a building sprite on top of it. To combine and arrange these sprites a [[NML:Spritelayout|sprite layout]] is used, directly referring to sprite sets is not possible here |
||
* Features not mmentioned here have no use for sprite sets, as such they are not supported by NML. |
* Features not mmentioned here have no use for sprite sets, as such they are not supported by NML. |
||
| − | |||
| − | == Real sprite format == |
||
| − | |||
| − | Several features will need to reference actual graphics from files you created. You can provide real sprites in many different formats, all detailed below. There is a lot of information you'll need to provide. Most important are the filename and the location of the sprite in that file. Since most blocks that reference realsprites will allow you to specify a default filename, you don't often need to give a filename for every separate sprite. |
||
| − | |||
| − | Allowed formats: |
||
| − | |||
| − | [left_x, upper_y, width, height, offset_x, offset_y] |
||
| − | [left_x, upper_y, width, height, offset_x, offset_y, compression] |
||
| − | [left_x, upper_y, width, height, offset_x, offset_y, filename] |
||
| − | [left_x, upper_y, width, height, offset_x, offset_y, compression, filename] |
||
| − | [offset_x, offset_y] |
||
| − | [offset_x, offset_y, compression] |
||
| − | [offset_x, offset_y, filename] |
||
| − | [offset_x, offset_y, compression, filename] |
||
| − | |||
| − | If you don't specify left_x, upper_y, width and height it'll default to the complete file. If you don't specify the filename it'll take the filename from the block containing this realsprite. It's a fatal error not to specify a filename for either the block containing a realsprite or the realsprite itself. For possible values of compression, see the table below. |
||
| − | |||
| − | For all parameters you can use expressions as complex as you want as long as they can be resolved at compile time. |
||
| − | |||
| − | As of NML r1654 the compression bit has only two possible values. When ommitted it will take the default value. |
||
| − | |||
| − | {| class="t" |
||
| − | ! Name |
||
| − | ! Description |
||
| − | |- |
||
| − | | CROP (default) or NOCROP |
||
| − | | Whether to crop the sprites when the -c command line option is set. |
||
| − | |} |
||
| − | |||
| − | |||
| − | Example: |
||
| − | |||
| − | <pre style="color:blue"> |
||
| − | [0, 0, 64, 31, -31, 0, TILE] |
||
| − | </pre> |
||
Revision as of 00:23, 9 September 2011
Vehicles, Stations, Canals, Bridges, Towns, Houses, Industries (Tiles), Cargos, Airports+Tiles, Objects, Railtypes, Roadtypes, Tramtypes, Terrain
A spriteset associates a name with a number piece of an existing image file and describes the offsets with respect to some origin the graphics will be painted within the game. Different features and situations require that a single set has a certain amount of actual sprites associated. E.g. a vehicle usually requires eight sprites in order to provide on view for each of the eight possible ingame orientations of a vehicle.
spriteset (SPRITESET_NAME, graphics_file) {
list of realsprites
...
}
Each sprite may be prefixed with a label, see sprite layouts for more info. Example:
some_label: [... real sprite ...]
How to use a sprite set depends on the feature:
- For canals, cargos, airports (not tiles!) and railtypes, you can refer to sprite sets directly from the graphics block, or use intermediate (random)switches to make a descision.
- For vehicles, the same as above is possible. However, to facilitate the common case of having multiple loading stages, you can also define sprite groups, see below. These sprite groups are then used in place of a single sprite set.
- Stations, houses, industry tiles, objects and airport tiles all define the look of a tile. This often requires more than one sprite, for example a concrete ground sprite with a building sprite on top of it. To combine and arrange these sprites a sprite layout is used, directly referring to sprite sets is not possible here
- Features not mmentioned here have no use for sprite sets, as such they are not supported by NML.
