Exe - zmiany w stosie graficznym i dźwiękowym

[Turbokibel]

A mówili, że AMD i MaSzyna to zło.

[JAN21]

#teamNvidia, mam to samo :P I5-9400F, 16GB RAM i 750Ti. Multisampling na 0, FPSy praktycznie cały czas na poziomie 60. Dopóki kamerą się nie macha, dopóty idzie płynnie. Tak mocno próbowali i kombinowali żeby działało na AMD, że teraz produkty od "Zielonych" się buntują ;)

[wacek12321]

A mówili, że AMD i MaSzyna to zło.

Używam AMD do maszyny od 5 lat i przez te 5 lat może raz kiedyś miałem wysyp a tak to nie wiem w czym problem :)

[chyzy17]

Czyli wychodzi na to, że faktycznie coś z tą nvidią jest nie halo teraz. Już od kilku ładnych wydań maszyny mam takie problemy.

A mówili, że AMD i MaSzyna to zło.

Ano było tak, było :P

[Turbokibel]

Tmj, jak były te problemy z crashowaniem na AMD to zrobiłeś poprawkę, to może do NVIDII też byś zrobił, by nie szarpało, bo jak widać na AMD nic nie szarpie, a na NVIDII nawet na dobrym sprzęcie problem występuje.

[Miłosz Dorsz]

Tylko gdyby tmj jeszcze wiedział w czym leży problem, żeby móc go wyeliminować...

[Turbokibel]

Jeszcze do tego ścinania, zauważyłem, że nie tylko przy ruszaniu myszą to występuje, wskazówki manometrów też chodzą tak "schodkowo" (na zoomie nie), film:

[Turbokibel]

W EN96 falownik włącza się z opóźnieniem w członie B.

a na sceneriach czasami w ogóle falownik się nie włącza w członie B, pomaga wtedy zmiana kabiny.

[Stele]

Jak widzisz po debugu, fizycznie człon B jest trupem. Człon A reprezentuje dwa wózki napędowe a człon B wózek toczny. Maszyna nie obsługuje różnych typów wózków w jednym pojeździe, a jakoś trzeba rozłożyć siły.

[Max_EN_57]

Problem z FPS i rwaniem obrazu bardzo przypomina to z czym ja miałem do czynienia już kilka lat temu. Pozwalam sobie wkleić moje rozwiązanie na ów problem z innego wątku, może komuś pomoże:

Ostatnio walczyłem z podobnym problemem i niewykluczone, że znalazłem rozwiązanie. Mój sprzęt to i5 7600 3.50GHz; 16 GB RAM; NVIDIA 1060 6GB. Średnio na wszystkich sceneriach mam 200 FPS. I teraz ciekawostka - mam identyczne "rwania obrazu" jak te pojedyńcze na Twoim filmie, różnica polega na tym, że u mnie... występują co 2 sekundy, dosłownie. Wygląda to tak jakby v-sync w MaSzynie nie tolerował wysokiego FPS (ale tylko na sceneriach z wieloma obiektami) i próba zrzucania FPS z kilkuset na 60 FPS powoduje "czkawkę" w postaci tego "rwania". Rozwiązania:

[Metoda 100% skuteczna] - 1. Wymuszenie wyłączenia v-sync w sterownikach NVIDIA. Jako, że wyłączenie v-sync powoduje generowanie znacznej ilości FPS (które jest nam zbędne, bo PC się tylko grzeje, a na monitorze widzimy klatek np 60) to polecam ściągnięcie zewnętrznego limitera FPS, ja np mam RivaTuner Statistics Server. Owszem, będzie widoczne czasem "łamanie obrazu" charakterystyczne dla wyłączonego v-sync, ale wszelkie czkwawki i zwiechy znikają, a PC się nie grzeje bo zewnętrzny limiter i tak trzyma 60 FPS.

[Metoda, którą odkryłem dzisiaj, w fazie testów] - 2. Wymuszenie włączenia v-sync w sterownikach NVIDIA (opcja "on", żadne adaptive itp) + zewnętrzny limiter FPS (koniecznie). V-sync w MaSzynie wyraźnie potrzebuje wsparcia zewnętrznego programu bo sam po prostu nie do końca sobie radzi ze zrzucaniem z wysokiego FPS. Ta metoda jest dopiero w fazie testów, nie wiem czy to nie jakiś przypadek lub coś się nie rozłączy, ale póki co wszystko chodzi cacy.

Mam nadzieję, że któraś z tych metod Ci pomoże.

Pozdrawiam

Potwierdzam, że metoda 2 działa jak należy. Proszę też pamiętać, żeby sprawdzić ile Wasze monitory mają Hz (częstotliwość odświeżania). Jeżeli jest to 60Hz, to nie ustawiajcie limitu na 65, 75 albo więcej gdyż nie ma to żadnego sensu (daje to jedynie wyższe temperatury CPU i GPU). Przy 60Hz ustawcie limit w RivaTunerze na 60 FPS i sprawdźcie czy to pomogło. Jeżeli Wasz sprzęt pozwala uzyskiwać głównie ~40 FPS to spróbujcie ustawić limit FPS na 30 (najlepsza płynność animacji następuje przy FPS, które stanowi całość, połowę, ćwierć itp Hz monitora). Nie wiem jak sprawa się ma z technologią G-sync, gdyż takiej mój monitor nie obsługuje.

Pozdrawiam

[Matson]

Powyższe rozwiązanie faktycznie pomaga, ale jest to wciąż rozwiązanie doraźne, gdyż problem szarpania to nie do końca jest kwestia FPS-ów. Ustawienie limitu na 50 mimo 46 klatek na Janiszewie nie powoduje szarpania, natomiast na 60 klatek/s już tak a przeskok jest drastyczny.

[DieselPower]

Na ostatnim eu07-x64_200129 nie wyświetlają się wszystkie tekstury. Paczkę specular.7z też mam wrzuconą, pliki najświeższe z repo.

[Stele]

Skórki byków edytowałem. Zobacz co skopałem. Hebelki też edytowałem i jak widać zrobiłem śmietnik. Jaka to kabina? Co log mówi o hebelkach?

[DieselPower]

Bad file: failed do locate texture file "hebel1"
Bad file: failed do locate texture file "hebel_normal"
bad material: textures/tabor/hebel1: missing texture: diffuse
bad material: textures/tabor/hebel1: missing texture: normalmap

W matach powpisywane jest texture_diffuse: hebel1 a nie powinno być texture_diffuse: textures/tabor/hebel1?

Na tym exe bez wpisu :st detale ET22 wyświetlają się normalnie.

[Stele]

Tak. Mat skopany. śmieszne, bo wszystkie inne heble mają pełne ścieżki. Fatum trwa.
Jak te detale na dachu są mapowane, że wyłączenie zawijania je psuje? Choć może wystarczyć, że będą przesunięte za obszar uv 0-1. Wychodzi na to, że trzeba wywalić te parametry. :<

[DieselPower]

Tak wygląda mapowanie podstawa_pant z którym właśnie są takie problemy. 😯

[Stele]

No to puszczaj cofkę materiałów, bo tam więcej może wyłazić za 0-1. :< Cudów parametr nie zdziałał. Nie ma co przesuwać połowy uv w modelu by to utrzymać.

[DieselPower]

Pousuwałem te wpisy w rev. 5277, wszystko wróciło do normy.

Te ET22 w testach jeszcze mają wpisy :st. U siebie mam je usunięte, więc w kolejnych paczkach lub przy wrzutce już ich nie będzie.

[Turbokibel]

Zauważyłem jakiś problem z lampkami wyłącznika szybkiego, lecz on nie zawsze występuje, nie mam pojęcia od czego to uzależnione, mianowicie, np. po wywaleniu WSa, lampka nam nie gaśnie lub też wyłączymy WSa ręcznie to po sekundzie lampka się zapala, nie wiem czemu tak się dzieje, filmik:

[Miłosz Dorsz]

A ta lampka nie jest podpisana "wyłącznik szybki wyłączony"?

[SM40]

Zauważyłem jakiś problem z lampkami wyłącznika szybkiego, lecz on nie zawsze występuje, nie mam pojęcia od czego to uzależnione, mianowicie, np. po wywaleniu WSa, lampka nam nie gaśnie lub też wyłączymy WSa ręcznie to po sekundzie lampka się zapala, nie wiem czemu tak się dzieje, filmik:

Potwierdzam, występuje też problem z przyciskiem WS'a w Elfie powinien być tylko impuls załączenia a da się nim wyłączyć.

[Stele]

WS w elfie powinien być przepięty kilka tygodni temu.

[Turbokibel]

Tak, tylko, że jak to wpiszesz to WS się będzie włączał po puszczeniu przycisku, a nie jak kiedyś, czyli w trakcie trzymania.

[tmj]

Pytales sie juz o to i tlumaczylem wtedy ze przycisk wstawiony obecnie do elfa w odroznieniu od poprzedniego dziala dopiero po puszczeniu, bo tak ten przycisk dziala w siudemce, a u nas nadal wszystko jest siudemkom.

[Turbokibel]

A ta lampka nie jest podpisana "wyłącznik szybki wyłączony"?

Podpięta jest dobrze, to jest raczej błąd exe. Kolejny błąd zauważyłem, w kiblach, jeśli nam wywali WS i nie tylko, to jak klikniemy na klawiaturze M to przycisk nie będzie w ogóle animowany :/

[tmj]

W dzisiejszym uaktualnieniu:

- zeby bylo tak jak bylo, dolaczony szader dla chmur, wierniej emulujacy modyfikacje oswietlenia wersji nieszaderowej. W zalaczniku dostosowany plik .mat oraz lekko zmodyfikowana bazowa tekstura chmur

- dobra zmiana, dolaczony kod obslugi trybu multiplayer z galazki Milka7. Konfiguracja rozgrywki odbywa sie na tych samych zasadach:
-- wpis w ini network.server tcp 0.0.0.0:port (gdzie port to np. 42424) powoduje uruchomienie symulatora w trybie serwera, komunikujacego sie na podanym porcie
-- wpis w ini network.client tcp X.Y.Z.W:port (gdzie X.Y.Z.W to adres IP dzialajacego serwera przyjmujacego polaczenia na podanym porcie) powoduje uruchomienie serwera w trybie klienta, laczacego sie z serwerem o podanym adresie

Nalezy zwrocic uwage ze plynnosc symulacji w trybie multiplayer (o ile mozna mowic tu o plynnosci) jest w duzej mierze uzalezniona od wydajnosci komputera pelniacego role serwera, i nie oczekiwac pod tym wzgledem zbyt wiele :v

[mareczek]

Rzyga i rzyga i przestać nie może. Ale gra działa :-)

Kod: [Zaznacz]

bad gfx code: 0x20096 (medium severity) Program undefined behavior warning: The current GL state uses a sampler (0) that has depth comparisons disabled, with a texture object (0) with a non-depth format, by a shader that samples it with a shadow sampler. This will result in undefined behavior.

[Turbokibel]

Dlaczego każdy pojazd na start ma włączoną baterię i podniesione pantografy?
Edit: tylko z odznaczoną opcją "zasilanie pantografów tylko pod siecią trakcyjną".

[tmj]

Efekt uboczny podpiecia kodu do multiplayera; teraz kazdy pojazd startuje w trybie aktywnej AI, ktora potencjalnie zabiera sie zwawo za uruchamianie pojazdu zanim jeszcze wsiadzie do niego uzytkownik. Moze uda sie z tym cos zrobic, ale nie obiecuje.

W dzisiejszym uaktualnieniu:

- poprawka, wylaczone debugowanie kodu graficznego

- funkcjonalnosc, wprowadzona nowa sekcja w plikach .fiz o identyfikatorze AI: w zalozeniu pozwalajaca na podpowiedzi dla AI jak obslugiwac dany pojazd. Na razie rozpoznawany jest jeden wpis

Kod: [Zaznacz]

Pantstate=X // sugerowana konfiguracja pantografow, gdzie X to 1 jesli w czasie jazdy podniesiony ma byc pantograf nad kabina A, 2 gdy podniesiony ma byc pantograf nad kabina B, lub 3 gdy podniesione maja byc oba pantografy

- eksperymentalnie, przeszczepiony kod obslugi ekranow Pythona z galazki Milka7. Jednym z efektow przeszczepu jest obsluga dodatkowego przelacznika w pliku eu07.ini

Kod: [Zaznacz]

python.threadedupload yes/no // (yes) wysylanie wygenerowanych obrazow ekranow przy uzyciu osobnego watku

Teoretycznie przelacznik ten nie powinien byc potrzebny, w praktyce byc moze polepszy jakos wrazenia u osob ktorym symulator "szarpie" przy majtaniu mysza i innych dziwnych czynnosciach

[tmj]

W dzisiejszym uaktualnieniu:

- poprawka, aktywny ekran pauzy powinien ponownie reagowac na klawisz pauzy
 
- eksperymentalnie, wirtualni mechanicy odczekuja chwile z aktywacja swoich pojazdow, dajac symulacji szanse na zastapienie ich przez niewirtualnego uzytkownika

- funkcjonalnosc, warunek memcompare moze byc definiowany w formie rozbudowanej, pozwalajaca na bardziej elastyczne uruchamianie eventow. Nowy format wyglada nastepujaco:

Kod: [Zaznacz]

memcompareex tryb_porownania operator tekst operator wartosc1 operator wartosc2
gdzie:
-- tryb_porownania: slowo-klucz okreslajace czy do spelnienia warunku wymagane jest zaliczenie porownan wszystkich zdefiniowanych elementow komorki pamieci (all) czy tez przynajmniej jednego z nich (any) lub tez zadnego (none) Dotychczasowy sposob dzialania warunku memcompare jest odpowiednikiem trybu all

-- operator: metoda porownania elementu komorki pamieci ze zdefiniowana wartoscia. Dostepne metody to == (rowny) != (nierowny) < (mniejszy) > (wiekszy) <= (mniejszy lub rowny) oraz >= (wiekszy lub rowny) Dotychczasowy sposob dzialania warunku memcompare jest odpowiednikiem operatora ==

-- tekst, wartosc1, wartosc2: wartosci z jakimi porownywane beda poszczegolne elementy komorki pamieci.

Uzycie klucza * zamiast pary operatora i wartosci powoduje pominiecie testu danego elementu.

Przyklady uzycia:

Kod: [Zaznacz]

condition memcompareex any == Foo > 0 <= 10
warunek zostanie spelniony gdy tekst przechowywany w testowanej komorce pamieci ma postac "Foo", lub gdy pierwsza przechowywana wartosc liczbowa jest wieksza niz 0, lub gdy druga przechowywana wartosc liczbowa jest mniejsza lub rowna 10

Kod: [Zaznacz]

condition memcompareex all * * > 5
warunek zostanie spelniony gdy druga wartosc liczbowa przechowywana w testowanej komorce pamieci jest wieksza niz 5

Kod: [Zaznacz]

condition memcompareex all != winter: < 150 *
warunek zostanie spelniony gdy przechowywany w testowanej komorce pamieci tekst nie brzmi "winter:" a pierwsza przechowywana liczba jest mniejsza niz 150