Od ponad roku testowałem który format tekstur jest najlepszy dla wydajności OMSI 2. W ramach tego eksperymentu zmieniałem używane tekstury wszystkich obiektów scenerii na mapie (w niektórych przypadkach również splinów), a następnie robiłem próbne przejazdy (oczywiście tym samym autobusem). Mapy których używałem są bardzo wymagające, więc różnice były widoczne na pierwszy rzut oka. Udało mi się przetestować wszystkie powszechnie używane formaty (BMP, DDS, JPG, PNG, TGA) i chcę się podzielić swoimi spostrzeżeniami.

Zanim zaczniemy warto wspomnieć, że pod pojęciem wydajności rozumiem dwie rzeczy - ilość fpsów oraz ilość "freezów" wraz z ich długością. Są one od siebie niezależne, co może ułatwić dobór formatu.

Ilość klatek na sekundę zależy od tego, czy dana tekstura posiada wygenerowane mipmapy. Generowanie mipmap polega na tym, że tekstura zawiera pomniejszone wersje samej siebie. Dzięki temu możemy troszkę odciążyć silnik OMSI, który w trakcie gry musi ciągle skalować wszystkie tekstury w zależności od odległości z jakiej na nie patrzymy. Z formatów które wymieniłem, to tylko BMP i DDS obsługują mipmapy, ale w przypadku DDSów trzeba zaznaczyć odpowiednią opcję przy eksporcie.

Teraz przejdźmy do zacinania się gry. Wynikają one z wczytywania się tekstur, natomiast rozmawiamy o OMSI, więc rozwiązanie problemu nie jest oczywiste. Z moich doświadczeń wynika, że najlepiej w tej kwestii radzą sobie BMP i JPG, chociaż format JPG ma inny problem do którego przejdę za chwilę. Moja teoria jest taka, że wynika to z faktu, iż OMSI ma oznaczone te formaty jako nieobsługujące przezroczystości, a w przypadku każdego innego formatu OMSI od razu zakłada, że ten będzie miał w sobie przezroczystość, bez patrzenia np. czy istnieją wpisy [matl_alpha] i zaczyna go całego skanować. Ale wróćmy do wątku formatu JPG. Jest to format mocno skompresowany, więc mimo wszystko nie wczyta się on od razu. I tutaj mamy ciekawą sytuację - OMSI nie będzie czekać aż dekompresja się skończy, tylko pozwoli aby symulacja trwała dalej, a na potrzebny czas tekstura będzie biała. Nie może to jednak trwać wiecznie, więc jeżeli po 3-5 sekundach nadal tekstura będzie biała, to symulacja znowu się zatrzyma i będzie czekać aż do końca dekompresji. Tak więc używając formatu JPG będziemy spotykać białe tekstury (a gdy jedziemy szybko, to nie zdążą zniknąć, co źle wpływa na estetykę gry), a czasami i tak nie będziemy w stanie uniknąć laga.

Łącząc obie wypowiedzi nasuwa się wniosek, że do tekstur z przezroczystością najlepszy będzie DDS, a do zwykłych BMP. Niestety jest jeden problem o którym nie wspomniałem - waga tekstury. W tej kwestii najwięcej ma do powiedzenia twórca danego obiektu. W obu formatach liczy się tylko wielkość danej tekstury i nic więcej. Nie wydaje mi się, aby był sens upychać do OMSI tekstury w nie wiadomo jak dużej rozdzielczości, a są różne sposoby aby efektywnie wykorzystać już konieczną do zajęcia przestrzeń. Oczywiście, że znajdą się od tego wyjątki - chociażby malowanie autobusu. Gdyby spróbować przekonwertować malowanie SU18 do formatu BMP, to otrzymalibyśmy teksturę o skromnej wadze 17MB. Można próbować zmniejszyć format kolorów do 8 bit, wspomagać się ditheringiem i przełknąć fakt, że tekstura nie będzie najlepszej jakości. Można również pogodzić się z losem i użyć PNG aby jak najmocniej zmniejszyć wagę tekstury. Natomiast naprawdę zachęcam do podjęcia walki - fpsy mogą podskoczyć nawet dwukrotnie, a "freezy" gry można praktycznie całkowicie wyeliminować.

Jeżeli uważacie, że coś jest nieprawdą, o czymś nie wspomniałem, lub macie własną wiedze do dodania, to zachęcam aby się tym podzielić.