24-04-2019, 14:18
Zdaje się , że railtypes to jest 10 (00 train) .
Natomiast w miarę przerabiania, pamięci nie pochłaniają marginalizmu
i okazuje się przejrzystość przyswajalna .
Ponadto Grfcodec utworzy podkatalog [sprites] gdy wcześniej nie dekodowano.
Standardowo umieszczane są tam zawartości "prze_konwertowane" z .grf
W paczce z grfcodec dołączony jest nforenum.exe, który częściowo rekonstruuje zawiłości.
wywołany w asyście:
m.in. numeruje uzupełnione linie i zlicza bajty, długość pseudosprites - koryguje oraz wytknie pomyłki
(niektóre punkty)
~kiedy można sklecić jakiś nie za bardzo skomplikowany .grf , który może kreować nie tylko do JGR's
(tudzież OpenTTD-YPS z wariantem "decoupling").
source -
Przygotowanie zdekodowanego 32bpp_ez-0.1.grf , to wszystko wytworzy aplikacja grfWizard, jak minimalna instalacja experckiego kalkulatora.
Większość przetworzenia w .nfo sposobem schowek/Clip-board .
Ilustracje przetransferowane zgodnie z ich przesunięciami- ponumerowanie w pliku nfo jest powiązane z "kontenerami" obrazowymi (zbiór).
Zaznaczenie obejmuje zwykle poprzedzające pseudosprites (linie z * nad realsprites -dawniej.pcx).
Na koniec kompilacja kliknięciem w kwadracik to oznajmujący.
Z racji ,że poniższa linia :
...
1 * 54 14 "CINFOBVRSN" 04 00 02
...
-identyfikator nie może powtarzać się w dwóch .nfo /.grf .
-teoretycznie mogłoby się obejść , to w ramach unormowanego schematu
-jest zmieniona ostatnia cyfra (tylko zwiększona o 1), choć zalecane po-edytować dowolnie , żeby nie było identycznie.
Po ogarnięciu tego, jako tako, warto ponownie przejrzeć informacje o action 8, 14 { linki wyżej } ,
wyszperać kontynuacje .
Natomiast w miarę przerabiania, pamięci nie pochłaniają marginalizmu
i okazuje się przejrzystość przyswajalna .
Ponadto Grfcodec utworzy podkatalog [sprites] gdy wcześniej nie dekodowano.
Standardowo umieszczane są tam zawartości "prze_konwertowane" z .grf
W paczce z grfcodec dołączony jest nforenum.exe, który częściowo rekonstruuje zawiłości.
wywołany w asyście:
Kod:
nforenum sprites\nazwapliku.nfo(niektóre punkty)
~kiedy można sklecić jakiś nie za bardzo skomplikowany .grf , który może kreować nie tylko do JGR's
(tudzież OpenTTD-YPS z wariantem "decoupling").
source -
Kod:
// Automatically generated by GRFCODEC. Do not modify!
// (Info version 32)
// Escapes: 2+ 2- 2< 2> 2u< 2u> 2/ 2% 2u/ 2u% 2* 2& 2| 2^ 2sto = 2s 2rst = 2r 2psto 2ror = 2rot 2cmp 2ucmp 2<< 2u>> 2>>
// Escapes: 71 70 7= 7! 7< 7> 7G 7g 7gG 7GG 7gg 7c 7C
// Escapes: D= = DR D+ = DF D- = DC Du* = DM D* = DnF Du<< = DnC D<< = DO D& D| Du/ D/ Du% D%
// Format: spritenum imagefile depth xpos ypos xsize ysize xrel yrel zoom flags
0 * 4 0E 00 00 00
1 * 54 14 "CINFOBVRSN" 04 00 02 00 00 00 "BMINV" 04 00 00 00 00 00 "BNPAR" 01
00 00 "BPALS" 01 00 "WBBLTR" 01 00 33 00 00
2 * 72 08 08 "32ZC32bpp extra zoom tracks graphics" 00
"32bpp extra zoom tracks graphics" 00
// Zestaw wstawia do torow zwrotnice
// (zastepuje wyglad zredukowanej rozdzielczosci),
// nieznaczne obsorbcje CPU - utrzymujac mozliwosci energetyczne pod multum oprogramowania na baterii
3 * 5 0A 01 01 ED 03
4 sprites/32bpp_ez-0.100.png 8bpp 242 8 1 1 0 0 normal
| sprites/32bpp_ez-0.100.32.png 32bpp 274 360 256 132 -124 -6 zi4 chunked
| sprites/32bpp_ez-0.100.32.png 32bpp 546 360 128 66 -62 -3 zi2 chunked
5 * 5 0A 01 01 EE 03
6 sprites/32bpp_ez-0.100.png 8bpp 274 8 1 1 0 0 normal
| sprites/32bpp_ez-0.100.32.png 32bpp 2 504 256 132 -124 -6 zi4 chunked
| sprites/32bpp_ez-0.100.32.png 32bpp 274 504 128 66 -62 -3 zi2 chunked
7 * 5 0A 01 01 EF 03
8 sprites/32bpp_ez-0.100.png 8bpp 306 8 1 1 0 0 normal
| sprites/32bpp_ez-0.100.32.png 32bpp 418 504 256 132 -124 -6 zi4 chunked
| sprites/32bpp_ez-0.100.32.png 32bpp 2 648 128 66 -62 -3 zi2 chunked
9 * 5 0A 01 01 F0 03
10 sprites/32bpp_ez-0.100.png 8bpp 338 8 1 1 0 0 normal
| sprites/32bpp_ez-0.100.32.png 32bpp 146 648 256 132 -124 -6 zi4 chunked
| sprites/32bpp_ez-0.100.32.png 32bpp 418 648 128 66 -62 -3 zi2 chunked
11 * 5 0A 01 01 F1 03
12 sprites/32bpp_ez-0.100.png 8bpp 370 8 1 1 0 0 normal
| sprites/32bpp_ez-0.100.32.png 32bpp 2 792 256 132 -124 -6 zi4 chunked
| sprites/32bpp_ez-0.100.32.png 32bpp 274 792 128 66 -62 -3 zi2 chunked
13 * 5 0A 01 01 F2 03
14 sprites/32bpp_ez-0.100.png 8bpp 402 8 1 1 0 0 normal
| sprites/32bpp_ez-0.100.32.png 32bpp 418 792 256 132 -124 -6 zi4 chunked
| sprites/32bpp_ez-0.100.32.png 32bpp 2 936 128 66 -62 -3 zi2 chunkedPrzygotowanie zdekodowanego 32bpp_ez-0.1.grf , to wszystko wytworzy aplikacja grfWizard, jak minimalna instalacja experckiego kalkulatora.
Większość przetworzenia w .nfo sposobem schowek/Clip-board .
Ilustracje przetransferowane zgodnie z ich przesunięciami- ponumerowanie w pliku nfo jest powiązane z "kontenerami" obrazowymi (zbiór).
Zaznaczenie obejmuje zwykle poprzedzające pseudosprites (linie z * nad realsprites -dawniej.pcx).
Na koniec kompilacja kliknięciem w kwadracik to oznajmujący.
Z racji ,że poniższa linia :
...
1 * 54 14 "CINFOBVRSN" 04 00 02
...
-identyfikator nie może powtarzać się w dwóch .nfo /.grf .
-teoretycznie mogłoby się obejść , to w ramach unormowanego schematu
-jest zmieniona ostatnia cyfra (tylko zwiększona o 1), choć zalecane po-edytować dowolnie , żeby nie było identycznie.
Po ogarnięciu tego, jako tako, warto ponownie przejrzeć informacje o action 8, 14 { linki wyżej } ,
wyszperać kontynuacje .
![OpenTTD #Polska - Polskie forum gry OpenTTD [ARCHIWUM] OpenTTD #Polska - Polskie forum gry OpenTTD [ARCHIWUM]](https://forum.openttd.pl/images/logo.png)