Autor Wątek:  Exe - konwersja na C++  (Przeczytany 890966 razy)

0 użytkowników i 3 Gości przegląda ten wątek.

Offline HTD

  • Wiadomości: 697
  • "Twoja stara mieszka w Boldach" xD
    • Zobacz profil
    • I like trains
  • Otrzymane polubienia: 30
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1230 dnia: 12 Marca 2017, 07:51:04 »
OK, test na Drawinowie: cała droga 60FPS, ogromna poprawa względem 20-30 co miałem wcześniej na stacjach Grodzisk, Drawinowo, Grabówek czy Włodowice. Niestety ogromne pogorszenie jakości obrazu i to wcale nie na stacjach, które wyglądają tak samo, tylko jadąc przez las i wieś, gdzie miałem zawsze 60FPS na starym exe.

Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą. Proszę, zmniejszanie widoczności obiektów kompletnie nic nie daje dla wszystkich współczesnych a nawet dość starych kart graficznych. To nie dlatego MaSzyna przycinała. Tak jak mówiłem - przycinanie występowało u mnie dokładnie identycznie dla 2 różnych kart graficznych (bardzo stary Radeon i dużo nowszy GTX960), do tej samej wartości i w tych samych miejscach - na dużych torowiskach. Jadąc przez wieś miałem 60FPS nawet na zintegrowanym Intelu we w miarę nowym laptopie.

Najlepiej dodać opcję w konfiguracji, tzn ini, drawing distance, bez limitu, albo z limitem 10km. Wtedy po szybkich testach będziemy wiedzieć co wpływa na FPS na różnych kartach graficznych, a co nie.

I jeśli już modernizujemy MaSzynę, to modernizacja raczej nie powinna się koncentrować na muzealnych komputerach. MaSzyna była muzealnym symulatorem dla muzealnych komputerów. Największą jej wadą był kompletny brak wsparcia dla nieco nowszych (a przez nowsze mam na myśli takie z 5-6 letnie) komputerów. Całe szczęście to się da pogodzić dzięki konfiguracji. Jak ktoś chce sobie MaSzynę odpalić na kalkulatorze, nie ma sprawy - może sobie wyłączyć wszystkie detale graficzne i pójdzie. Jak ktoś ma kilkuletni sprzęt (a nie kilkunastoletni) - włączy sobie wszystko na maksa i też będzie zadowolony.

Od początku mojej przygody z MaSzyną zauważyłem niemal kompletny brak wpływu włączonych poprzez sterownik karty graficznej detali a FPS. Obojętnie czy był to Radeon z seri 4, 5, 6, czy NVidia - ustawienia grafiki w ogóle nie wpływały na FPS. Mało tego - ten sam efekt obserwowałem przed i po zastosowaniu mojego patcha, który ustawiał wszystkim obiektom widoczność -1. Brak wpływu na FPS, równy przed i po (chociaż różnica w delatach grafiki była wyraźnie zauważalna). Pomimo tego, że masa osób usiłowała zaprzeczać faktowi - tak samo nie miałem żadnej różnicy w FPS pomiędzy teksturami TGA i DDS. Była niewielka różnica w czasie ładowania, ale mało zauważalna.

Ergo nie tędy droga. MaSzyna zacinała mi z kolei po ustawieniu wszystkich efektów graficznych na minimum przykładowo na Drawinowie, na stacjach. Mogłem sobie nawet wygładzanie krawędzi wyłączyć i filtrowanie tekstur, tam klatkowało i koniec. Na każdej karcie graficznej tak samo, efekt klatkowania był zależny wyłącznie od CPU, w ogóle nie od karty graficznej.

FPS jest wyznacznikiem wydajności jedynie na monitorach CRT lub tych nowszych, które mają dynamiczną synchronizację ramki. Przy opcji vsync on FPS nie mówi nic. Nawet jak moja karta jest w stanie wyświetlić 300FPS, to i tak wyświetli 60 więc co mi mówi o wydajności FPS? Nic.

Offline Krzysiek626

  • Zasłużony dla Symulatora
  • Wiadomości: 5925
  • EXIT
    • Zobacz profil
    • Krzysiek626
  • Otrzymane polubienia: 443
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1231 dnia: 12 Marca 2017, 08:11:10 »
@HTD, z całym szacunkiem ale wygadujesz rzeczy, które Ty doświadczyłeś. Moje doświadczenia, są zupełnie inne. Nic mi nie wyskakuje, jakość obrazu nie pogorszyła się. Ale to subiektywna ocena. Nie zgadzam się, że wprowadzenie dds nie miało wpływu na czas ładowania, bo to dziś jeszcze można udowodnić. Do tego tekstury TGA zajmują więcej miejsca w pamięci. Ponieważ zawsze pod ręką miałem kilka komputerów, to pozwolę sobie zaprzeczyć, że efekt klatkowania zależy tylko od procesora. Przytaczać przykładów nie będę, tu nie ma miejsca na takie dywagacje, chyba, że w osobnym wątku. O ile wiem, nie mamy możliwości zrobić rewolucji na posiadanym exe, materia jest delikatna i czasem doprowadza do płaczu i krwawienia oczu (cytata za tmj i milek7). Twoje pomysły można by zastosować w aplikacji od nowa pisanej, jeśli w ogóle coś wnoszą. Przejadę Drawinowo, wypowiem się na temat wyglądu lasów i wsi.
ED:
OK, test na Drawinowie: cała droga 60FPS, ogromna poprawa względem 20-30 co miałem wcześniej na stacjach Grodzisk, Drawinowo, Grabówek czy Włodowice. Niestety ogromne pogorszenie jakości obrazu i to wcale nie na stacjach, które wyglądają tak samo, tylko jadąc przez las i wieś, gdzie miałem zawsze 60FPS na starym exe.
Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą. <ciach>
Nic mi nie wyskakiwało FPS od 65 na stacjach do 200 w trasie. Oczywiście uwolniony monitor od synchronizacji. Jak wiesz posiadam nie najnowszy sprzęt i z wyniku jestem bardzo zadowolony.
Powtórzę pytanie o migotanie krawędzi przenikających się tekstur (przykład: trawa+podsypka, ale nie tylko bo są inne tekstury nakładane na trawę). Będzie można coś na to poradzić? Nie pytam z niecierpliwości, jestem zwyczajnie ciekawy.
« Ostatnia zmiana: 12 Marca 2017, 11:01:38 wysłana przez Krzysiek626 »

Offline Wiggle

  • Deweloper
  • Wiadomości: 477
    • Zobacz profil
  • Otrzymane polubienia: 141
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1232 dnia: 12 Marca 2017, 12:02:53 »
U mnie ucina dźwięki syreny, dźwięk rozpoczynający i trwający jest, natomiast kończącego wcale nie odpala. Na exe 11.03 działa bez problemu.
« Ostatnia zmiana: 12 Marca 2017, 12:07:14 wysłana przez Wiggle »
Maszynista Instruktor
POLREGIO Zakład Wielkopolski

Offline Krzysiek626

  • Zasłużony dla Symulatora
  • Wiadomości: 5925
  • EXIT
    • Zobacz profil
    • Krzysiek626
  • Otrzymane polubienia: 443
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1233 dnia: 12 Marca 2017, 12:11:29 »
Jakbyś jeszcze loka podał, bo wiesz w siódemce, ósemce i dziewiątce mam ok.

Offline Wiggle

  • Deweloper
  • Wiadomości: 477
    • Zobacz profil
  • Otrzymane polubienia: 141
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1234 dnia: 12 Marca 2017, 12:15:25 »
Traxx, kibel, na razie tylko odpaliłem i był ten sam błąd. U mnie na siódemce dźwięk się kończący odpala, ale nie trwa do końca, tylko go ucina, a w tych co wymieniłem wgl sie nie odpala.
Maszynista Instruktor
POLREGIO Zakład Wielkopolski

Offline Krzysiek626

  • Zasłużony dla Symulatora
  • Wiadomości: 5925
  • EXIT
    • Zobacz profil
    • Krzysiek626
  • Otrzymane polubienia: 443
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1235 dnia: 12 Marca 2017, 12:33:34 »
Sprawdziłem, tak jak pisałem 07, 08, 09 mam dobrze. Trax jest dziwny na 0311 i na 0312
Kibel jest ok na 0311, jest źle na 0312. Potwierdzam, że z dźwiękami Traxa i Kibla coś się zadziało.

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1236 dnia: 12 Marca 2017, 12:54:05 »
Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą.
Sprawdz, jesli mozesz, czy to wystepowalo przy wersji 03.12, czy takze na poprzednich? Albo wylacz na chwile vsync in 03.12 i porownaj czy dalej jest to samo?

W 03.12 przy zmianach zgubilo sie dotychczasowe zachowanie domyslne symulatora, czyli zwiekszenie poczatkowego zakresu widzialnosci przy fps > ~30. Idzie do porawki, lacznie z przebazowaniem tego na czas kreslenia ramki, bo to sensowny pomysl.

edit:
Cytuj
Proszę, zmniejszanie widoczności obiektów kompletnie nic nie daje dla wszystkich współczesnych a nawet dość starych kart graficznych.
Cytuj
OK, test na Drawinowie: cała droga 60FPS, ogromna poprawa względem 20-30 co miałem wcześniej na stacjach Grodzisk, Drawinowo, Grabówek czy Włodowice.
Nie wydaje ci sie, ze tutaj sam sobie troche przeczysz? :)  Gdyby regulacja widocznosci faktycznie nic nie dawala, to zmiany nie powinny wplynac na fps ktorego doswiadczasz, i tam gdzie miales 20-30, nadal mialbys 20-30. Skoro jednak zamiast tych 20-30 masz 60+ to chyba jednak jakis wplyw na wydajnosc to ma.
« Ostatnia zmiana: 12 Marca 2017, 13:06:29 wysłana przez tmj »

Offline Siecool

  • Deweloper
  • Wiadomości: 982
    • Zobacz profil
  • Otrzymane polubienia: 232
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1237 dnia: 12 Marca 2017, 13:09:10 »
Do kolekcji. Sceneria ta sama, misja inna, szybko poszło, bo w mniej niż 10 minut.

Offline Stele

  • Zasłużony dla Symulatora
  • Wiadomości: 10133
    • Zobacz profil
  • Otrzymane polubienia: 2609
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1238 dnia: 12 Marca 2017, 14:51:13 »
Zmiana zakresu na wielkie trójkąty nie pomogła. Gdy jest 3x to jest, spoko, ale jak mi fps spadł i zeszło do 1.4x to zaczęło być brzydko. Znacznie brzydziej niż wcześniej. Nie obcina rysowania całości. Teren w e3d był po horyzont, tory ucinało w widocznej odległości, dworca wyświetlało tylko niektóre elementy.
Mój kanał youtube

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1239 dnia: 12 Marca 2017, 16:10:27 »
OK, czyli wyglada na to ze eksperyment sie nie powiodl, odlozymy to do czasu gdy teren zostanie ogolnie ogarniety. A na razie wracamy do tego co bylo, a wlasciwie czesciowo do tego co bylo (kod rysujacy) ale z regulacja zakresu na podstawie predkosci rysowania ramek, a nie fps.

Nawiasem mowiac, wyglada na to ze powrot do starego renderowania terenu naprawil tez uciete dzwieki syreny. Albo moze ja gluchy jestem, ale tak czy owak magia panie, magia.

A zeby nie bylo calkiem nudno, to symulator ma teraz swoja ikone na belce okna (glownego okna, nie tego do logowania) prawie jak prawdziwy program :d

edit:
Do kolekcji. Sceneria ta sama, misja inna, szybko poszło, bo w mniej niż 10 minut.
To chyba znowu brak pamieci jest, bo wylecial na bad_alloc() jak przedtem. Chociaz zawsze w tym samym miejscu, co jest dosc podejrzane. Troche trudno dojsc, czemu akurat tam, ale jesli uda mi sie wywolac to u siebie, to sie przyjrze.

Powtórzę pytanie o migotanie krawędzi przenikających się tekstur (przykład: trawa+podsypka, ale nie tylko bo są inne tekstury nakładane na trawę). Będzie można coś na to poradzić? Nie pytam z niecierpliwości, jestem zwyczajnie ciekawy.
Tutaj wplyw ma w duzej czesci ograniczenie 'rozdzielczosci' liczb zmiennoprzecinkowych, im dalej od "punktu 0" tym jest gorzej. Byc moze uda sie cos tutaj zrobic stosujac pewne sztuczki, ale zadnej gwarancji ze cos z nich wyjdzie niestety nie ma, zwlaszcza gdy kod rysujacy jest zakrecony tak jak jest. Sam chcialbym to poprawic, mnie tez to denerwuje ;d

edit2: aha, zapomnialem, poniewaz zgloszono zapotrzebowanie to ctrl + rolka kontroluje teraz przyblizenie takze w trybie normalnym, nie tylko debug.
« Ostatnia zmiana: 12 Marca 2017, 16:43:10 wysłana przez tmj »

Offline HTD

  • Wiadomości: 697
  • "Twoja stara mieszka w Boldach" xD
    • Zobacz profil
    • I like trains
  • Otrzymane polubienia: 30
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1240 dnia: 12 Marca 2017, 17:56:23 »
@tmj, dobra, usuwam poprzedni komentarz, odnoszący się do poprzedniej wersji.

PEŁEN SUKCES. Na 312b w Drawinowie mam cały czas 60FPS i nie ma "pustyni". Ideał! Rysowanie mam 1.5x na stacjach, poza stacjami 3x, czyli teraz działa to dokładnie tak jak powinno.
« Ostatnia zmiana: 12 Marca 2017, 18:28:11 wysłana przez HTD »

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1241 dnia: 12 Marca 2017, 18:07:37 »
Ktoś kiedyś pisał, że nie ma sensu, żeby kosz na śmieci był widoczny z 500m, racja. Ale ściana lasu to nie wiem, nawet z kilometra powinna się wyświetlać. Podobnie budynki i drzewa.
Zgadza sie, sek w tym ze symulator nie rozumie czegos takiego jak "kosz" czy "sciana lasu" -- dla niego to jest wszystko to samo, zbior trojkatow ktore kaze mu sie narysowac. A kiedy rysowac, to juz jest w duzym stopniu decyzja autora obiektu i/lub sceny, ktory ustawia parametry minimalnego i maksymalnego zakresu widocznosci. W przypadku scian lasow i innych tego typu konstrukcji problematyczne moze byc podejscie konstruowania tychze w oparciu o pojedyncze prostokaty kilometrowej i wiekszej dlugosci. Do pewnego stopnia exe sobie to podzieli na mniejsze kawalki, ale na pewno nie pomaga to w okresleniu, gdzie taki obiekt sie znajduje, i kiedy go wyswietlic.

Jesli mozesz, to sprawdz tez jak sytuacja wyglada w 03.12b -- klopoty w 03.12 do pewnego stopnia byly kombinacja wlaczonego vsync i zmienionej regulacji widocznosci, co spowodowalo ze widziales mniej wiecej to, co symulator zazwyczaj wyswietla przez pierwszy ulamek sekundy swojej pracy. W biezacym uaktualnieniu powinno to ulec poprawie.

Offline youBy

  • Deweloper
  • Wiadomości: 6163
  • Co tam?
    • Zobacz profil
    • Automat Weryfikujący Regulację i Lambdę
  • Otrzymane polubienia: 865
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1242 dnia: 12 Marca 2017, 18:29:17 »
Jak coś, to w kodzie powinny się jeszcze pałętać resztki przesuwacza scenerii po przekroczeniu (chyba) 10 km od środka.
Xoov
Powyższy post wyraża jedynie opinię autora w chwili publikacji. Autor zastrzega sobie prawo do zmiany poglądów bez podawania przyczyny, jak również informowania o tym.

Offline HTD

  • Wiadomości: 697
  • "Twoja stara mieszka w Boldach" xD
    • Zobacz profil
    • I like trains
  • Otrzymane polubienia: 30
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1243 dnia: 12 Marca 2017, 18:31:29 »
Teraz jest idealnie w tej wersji. W poprzednich nie było przycinania, ale było klatkowanie. Teraz wilk syty i owca cała. Nie ma ani klatkowania ani przycinania. Jest super. Nie wiem jaką magią to osiągnąłeś, ale to mocne voodoo ;) A co do tej odległości od środka, czy to jest bug OpenGL, czy efekt jakiegoś innego problemu?

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1244 dnia: 12 Marca 2017, 18:34:36 »
Jak coś, to w kodzie powinny się jeszcze pałętać resztki przesuwacza scenerii po przekroczeniu (chyba) 10 km od środka.

Aha, jest tam cos takiego, ale wylaczone. Mysle raczej o zrobieniu tego dynamicznie, tzn zamiast bawic sie w ustawianie macierzy na pozycje kamery a potem przesuwac dodatkowo o wspolrzedne obiektu, mozna by sprobowac podejscia gdzie kamera jest zawsze traktowana jakby byla w punkcie 0, a obiekty sa jednynie przesuwane o roznice miedzy kamera a ich wlasna pozycja. Ale to moze wymagac zmiany tego, jak obecnie kalkulowane i przechowywane sa wspolrzedne, na sucho trudno powiedziec.

A co do tej odległości od środka, czy to jest bug OpenGL, czy efekt jakiegoś innego problemu?
To troche kombinacja czynnikow, ale oba sprowadzaja sie do tego, ze liczby typu float maja ograniczona precyzje -- im wiecej liczb po przecinku, tym mniej 'miesci sie' przed przecinkiem, i odwrotnie. Wiec przy obiektach o wspolrzednych kilku- lub kilkunastu tysiecy metrow, precyzja spada wrecz do centymetrow, i to co technicznie jest of siebie odsuniete, zaczyna sie pokrywac. Dodatkowo openGL (ale to nie jest tylko openGL) uzywa tych liczb do okreslenia na jakiej 'glebokosci' zostaly namalowane piksele, co jest uzywane przy decyzji ktore trojkaty zaslaniania inne. Podobnie wiec, wieksza precyzja blisko kamery skutkuje pogorszeniem dla obiektow odleglych. Mozna to troche kontrowac renderowaniem tzn osobno obiekty odlegle, osobno bliskie, albo kombinowaniem z tzw buforem logarytmicznym, ale to sa dodatkowe komplikacje.
« Ostatnia zmiana: 12 Marca 2017, 18:42:00 wysłana przez tmj »

Offline Milek7

  • Administrator
  • Wiadomości: 1047
    • Zobacz profil
  • Otrzymane polubienia: 902
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1245 dnia: 12 Marca 2017, 19:16:35 »
ztcp to depth buffer w opengl jest logarytmiczny

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1246 dnia: 12 Marca 2017, 19:27:10 »
Nie dam glowy ze cos sie pod tym wzgledem nie zmienilo, ale do niedawna przynajmniej skalowanie bylo linearne + troche dodatkowego kombinowania*; gdyby bylo inaczej ludzie nie marnowali by wiele energii zeby temu zaradzic ;)  tutaj jest niezly artykul na ten temat: http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

edit:
*) tutaj jest artykul o szczegolach, i fajny kalkulator ktory demonstruje jak zmienia sie rozdzielczosc w zaleznosci od parametrow bufora, i polozenia obiektu: https://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
« Ostatnia zmiana: 12 Marca 2017, 19:35:30 wysłana przez tmj »

Offline Milek7

  • Administrator
  • Wiadomości: 1047
    • Zobacz profil
  • Otrzymane polubienia: 902
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1247 dnia: 12 Marca 2017, 19:50:39 »
tak, masz rację. miałem tylko na myśli że nie jest całkowicie liniowy tylko wraz z oddalaniem się od znear precyzja maleje. (co właściwie ze względu na to że floaty też tak to jeszcze bardziej pogarsza sprawę przy dalszych obiektach)

Offline HTD

  • Wiadomości: 697
  • "Twoja stara mieszka w Boldach" xD
    • Zobacz profil
    • I like trains
  • Otrzymane polubienia: 30
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1248 dnia: 13 Marca 2017, 07:37:35 »
Ktoś wie co tu się stało? Jechałem sobie dziś na nowym exe scenariusz calkowo_sn61, ale bez SN-61, z racji tego, że popsuta jest. Zamiast tego wziąłem stonkę. I niespodzianka - trasa nagle dostała działającego kierpocia, tak sama z siebie. Nigdy na tej trasie nie słyszałem kierpocia, chociaż ewidentnie sygnał odjazdu jest nagrany. Przez całą trasę rozkład jazdy się przewijał, pomimo tego, że nigdy mi się to nie zdarzało na tej trasie.

Offline Stele

  • Zasłużony dla Symulatora
  • Wiadomości: 10133
    • Zobacz profil
  • Otrzymane polubienia: 2609
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1249 dnia: 13 Marca 2017, 10:16:33 »
Ale tam od jakichś dwóch lat powinien być kierpoć i przewijany rozkład. Robiłem to kiedyś razem z SKP. :D
Mój kanał youtube

Offline Krzysiek626

  • Zasłużony dla Symulatora
  • Wiadomości: 5925
  • EXIT
    • Zobacz profil
    • Krzysiek626
  • Otrzymane polubienia: 443
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1250 dnia: 13 Marca 2017, 11:39:05 »
Ktoś wie co tu się stało?
No to przejechałem na SN61 i też mi się przewija rozkład i mam kierpocia.

Offline HTD

  • Wiadomości: 697
  • "Twoja stara mieszka w Boldach" xD
    • Zobacz profil
    • I like trains
  • Otrzymane polubienia: 30
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1251 dnia: 13 Marca 2017, 13:54:07 »
Ale na starym exe też? Bo mi na starym exe (wersja 482 bodajże) kierpoć nie działał. Później nie testowałem, dziś pierwszy raz odpaliłem to na nowym exe i kierpoć działał. Wyglądało to tak, jakby nowe exe miało poprawionego jakiegoś buga który psuł kierpocia. No albo to jakieś czary.

Offline Krzysiek626

  • Zasłużony dla Symulatora
  • Wiadomości: 5925
  • EXIT
    • Zobacz profil
    • Krzysiek626
  • Otrzymane polubienia: 443
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1252 dnia: 13 Marca 2017, 15:03:07 »
Nie sprawdzalem na exe z pacza, wydaje mi sie ze nie dzialalo. Bedzie chwila sprawdze, calej scn nie musze jechac.
ED:
Na exe 481 coś ze skanowaniem i tabelą jest nie tak, po zakończeniu manewrów w Jarkawkach, w tabeli nie ma stop_info. Nawet AI szamocze się, nie wie czy ma jechać czy stać. Myślę, że to już mało ważny szczegół jest.
« Ostatnia zmiana: 13 Marca 2017, 16:06:28 wysłana przez Krzysiek626 »

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1253 dnia: 13 Marca 2017, 18:28:37 »
Sprawdziłem ten GL_POINT_SMOOTH i to nie to. Niestety camera frustum tutaj psuje. Myślę, ze wprowadziłeś dużo cache misses w tym kodzie i ograniczyło mocno wydajność.
« Ostatnia zmiana: 13 Marca 2017, 18:30:09 wysłana przez firleju »
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1254 dnia: 13 Marca 2017, 19:28:48 »
Sek w tym, ze frustum to jest zaledwie kilka przemnozen zwyklych macierzy 4x4 na ramke, i podobnie ograniczony wplyw przy kalkulacji widocznosci (kilka-kilkanascie mnozen, w porywach kilkadziesiat przy duzej ilosci pojazdow na ekranie) A symulator wykonuje takich operacji na ramke w tysiacach jesli nie dziesiatkach tysiecy, wiec 50% spadek wydajnosci ma tu bardzo malo sensu.

Przyszlo mi do glowy cos innego -- w tym uaktualnieniu eksperymentalnie jest tez wylaczony limit dla kalkulacji fizyki, tzn poprzednio liczone bylo maks. do 20 iteracji, a po zmianie liczy tyle, ile mu wyjdzie. Zastanawiam sie teraz, czy to nie powoduje roznicy przy slabszej wydajnosci, byloby to bardziej sensowne wytlumaczenie. Przywroce w nastepnym uaktualnieniu ugraniczenie i zobaczymy, czy cos sie zmieni.

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1255 dnia: 13 Marca 2017, 19:48:20 »
Ale robisz te dodatkowe obliczenia na danych, które masz aktualnie już użyte (więc są w cache) czy ciągniesz na nowo z ram-u? Jak to drugie to spadek wydajności masz gwarantowany.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1256 dnia: 14 Marca 2017, 11:55:43 »
Przepuscilem exe przez profiler, i wychodzi ze potencjalnie zrodlem spowolnienia moze byc uzycie funkcji glGet do odczytu aktualnego ustawienia kamery; niektore implementacje/sterowniki nie lubia jej bardziej niz inne. Problem w tym, ze na chwile biezaca idealnego rozwiazania tutaj nie ma. Mozna:
- wrocic do tego co bylo, i ignorowac ze modele czasami znikaja kiedy nie powinny
- zostawic jak jest teraz i pogodzic sie ze na niektorych konfiguracjach bedzie wolniej
- wymienic odczyt na kalkulacje parametrow od strony exe. To akurat byloby najlepsze bo praktycznie calkowicie eliminuje koszt (w dodatku i tak trzeba to zrobic przy przejsciu na shadery itp) /ale/ latwo nie da sie zrobic, bo exe bardzo miesza przy renderowaniu widoku z kabiny, i dopoki sie tego nie rozsupla, zwykla wymiana wiecej psuje niz naprawia.

na razie sklaniam sie ku 2 i docelowo 3.

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1257 dnia: 14 Marca 2017, 12:02:23 »
Może glGet raz na ileś klatek (co sekundę?). Przez większą część czasu i tak się kamerą nie rusza specjalnie + zakres widoczności większy niż w rzeczywistości co powinno pomóc na delikatne ruchy.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline tmj

  • Zasłużony dla Symulatora
  • Wiadomości: 3808
    • Zobacz profil
  • Otrzymane polubienia: 2351
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1258 dnia: 14 Marca 2017, 12:41:11 »
Co sekunde to chyba raczej nie (trzeba by sie zaczac bawic w dodatkowe sprawdzanie czy nie bylo przelaczenia widoku np na lusterka itp) ale mozna by sprobowac uaktualniania co kilka klatek, zobaczymy.

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Odp: Exe - konwersja na C++
« Odpowiedź #1259 dnia: 14 Marca 2017, 13:29:03 »
No też wydaje mi się, że jeśli funkcja jest zasobożerna to lepiej jej nie uruchamiać za często.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es