Benchmark w Euro Truck Simulator 2: jak przygotować trasę testową

benchmark ETS2, trasa testowa ETS2, frametime Euro Truck Simulator 2, pomiar FPS ETS2, obciążenie CPU GPU ETS2, powtarzalny test wydajności, ustawienia benchmarku ETS2, save do testów ETS2, stutter w ETS2, test modów ETS2, metodologia benchmarku gry, monitorowanie wydajności symulatora

Zanim ruszysz: jaki błąd najczęściej psuje benchmark w ETS2

Największy problem to nie licznik FPS, tylko brak kontroli warunków

Źle przygotowany benchmark w Euro Truck Simulator 2 bardzo często wygląda wiarygodnie tylko na pierwszy rzut oka. Dwa przejazdy wydają się podobne, ale w praktyce różnią się ruchem AI, pozycją startową, kamerą, porą dnia albo tym, że za jednym razem trafiasz na korek przy skrzyżowaniu, a za drugim przejeżdżasz płynnie. Efekt jest prosty: wynik niby porównujesz, ale tak naprawdę testujesz inne sytuacje, a nie tę samą konfigurację sprzętu czy ustawień.

To właśnie dlatego przygotowanie trasy testowej ETS2 zaczyna się nie od uruchomienia narzędzia do pomiaru FPS, ale od ograniczenia losowości. Im mniej zmiennych między próbami, tym szybciej da się wychwycić realną różnicę. Jeśli po zmianie jednego suwaka gra pokazuje wynik wyższy o kilka klatek, ale podczas drugiego przejazdu miała mniej pojazdów na rondzie albo krótszy postój na światłach, taki „zysk” może być tylko przypadkiem.

W praktyce domowy benchmark ETS2 wygrywa nie wtedy, gdy jest skomplikowany, ale wtedy, gdy da się go odtworzyć po tygodniu, po aktualizacji gry albo po zmianie sterownika. To daje realną wartość. Od tego zacznij.

Średni FPS nie obroni słabego testu

Średni FPS jest wygodny, bo łatwo go zapisać i porównać. Problem w tym, że w ETS2 sama średnia często ukrywa to, co najbardziej wpływa na odczucie płynności. Dwa przejazdy mogą zakończyć się prawie identycznym wynikiem, a jeden z nich będzie wyraźnie bardziej szarpany przez skoki frametime przy wjeździe do miasta, obciążonych skrzyżowaniach albo w miejscach z większą liczbą obiektów.

Jeśli benchmark ma służyć do sensownego porównania ustawień, modów albo sprzętu, trzeba patrzeć nie tylko na średnią, ale też na przebieg płynności podczas całego przejazdu. To szczególnie ważne w symulatorze, gdzie zacięcie na 1–2 sekundy przy gęstszym ruchu jest znacznie bardziej odczuwalne niż spadek średniej o kilka FPS na prostym odcinku autostrady.

Krótko: dobry benchmark ETS2 ma być powtarzalny i czytelny, a nie tylko „ładny” w arkuszu z wynikami. Dzięki temu wychwycisz prawdziwe problemy, a nie przypadkowe odchylenia.

Najpierw cel testu, dopiero potem przejazd

Trasa testowa do benchmarku nie jest celem samym w sobie. Ma odpowiadać na konkretne pytanie. Chcesz porównać ustawienia grafiki? Sprawdzasz wpływ modów? Oceniasz, co zmieniła aktualizacja ETS2 lub sterownika? A może po wymianie karty graficznej próbujesz rozdzielić ograniczenia CPU i GPU? Każdy z tych scenariuszy wymaga tej samej dyscypliny metodologicznej, ale nie zawsze identycznego obciążenia.

Do własnej diagnostyki można przyjąć prostszy model: jedna trasa, kilka prób, ten sam save, notatka z ustawień i obserwacja frametime. Jeśli jednak wynik ma trafić na forum, blog albo kanał, benchmark powinien być bardziej rygorystyczny. Trzeba dokładnie opisać warunki, wersję gry, aktywne mody, ustawienia ruchu i sposób przejazdu. Wtedy ktoś inny ma szansę odtworzyć test i dojść do podobnych wniosków.

Najpierw zamroź warunki, dopiero potem licz klatki. To jedna decyzja, która oszczędza mnóstwo niepotrzebnych powtórek.

Krok 1. Ustal cel testu i zdecyduj, czy wystarczy jedna trasa

Cztery najczęstsze zastosowania domowego benchmarku

Najprostsze i najczęstsze zastosowanie to porównanie ustawień graficznych. W takim scenariuszu nie zmieniasz niczego poza tym, co faktycznie chcesz sprawdzić: preset, skalę renderowania, jakość cieni, zasięg rysowania, ustawienia lusterek, SSAO, filtrowanie czy antyaliasing. Cała reszta musi zostać identyczna, bo inaczej trudno ustalić, która opcja naprawdę wpłynęła na wydajność.

Drugi popularny przypadek to test po aktualizacji gry albo sterownika. Tu bardzo łatwo się pomylić, bo po patchu użytkownik zwykle ma wrażenie, że „jest lepiej” albo „jest gorzej”, ale bez tej samej trasy testowej ETS2 takie odczucie bywa złudne. Jedna poprawka może zmienić zarządzanie cieniem lub zasięg obiektów, a inna po prostu przypadkowo wypada w mniej zatłoczonym przejeździe. Stały save i stały scenariusz robią ogromną różnicę.

Trzeci scenariusz to test modów ETS2. To ważne, bo mody potrafią zmienić nie tylko wygląd, ale też obciążenie CPU i GPU. Dodatkowe mapy, pakiety ruchu, nowe rośliny, oświetlenie, tekstury czy gęstsza zabudowa mogą wpływać na wydajność zupełnie inaczej niż zwykła zmiana ustawień graficznych. W takim teście trzeba zapisać nie tylko listę modów, ale też ich kolejność ładowania, bo ona również może zmieniać wynik końcowy.

Czwarty przypadek to zmiana sprzętu. Jeśli porównujesz dwa procesory, dwie karty graficzne albo np. stary i nowy zestaw pamięci, jedna trasa może nie wystarczyć. Wtedy przydają się dwa scenariusze: jeden bardziej CPU-heavy, drugi bardziej GPU-heavy. Dzięki temu od razu zobaczysz, czy wzrost wydajności pojawia się głównie w mieście i przy ruchu AI, czy raczej na otwartych odcinkach z cięższą grafiką.

Im precyzyjniej określisz cel, tym mniej czasu stracisz na późniejsze poprawki metodologii. To dobry moment, żeby zapisać sobie jedno zdanie: co dokładnie porównuję i czego nie zmieniam.

Kiedy jedna trasa wystarczy, a kiedy trzeba zrobić dwa benchmarki

Jedna trasa testowa ETS2 wystarczy wtedy, gdy benchmark ma służyć głównie tobie i ma dawać regularny punkt odniesienia. Na przykład sprawdzasz co jakiś czas wpływ skali renderowania, cieni i ustawień lusterek na tym samym komputerze. W takim zastosowaniu ważniejsza jest stałość procedury niż rozbudowany, wielowariantowy plan.

Dwa benchmarki mają sens, gdy chcesz rozdzielić ograniczenia CPU i GPU albo publikować wyniki dla innych. ETS2 potrafi reagować bardzo różnie zależnie od miejsca na mapie i rodzaju obciążenia. Gęste miasto z wieloma pojazdami AI, światłami i skrzyżowaniami częściej obnaża ograniczenia procesora. Z kolei otwarta droga z dalszym widokiem, roślinnością i wyższą skalą renderowania częściej mocniej dociąża kartę graficzną.

W praktyce scenariusz CPU-heavy powinien zawierać wjazd do miasta, skrzyżowania, sygnalizację świetlną, większą liczbę obiektów przy drodze i potencjalne miejsca, gdzie silnik gry musi obsłużyć więcej zdarzeń jednocześnie. Nie chodzi o skrajny chaos, tylko o odcinek, który regularnie pokazuje, czy procesor nadąża.

Scenariusz GPU-heavy lepiej zbudować na bardziej otwartym terenie: dłuższy widok, roślinność, cienie, elementy krajobrazu i wyższe ustawienia obrazu. Jeśli testujesz wpływ rozdzielczości, skali renderowania czy efektów graficznych, taki odcinek będzie znacznie bardziej użyteczny niż samo miasto.

Jeśli masz wątpliwości, zacznij od jednej sensownej trasy i dopiero po kilku próbach sprawdź, czy nie potrzebujesz drugiej. To prostsze i zwykle w zupełności wystarcza na start.

Krok 2. Zbuduj środowisko testowe, które da się odtworzyć

Co dokładnie trzeba zamrozić przed pomiarem

Podstawą powtarzalnego testu wydajności w ETS2 jest ten sam save. Nie „podobny”, nie „w tym samym mieście”, tylko ten sam zapis gry uruchamiany przed każdą próbą. Dzięki temu startujesz z identycznej pozycji, tym samym stanem świata i tym samym zestawem ustawień zapisanych w profilu. Jeśli benchmark zaczynasz po dłuższej normalnej rozgrywce, bardzo łatwo nieświadomie zmienić warunki.

Kolejny element to ta sama ciężarówka i ta sama konfiguracja pojazdu. Warto utrzymać identyczny silnik, skrzynię biegów, kabinę, dodatki i – jeśli test tego wymaga – tę samą naczepę albo konsekwentny brak naczepy. Masa zestawu wpływa na przyspieszenie, hamowanie i styl jazdy, a to z kolei może decydować, czy do konkretnego skrzyżowania dojedziesz na zielonym, czy zatrzymasz się na czerwonym. Mała zmiana mechanicznie przechodzi więc w dużą różnicę pomiarową.

Bardzo często ignorowanym elementem jest kamera. Widok z kabiny, kamera zewnętrzna i bardziej oddalone ujęcia mogą generować inne obciążenie, bo pokazują różny zakres obiektów i wnętrza pojazdu. Jeśli w jednym przejeździe jedziesz z kokpitu, a w drugim przełączasz się na zewnętrzny widok „dla wygody”, benchmark traci sens porównawczy. Wybierz jedną kamerę i trzymaj ją od startu do końca.

Trzeba też ustalić porę dnia i pogodę. Oświetlenie, cienie, odbicia i opady mają znaczenie dla wydajności, a dynamiczna pogoda potrafi skutecznie zepsuć nawet dobrze zaplanowaną trasę. Najbezpieczniej testować przy stałych warunkach, bez zmian deszczu i bez przechodzenia z jasnego dnia do zmierzchu w trakcie przejazdu. To daje czystszy sygnał.

Do tej listy dochodzą jeszcze ustawienia ruchu AI i zdarzeń drogowych. Jeśli korzystasz z modów zmieniających ruch, zachowanie pojazdów albo gęstość świata, od razu to zanotuj. W benchmarku to nie detal, tylko jedna z głównych zmiennych.

Przygotowanie systemu i gry przed startem

Nawet idealna trasa testowa ETS2 nie uratuje pomiaru, jeśli system pracuje w tle jak podczas zwykłego dnia pracy. Aktualizacja przeglądarki, synchronizacja chmury, antywirus skanujący katalog, launcher pobierający pliki, komunikator z aktywną nakładką albo nagrywanie pulpitu mogą powodować skoki użycia CPU, dysku i pamięci. Efektem są losowe piki frametime, które wyglądają jak problem gry, choć ich źródło leży poza ETS2.

Przed uruchomieniem testu zamknij wszystko, co nie jest potrzebne. Jeśli korzystasz z narzędzia do monitorowania wydajności, zostaw tylko je i ewentualnie jedno lekkie narzędzie do logowania. To szczególnie ważne po zmianie sterownika lub moda, bo wtedy najłatwiej niesłusznie obwinić trasę testową za niestabilny wynik.

Druga sprawa to elementy zakłócające przebieg samej gry. Autosave uruchomiony w newralgicznym momencie może wywołać chwilowe przycięcie, które nie ma nic wspólnego z „normalną” wydajnością przejazdu. Podobnie działają niektóre overlaye, nagrywanie w tle i rozmaite komunikaty systemowe. Jeśli benchmark ma być czysty, ogranicz takie rzeczy do minimum albo przynajmniej konsekwentnie używaj ich we wszystkich próbach.

Ustal też z góry limiter FPS, V-Sync oraz tryb pełnoekranowy lub okienkowy. Te opcje muszą być identyczne między przejazdami. Jeśli raz testujesz z aktywnym limitem 60 FPS, a raz bez limitu, nie porównujesz już tych samych warunków. To samo dotyczy synchronizacji pionowej, która może wpływać nie tylko na maksymalny wynik, ale też na przebieg frametime.

Im mniej zmiennych w tle, tym szybciej dojdziesz do prawdziwej przyczyny spadków. Ta część przygotowań nie jest widowiskowa, ale daje najwięcej porządku.

Krótka checklista przed uruchomieniem benchmarku

• Ten sam save uruchamiany przed każdą próbą.
• Ta sama ciężarówka, konfiguracja i naczepa albo świadomy brak naczepy.
• Ta sama kamera przez cały przejazd.
• Ta sama pora dnia i pogoda, bez dynamicznych zmian.
• Te same ustawienia ruchu AI i tych samych modów.
• Wyłączone zbędne procesy w tle, aktualizacje i niepotrzebne nakładki.
• Stały limiter FPS, V-Sync i tryb ekranu.
• Wyłączone lub uwzględnione autosave w tej samej formie dla każdej próby.

Ta lista wygląda prosto, ale właśnie dzięki niej benchmark przestaje być jednorazową zabawą i zaczyna mieć wartość porównawczą. Zapisz ją obok wyników i wracaj do niej przed każdym testem.

Krok 3. Wybierz trasę, która naprawdę testuje grę, a nie przypadek

Kryteria dobrej trasy benchmarkowej

Dobra trasa testowa ETS2 musi być przede wszystkim powtarzalna. To oznacza łatwy do odtworzenia punkt startu i końca oraz taki przebieg, który nie zależy całkowicie od kaprysu ruchu AI. Odcinek pełen skrzyżowań z długimi światłami może być wymagający, ale jeśli raz stoisz tam 20 sekund, a raz przejeżdżasz bez zatrzymania, porównanie przestaje być czyste. Lepiej wybrać miejsce, które jest obciążające, ale nie skrajnie nieprzewidywalne.

Drugie kryterium to reprezentatywność. Benchmark nie powinien składać się wyłącznie z jednego rodzaju sceny. Samo miasto pokaże część problemów, ale nie odda zachowania gry na otwartej trasie. Sama autostrada da ładny wykres średniego FPS, ale może ukryć stutter przy bardziej złożonych miejscach. Sensowny odcinek powinien zawierać przynajmniej kilka typów obciążenia: fragment miejski, odcinek otwarty i miejsce z wyraźnie większą liczbą obiektów lub świateł.

Trzecia rzecz to długość. Zbyt krótka trasa bywa zdradliwa, bo jeden przypadkowy korek, jeden autosave albo jeden nieudany wjazd na rondo potrafią wywrócić cały wynik. Z kolei bardzo długi przejazd utrudnia powtarzalność i zabiera czas przy każdej zmianie ustawień. Najpraktyczniej sprawdza się odcinek, który da się przejechać kilka razy pod rząd bez zmęczenia, a jednocześnie obejmuje przynajmniej jeden moment „cięższy” dla silnika. Jeśli po dwóch próbach widzisz, że połowa wyniku zależy od jednego światła, szukaj lepszej trasy. To oszczędza masę nerwów.

Dobrze działa też prosty test zdrowego rozsądku: uruchom ten sam odcinek trzy razy bez żadnych zmian ustawień i zobacz, czy wyniki są do siebie zbliżone. Jeśli rozjazd jest duży, problemem nie musi być sprzęt, tylko sama trasa albo warunki wokół niej. Czasem wystarczy przesunąć punkt startu o kilkaset metrów, ominąć szczególnie losowe skrzyżowanie albo skrócić fragment z gęstym ruchem AI. Taka korekta robi większą różnicę niż kolejne kombinowanie suwakiem grafiki, więc sprawdź to od razu.

W praktyce najwygodniej przygotować sobie dwie wersje odcinka: jedną „codzienną” do szybkich porównań po zmianie sterownika czy ustawień i drugą, trochę bardziej wymagającą, do sprawdzania frametime oraz zachowania gry w trudniejszych miejscach. Nie muszą być długie ani efektowne. Mają być użyteczne, czyli możliwe do odtworzenia bez zgadywania, co poszło inaczej niż poprzednio. Z taką bazą od razu łatwiej wychwycić, czy zysk jest prawdziwy, czy tylko wypadł z łaskawego układu świateł. Ustal trasę raz porządnie, a potem trzymaj się jej konsekwentnie.

Najczęstsza wpadka pojawia się na samym końcu: ktoś zmienia trasę albo styl jazdy między próbami, bo „przecież to prawie to samo”. W benchmarku właśnie takie „prawie” psuje cały sens porównania, więc gdy już zbudujesz sensowny przejazd, nie poprawiaj go co test — poprawiaj tylko ustawienia, które naprawdę chcesz zmierzyć.

Jak złożyć trasę z odcinków, które pokazują różne obciążenie

Najwygodniejsza trasa testowa nie jest „ładna”, tylko użyteczna. Dobrze, gdy składa się z 3–4 krótkich segmentów, z których każdy obciąża grę trochę inaczej. Dzięki temu po jednym przejeździe widzisz nie tylko średni FPS, ale też gdzie ETS2 traci płynność. To od razu przybliża odpowiedź, czy ogranicza cię głównie CPU, GPU czy po prostu źle dobrany scenariusz.

Praktyczny układ wygląda tak:

• start w mieście lub przy większym węźle – dużo obiektów, ruch AI, sygnalizacja, budynki i krótsze dystanse widzenia,
• przejście przez przedmieścia – mieszane obciążenie, sporo znaków, roślinności i zmieniającej się geometrii sceny,
• otwarta droga albo autostrada – daleki widok, większa prędkość, stabilniejszy rytm jazdy,
• jeden punkt cięższy – rondo, zjazd, tunel, bramki, gęstsza zabudowa albo miejsce z większą liczbą źródeł światła.

Taka kompozycja jest lepsza niż samo „kółko po mieście”, bo nie zamyka testu w jednym typie obciążenia. Jeśli po zmianie ustawień wzrost pojawia się tylko na autostradzie, a w mieście nie, masz już bardzo cenną wskazówkę. Zbuduj trasę tak, by każdy segment miał sens diagnostyczny.

Kiedy jedna trasa nie wystarcza

Jedna trasa wystarczy do codziennych porównań tylko wtedy, gdy daje zbliżone wyniki przy kolejnych przejazdach i obejmuje sceny, które rzeczywiście sprawiają problem. Jeśli po zmianie sprzętu albo ustawień widzisz, że w jednym miejscu gra przyspiesza mocno, a w drugim prawie wcale, lepiej rozdzielić benchmark na dwa scenariusze.

Najpraktyczniejszy podział to:

• scenariusz CPU-heavy – więcej miasta, ruchu AI, skrzyżowań, obiektów i częstych zmian sytuacji na drodze,
• scenariusz GPU-heavy – bardziej otwarty teren, daleki widok, roślinność, cienie, odbicia i miejsca, gdzie karta graficzna ma co renderować.

To szczególnie pomaga po zmianie rozdzielczości, skali renderowania albo po instalacji modów graficznych. Jeżeli wzrost wydajności pojawia się tylko w scenariuszu GPU-heavy, a miejski przejazd prawie stoi w miejscu, nie ma sensu szukać winy w teksturach czy filtracji. Wtedy test mówi wprost: problem siedzi gdzie indziej. Rozdzielenie tras daje czystszy obraz niż jedna „uniwersalna” pętla, która wszystko miesza.

Krok 4. Ustal zasady przejazdu, żeby każda próba wyglądała tak samo

Stały styl jazdy jest częścią metodologii

W ETS2 benchmark nie kończy się na wyborze drogi. Ten sam odcinek można przejechać w sposób, który da dwa różne wyniki. Mocniejsze przyspieszanie, późniejsze hamowanie, inna prędkość na zjeździe albo zmiana toru jazdy potrafią przesunąć moment doczytywania obiektów, wejścia w cień czy spotkania z ruchem AI. To nie brzmi groźnie, ale przy porównywaniu małych różnic robi się ważne.

Dlatego trzymaj się prostych reguł:

• ruszaj w ten sam sposób i nie „ratuj” wyniku agresywną jazdą,
• utrzymuj podobną prędkość przelotową na tych samych odcinkach,
• nie zmieniaj kamery w trakcie testu,
• nie rób objazdów, nie ścinaj zakrętów i nie cofaj po pomyłce,
• jeśli wydarzy się kolizja albo nietypowy korek, anuluj próbę i uruchom save ponownie.

To nie jest przesada. Dwie sekundy postoju pod światłami albo wymuszone hamowanie przez AI mogą dać wykres, który wygląda jak problem z frametime. A to po prostu zły przejazd. Trzymaj rygor, a szybciej odróżnisz prawdziwy spadek wydajności od bałaganu na trasie.

Ile powinien trwać jeden przejazd

Dobry benchmark powinien być na tyle długi, by złapać normalne zachowanie gry, ale na tyle krótki, by dało się go łatwo powtórzyć kilka razy. W praktyce najlepiej sprawdza się przejazd, który trwa kilka minut i zawiera przynajmniej jeden wyraźnie cięższy fragment. To zwykle wystarcza, żeby zobaczyć średni FPS, wykres frametime i ewentualne stuttery bez męczenia się dziesięcioma kilometrami powtarzalnej jazdy.

Jeśli odcinek kończy się po chwili i cały wynik zależy od jednego skrzyżowania, jest zbyt krótki. Jeśli po każdej zmianie cieni, modów albo sterownika musisz poświęcać długi czas na komplet prób, jest zbyt długi. Szukaj środka: odcinka, który da się przejechać trzy razy pod rząd bez rozbijania sesji testowej na pół dnia. Taką trasę naprawdę będziesz używać, a to jest klucz.

Krok 5. Mierz przejazd, a nie pojedynczy kadr

Jak logować FPS, frametime i obciążenie CPU/GPU

Statyczny postój na poboczu niewiele mówi o ETS2. Gra zmienia obciążenie podczas jazdy, doczytywania terenu, mijania AI i wjazdu do gęstszych obszarów. Dlatego pomiar powinien obejmować cały ustalony przejazd, od wyraźnego punktu startowego do wyraźnego punktu końcowego.

Do pomiaru użyj jednego, stałego zestawu narzędzi do wyświetlania i logowania danych. Nie chodzi o konkretną markę programu, tylko o konsekwencję. Między próbami nie zmieniaj sposobu odczytu, częstotliwości logowania ani zestawu monitorowanych parametrów, bo sam pomiar zacznie się różnić od pomiaru.

Najpraktyczniej zapisywać:

• średni FPS,
• frametime i piki frametime,
• 1% low lub zbliżony wskaźnik pokazujący gorsze momenty płynności,
• użycie GPU,
• użycie CPU oraz, jeśli to możliwe, zachowanie głównych wątków,
• temperatury i taktowania, jeśli sprawdzasz wpływ sprzętu albo throttlingu.

To daje dużo lepszy obraz niż samo „średnio wyszło tyle FPS”. Czasem średnia wygląda dobrze, a frametime pokazuje regularne szarpnięcia przy każdym wjeździe do miasta. I właśnie tam benchmark zaczyna być użyteczny. Ustaw logowanie raz porządnie i potem nie zmieniaj metod w połowie porównań.

Punkt startu i końca pomiaru

Pomiar musi zaczynać się i kończyć w tym samym miejscu. Najprościej wybrać wyraźne punkty orientacyjne: ruszenie spod konkretnego znaku, minięcie bramy firmy, wyjazd spod stacji, przejazd pod wiaduktem albo zakończenie przy określonym zjeździe. To ogranicza sytuację, w której raz liczysz jeszcze moment po załadowaniu świata, a innym razem już nie.

Dobra praktyka jest prosta: po wczytaniu save odczekaj chwilę, aż gra się uspokoi, ustaw kamerę, przygotuj logowanie i dopiero wtedy rozpocznij przejazd. Na końcu zatrzymaj zapis dokładnie przy tym samym punkcie. Taki drobiazg robi sporą różnicę, bo odcina losowe sekundy „przed” i „po”, które potrafią rozmywać wynik.

Krok 6. Oceń, czy wynik jest wiarygodny

Nie patrz tylko na średni FPS

Średni FPS jest użyteczny, ale sam w sobie bywa mylący. Dwa przejazdy mogą mieć podobną średnią, a zupełnie inne odczucie płynności. Jeden będzie równy, drugi poszarpany. W ETS2 zwykle szybciej poczujesz problem na wykresie frametime niż na samej średniej.

Przy ocenie wyniku sprawdzaj trzy rzeczy jednocześnie:

• czy średni FPS jest zbliżony między próbami,
• czy frametime ma podobny przebieg, bez pojedynczych, przypadkowych pików z zewnętrznej przyczyny,
• czy najgorsze momenty pojawiają się w tych samych miejscach trasy.

Jeśli dwa przejazdy różnią się minimalnie, ale oba mają podobny kształt wykresu i przycięcia w tych samych punktach, benchmark jest najpewniej zdrowy. Jeśli jeden przejazd ma nagły, samotny skok frametime w miejscu, gdzie zwykle nic się nie dzieje, najpierw podejrzewaj zakłócenie z tła albo nietypowe zachowanie AI, a nie wielki problem z grą.

Ile prób zrobić, zanim porównasz ustawienia

Jedna próba to za mało, jeśli chcesz mówić o porównaniu z przekonaniem. Sensowne minimum to kilka przejazdów dla tego samego scenariusza i odrzucenie wyniku ewidentnie zepsutego przez korek, kolizję, autosave albo inny losowy incydent. Nie chodzi o bicie rekordów w liczbie testów, tylko o złapanie powtarzalności.

Dobry sygnał jest wtedy, gdy kolejne próby bez żadnych zmian trzymają się blisko siebie. Jeśli rozjazd jest wyraźny, nie przechodź od razu do testowania nowych ustawień. Najpierw popraw samą metodę: skróć trasę, zmień bardziej losowy fragment albo wyłącz element, który zaburza wynik. To oszczędza czas i eliminuje fałszywe wnioski.

Lista kontrolna: przed, w trakcie i po przejeździe

Przed startem

• Wczytaj ten sam save i ten sam profil gry.
• Sprawdź ciężarówkę, naczepę i kamerę.
• Potwierdź porę dnia, pogodę i ustawienia ruchu AI.
• Zamknij zbędne procesy w tle i upewnij się, że nie startuje aktualizacja.
• Włącz to samo narzędzie do logowania z tymi samymi parametrami.
• Sprawdź limiter FPS, V-Sync, skalę renderowania i tryb ekranu.
• Ustal punkt startu i końca pomiaru zanim ruszysz.

W trakcie przejazdu

• Jedź tą samą trasą, bez improwizacji.
• Utrzymuj podobny styl jazdy i zbliżoną prędkość tam, gdzie to możliwe.
• Nie zmieniaj kamery ani ustawień gry.
• Przerwij próbę, jeśli pojawi się nietypowa kolizja, korek albo oczywiste zakłócenie z systemu.
• Zakończ logowanie dokładnie w wybranym punkcie końcowym.

Po zakończeniu

• Zapisz nazwę trasy i wersję gry.
• Zanotuj ustawienia grafiki, mody, sterownik i rozdzielczość.
• Oznacz próbę jako poprawną albo odrzuconą.
• Sprawdź wykres frametime, a nie tylko średni FPS.
• Porównuj tylko przejazdy wykonane tą samą metodą.

Najczęstsze błędy, które psują benchmark mimo dobrej trasy

Zmiana więcej niż jednej rzeczy naraz

To najprostszy sposób, by stracić kontrolę nad wynikiem. Nowy sterownik, inna skala renderowania, dołożone mody, zmieniony limiter FPS i jeszcze inna trasa w tym samym dniu — wtedy nie da się uczciwie powiedzieć, co faktycznie wpłynęło na wydajność. Jeśli chcesz dostać odpowiedź, zmieniaj jedną zmienną na raz.

Test na trasie, która wygląda „ciężko”, ale jest za bardzo losowa

Rondo z dużym ruchem, kilka świateł i zdarzenia drogowe mogą wydawać się świetnym benchmarkiem, bo „dużo się dzieje”. Problem w tym, że wtedy benchmark mierzy często przypadek, a nie wydajność. Jeśli raz stoisz dłużej przez AI, a raz jedziesz płynnie, różnica nie wynika z ustawień tylko z ruchu. Taki odcinek trzeba uprościć albo rozbić na dwa testy.

Brak notatek po teście

Za miesiąc łatwo zapomnieć, czy test był robiony z modami, po aktualizacji gry, z V-Sync czy bez, na której wersji sterownika i jaką kamerą. Wtedy nawet dobry wynik przestaje być przydatny. Minimum to krótki zapis: data, wersja gry, trasa, ustawienia, mody, sterownik, liczba prób i które wyniki zostały odrzucone. To zajmuje chwilę, a potem ratuje cały sens benchmarku.

Najbardziej zdradliwy błąd jest prosty: trasa zostaje ta sama, ale po drodze zmienia się drobiazg, który „nie powinien mieć znaczenia”. W ETS2 właśnie takie drobiazgi zwykle mają znaczenie, więc jeśli chcesz porównania, pilnuj metody równie mocno jak ustawień.

Najczęściej zadawane pytania (FAQ)

Jak zrobić powtarzalny benchmark w ETS2?

Najpierw trzeba ograniczyć losowość, bo to ona najczęściej psuje wynik. Podstawą jest ten sam save uruchamiany przed każdą próbą, identyczna pozycja startowa, ta sama kamera, podobna pora dnia i brak zmian w ustawieniach poza jedną testowaną opcją. Dzięki temu porównujesz sprzęt albo suwak graficzny, a nie przypadkowo inny przejazd.

Dobrze działa prosty schemat: ten sam zapis gry, ta sama trasa, kilka przejazdów i notatka z warunków testu. Jeśli raz ruszasz z miasta przy dużym ruchu, a drugi raz z tego samego miejsca po innym zapisie gry, wyniki mogą się rozjechać mimo braku zmian w konfiguracji. Ustal procedurę i trzymaj się jej bez wyjątków.

Czy średni FPS wystarczy do testu wydajności Euro Truck Simulator 2?

Nie, bo w ETS2 średni FPS bardzo łatwo maskuje chwilowe przycięcia. Dwa przejazdy mogą mieć podobną średnią, a jeden będzie wyraźnie mniej płynny przez skoki frametime przy wjeździe do miasta, na skrzyżowaniach albo w gęstszym ruchu AI. To właśnie te momenty najbardziej czuć za kierownicą.

Jeśli chcesz ocenić płynność sensownie, sprawdzaj nie tylko średnią liczbę klatek, ale też frametime i przebieg wydajności podczas całej trasy. Krótkie zacięcie przy światłach bywa ważniejsze niż kilka FPS różnicy na pustej autostradzie. To szybciej pokaże prawdziwy problem.

Jaką trasę testową wybrać do benchmarku ETS2?

Trasa powinna odpowiadać na konkretne pytanie. Jeśli sprawdzasz ustawienia graficzne, przyda się odcinek z miejscami, które faktycznie obciążają kartę lub procesor: fragment miasta, skrzyżowanie, trochę ruchu AI i kawałek bardziej otwartej drogi. Chodzi o scenariusz, który da się łatwo odtworzyć po tygodniu czy po aktualizacji sterownika.

Do użytku domowego często wystarcza jedna sensowna trasa. Gdy chcesz rozdzielić ograniczenia CPU i GPU, lepiej przygotować dwa benchmarki:

• CPU-heavy: miasto, światła, skrzyżowania, więcej obiektów i ruchu AI,
• GPU-heavy: otwarty teren, dalszy widok, roślinność, cienie, wyższa skala renderowania.

Nie szukaj „idealnej” trasy godzinami. Zbuduj jedną dobrą i sprawdź, czy daje stabilne wyniki.

Co trzeba ustawić przed pomiarem FPS w ETS2?

Najważniejsze jest zamrożenie warunków testu. Ten sam save to podstawa, ale dobrze dopilnować też ciężarówki, konfiguracji pojazdu, kamery i zestawu aktywnych modów. Jeśli raz testujesz z inną kolejnością ładowania modów albo innym profilem ustawień, porównanie zaczyna tracić sens.

W praktyce przed startem pomiaru dobrze sprawdzić:

• wersję gry i sterownika,
• listę modów oraz ich kolejność,
• ustawienia grafiki, szczególnie skalę renderowania, cienie i lusterka,
• to samo miejsce startowe i ten sam sposób przejazdu.

Taki krótki „checklist” oszczędza sporo nerwów, zwłaszcza gdy porównujesz wyniki po kilku dniach.

Jak testować mody w ETS2, żeby wynik miał sens?

Najlepiej zmieniać tylko jeden element naraz. Jeśli wrzucisz jednocześnie mapę, pakiet ruchu, tekstury i mod oświetlenia, nie ustalisz, co naprawdę pogorszyło albo poprawiło wydajność. Dużo lepiej działa test bazowy bez zmian, a potem kolejne przejazdy z jednym konkretnym modem lub jedną paczką modów.

Przy modach szczególnie ważny jest zapis konfiguracji. Sama lista nie zawsze wystarcza, bo znaczenie ma też kolejność ładowania. Typowy przykład: po dołożeniu paczki roślin na otwartej trasie rośnie obciążenie GPU, a po modzie ruchu AI bardziej cierpi CPU i frametime w mieście. Rozdziel te scenariusze i od razu zobaczysz, co faktycznie obciąża grę.

Jak sprawdzić, czy ETS2 ogranicza CPU czy GPU?

Najprościej zrobić dwa różne scenariusze testowe i obserwować nie tylko FPS, ale też obciążenie podzespołów oraz frametime. Jeśli największe problemy pojawiają się głównie w mieście, przy światłach i większej liczbie pojazdów AI, częściej wychodzi ograniczenie po stronie procesora. Gdy spadki nasilają się po podniesieniu rozdzielczości, skali renderowania albo jakości cieni, zwykle mocniej pracuje karta graficzna.

Dobry znak ostrzegawczy to sytuacja, w której średni FPS wygląda podobnie, ale frametime robi się nierówny tylko w określonych miejscach. To często więcej mówi o realnej płynności niż sam licznik klatek. Zrób dwa krótkie testy zamiast jednego przypadkowego przejazdu.

Jaki jest najczęstszy błąd przy benchmarku ETS2?

Porównywanie przejazdów, które tylko wyglądają na podobne. Ten sam odcinek mapy nie wystarczy, jeśli zmienia się ruch AI, moment startu, kamera albo zapis gry. Wtedy łatwo uznać, że nowe ustawienie „dało wzrost”, choć w praktyce po prostu nie było korka na rondzie albo postój na światłach trwał krócej.

Drugi częsty błąd to patrzenie wyłącznie na średni FPS. Przez to da się przeoczyć stutter i skoki frametime, które w ETS2 są dużo bardziej odczuwalne niż mała różnica w średniej liczbie klatek. Jeśli chcesz wyciągnąć użyteczne wnioski, nie testuj „na oko” — właśnie tam najłatwiej o fałszywy wynik.

Źródła informacji

• Euro Truck Simulator 2. SCS Software (2012) – Oficjalna strona gry; podstawy o ETS2 i kontekście testów.
• PresentMon. Intel (2024) – Narzędzie do pomiaru frametime i FPS na Windows.
• CapFrameX Documentation. CapFrameX – Metodyka analizy frametime, percentyli i powtarzalności pomiarów.
• OCAT User Guide. AMD – Opis rejestrowania czasu renderowania i wydajności GPU.
• Frame Rating: Dissecting PC Gaming Performance. PC Perspective (2013) – Wyjaśnia, czemu sam średni FPS nie opisuje płynności.