realSprites
  EN PL |
| Introduction |
Real'sprites' są graficzną częścią plików GRF, są tym, co użytkownik faktycznie widzi w grze. Od wersji 1.2 OpenTTD istnieją dwa wyraźnie różne sposoby pisania prawdziwych 'sprites' , w zależności od używanej wersji informacji.
TTDPatch i OpenTTD do wersji 1.2 rozumieją tylko informacje GRF w wersji 7.
'Prawdziwy sprite' ma następujący format:
<sprite_attributes> ::= [<label>,] <filename> <xpos> <ypos> <flags> <ysize> <xsize> <xrel> <yrel> sprite(<sprite_attributes>)
| <sprite_attributes> | ||
| Element | Rozmiar | Opis |
|---|---|---|
| <label> | string | Etykieta umożliwiająca opcjonalne odwoływanie się do tego 'sprite' |
| <filename> | string* | Nazwa pliku, w którym zostanie znaleziony 'sprite' |
| <xpos> | dec | Pozycja x lewego górnego rogu 'sprite' w pliku |
| <ypos> | dec | Pozycja y lewego górnego rogu 'sprite' w pliku |
| <flags> | B | "Flagi", patrz poniżej |
| <ysize> | dec | Rozmiar y sprite'a |
| <xsize> | dec | Rozmiar x 'sprite' |
| <xrel> | dec | Pozycja x lewego górnego rogu 'sprite' względem "środka" (zwykle jest to wartość ujemna) |
| <yrel> | dec | Pozycja y lewego górnego rogu 'sprite' względem "środka" (zwykle jest to wartość ujemna) |
- W przeciwieństwie do ciągów tekstowych w kodzie GRF, ten ciąg nie powinien mieć kończącej liczby "00" i nie powinien być umieszczany w cudzysłowie.
<label>
'Sprite' można nadać etykietę. Zwykle nie ma to sensu, ponieważ w bloku 'sprites' mogą znajdować się tysiące 'sprites' , ale mogą wystąpić przypadki, w których byłoby to pomocne w zarządzaniu dużymi, ale ustrukturyzowanymi zestawami 'sprites' . Etykiety te można stosować również w układach kafli na stacjach:
Example:
spriteblock(
set(
...
sprite(__platform, modern_set.pcx 210 1432 09 24 42 -31 -3) // platforms start
...
)
)
layout(_BAMBERG,
...
tile(
ground(1012)
normal(__platform, xyz(0,0,0), dxdydz(5,16,12))
normal(__platform+1, xyz(0,0,0), dxdydz(16,16,35))
)
...
)
Określa nazwę pliku graficznego zawierającego sprite'y. Dołączenie nazwy pliku do każdej funkcji sprite() pozwala na ich dystrybucję w różnych plikach. Ścieżka powinna być ścieżką względną, lub w ogóle ją pominąć, a zamiast tego powinna być podana przez zewnętrzną zmienną w jednym z lokalnych plików .m4 lub ustawiona przez funkcję setpath() . Zobacz przykład.
Żaden sprite nie może również zawierać zerowych pikseli; ysize i xsize muszą mieć co najmniej 1.
W grfcodec 0.9.7 i wcześniejszych wersjach jest błąd, który uniemożliwia im prawidłowe zakodowanie 'sprite' z mniejszą wartością ypos niż jakikolwiek wcześniejszy sprite. Najlepszym sposobem na obejście tego błędu jest aktualizacja do najnowszej wersji. W przeciwieństwie do innych liczb jest to bajt szesnastkowy. Obecnie obsługiwane są następujące bity:
| Bit | Wartość | Znaczenie |
|---|---|---|
| 0 | 1 | Indeks koloru 0 jest przezroczysty (powinien być zawsze ustawiony; ignorowany, jeśli ustawiony jest bit 3) |
| 1 | 2 | Przechowuj skompresowany sprite w pamięci |
| 3 | 8 | Sprite jest w formacie podzielonych ( chunked) danych (inaczej "kompresja kafli") |
| 6 | 40 | Sprite nie powinien być przycinany ( cropped) [*]. (przestrzegane przez GRFCodec r1604 i nowsze) |
[*] Zwykle grfcodec przycina przezroczyste obramowanie pikseli z 'sprite' do możliwie najmniejszego rozmiaru bez utraty informacji. Można tego uniknąć, ustawiając tę flagę w przypadkach, gdy rzeczywisty rozmiar 'sprite' ma znaczenie, tj. Gdy 'sprites' podrzędne na niej polegają.
Najczęstsze wartości flag to "01" i "09". "03" jest przydatna w przypadku dużych 'sprites' , które są rzadko używane, ponieważ zmniejsza zużycie pamięci kosztem wolniejszej szybkości rysowania. Generalnie złym pomysłem jest używanie jakiejkolwiek innej wartości, ponieważ może to powodować problemy. "255" to szczególnie zły pomysł.
TTD przechowuje jeden punkt dla każdego 'sprite' . xrel i yrel określają, jak daleko w prawo i w dół (odpowiednio) ma przejść od punktu TTD do lewego górnego rogu 'sprite' . Zobacz wpis o współrzędnych w Tutorial`u TTDPatch.
Zmniejszenie rozmiaru xsize i ysize o połowę oraz zanegowanie wyników daje przyzwoity punkt wyjścia dla tych wartości, a dalsze korekty można wykonać manualnie, za pomocą NFOEditor lub (w TTDPatch 2.0.1 alpha 69 i nowszych) za pomocą GRFAuthorHelperWindow . Zakresy czterech liczb po flagach są następujące:
ysize: 1 .. 255
xsize: 1 .. 65535
xrel: -32768 .. 32767
yrel: -32768 .. 32767
Należy odnotować, że ysize*xsize nie może przekraczać 65535. Przezroczystość i efekt szkła można osiągnąć za pomocą RecolourSprites
| Format info version 32 |
<sprite_attributes> ::= [<label>,] <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> normal <flags>
sprite(<sprite_attributes>)
|
Prośba odnotowania, że parametry <xsize> i <ysize> zostały zamienione w info version32!
Możliwe jest również zdefiniowanie sprite'ów 32bpp dla wielu poziomów powiększenia. W tym przypadku format jest następujący:
<sprite_attributes> ::= [<label>,] <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> normal <flags>
| <filename> 8bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> <zoomlevel> <flags>
| <filename> 32bpp <xpos> <ypos> <xsize> <ysize> <xrel> <yrel> <zoomlevel> <flags>
| <filename> mask <xsize> <ysize>
...
sprite(<sprite_attributes>)
|
Typ pierwszego 'sprite' musi zawsze mieć wartość 8bpp i 'normalny' poziom powiększenia (patrz poniżej). Kolejne wiersze dla alternatywnych 'sprites' mogą być dowolnego typu i poziomu powiększenia. Dostępne typy to:
| Typ | Opis |
|---|---|
| 8bpp | Sprite z 8-bitową głębią kolorów w jednej z akceptowanych palet |
| 32bpp | Sprite True Color z 32-bitową głębią kolorów |
| maska | Jeśli jest używany, ten typ musi natychmiast następować po wpisie 32bpp. Definiuje 'translacje' koloru dla poprzedzającego sprite'a 32bpp i musi być sprite'em z paletą 8bpp o dokładnie takim samym rozmiarze jak poprzedni sprite 32bpp. 'Wpis' palety 0 oznacza narysowanie 32bpp jak zwykle, inne kolory definiują kolory zastępcze, gdzie poprzedni sprite 32bpp jest interpretowany jako informacja o intensywności i kanale alfa |
| nazwa | zoom level | 'krata' rozmiar | ground sprite (zig-zag border) | ground sprite ('gładka granica') | xrel, yrel (smooth border) | opis |
|---|---|---|---|---|---|---|
| zo8 | 8x out | 8 x 3 | 8 x 4 | 8 x 3 | -3, 0 | 'pomniejszone' |
| zo4 | 4x out | 16 x 8 | 16 x 7 | 16 x 7 | -7, 0 | |
| zo2 | 2x out | 32 x 16 | 32 x 15 | 32 x 15 | -15, 0 | |
| normal | none | 64 x 32 | 64 x 31 | 64 x 31 | -31, 0 | standard |
| zi2 | 2x in | 128 x 64 | 128 x 62 | 128 x 63 | -62, -1 | zoomed in |
| zi4 | 4x in | 256 x 128 | 256 x 124 | 256 x 127 | -124, -2 |
Dodatkowo powinieneś wywołać funkcję zoom32_on() raz w każdym pliku źródłowym w celu obsługi pełnych nazw ścieżek dla dodatkowych 32 bpp i/lub zoom sprite'ów w funkcji sprite().
Prośba odnotowania, że kompilowanie plików zawierających grafikę 32bpp i/lub grafiki z poziomami powiększenia wymaga pliku "count32.m4" (ustawia to 'wersję 32 informacji o formacie' dla grfcodec) zamiast "count.m4" .
W m4nfo prawdziwe sprite'y są obsługiwane przez funkcję sprite():
Example (real sprite):
// info version 7
sprite(120T.pcx 10 10 01 14 6 -2 -11)
// info version 32
sprite(120T.pcx 8bpp 10 10 14 6 -2 -11 normal
| 120T_z2.pcx 32bpp 10 10 28 12 -4 -22 zi2
| 120T_z4.pcx 32bpp 10 10 56 24 -8 -44 zi4
)
W m4nfo, prawdziwe sprite'y muszą być używane wewnątrz funkcji spriteblock() , w zależności od danej funkcji (pociągi, stacje, domy, ...). Więcej informacji znajdziesz w rozdziale o grupowaniu 'sprites' .