[Pm37]

Cześć!

Nie mam bladego pojęcia jak doprecyzować nazwę tematu, żeby każdy mógł zrozumieć o co tu chodzi, a sądzę, że temat może okazać się jeszcze - pomimo tylu lat od premiery gry (!) - przydatny.

Na początku wyjaśnię zasady i o co chodzi. To będzie długi wywód, ale sądzę, że warto się z nim zapoznać, bo zawieram w nim liczne obserwacje.

Cytat:

Specyfikacja mojego komputera: Procesor: Intel Core i7-7700K (bez OC) Karta graficzna: Gigabyte GeForce GTX 1070 G1 Gaming 8GB GDDR5 RAM: 4 x 8 GB DDR4 3200 MHz (łącznie 32 GB) Wersja systemu: najpierw Windows 7 64-bit, potem Windows 10 Professional Dysk instalacji systemu: SSD Samsung 850 Evo 250 GB M.2 Dysk instalacji Trainza 2010: SSD Samsung 960 Evo 500 GB M.2 Wersja Trainza 2010: Trainz Simulator 2010 build 49933, tryb kompatybilny/natywny (w późniejszym czasie natywny dla weryfikacji błędów)

Cytat:

Cele eksperymentu: - Przystosować wszystkie / jak najwięcej dodatków pod build 3.3 - Odzyskać wydajność Trainza i płynność map - Przygotować się pod przejście na wyższe/nowsze wersje Trainza

Z racji tego, że byłem wieloletnim użytkownikiem tej wersji Trainza, konkretnie Trainz Simulator 2010 na buildzie 49933, borykałem się z różnymi kłopotami tej konkretnej wersji. A to potrafiło mi lagować mapy, doznawałem spadków ilości FPS, a to długi czas wczytywania mapy, a to przycięcie przy wstawieniu obiektu itd. No myślę, że każdy się z tym spotykał. Byłem też w pełni świadom, że TS2010 z buildem 49933 to w dalszym ciągu przestarzały silnik graficzny JETengine oraz, że jest program 32-bitowy, a zatem nie obsługuje zbyt dużej ilości pamięci RAM, nie wykorzysta potencjału GPU czy chociażby możliwość SSD na porcie M.2. Nie jest tak, że tych właściwości Trainza olałem czy coś. Byłem tego jak najbardziej w pełni świadom.

I teraz konkret. W zeszłym roku wkurzyłem się i postanowiłem coś zrobić z tymi przycinkami. Czarę goryczy przelał fakt, że miałem problem z mapą, którą od lat chciałem się pobawić swobodnie, a konkretniej mapą Polskie Koleje Wąskotorowe od Jamala. Mapa miała u mnie kłopoty i w TRS2006 (chociaż tam działała jeszcze jako tako), jak i w TS2010. Tyle, że w TS2010 działała znacznie gorzej.



Tak, tak wyglądały u mnie PKW. Zapomniałem dodać oczywiście, że pierwotnie pracowałem w trybie kompatybilnym. Grywalność zerowa, tylko momentami mogłem zobaczyć jakiś fragment mapy w trybie geodety, w niektórych przypadkach nawet ustrzeliłem screenshoota (!) po bardzo długiej męczarni z samą mapą, a wszystko to zostawiało we mnie niedosyt i złość, którą w końcu przekułem w coś ambitnego.

Postanowiłem najpierw w swojej bazie zasobów eliminować dodatki z czerwonymi wykrzyknikami. Część dzięki użytkownikom udało mi się naprawić, a resztę własnymi siłami i pomyślunkiem dałem radę. Z czasem dla zasady ponaprawiałem lub wsparłem się pomocą kolegów (m. in. RBachowi - serdecznie Ci dziękuję za tę pomoc ;)) dla wszystkich map, żeby w końcu nie mieć ani jednej błędnej zależności.

Rezultat? Grywalność wcale się nie zmieniła :D To znaczy mapy dalej miały dokładnie te same bolączki. Imho - tutaj teraz zaznaczę, że wtedy nie miałem takiej wiedzy jaką mam aktualnie. Myślałem, że problemem są wyłącznie dodatki z wykrzyknikami i że to ich błędy mogą powodować jakieś problemy z wydajnością. Dodajmy - korzystałem z symulatora wyłącznie do screenshootów (!). Tylko i wyłącznie (!). Stąd też zarazem i moja niska i typowo screenshoociarska aktywność na forum.

No ale wracając do tematu. Oczywiście parę przecinków i cygaret później, wróciłem do tematu i zabrałem się za niego inaczej. Zabrałem się za przerabianie dodatków i dostosowanie ich do buildu 3.3, czyli teoretycznie (tak mi się wydaje) pożądanego przez Trainz Simulator 2010 w buildzie 49933 i w trybie kompatybilnym (chociaż te drugie bez znaczenia czy tryb natywny czy kompatybilny). Na początku też w ogóle nie miałem bladego pojęcia co się stanie. Miałem jedynie plan, a właściwie cel - ciekawe co ty zrobisz, gdy ja zrobię ci dobrze i będziesz mieć w końcu dodatki dostosowane do tego co ty chcesz.

No i finalnie zrobiłem to co było trzeba.

Edit: po namyśle zostawiam przejściowe "wersje", gdzie stopniowo przybywało dodatków poprawionych:







No i finalnie dotarłem do tego stanu:



Tak, to jest rezultat tych napraw. I teraz muszę z góry przeprosić, ale nie mam bladego pojęcia ile tutaj dodatków finalnie zostało przeze mnie naprawionych lub przerobionych na build co najmniej 2.9 (a domyślnie 3.3), ale pamiętam, że ok. 150 zostawiłem na oryginalnym formacie.

Zainteresowanych samą mapą i przyczyną jej fatalnego działania mogę od razu odpowiedzieć, że problemem w tej mapie były w dużej mierze dodatki, które nie korzystały z wpisów mesh-table, a co jest chyba warunkiem koniecznym przynajmniej od czasów TRS2006 (pewności nie mam, ale faktycznie build 2.9 nie pozwala już tworzyć dodatków bez tych wpisów, inaczej zaskoczy nas wykrzyknikiem). Głównym zabójcą wydajności były też drzewa spline od Wojtasa. Największy skok wydajności zaliczyłem w momencie, w którym te drzewa dostosowałem do buildu 2.9+. Od tamtej pory mapa prezentowała się już poprawnie, a pozostałe dodatki straciły znaczenie. Przyrost wydajności potem nie był już taki duży tzn. nie poprawił się ani znacząco sam zasięg odległości rysowania mapy, ani też szybkość w wyświetlaniu obiektów itd.

Zadowolony z rezultatu zaczynałem się też zastanawiać co się dzieje, że Trainz strzelał takie fochy. Jedyne wytłumaczenie jakie mi się nasunęło to to, że być może Trainz kompilował sobie przy każdorazowym uruchomieniu mapy lub wczytaniu jakiegoś jej fragmentu dodatki, a że te były napisane w starożytny sposób, to on musiał zużywać dodatkowe zasoby na ich ogarnięcie. Nie widzę innego wytłumaczenia. Mam nadzieję, że ktoś mądrzejszy lepiej to wytłumaczy.

No ale zabawa u mnie się rozkręciła i od tamtej pory bawiłem się w kolejne naprawy.

Cytat:

Garść statystyk: Z racji tego, że nie jestem pewien z iloma dodatkami z buildem 3.3 zaczynałem TS2010, zakładam, że było ich około 600, bo gdzieś taką liczbę pamiętam. Dla TS2009-TS12 żeby zabawa tryb natywny miała sens, wystarczy build 2.9 z moich obserwacji. To jest taki dla mnie pewniak, bo wtedy dodatki najchętniej pokazywały swoje błędy, a po ich naprawie taki dodatek już nie zamulał map, a i po przejściu na T:ANE nie stwarzał większych problemów poza miniaturkami. Innymi słowy - raz naprawiony dodatek, wieczny spokój. Chyba, że masz wpisy o miniaturki, które nie istnieją. Tego CMP w TS2010 nie pokazywał. I tak: po naprawie uzyskałem: - 6 786 dodatków z buildem 3.3 - 15 175 dodatków z buildem co najmniej 2.9 na łączną sumę bazy danych liczącą 57 927 dodatków na stan dzisiejszy tj. 13 lutego 2022. To jest łączny wynik. Nie rozgraniczam różnicy między dodatkami wbudowanymi, a zainstalowanymi, bo obydwa typy tak samo przyczyniały się do moich spadków wydajnościowych i nie tylko.

Eksperyment w końcu mnie zadowolił, bo z czasem zacząłem odzyskiwać wydajność na kolejnych mapach. Nawet legendarny już Projekt Sudety 1976 uzyskał u mnie jeszcze lepszą wydajność.

Z czasem też postanowiłem przetestować tryb natywny, który znalazł dla mnie ciekawe zastosowanie. Chodzi o to, że pomagał mi wyłapywać roślinność np. Jankvisa lub Denloga, które zachowywały się dziwnie, tzn. świeciły albo nie wyświetlały przeźroczystości.

Rozwiązaniem problemu okazało się przeskanowanie tych dodatków programem IM Editor, dzięki czemu porównując je z roślinnością np. Bogdana, ustaliłem, że Jankvis powinien był (chociaż w czasach gdy ta roślinność była tworzona to najpewniej o tym nie wiedział, bo Trainz nie zmienił tylu rzeczy w sobie) zastosować następujące parametry dodatku:

Cytat:

Ambient colour: 255,255,255 Diffuse color: 0,0,0 Specular color: 0,0,0

Z jakiegoś powodu Trainz 2010 w wersji natywnej ignoruje wpisy light = 0 w configu i i tak domyślnie próbuje oświetlić ten obiekt. Ta informacja jest o tyle ważna, że ta naprawa dokonana w TS2010 przydała się także w T:ANE, dzięki czemu roślinność Jankvisa oraz Denloga mogą się wyświetlać normalnie bez efektu "odbijania słońca" pod niektórymi kątami. Kto raz bawił się mapami bez tych naprawionych dodatków, chyba pamięta ten połysk, wręcz biały pod odpowiednim kątem.

Dodatkowo też programem AssetX (w niektórych przypadkach byłem zmuszony użyć programu PEVSoft Images2TGA) hurtowo poprawiałem tekstury oraz dodawałem wpisy o wyświetlaniu tekstury wzorem Bogdana. Chodziło o zastosowanie zwykłej przeźroczystości bez alphy zapisanej w pliku .bmp.

Denlog z kolei podobnie stosował przeźroczystość korzystając z plików alphy w formacie .bmp, a także w IM Editorze pokazywało, że zamiast stosować material type "onetex" zastosował "thumptex", co sprawiło, że roślinność nie obsługiwała przeźroczystości i wyświetlała się nam roślina z jakimś tłem. Po zmianie roślinność wracała do normy i działa normalnie.

Zostawiam też tę wiedzę, bo przyda się być może komuś, kto chce korzystać z naszych starych map w T:ANE+, a nie wie co się dzieje i rezygnuje z używania nich lub wymienia roślinność na inną.

Wracając do wątku. Tryb natywny pozwalał mi wyłapywać te błędy w wyświetlaniu się różnych obiektów, a także pokazał mi jak powinna wyglądać wydajność Trainza. No i faktycznie był dużo bardziej płynny od kompatybilnego, ale do czasu... Okazało się, że po licznych naprawach obiektów, różnica w wydajności pomiędzy trybami się zmniejsza, aż w końcu jest identyczna. Przynajmniej tak było w moim przypadku.

Finalnie porwałem się też na mapę Lublin - Dorohusk, która od początku była moim marzeniem, a z której w sumie nigdy nie popełniłem żadnego większego screena. Wiedziałem już co robić i się za to wziąłem. Tygodnie kreciej roboty pomogły mi w końcu zmienić widok tego typu:



W ten:



Finalnie mapa działa w końcu tak jak chciałem. I w sumie tak było do czasu, bo zostało mi jeszcze trochę do poprawy, aż kilka tygodni temu... Trainz 2010 zrobił mi dziwny bunt i zaczął na nowo obcinać zasięg rysowania (!) moim zdaniem bez powodu.






Przyznam szczerze, że nie mam bladego pojęcia co się stało. W plikach nie usuwałem siatek LOD ani nic takiego, starałem się naprawiać dodatki zgodnie ze sztuką. Jestem zaskoczony tym, że Trainz zrobił coś takiego, co moim zdaniem nie ma żadnego uzasadnienia, ale finalnie po tym numerze zakończyłem przygodę z Trainz 2010 w jakimkolwiek wydaniu, edycji, formacie itd. Od tamtej pory siedzę na T:ANE i jest mi dobrze.

Dobra, skoro już tyle napisałem, chcę zostawić garść swoich przemyśleń, a także jestem ciekaw opinii i waszych doświadczeń.

Ten projekt zrobiłem z ciekawości. Finalnie ta "bezużyteczna" robota czegoś mnie nauczyła, jestem bardzo zadowolony, że nauczyłem się dzięki temu nowych sztuczek, obsługi programów. Jestem też w pewnym sensie pełen podziwu dla starego TS2010, bo sądzę, że mimo wszystko niesłusznie jest postrzegany jako mało wydajny. On potrafi być, ale w dobie, gdy T:ANE i TRS19 są już podstawowymi wersjami Trainza, zdecydowanie odstaje.

Ostatni problem, który finalnie sprawił, że przesiadłem się na T:ANE, najpewniej można wyeliminować poprzez reinstalację Trainza, ale tej już nie zrobię, bo uważam, że to nie ma dla mnie sensu.

Chciałem jeszcze TS2010 zachować jako bazę zasobów do sprawdzania rzeczy, poszukiwania błędów, a nawet może jako formę programu "retro". W końcu Lublin - Dorohusk w oryginalnym wydaniu, czyli z drzewami SpeedTree, można tylko i wyłącznie w TS2010 odpalić. W T:ANE te biblioteki szybkich drzewek oczywiście nie są obsługiwane, więc trzeba by całą mapę przebudować pod jakieś inne. Ja w to nie wnikam, swój eksperyment uważam za zakończony, a T:ANE od tej pory mnie w pełni zadowala, bo znowu... dzięki RBachowi dałem się przekonać do nowszej wersji, a także rozwiązał trochę moich problemów i wątpliwości co do niej. Z dodatkami na czele :)

Dzięki Radku! Uważam, że ten temat to pokłosie naszych rozmów. Myślę, że warto to tutaj zostawić. Chciałbym, żeby ta wiedza mogła gdzieś funkcjonować, mogła też czemuś się przysłużyć, nawet jeśli TS2010 będzie już kompletnie martwą grą, to może wrócić jeszcze kiedyś właśnie jako ta "retro-gra" do obsługi tych wszystkich map... albo do pomocy do postawienia tych map na nowo w wyższych wersjach Trainza ;) Nie ukrywam, że Polskie Koleje Wąskotorowe czy Polskiej Koleje Piaskowe po pobraniu cdp-a z PTT nie uruchomią się w T:ANE, a przynajmniej u mnie nie uruchomiły się, więc trzeba było te pliki mapy przerobić w TS2010 poprzez dowolną edycję mapy, zapisać ją, a potem przenieść do T:ANE, aby to ruszyło.

Cytat:

Podsumowanie: - TS2010 po naprawie odpowiedniej ilości dodatków jest tak samo wydajny w trybie kompatybilnym jak i natywnym (efekt zaobserwowałem u siebie, screenshooty nie oddadzą tego w pełni, ale pokazują, że zmienia się zasięg rysowania, co jest oczywistym dowodem na to, że problemem były dodatki) - TS2010 może być wydajny, chociaż oczywiście nie tak jak nowsze, współczesne wersje Trainza - Dodatki bez nowych configów z wpisami mesh-table zamulają starego TS2010

Proszę też bez pisania złośliwości. Poświęciłem na trochę czasu mając nadzieję na to, że Trainz 2010 ma w sobie jeszcze trochę soków, a finalnie okazało się, że coś zaszwankowało. Nie wiem co spowodowało te nagłe problemy TS2010, ale tego nie będę też już rozwiązywać, bo finalnie TS2010 odchodzi do lamusa. Nawet gdyby ten problem nie wystąpił, i tak bym się przesiadł do T:ANE, bo pod koniec mojej przygody z TS2010, baza dodatków w T:ANE była już u mnie gotowa i poprawiona.

[ryszard]

Ciekawe wnioski, myślę że dla niektórych będą przydatne. Sporo osób jeszcze działa na TS 2010 i weźmie Twoje przemyślenia pod uwagę.

[Pm37]

Jeśli zajdzie potrzeba, to też służę swoją radą i wiedzą.

Ja i tak jestem zwolennikiem poprawy dodatków, chociaż w T:ANE nie ma z tego tytułu większych korzyści, bo ten Trainz działa kompletnie inaczej od tych starych, więc nawet najstarszy australijski dodatek mapy nie zamuli tak jak to zrobi w TS2010.

Problemem też pozostają stare funkcje, które configi z buildem 2.9 nie obsługują (w dużej mierze to są najczęściej dodatki typu spline).

Na pewno funkcja "grounded" jest szczególnie problematyczna, ponieważ nie znalazłem jej sensownego odpowiednika w nowych wpisach, a było to mi potrzebne do na przykład poprawienia dróg Voytasa (mapa PKW). Jedno jest pewne - polskie mapy korzystają z ok. 16,5 tysiąca dodatków. Oczywiście nie mam wszystkich map, liczba najpewniej jest jeszcze większa, ale i tak ogarnięcie podstawowej większości gwarantuje poprawę wydajności. Pytanie ile tego trzeba realnie przerobić, żeby mieć największą możliwą wydajność ;)

[Railwoj]

Dzięki za podzielenie się pomysłem na naprawę drzew Jankvisa i Denloga. Ja napotkałem na problem z nimi na Ziemi Świętokrzyskiej pod TANE, gdzie tym drzewkom gra dodawała jakby "kartonową kopertę", ponieważ taki rezultat dawała interpretacja pliku kanału alfy. Nietrudno się domyślić, ze to fatalnie wygląda i psuje jakikolwiek smak jazdy po takiej mapie. Przyznaję jednak, że nie miałem cierpliwości, aby wejść tak głęboko, jak Ty w szukanie przyczyny problemu, tylko hurtem wymieniłem te "kartonowe" na roślinność Bogdana. Ale ostatnio na innej części Ziemi Świętokrzyskiej odkryłem jeszcze obszary, gdzie te drzewa się nie wymieniły. Dzięki Twojemu pomysłowi spróbuję je naprawić.