-
Notifications
You must be signed in to change notification settings - Fork 0
instal
![]() EN PL |
m4nfo najlepiej nadaje się do dużych projektów programistycznych newGRF, które zwykle składają się z rozproszonych plików źródłowych i wymagają pewnego rodzaju zarządzania projektami. Wymaga to dodatkowego wsparcia oprogramowania, co skutkuje 'zaawansowaną instalacją'. Ale oczywiście możliwe jest również użycie m4nfo w bardzo prosty sposób z tylko jednym modułem m4nfo i grfcodec.
Po zainstalowaniu M4 i grfcodec , może być konieczne ustawienie zmiennej $PATH / %PATH% w taki sposób, aby oba programy były dostępne z katalogu roboczego. Następnie rozkaz
M4 -R m4nfo_trains.m4 <test.nfx> test.nfo
powinien wygenerować test.nfo z pliku test.nfx, biorąc pod uwagę, że test.nfx jest plikiem źródłowym m4nfo zawierającym prawidłowy kod m4nfo.
Od nagłówka m4nfo r91, różne systemy operacyjne są obsługiwane przez funkcje m4nfo cargotranslationtable() i export(), które wymagają, aby podstawowy system operacyjny obsługiwał pliki scratch podczas pracy z rozproszonymi plikami źródłowymi. Domyślnie jest to windows, aby uzyskać poprawne zachowanie dla systemu Unix/OSX , powyższe polecenie należy zmodyfikować na
M4 -Dunix -R m4nfo_trains.m4 <test.nfx> test.nfo
Należy pamiętać, że test.nfo nie zawiera obecnie odpowiednich numerów sprite. Ponieważ numery sprite są niezbędne do debugowania, muszą zostać wygenerowane przez drugie uruchomienie, w tym plik count.m4 (lub ''count32.m4'' , oba zawarte w pakiecie do pobrania m4nfo):
copy count.m4 + test.nfo test.tt (Windows) lub cat count.m4 test.nfo > test.tt (Unix / OSX) M4 < test.tt > test.nfo
Możesz wtedy wydać ostatnie polecenie
grfcodec -e test.grf
aby wygenerować newGRF test.grf zarówno z pliku test.nfo , jak i wszelkich powiązanych plik(ów) graficznych, np. test.pcx lub test.png .
Zaleca się umieszczenie potrzebnych poleceń w pliku wsadowym i tym samym możliwość wygenerowania nowego GRF przy użyciu tylko jednego polecenia:
|
Przykład (DOS/Windows): m4.exe <sprites\%1.nfx >sprites\%1.nfo copy count.m4 + sprites\%1.nfo test.tt m4.exe <test.tt >sprites\%1.nfo grfcodec.exe -e %1.grf |
Przykład (Unix/OSX): #!/bin/bash m4 -Dunix <sprites/$1.nfx >sprites/$1.nfo cat count.m4 sprites/$1.nfo >test.tt m4 <test.tt >sprites/$1.nfo grfcodec -e $1.grf |
Prośba zanotowania: Pliki źródłowe m4nfo są zwykłymi plikami tekstowymi i mają rozszerzenie .nfx. Pliki nagłówkowe m4nfo (jeśli istnieją) są również zwykłymi plikami tekstowymi, ale są oznaczone .m4 suffix.
Po zainstalowaniu M4 , make , grfcodec , irfanview i pspad , powinieneś ustawić odpowiednią strukturę katalogów dla swojego projektu.
Załóżmy, że projekt będzie składem o nazwie 'bluetrain' . W takim przypadku należy założyć katalog 'bluetrain' i dołączyć do niego inny katalog 'sprites' . Ponadto potrzebujesz pliku 'makefile' w katalogu 'bluetrain' , aby sterować narzędziem GNU 'make' . Ten katalog może również zawierać pliki związane z projektem, takie jak plik 'names.m4' z mapowaniem nazwy /ID pojazdu dla wszystkich pojazdów zestawu lub ogólny plik 'bluetrain.m4' zawierający jeszcze więcej elementów związanych z projektem, takich jak jako ciągi tekstowe, stałe odbarwiania, niestandardowe kody błędów, typy ładunków itp. Pokazane tutaj przykłady z mojego "DB Set" newGRF:
Przykład (names.m4): define(_BR92,0x00) define(_BR38,0x01) define(_BR18,0x02) define(_BR01,0x03) define(_BR05,0x04) define(_BR44,0x05) define(_SVT137,0x06) ...
Przykład (dbxl.m4):
// M4 macros for DBXL 0.9
//
// transparent sprite
define(VOID, 0xFE)
// shorthands
define(ALLOW,{cbr(1)})
define(DISALLOW,{cbr(0)})
// DBXL Parameters
define(_CAPACITIES,0)
define(_GATES,1)
define(_TANKLIVERY,2)
define(_STAKELIVERY,3)
define(_SEMAPHORES,4)
define(_DBRAILS,5)
// DBXL cargo aging values
define(PS_LOW,128) // *1
define(PS_DEFAULT,256) // *2
define(PS_MEDIUM,1152) // *9
define(PS_HIGH,2048) // *16
define(PS_HIGHER,3200) // *25
define(PS_DELUXE,4608) // *36
define(PS_DELUXEXL,6272) // *49
// DBXL text constants
//
// TSF = SuffiX for cargoes
define(TSF_PGOOD,0x00)
define(TSF_CONT,0x01)
define(TSF_PLYW,0x02)
define(TSF_LIQU,0x03)
define(TSF_MACH,0x04)
...
// TSX = SuffiX for coaches
define(TSX_RHEINGOLD,0x20)
define(TSX_TEE,0x21)
define(TSX_IR,0x22)
define(TSX_IC,0x23)
define(TSX_SBAHN,0x24)
...
// TTS = Train Services / refittable coaches
define(TTS_RHEINGOLD,0x50)
define(TTS_FTRAIN,0x51)
define(TTS_RHEINGOLD2,0x52)
define(TTS_TEE,0x53)
define(TTS_IRIC,0x54)
...
// TLH = Locomotive Help texts
define(TLH_BR92,0xD0)
define(TLH_BR75,0xD1)
define(TLH_BR38,0xD2)
define(TLH_BR18,0xD3)
define(TLH_BR01,0xD4)
...
// constants for recolouring
//
// original colours / CB results
define(DBLUE,0x8307)
define(LGREEN,0x8308)
define(PINK,0x8309)
define(YELLOW,0x830A)
define(RED,0x830B)
...
// error codes
//
define(ATT_OK,0xFE)
define(ATT_VAN,0x40)
define(ATT_CAR,0x41)
define(ATT_REQLDCAR,0x42)
define(ATT_CARBADNUM,0x43)
...
Katalog 'sprites' będzie zawierał wszystkie pliki graficzne projektu, a także wszystkie pliki źródłowe m4nfo (~ .nfx).
Teraz rdzeniem systemu jest plik 'makefile' , który będzie sterował narzędziem 'make' w taki sposób, że projekt będzie aktualizowany we właściwy sposób, niezależnie od plików, nad którymi pracowano od ostatniej aktualizacji. Np. Jeśli projekt zawiera 4 pliki źródłowe bluetrain_1.nfx .. bluetrain4.nfx, a plik graficzny silnika 'VT_001.bmp', do którego adresowany jest adres 'bluetrain_3.nfx', zostałby zaktualizowany od ostatniego uruchomienia, 'make' uruchomi narzędzie do konwersji grafiki, aby przekonwertować 'VT_001.bmp' na 'VT_001.pcx' , a następnie uruchomi grfcodec, aby zbudować nowyGRF.
Podobnie, jeśli od ostatniego uruchomienia nastąpiły zmiany w pliku 'bluetrain_2.nfx' , polecenie 'make' uruchomi M4 w celu skompilowania 'bluetrain_2.nfo' z 'bluetrain_2.nfx' , a następnie uruchomi grfcodec, aby zbudować nowyGRF.
W ten sposób tylko zaktualizowane pliki są używane do tworzenia nowego GRF.
Oto prototypowy plik makefile dla wyżej wymienionego projektu:
Przykład (makefile):
# 'bluetrain' makefile
V = sprites\bluetrain
# include macro files, header, trains, names etc
INCS = bluetrain.m4 names.m4
# .nfo target files
NFOFILES = $V_0.nfo $V_1.nfo $V_2.nfo $V_3.nfo $V_4.nfo
# graphics source files
BMPDIR = bluetrain/sprites/
PCXFILES := $(patsubst %.bmp,%.pcx,$(subst /,\,$(wildcard $(BMPDIR)*.bmp)))
# M4 text processor
M4 = c:\programs\m4gnuw32\bin\m4.exe
# grfcodec program
GRFCODEC = c:\mpstest\ttdlx\grfcodec.exe
GRFCODECFLAGS = -e -m0
# irfanview program
IVIEW = c:\programs\iview351\i_view32.exe
# rule to make .nfo from .nfx
%.nfo : %.nfx $(INCS)
$(M4) $< > $@
# rule to make .pcx from .bmp
%.pcx : %.bmp
$(IVIEW) < /convert=$@
# rule to make test.grf from .nfo and .pcx
test.grf : $(PCXFILES) $(NFOFILES)
copy count.m4 + $(strip $(NFOFILES)) sprites\test.tt
$(M4)<sprites\test.tt >sprites\test.nfo
$(GRFCODEC) $(GRFCODECFLAGS) test.grf
copy test.grf C:\ttdxwin\newgrf\bluetrainw.grf
copy test.grf C:\mpstest\ottd\data\bluetrainw.grf
all: test.grf
Nie ma tu ani czasu, ani miejsca na ogólne wyjaśnienie plików makefile, dlatego warto zajrzeć do dokumentacji 'make' .
Teraz najlepsze jest to, że ten plik makefile można aktywować uruchamiając 'make' z edytora, np. w PSPAD , klikając przycisk 'kompiluj' !

