- 01Opisz, co wydaje się nieprawidłowe
- 02Ustal bazę odniesienia, którą możesz powtórzyć
- 03Najpierw zmień tylko ustawienie grafiki.
- 04Oceń limit klatek osobno.
Na podstawie podlinkowanych źródeł i oryginalnej analizy. Nie twierdzono, że testowano gry bezpośrednio.
Zlokalizowane z angielskiego wydania badawczego; w grze zachowano nazwy własne do wyszukiwania.
Zweryfikowany lider ds. grafiki
Niskie ustawienia graficzne są przydatnym pierwszym punktem porównania, gdy He Who Watches działa słabo. W dyskusji z 6 września deweloper Danga wskazał mgłę wolumetryczną jako prawdopodobną przyczynę dużych różnic obciążenia GPU między ustawieniami średnimi a niskimi. W osobnej odpowiedzi z 5 września deweloper stwierdził, że ustawienie Niskie wyłącza mgłę wolumetryczną. Te stwierdzenia wspierają testowanie tego presetu; nie oznaczają one jednak, że mgła powoduje każde przycięcie ani że Niskie gwarantuje płynną wydajność na każdym komputerze.
Raport o wydajności w hubie opisywał również nieregularną animację ruchu. Deweloper uznał, że jest ona gorsza od oczekiwanej i poprosił o opinie za pomocą menu pauzy, gdy problem występował. To pozostaje ważnym rozróżnieniem: prawdopodobne wytłumaczenie jednej różnicy w obciążeniu grafiki nie stanowi potwierdzonej diagnozy dla każdego objawu w tym samym raporcie.
Poniższy proces pracy to oryginalne ogólne rozwiązywanie problemów oparte na wąskiej wskazówce od dewelopera. Nie był on testowany na maszynie testowej do tego artykułu. Wykorzystaj go do czystego porównania na własnym sprzęcie, zachowaj wyniki i zdecyduj, czy masz użyteczne obejście problemu, czy też problem wymaga zgłoszenia.
Opisz, co wydaje się nieprawidłowe
Zacznij od widocznego objawu. Czy ruch jest konsekwentnie wolny, obraz zatrzymuje się w odstępach czasu, czy też wprowadzenie danych wydaje się pomijać część swojej animacji? Czy problem występuje podczas stania w miejscu, obracania się lub poruszania po hubie? Te spostrzeżenia są bardziej przydatne niż jedno stwierdzenie, że wydajność jest zła.
Jeżeli masz już dostępny wskaźnik liczby klatek na sekundę, nagraj obserwowane wartości, ale nie pozwól, aby jedna liczba zastąpiła opis. Gra może pokazywać akceptowalną średnią, a mimo to wywoływać zauważalne przerwy. Z drugiej strony, niższa, ale stabilna liczba klatek może wydawać się bardziej przewidywalna. Pytanie dotyczące wsparcia dotyczy Twojego doświadczenia, a nie tylko najwyższej liczby uzyskanej w pustej scenie.
Trzymaj awarie i ponowne uruchomienia systemu w osobnej kategorii. Wymagają one innej reakcji niż niewielka różnica liczby klatek. Nie uruchamiaj wielokrotnie sceny, która powoduje restart całego komputera, tylko po to, aby zebrać kolejny próbny wynik wydajności. Strona dotycząca awarii i informacji zwrotnej wyjaśnia, jak nagrać ten objaw, nie traktując go jak zwykłego testu wydajności.
Ustal bazę odniesienia, którą możesz powtórzyć
Wybierz miejsce, do którego możesz wrócić, oraz krótką czynność, którą możesz powtórzyć, na przykład mały obrót lub krótkie przesunięcie wzdłuż widocznej części centrum. Zapisz nazwę komnaty, ustawienie grafiki, rozdzielczość, jeśli jest dostępna, limit klatek, jeśli go używasz, oraz czy maszyna działa na swoim normalnym zasilaniu. Utrzymuj test krótki, aby stan pokoju pozostał łatwy do przywrócenia.
Obserwuj tę samą czynność kilka razy, zanim zmienisz ustawienie. Jednorazowa pauza podczas przejścia może nie odzwierciedlać stabilnego zachowania sceny. Szukasz wzoru na tyle wyraźnego, aby późniejsze porównanie mogło się od niego znacząco różnić. Nie spędzaj całej sesji na zbieraniu danych, jeśli krótkie obserwacje już wykazują problem.
Podstawą jest Twoje lokalne odniesienie, a nie uniwersalny punkt odniesienia. Inny gracz może użyć tego samego ustawienia na innym sprzęcie i uzyskać inny wynik. Zapisz wystarczająco dużo kontekstu, aby Twoje własne porównanie „przed i po” było uczciwe, nie przedstawiając go jako obietnicy dla wszystkich innych.
Najpierw zmień tylko ustawienie grafiki.
Wybierz Niskie w opcjach grafiki gry, korzystając z etykiet menu widocznych w Twojej wersji. Wróć do tej samej sceny i powtórz tę samą krótką czynność. Pozostaw inne ustawienia bez zmian przy tym pierwszym porównaniu, jeśli to możliwe. Celem jest sprawdzenie, czy zmiana ustawienia grafiki powoduje zauważalną różnicę w podobnych warunkach.
Oryginalny raport gracza zmieniał zarówno jakość grafiki, jak i limit klatek. Jego wynik nie izoluje więc efektu jednej zmiennej. Wyjaśnienie dewelopera dotyczące mgły sprawia, że ustawienie grafiki jest silnym wskazaniem, ale kontrolowane lokalne porównanie może powiedzieć Ci więcej o Twojej konfiguracji niż kopiowanie kilku zmienionych wartości razem.
Jeśli Niskie ustawienie wyraźnie pomaga, masz praktyczny wybór ustawień. Nie musisz wielokrotnie przywracać słabej konfiguracji, aby udowodnić poprawę. Zapisz, co stało się lepsze, a co pozostało bez zmian. Redukcja obciążenia przy utrzymujących się pauzach w centrum daje inny wynik niż całkowite zniknięcie obu symptomów, a różnica ma znaczenie dla użytecznego raportu.
Oceń limit klatek osobno.
Jeśli gra udostępnia limit klatek w Twoim obecnym menu, możesz porównać niższy limit jako drugi test. Zachowaj ustawienie grafiki bez zmian podczas tego porównania. Jest to ogólne rozwiązywanie problemów z grafiką, a nie potwierdzone przez dewelopera lekarstwo na tę grę. Użyj wartości, która ma sens dla Twojego wyświetlacza i preferencji, zamiast kopiować liczbę innego gracza jako idealny cel.
Obserwuj, czy limit zmienia spójność, reakcję i objaw, który pierwotnie opisałeś. Niższy cel może zmienić to, jak mocno system pracuje, ale rzeczywisty wynik zależy od ustawień i sceny. Nie wnioskuj o konkretnej temperaturze lub redukcji obciążenia bez zmierzenia jej na swoim urządzeniu.
Jeśli zmieniasz limit klatek i preset grafiki razem dla wygody, zanotuj je jako połączony test. Nadal jest to użyteczne, jeśli celem jest komfortowa konfiguracja. Po prostu nie można stwierdzić, która zmiana spowodowała poprawę. Uczciwe oznaczanie zachowuje wartość wyniku bez twierdzenia, że przeprowadziłeś eksperyment, którego nie wykonałeś.
Porównaj huby z mniejszymi scenami
Deweloper zauważył, że huby są większe, a jednocześnie powiedział, że zgłoszone zachowanie wydawało się gorsze niż oczekiwano. Możesz pomóc odróżnić problem specyficzny dla sceny, porównując tę samą podstawową akcję w hubie i w mniejszym pokoju, do którego masz dostęp. Podczas tego porównania utrzymuj stałe ustawienia grafiki.
Zapisz, czy problem pojawia się we wszystkich hubach, które sprawdziłeś, czy tylko w jednej nazwanej komnacie. Nie generalizuj na podstawie jednego miejsca, w którym zauważyłeś problem po raz pierwszy. Raport dotyczący konkretnego hubu daje deweloperowi bardziej skoncentrowane miejsce do zbadania niż stwierdzenie, że wszystkie duże obszary są zepsute, gdy testowałeś tylko jeden.
Jeśli problem zależy od konkretnego widoku w hubie, zanotuj widoczny punkt orientacyjny lub kierunek. To nie dowodzi, który efekt lub obiekt jest odpowiedzialny, ale może ułatwić odtworzenie zachowania. Krótki opis widoku jest często bardziej użyteczny niż niepoparte przypuszczenie dotyczące silnika renderującego.
Utrzymuj problemy ruchu oddzielnie
Animacja, która wydaje się obejmować dwa kafelki naraz, nie jest automatycznie problemem z przypisaniem wejścia. Podobnie skręcanie postaci w lewo i prawo zamiast ruchu w bok nie jest automatycznie problemem z liczbą klatek na sekundę. Porównaj pozycję końcową i kierunek ustawienia po jednym świadomym naciśnięciu. To pomaga zdecydować, czy badać czasowanie, stan wejścia, czy oba.
Znany obejście Shift ma specyficzny objaw i własną odpowiedź dewelopera. Użyj tej strony, jeśli obrót zastępuje ruch w bok, szczególnie po nakładce. Nie łącz tego ze zmianami grafiki, chyba że zaobserwowałeś oba problemy i testujesz je osobno. W przeciwnym razie możesz stracić możliwość określenia, która zmiana pomogła.
Jeśli scena zatrzymuje się, ale końcowa akcja jest poprawna, zaznacz to. Jeśli sam stan końcowy różni się od oczekiwanego wejścia, zaznacz to zamiast tego. Deweloper może wykorzystać te rozróżnienia, aby oddzielić problem wizualnej prezentacji od akcji, która mogła być przetworzona inaczej.
Rejestruj kontekst systemu bez zgadywania
Uwzględnij system operacyjny, procesor, urządzenie graficzne, pamięć oraz to, czy grasz przez warstwę zgodności, kiedy jesteś w stanie je zidentyfikować. Używaj nazw podawanych przez system, zamiast ogólnych określeń, takich jak laptop do gier. Nie musisz ujawniać niepowiązanych informacji osobistych, aby dostarczyć przydatny kontekst sprzętowy.
Jeśli nie jesteś pewien co do komponentu, oznacz go jako nieznany, dopóki nie będziesz mógł to sprawdzić. Nie wywnioskowuj modelu karty graficznej na podstawie marki komputera lub naklejki marketingowej. Dokładne informacje są przydatne, ale wymyślona precyzja może wprowadzić wsparcie w złym kierunku.
Zanotuj również, czy podczas porównania działały inne wymagające zadania. Nie oznacza to, że należy obwiniać każdą działającą aplikację w tle. Pomaga to jedynie wyjaśnić, dlaczego dwa lokalne obserwacje mogą się różnić. Jeśli chcesz przypisać różnicę ustawieniom gry, przeprowadzaj testy w w miarę podobnych warunkach.
Interpretuj użycie GPU ostrożnie
Wysokie użycie GPU samo w sobie nie wskazuje błędu. Znaczenie tego zależy od obciążenia, ustawień, docelowej liczby klatek i obserwowanych objawów. Komentarz dewelopera daje prawdopodobne wyjaśnienie różnicy między dwoma ustawieniami w jednym raporcie, a nie próg, powyżej którego każdy system działa wadliwie.
Jeśli już monitorujesz użycie, zanotuj je wraz ze sceną i ustawieniami zamiast jako odosobnioną liczbę. Wartość ze hubu i wartość z menu nie tworzą czystego porównania. To samo dotyczy pomiarów wykonanych po różnym czasie gry lub podczas pracy innych programów w tle.
Nie kopiuj wartości temperatury innego gracza jako bezpiecznego lub niebezpiecznego limitu dla swojego sprzętu. Ta strona nie jest podręcznikiem diagnostyki sprzętu. Jeśli komputer sam się wyłącza lub restartuje, przestań traktować sesję jako test wydajności i skorzystaj z odpowiedniego wsparcia dla urządzenia wraz z rzeczowym raportem z gry.
Unikaj nieobsługiwanych przepisów optymalizacji
Źródła tutaj nie ustanawiają specjalnych flag uruchomieniowych, edycji rejestru, usuniętych plików konfiguracyjnych ani specyficznych dla gry nadpisanych sterowników, które naprawiają przycięcia w hubie. Długa lista takich zmian sprawiałaby wrażenie kompleksowego artykułu, zmniejszając jednocześnie wiarygodność porad. Zacznij od udokumentowanego wprowadzenia ustawień i zwykłych, obserwowalnych porównań.
Ogólna konserwacja, tak jak utrzymywanie aktualnego wspieranego oprogramowania, może być odpowiednia dla twojego systemu, ale nie powinna być reklamowana jako sprawdzony sposób naprawy He Who Watches. Jeśli zmienisz sterownik lub składnik systemu operacyjnego z własnych powodów, zanotuj stan przed i po oraz unikaj zmieniania kilku innych zmiennych w tym samym teście.
Nie poświęcaj działającego zestawu, by gonić cel z czyjegoś komputera. Przydatnym efektem jest stabilna i komfortowa gra na Twoim sprzęcie. Umiarkowany preset, który działa stabilnie, może być lepszym praktycznym wyborem niż bardziej wymagający wybrany tylko dlatego, że używał go w filmie porównawczym.
Użyj wartości numerycznych obecnie wyświetlanych w menu
Patch z 4 września dodaje wyświetlane wartości obok suwaków. Gdy odpowiednia opcja używa suwaka, zapisz wartość wyświetlaną, zamiast opisywać jej pozycję w ogóle. To ułatwia powtórzenie porównania ustawień i ułatwia interpretację raportu wsparcia.
Zmiana nie ustala nazw ani zakresów każdej opcji. Przeczytaj aktualne etykiety w menu i zachowaj je w notatkach. Jeśli porównujesz z innym językiem, dołącz zrzut ekranu lub krótki opis funkcji, zamiast zakładać, że przetłumaczona etykieta jest identyczna z angielskim przewodnikiem.
Prowadź mały zapis ustawień dla preferowanej konfiguracji. Jeśli później eksperymentujesz, możesz wrócić do znanej lokalnej bazy, nie pamiętając o kilku suwakach. Jest to szczególnie przydatne, gdy ustawienie wpływające na komfort różni się od tego, które zmieniasz dla wydajności.
Zdecyduj, czy obejście jest wystarczające
Jeśli Low usuwa problem, a efekt wizualny ci odpowiada, kontynuowanie tego jest rozsądnym praktycznym rozwiązaniem. Możesz nadal zgłaszać pierwotne zachowanie, jeśli masz jasny opis. Nie ma wymogu kontynuowania rozwiązywania problemów po osiągnięciu własnego celu komfortowej zabawy.
Jeśli Low poprawia obciążenie, ale nie pauzy, trzymaj oba wyniki oddzielnie. Preset może być przydatny, dopóki pozostaje inny problem. To bardziej informacyjne niż twierdzenie, że w ogóle nie działał. Informuje programistę, która część raportowanego doświadczenia zmieniła się w zalecanym porównaniu.
Jeśli nie ma widocznej poprawy, przestań powtarzać ten sam test bez nowego pytania. Zbierz szczegóły sceny, ustawień i objawów i skorzystaj z informacji zwrotnej. Wynik negatywny jest użytecznym dowodem, gdy warunki są jasne; nie trzeba go przekształcać w pewną teorię o wąskim gardle.
Przesyłaj opinię, gdy problem jest istotny
W wątku dotyczącym wydajności huba deweloper specjalnie poprosił o raport opinii z menu pauzy podczas opóźnień. Podążaj tą ścieżką, jeśli gra pozostaje wystarczająco użyteczna, by to zrobić. Opisz hub, akcję, preset i czy podobne zachowanie pojawia się gdzie indziej. Dołącz wynik porównania Low.
Krótki raport może wskazywać, że nazwany hub zatrzymuje się podczas prostego zakrętu, mniejsze pomieszczenie nie, a zmiana ustawienia zmniejszała obciążenie bez zmiany przerw. To jest wzorzec raportu, a nie twierdzenie dotyczące twojej maszyny. Korzystaj tylko z rzeczywistych obserwacji i pomijając nieprzetestowane porównania.
Jeśli dołączasz nagranie, skup je na powtarzalnym momencie. Wyjaśnij dane wejściowe i oczekiwany ruch, aby programista mógł odróżnić celową pauzę od problemu. Odpowiednio oznacz tajne obszary, jeśli publikujesz publicznie, i unikaj odsłaniania niezwiązanych z tym treści na pulpicie podczas przechwytu.
Sprawdzaj ponownie tylko wtedy, gdy coś istotnego się zmieni
Po wybraniu funkcjonalnego zestawu wracaj do problemu, gdy odpowiednia aktualizacja, zmiana sprzętu lub nowa instrukcja dla dewelopera poda powód. Powtarzanie tego samego benchmarku co sesję niewiele informacji. Datowana notatka pozwala porównać późniejszą zmianę ze stanem, który już udokumentowałeś.
Nie zakładaj, że jakakolwiek nowa poprawka poprawia wydajność, chyba że jej notatki lub twoje obserwacje tego potwierdzają. Ogłoszenie z 4 września obejmuje zmiany zagadek i menu, a nie uniwersalną poprawkę zacięć. Zachowaj późniejszą poprawę powiązaną z buildem i warunkami, w których ją zaobserwowałeś.
Przydatna pętla wsparcia jest niewielka: opisz objaw, porównaj jedno ustawienie w tej samej scenie, zachowaj wynik i zgłoś utrzymujący się problem z kontekstem. Dzięki temu sygnał mgły programisty jest możliwy do działania, zachowując jednocześnie różnicę między potwierdzonym zachowaniem ustawienia a nierozwiązaną diagnozą wydajności.
Przeczytaj krótki dziennik porównawczy
Wyobraź sobie lokalny log z trzema wpisami: hub na oryginalnym presetie, ten sam hub na Low i mniejszy pokój na Low. To jest sugerowana struktura testu, a nie dane benchmarkowe z tego artykułu. Pierwsza para pyta, czy preset zmienia objaw. Druga para pyta, czy pozostałe zachowanie zależy od sceny. Utrzymanie tych pytań w oddzieleniu ułatwia interpretację wyników.
Jeśli hub poprawi się na Niskim, a mniejszy pokój jest płynny, masz praktyczną konfigurację do wykorzystania. Możesz zgłosić pierwotny problem w kontekście ustawień, ale nie musisz ciągle zmieniać opcji tylko po to, by uzyskać bardziej szczegółowe wyjaśnienie. Lokalny cel stabilnej gry może być już osiągnięty.
Jeśli hub poprawia się tylko częściowo, podczas gdy mniejsze pomieszczenie zachowuje się dobrze, nazwij pozostały objaw. Może to być krótka, powtarzająca się pauza, nagła animacja lub inny widoczny efekt. Nie redukuj częściowej poprawy na całkowicie stałą lub żadną różnicę. To rozróżnienie daje deweloperowi jaśniejszy obraz tego, na co wpływa preset.
Jeśli obie sceny pokazują ten sam problem, porównanie nie wyodrębniło problemu specyficznego dla huba. To nie dowodzi, że przyczyna leży poza grą. Oznacza to po prostu, że rozmiar sceny, w warunkach, które sprawdzałeś, nie rozdzielił przypadków. Dołącz wynik i przejdź do odpowiedniego pytania wsparcia zamiast wymyślać wniosek.
Jeśli pomiary różnią się zbyt mocno, aby je interpretować, skróć test i ustabilizuj warunki. Użyj tego samego widoku, akcji i ustawień przy kolejnej obserwacji. Hałaśliwe porównanie jest powodem do poprawy obserwacji, a nie powodem do wybierania dowolnej liczby wspierającej preferowaną teorię.
Utrzymuj log wystarczająco krótki, aby był czytelny. Kilka wyraźnie opisanych porównań może być bardziej użyteczne niż setki wartości bez przypisanej sceny lub ustawień. Deweloper potrzebuje wiedzieć, co się zmieniło, a co nie. Twoje przyszłe ja potrzebuje tych samych informacji przy decyzji, czy późniejsza aktualizacja wpłynęła na problem.