Wiadomości

2461

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 15 Marca 2017, 12:51:39 »

Nie boj zaby, wyswietlanie jest teraz prostsze :) Zamiast bawic sie z glRaster, glPrint itp po prostu dodajesz skonstruowana linie tekstu do panelu i tyle, reszte robi UI.

edit: np wyswietlenie calej starej tabelki skanowania wyglada teraz tak:

Kod: [Zaznacz]

                float4 linecolor( 225.0 / 255.0f, 225.0f / 255.0f, 225.0f / 255.0f, 1.0f );
                int i = 0;
                do {
                    std::string scanline = tmp->Mechanik->TableText( i );
                    if( scanline.empty() ) { break; }
                    UITable->text_lines.emplace_back( Global::Bezogonkow( scanline ), linecolor );
                    ++i;
                } while( i < 16 );


2462

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 15 Marca 2017, 01:36:59 »

Teraz to owszem, dosc czesto maja 16:9/10, ale ekran startowy jest dla starego "dobrego" 1024x768 wiec tego sie trzymamy ;)

2463

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 15 Marca 2017, 01:05:18 »

Ok, blad sie znalazl =)  UI bylo robione przy zalozeniu ze program bedzie dzialal z ekranem o proporcjach 4:3 lub szerszym, a nie wezszym, i w rezultacie kod probowal umieszczac napisy poza kadrem. W uaktualnieniu powinno byc juz w porzadku, a przy okazji powinno byc tez lepsze centrowanie grafiki w czasie ladowania, na tego typu ekranach.

2464

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 23:43:01 »

Obawiam sie ze napisy u mnie dzialaja, wiec trudno wylapac przyczyne. Mozecie podac troche szczegolow ustawien, w rodzaju rozdzielczosc ekranu, okno czy tryb pelnoekranowy itp? Czy napisow nie ma w ogole, czy wyswietla sie tylko panel startowy? Co z napisami dla dzwiekow, jak te ktore pojawiaja sie np w calkowo - niebezpieczny pociag, czy sa widoczne, czy tez ich nie ma?

2465

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 22:43:42 »

W zasadzie powinno, ale to sie samo nie zrobi :)

2466

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 22:09:42 »

Też nie wiem, nie mam żadnych opisów słownych stanu pojazdu, tabeli skanowania ani rozkładów. Testowane na paczce co zwykle.

Czekaj czekaj, a ty masz na mysli panele widoczne w pojezdzie (skanowanie trasy, rozklad itp) czy te alternatywne, ktore wyswietlaja sie na zewnatrz? (pozycja kamery i inne takie) Bo jesli te drugie to faktycznie nie sa chwilowo podpiete.

Ja mam taką sugestię (może zbyt dalekosiężną), aby w przyszłości wprowadzić możliwość skalowania modelu w 3 wymiarach

Ze skalowaniem moze byc klopot, bo modele oprocz wspolrzednych wierzcholkow maja tez wektory normalne opisujace w ktora strone 'skierowany' jest kazdy trojkat, i tutaj skalowanie (zwlaszcza jesli nie jest takie samo we wszystkich wymiarach) potrafi sporo napsuc, i trzeba by to w locie korygowac.

2467

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 22:02:36 »

Ciekawe, u mnie tylko F4, F7 i widać zmianę czasu pod shit+F1. Aż wróciłem do wersji 12b i tam wszystko ok.

Myslalem ze moze to coz co wylazi w trybie pelnoekranowym ale nie, tam tez wszystko u mnie dziala. Byloby latwiej zrozumiec, gdybys w ogole nie mial zadnych paneli, ale jesli nie wlaczaje sie tylko niektore to nie wiem co to moze byc :<

2468

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 21:16:08 »

Chodzi o panel z dodatkowymi informacjami w trybie debug? Powinny byc dostepne po kolejnym wcisnieciu F1, chociaz nie ma na razie wszystkich danych.

2469

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 20:53:49 »

Z cyklu "zaraz mnie cos strzeli..."

Zaczalem pisac zastepstwo dla macierzy opengl. Zrobilem tak z 90% dojechalem do gluLookAt i "przypomnialo mi sie" ze matryca produkowana przez lookAt() nie zastepuje biezacej, ale jest przez nia mnozona. Wiec z ciekawosci odkomentowalem ten nieszczesny kod, ktory wczoraj sie rozlazil, zmienilem foo = glm::lookat() na foo *= glm::lookat() i wszystko poszlo jak trzeba D:

W sumie klasa zastepcza sie nie zmarnuje, bo i tak trzeba by bylo ja kiedys zrobic, ale na razie moge sobie odpuscic konczenie jej, skoro zwykla wymiana wystarcza :d

@Firleju, sprawdz jesli mozesz czy w dzisiejszym uaktualnieniu wydajnosc sie poprawi.

Dodatkowo (zeby nie bylo nudno) wymienilem obsluge UI na cos odrobine bardziej UI-podobnego, z zalozeniem ze ulatwi to dalsza wymiane/podpiecie prawdziwego systemu UI na przyszlosc. Zmiana jest tylko 'pod maska' wiec wizualnej roznicy nie ma, poza ujednoliceniem kolorow. Nie wszystkie panele sa jeszcze przywrocone na 100% ale wiekszosc dziala, ale na oslode jest pasek postepu ladowania scenerii, zamiast dotychczasowych raczej bezuzytecznych komunikatow :P

2470

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 14 Marca 2017, 14:54:35 »

Żeby nie rozgrzebywać kodu można by zachować stos macierzy, tylko napisać klasę z api takim samym jak w opengl i najlepiej użyć GLM do obliczeń.

Sek w tym ze rozgrzebac i tak chyba trzeba bedzie, bo tak jak zauwazyles, shaderom trzeba bedzie podawac macierze do rysowania, a w trybie kabinowym sa robione takie siupy z przesunieciami, rotacja itp ze --jak to mowia-- bez pol litra nie rozbieriosz. Wiec na dluzsza mete chyba lepiej to bedzie uproscic, bo bedzie wylazilo do konca zycia. Glm podpialem do tego recznego liczenia, ale wlasnie na trybie kabinowym polegl (w zewnetrznym jest prawidlowo) Tez sie zastanawialem nad zrobieniem takiego programowego stosu, to bedzie chyba najwygodniejsze podejscie.

Aha, co do freespotow, to oswietlenie torow jest slabe, bo tory chyba nie bardzo maja ustawione wektory normalne. Przy sprzetowych swiatlach jest podobnie, i ja tam oszukuje oswietlajac je skladnikiem ambient dla swiatla ;x

Na ircu to tak chyba z 15 lat nie bylem, za leniwy jestem.

2471

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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.

2472

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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.

2473

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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.

2474

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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

2475

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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.

2476

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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.

2477

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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.

2478

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« 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:

Proszę, zmniejszanie widoczności obiektów kompletnie nic nie daje dla wszystkich współczesnych a nawet dość starych kart graficznych.

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.

2479

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 12 Marca 2017, 01:00:08 »

Aha. Krzak byl gdzies przy skanowaniu tabelki predkosci, wiec na razie odpuszcze sobie tropienie go, bo moze zginie razem z reszta skanowania, gdy Firleju skonczy swoja wersje. Z tego co pamietam to chyba raz mi sie losowo trafil przez caly czas dreczenia exe, wiec wyglada na dosc rzadki/losowy przypadek.

2480

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 12 Marca 2017, 00:03:19 »

W sumie dobra wiadomosc, odpadnie mi szukanie krzaka ;)  Co do teselacji to jesli mozesz, sprawdz najpierw czy na dzisiejszym uaktualnieniu cos sie pod tym wzgledem polepszy/pogorszy? Wymieniony jest kod rysujacy dla kwadratow kilometrowych, ale trudno powiedziec na sucho czy zrobi jakas roznice.

Oprocz tego, wprowadzone zmiany:

- dodany now przelacznik o ktory prosilo pare osob, przygaszanie swiatel lokomotywy. Uaktywniany przez Ctrl+Shift+L, deaktywowany przez Ctrl+L. Pod samym L sa chyba styczniki liniowe, wiec moze byc zabawnie. Nazwa przelacznika w pliku .mmd to dimheadlights_sw Nawiasem mowiac, cala obsluga przelacznikow tez jest do przepisania :x

- zmienilem troche system dynamicznego zwiekszania/zmniejszania detali. Przy fps > 65 symulator stopniowo zwieksza zakres widocznosci obiektow, maksymalnie do 3x wartosci standardowej. Czyli obiekty ze zdefiniowanym zakresem widocznosci do 1km sa teraz widoczne z maks. ~3, a teoretyczny maksymalny zakres widocznosci to 7.5km Biezaca wartosc modyfikatora widoczna jest na ekranie F8.

2481

Na warsztacie / Exe c++ aktualnosci, changelog itp

« dnia: 10 Marca 2017, 17:26:38 »

Wątek tylko dla ogłoszeń deweloperów. Dyskusje i problemy z instalacją w oddzielnych tematach.
Dobra, nikomu innemu sie nie chcialo, to zrobie :P  Dla uproszczenia zycia, podsumowanie zmian w exe konwertowanym na c++ i aktualna paczka instalacyjna.

Instalacja

sciagnac aktualna wersje exe z zalacznika, i umiescic w katalogu symulatora

Zmiany i nowe funkcje

* parser obsluguje cudzyslowy tzn np "foo bar" jest traktowane przy pobieraniu jako jedno slowo

* przy podawaniu nazw tekstur w plikach konfiguracyjnych moga tez byc podane parametry kontrolne dla tekstury, w formacie:

Kod: [Zaznacz]

texturename.ext:traits
gdzie .ext to opcjonalne rozszerzenie nazwy pliku, a :traits to zdefiniowane opcjonalne parametry:
 s (wylacza zawijanie tekstury w 'poziomie')
 t (wylacza zawijanie tekstury w 'pionie')
 # (odpowiednik obecnego # na poczatku nazwy)

* poprawione filtrowanie tekstur. O jakosci filtrowania decyduje wpis w pliku .ini

Kod: [Zaznacz]

anisotropicfiltering X
gdzie X to 1, 2, 4, 8 lub 16. domyslnie przyjmowana jest wartosc 8

* odwrocone klawisze sterowania stanem tylnych swiatel. Teraz ten sam klawisz obsluguje przednie i tylne swiatlo po jednej stronie

* chodzenie w kabinie dziala teraz tak samo jak wszedzie indziej, czyli na podstawie kata obrotu kamery

* dodana funkcja powiekszenia/przyblizenia widoku, dostepna poprzez przytrzymanie srodkowego klawisza myszy

* dodana mozliwosc zmiany obszaru obejmowanego przez kamere symulatora. Regulacja odbywa sie poprzez wpis w .ini

Kod: [Zaznacz]

fieldofview X
gdzie X jest katem widzenia w pionie (wartosc pozioma jest dopasowywana na podstawie stosunku szerokosci/wysokosci okna) Standardowa wartoscia w symulatorze jest 45 stopni, wpisem w .ini mozna to zmienic w zakresie 15-75 stopni.

* w trybie debug regulacji kata widzenia kamery moze tez byc wykonana przy uzyciu klawisza Ctrl i kolka myszki. Aktualna wartosc kata widzenia podana jest na ekranie F8

* bardziej poprawnie kalkulowane oswietlenie cyklu dobowego, i kolorow nieba

* gwiazdy sa standardowym elementem sceny, pojawiaja sie gdy zrobi sie dostatecznie ciemno, nie trzeba wiec ich recznie dokladac do sceny

( dla autorow scenerii: w zwiazku ze zmianami w rysowaniu nieba zalecana jest wymiana w sceneriach obiektu sky_dynamic_stratus na skydome_clouds )

* rozbudowana kontrola uplywu czasu w trybie debug:
 f6: standardowa skala uplywu czasu
 shift+f6: 1 min = 5 min
 ctrl+f6: 1 min = 20 min
 shift+ctrl+f6: 1 min = 1 godz.

 shift + f1: przesuniecie zegara o 5 min
 ctrl + f1: przesuniecie zegara o 20 min

* dodany pod Ctrl+F7 przelacznik w trybie debug, pomiedzy swiatlem kalkulowanym na podstawie aktualnego czasu scenariusza, a stalym swiatlem dziennym

* zmieniona wizualizacja sceny w trybie wireframe (przelaczanym klawiszem F7 w trybie debug)

* dynamiczne oswietlenie sceny przez swiatla lokomotyw, na podstawie odleglosci do kamery i/lub ilosci zapalonych lamp. Ilosc obslugiwanych swiatel jest kontrolowana wpisem w .ini

Kod: [Zaznacz]

dynamiclights X
wartoscia domyslna jest 3, dopuszczalny zakres wartosci to 1-7  W miare wspolczesne karty graficzne nie powinny miec specjalnych klopotow z obsluga 7 zrodel, ale jest to kwestia indywidualnych testow

* zmiana funkcji klawisza F4: teraz po nacisnieciu F4 ladujemy na zewnatrz lokomotywy, mniej wiecej w okolicy drzwi do kabiny ktora zajmowalismy. Do obserwacji scenicznych przejazdow z dystansu jest teraz shift + F4.

* opcja w .ini umozliwiajaca synchronizacje wyswietlania z czestotliwoscia odswiezania monitora

Kod: [Zaznacz]

vsync yes
domyslnie ustawiona na 'no', dla wiekszej czestotliwosci odswiezania w sytuacji gdy generowanych jest mniej niz 60 klatek/sek

* dodany now przelacznik, przygaszanie swiatel lokomotywy. Uaktywniany przez Ctrl+Shift+L, deaktywowany przez Ctrl+L. Nazwa przelacznika w pliku .mmd to dimheadlights_sw

* poszerzony system dynamicznego zwiekszania/zmniejszania detali. Przy fps > 65 symulator stopniowo zwieksza zakres widocznosci obiektow, maksymalnie do 3x wartosci standardowej. Czyli obiekty ze zdefiniowanym zakresem widocznosci do 1km moga byc teraz widoczne z maks. ~3 km, a teoretyczny maksymalny zakres widocznosci to 7.5km

* dodany pasek postepu operacji podczas wczytywania scenariusza

* Dodane nowe parametry dostepne dla modulu pythona:

Kod: [Zaznacz]

linebreaker (stan wylacznika szybkiego)
mainctrl_pos (zazadane ustawienie dla nastawnika glownego)
scndctrl_pos (zadane ustawienie nastawnika dodatkowego)
traction_voltage (wartosc napiecia na pantografach)

* dodana mozliwosc zmiany koloru tekstow interfejsu uzytkownika. Odbywa sie to wpisem w .ini

Kod: [Zaznacz]

uitextcolor R, G, B
gdzie R, G, B to skladowe koloru, w zakresie 0-255

* przekonstruowany nieco rzeczony interfejs uzytkownika. Klawisze F1, F2, F3 maja teraz dwa tryby, orientacyjny i poszerzony, przelaczane kolejnymi nacisnieciami klawisza. W trybach tych podawane sa:
f1: stan nastawnikow i hamulcow, w trybie poszerzonym takze predkosc, ograniczenia i cisnienie hamulcow
f2: nastepna stacja, w trybie poszerzonym takze rozklad (dotychczas dostepne pod f3)
f3: wszystkie "flaki" pojazdu, w trybie poszerzonym takze tablica skanowania (dotychczas dostepne pod f2)

* dodane aureole dla punktow swietlnych

* dodany parametr zachmurzenia sceny. Na chwile obecna jest to opcjonalny parameter typu float w sekcji atmo pliku .scn, o wartosci miedzy 0 i 1  Niebo 'zachmurzone' jest bardziej monochromatyczne, i redukuje efekt jaki w oswietleniu ma slonce -- swiatlo sceny jest rozlozone bardziej rownomiernie

* przeorganizowane troche klawisze obslugi hamulcow:
- hamulec lokomotywy jest teraz w calosci na lewej kolumnie klawiatury numerycznej (7 zmniejszenie, 1 zwiekszenie, 4 odluzniacz)
- hamulec pociagu jest podobnie na jednej kolumnie klawiatury numerycznej (9 zmniejszenie, 3 zwiekszenie, 6 pozycja jazdy)
- poniewaz te dwie kolumny maja organizacje 'gorny klawisz = mniejsza sila hamowania, dolny klawisz = wieksza sila' kolumna srodkowa dziala teraz podobnie, tzn sila hamowania zwieksza sie idac po kolei klawiszami 8 -> 5 -> 2

* przeorganizowane troche klawisze obslugi swiatel:
- swiatla glowne na obsadzonym koncu lokomotywy przelaczane sa klawiszami Y, U, I
- swiatla czerwone na obsadzonym koncu lokomotywy przelaczane sa kombinacja Shift+Y i Shift+I
- aby przelaczyc swiatla na drugim koncu lokomotywy uzywamy powyzszych kombinacji lacznie z klawiszem Ctrl

* oprocz klawiatury symulator obsluguje tez gamepad. Jak na razie kontrola gamepadem jest tylko dla funkcji najbardziej podstawowych:
-- prawy drazek do rozgladania sie
-- lewy drazek ma dwie funkcje. W trybie podstawowym sluzy do chodzenia. Natomiast przy wcisnietym jednym z podstawowych klawiszy, sluzy do kontroli podstawowych urzadzen:
--- przycisk A + gora/dol: kontrola glownego nastawnike (gora: zwiekszenie, dol: zmniejszenie)
--- przycisk B + gora/dol: kontrola hamulca pociagu (dol: zwiekszenie sily hamowania, gora: zmniejszenie)
--- przycisk Y + gora/dol: hamulec lokomotywy (dol: zwiekszenie sily hamowania, gora: zmniejszenie)
--- przycisk X + gora/dol: nastawnik boczny (gora: zwiekszenie wartosci, dol: zmniejszenie)

* obsluge gamepada mozna wylaczyc poprzez wpis w pliku .ini

Kod: [Zaznacz]

input.gamepad no
moze to byc konieczne w przypadku konfiguracji z podlaczonym kontrolerem PoKeys (przynajmniej dopoki w exe nie ma pelnej konfiguracji dla gamepada)

* poruszanie sie ma tylko dwie predkosci, normalna (klawisze kursora) i "bieg" (shift + klawisze kursora)

* w trybie debug poruszanie jest przyspieszone: normalne odpowiada predkosci 'bieg' z trybu zwyklego, a bieg w trybie debug jest... szybszy.

* dodano obsluge dla wiecej niz jednego pliku logowania. Uaktywniana jest wpisem w .ini

Kod: [Zaznacz]

multiplelogs yes
Jesli opcja jest aktywna, symulator zamiast plikow log.txt i errors.txt tworzy w katalogu logs odrebne pliki dla kazdego uruchomienia/scenariusza, nie nadpisujac starych.

* dodana obsluga przycisku opuszczenia wszystkich pantografow (w kabinach wyposazonych w taki wihajster, czyli wpis pantalloff_sw w pliku .mmd z przypisanym sub-modelem), na ta chwile pod kombinacja Ctrl + P

* dodana obsluga dedykowanego przycisku opuszczania tylnego pantografu, pantrearoff_sw do pary z juz istniejacym wylacznikiem pantografu przedniego.

* dodana obsluga przyciskow podnoszacych/opuszczajacych pantografy wybrane przy pomocy odrebnego przelacznika/zaworu, pantselected_sw: i pantselectedoff_sw:  Wspomniany odrebny przelacznik nie jest jeszcze zaimplementowany, tymczasowo obsluga kabiny z nowym typem przyciskow odbywa sie uzywajac standardowych kombinacji klawiszy obslugi pantografow.

* rozszerzona obsluga tekstur wymiennych: dla modeli uzywajacych kilku tekstur wymiennych (uaktywnianych dodaniem znaku # po nazwie modelu w pliku .mmd) przy umieszczaniu modelu w scenie zamiast nazwy tekstury bazowej mozna tez podac liste nazw tekstur, rozdzielonych znakiem "|" Czyli np zamiast wpisu

Kod: [Zaznacz]

node -1 0 nazwa_pojazdu dynamic katalog nazwa_tekstury (...)
ktory instruuje exe by szukac tekstur "nazwa_textury,1" "nazwa_tekstury,2" "nazwa_tekstury,3" itp mozna podac wpis

Kod: [Zaznacz]

node -1 0 nazwa_pojazdu dynamic katalog teksturaA|teksturaB|teksturaC|teksturaD (...)
co spowoduje przypisanie do modelu tekstur "teksturaA", "teksturaB", "teksturaC" itd. Mozna definiowac w ten sposob do czterech tekstur (trzech, jesli model ma obslugiwac takze wymienna teksture tablic rozkladu)

* dodana obsluga konfiguracji klawiszy

na razie obejmuje tylko obsluge pojazdu, bo reszta nie jest jeszcze podpieta pod nowy system. Przypisania klawiszy przechowywane sa w pliku "eu07_input-keyboard.ini" (plik tekstowy, moze byc edytowany np. notatnikiem) Kazda linia pliku definiuje jeden klawisz, np

Kod: [Zaznacz]

pantographlowerall ctrl p // opuszczenie wszystkich pantografow
pierwsze slowo to nazwa komendy i tego nie ruszamy; nastepnie podany jest klawisz do ktorego ma byc przypisana, i opcjonalne modyfikatory shift i/lub ctrl  Komentarze tlumacza, ktora komenda jest do czego, zeby latwiej sie bylo polapac.

* obsluga odrebnych przyciskow aktywacji tonow syreny, hornlow_bt i hornhigh_bt Zalaczane sa tymi samymi klawiszami co zwykla dzwignia. Uwaga: oba przyciski maja zakres animacji (0, 1) w odroznieniu od 'starej' dzwigni gdzie animacja niskiego tonu miala zakres (0, -1)

* rozdzielone dzialanie przyciskow kontroli syreny, aktywacja tonu wysokiego nie wylacza niskiego, i odwrotnie. Aby uniknac blednego zapetlania sie dzwiekow aktywacja tonu wysokiego zostala przeniesiona domyslnie pod klawisz S (kontrola piasecznicy jest teraz domyslnie pod Shift+S, a przelacznik blokady drzwi pod Ctrl+S)

* dodane do .fiz: parametr AirLeakRate w sekcji Brakes: definiuje predkosc wycieku powietrza z ukladu hamulcowego. Wartosc nominalna to 1.0 wiec np wartosc 1.5 spowoduje 50% szybszy wyciek. Nie nalezy przesadzac ze zwiekszeniem parametru, bo wartosci rzedu 5+ moga doprowadzic do sytuacji gdzie sprezarka lokomotywy nie nadazy z produkcja. Przy standardowej wartosci 1.0 wycieki sa na poziomie zalaczania sprezarki co 5-15 min czasu symulacji, zaleznie od rodzaju i dlugosci skladu.

* dodane do .fiz: parametr ConverterStart w sekcji Cntrl: okreslajacy metode obslugi przetwornicy -- domyslnie (wartosc Manual) przetwornica sterowana jest recznie. Jesli wartosc parametru ustawiona jest na Automatic przetwornica wlacza sie automatycznie po zamknieciu wylacznika szybkiego.

* dodane do .fiz: parameter ConverterStartDelay w sekcji Cntrl: okreslajacy (w sekundach) opoznienie, z jakim uruchamia sie przetwornica po zamknieciu wylacznika szybkiego. wartosc domyslna to 0, czyli brak opoznienia.

* dodany nowe przelaczniki, kontrolujace prace przetwornicy i sprezarki tylko dla obsadzonego czlonu. Uaktywniane przez Shift+X (przetwornica) i Shift+C (sprezarka). Nazwa przelacznikow w pliku .mmd to converterlocal_sw i compressorlocal_sw

* wylacznik stycznikow liniowych moze byc obslugiwany jako bistabilny, a nie tylko impulsowy jak dotychczas. Tryb bistabilny uaktywnia sie wpisem MotorConnectors=Toggle w sekcji Switches: pliku .fiz

* zmiana w systemie wizualizacji, eliminujaca z-fighting i inne nieciekawe efekty zbyt niskiej precyzji liczb zmiennoprzecinkowych pojawiajace sie w miare oddalania od "srodka" mapy

* po zatrzymaniu sygnalem radio-stop AI potrafi teraz skasowac otrzymany sygnal poprzez wylaczenie/zalaczenie radia, zamiast stac w polu i tylko bezskutecznie dusic odluzniacz

* uruchomiona obsluga parametru grubosci linii dla elementow scenerii typu "lines" itp

* indywidualne oswietlenie dla sekcji modelu uproszczonego wnetrza. Submodele z nazwami w formacie corridorXX lub korytarzXX (gdzie XX to liczba of 00 do 99, czyli np korytarz00) sa klasyfikowane jako korytarze/przedsionki. Submodele z nazwami w formacie compartmentXX lub przedzialXX sa klasyfikowane jako przedzialy. Oswietlenie w sekcji jest zalaczane gdy spelnione sa wszystkie ponizsze warunki:
- na zewnatrz jest dostatecznie ciemno (definiowane jak dotychczas parametrem self illum)
- pojazd jest w skladzie z pojazdem prowadzacym, ktory ma zalaczony akumulator (co jest uproszczona metoda sprawdzenia, czy pojazd prowadzacy jest aktywny)
- dla przedzialow oswietlenie zalaczane jest z 75% szansa, okreslana w momencie spelnienia poprzednich warunkow, dla korytarzy oswietlenie zalaczane jest z szansa 100%

* aktywowana obsluga parametru sily odblaskow swiatla (specular highlights) dla modeli 3d. Poniewaz parametr poprzednio obslugiwany nie byl, wiekszosc modeli ma go ustawiony na cos w stylu (150, 150, 150) wartosc ta jest zazwyczaj zbyt wysoka dla materialow innych niz takie, ktore swiatlo odbijaja doskonale (szyby, wypolerowany metal)  W zwiazku z tym domyslnie exe modyfikuje podana wartosc parametru specular do 25% wartosci dla geometrii nieprzezroczystej, i 150% podanej wartosci dla geometrii polprzezroczystej, ktora w zalozeniu powinny byc wylacznie szyby itp. Mechanizm skalowania kontrolowany jest wpisem w ini

Kod: [Zaznacz]

scalespeculars (yes)/no

* dodana obsluga urzadzen kabiny przy uzyciu myszy. Do przelaczenia trybu pracy uzywany jest klawisz Alt. W trybie obslugi mysza kamera pozostaje nieruchoma a zamiast niej porusza sie kursor, ktorym mozna aktywowac urzadzenia. Dla wiekszosci urzadzen do aktywacji sluzy lewy przycisk, w przypadku urzadzen jak nastawnik, hamulec lub wielopozycyjne pokretla lewy przycisk przestawia urzadzenie 'do przodu' zas prawy 'do tylu'. Operowanie mysza elementami takimi jak nastawnik i hamulec odbywa sie tym szybciej, im dalej odsuniemy mysz od punktu w ktorym byla w momencie wcisniecia. W standardowym trybie pracy symulatora kursor myszy podswietla jedynie urzadzenia zdefiniowane w pliku .mmd, podajac ich ujednolicone nazwy. W trybie debug podswietlane sa wszystkie czesci kabiny, a zamiast nazw ujednoliconych wyswietlane sa nazwy submodeli.

* w trybie ruchu poza kabina pojazdu, gdy wlaczony jest debug mode i aktywowany jest tryb obslugi mysza, symulator wyswietla nazwy obiektow scenerii wskazanych mysza, o ile dany obiekt ma nazwe zdefiniowana w pliku .scn.

* liczba elementow typu "universal" zostala zwiekszona do 10. Definiowane sa w pliku .mmd jak dotychczas wpisami "universal0:", "universal1:" itp. az do "universal9:" Obsluga tych elementow zostala zunifikowana I uproszczona do przelaczania miedzy dwoma stanami, i wywolywana jest za posrednictwem myszy, lub klawiszami 0-9

* dodane przelacznik oswietlenia urzadzen jako dedykowany element kabiny. Definiowany jest wpisem instrumentlight_sw: a element 'oswietlajacy' ma definicje i-instrumentlight: i-instrumentlight_M: lub i-instrumentlight_C: zaleznie od typu zasilania.

* rozszerzona obsluga definiowania dzwiekow aktywacji urzadzen w kabinie pojazdu. nowa skladnia wyglada tak:

Kod: [Zaznacz]

mainctrl: { nastawnikpodst rot -0.02 0.0 0.15 soundinc: nastawnikdoprzodu.wav, sounddec: nastawnikdotylu.wav, sound17: nastawnikpozycja17.wav }
parametry dzwieku podawane sa w formacie klucz: nazwadzwieku.wav
rozpoznawane klucze to:
- soundinc: dzwiek odgrywany gdy urzadzenie przestawiane jest na pozycje 'nastepna' czyli np przestawienie nastawnika do przodu, zalaczenie przycisku, otwarcie szafki itp
- sounddec: dzwiek odgrywany gdy urzadzenie przestawiane jest na pozycje 'poprzednia' czyli np przestawienie nastawnika do tylu, puszczenie grzyba, zamkniecie okna itp.
- soundX: dzwiek odgrywany gdy urzadzenie ustawione jest na konkretna pozycje X wiekszosc przyciskow ma tylko dwie pozycje, "0" i "1" ale np nastawniki maja tyle pozycji, ile pozycji ma nastawnik Ilosc wpisow soundX dla danego elementu jest w zasadzie dowolna

* dzwieki moga byc tez przypisane do kontrolek. skladnia jest taka sama jak dla przelacznikow, ale jako ze lampki maja tylko stan zalaczony i wylaczony, rozpoznawane sa tylko klucze soundinc: i sounddec:

* dodane generowanie cieni obiektow na podstawie biezacej pozycji Slonca. Funkcja domyslnie wylaczona wlaczona, uaktywniana jest wpisem w .ini

Kod: [Zaznacz]

shadows yes

* jakosc generowanych cieni moze byc regulowana wpisem w .ini

Kod: [Zaznacz]

shadowtune 2048 250 250 500
gdzie poszczegolne wartosci to: rozdzielczosc generowanych cieni (wartosci rozsadne to 1024-4096), parametr (tymczasowo) nieuzywany, wielkosc obejmowanego cieniami obszaru (w metrach) i kolejny parametr (tymczasowo) nieuzywany

* kraglosc generowanych torow i drog mozna teraz zwiekszyc wpisem w .ini

Kod: [Zaznacz]

splinefidelity X
gdzie X to wartosc w przedziale 1-4. domyslnie przyjmowana jest wartosc 1, wartosci wyzsze zwiekszaja 'jakosc' generowanej geometrii

* poniewaz rozbudowany w exe silnik graficzny moze miec zbyt wysokie wymagania jak na mozliwosci starszych komputerow, istnieje mozliwosc wymuszenia uzycia dotychczasowego, uproszczonego silnika. Odbywa sie to przez wpis w .ini

Kod: [Zaznacz]

gfxrenderer simple

* dodana funkcja "recznego" uruchomienia procedury radiostopu w obsadzonym pojezdzie; domyslnie wywolywana kombinacja Shift+Ctrl+R

2482

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 11 Marca 2017, 22:27:43 »

Nie, to inny blad :)  Zeby bylo smieszniej, ten sam ktory trafil sie Stele kilka postow wyzej. Czy to moze tez na tym nowym Quarku? Nie bardzo wiem skad sciagnac, wiec trudno sie przyjrzec.

przyduże trójkąty terenu nadal znikają jak znikały.

Trojkaty terenu to inna czesc kodu do rysowania, probowalem sie temu dzisial przyjrzec, ale tylko na placz mi sie zebralo :|  okazuje sie ze teren jest teoretycznie podzielony na segmenty, ale co akurat w segmencie laduje, a co poza nim, to juz zupelnie inna bajka, i bez przepisania w zasadzie od nowa nie wiem, czy sie kiedykolwiek wyprostuje. Tyle dobrego, ze przy okazji zerknalem na zwiekszanie zakresu rysowania w zaleznosci od fps, ale moglo byc wiecej.

2483

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 11 Marca 2017, 21:30:52 »

Ok, ale commit ma polaczone zmiany kalkulacji widocznosci i wygladzanie punktow, natomiast w uaktualnieniach wydanych w watku bylo to podzielone -- kalkulacja widocznosci weszla w 3.08, a wygladzanie punktow w 3.09  Dlatego specjalnie pytam, czy jest jakas roznica w wydajnosci, przy porownaniu tych dwoch exe, bo moze latwiej da sie w ten sposob wylapac, co sprawia u ciebie problem.

(albo mozesz po prostu w world.cpp wykomentowac

Kod: [Zaznacz]

glEnable( GL_POINT_SMOOTH );
i porownac, jesli tak jest prosciej ;d

2484

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 11 Marca 2017, 19:20:31 »

Hmm troche dziwnie. Jesli to nie problem, moglbys jeszcze sprawdzic wydajnosc na 03.08? W 09+ wlaczone zostalo wygladzanie punktow, i moze akurat to gryzie sie ze starszym sprzetem.

2485

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 11 Marca 2017, 10:40:57 »

Tak tez wlasnie podejrzewam, ze chyba jest wlaczony. @Firleju, sprawdz na ostatniej wersji (0311) tam jest wylaczony domyslnie, albo wpisz vsync no w .ini?

2486

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 10 Marca 2017, 22:30:51 »

Dzieki, mniej wiecej tyle ustawilem, czyli moze dobrze bedzie.

Jak w ini na 0, to jak to się ma do suwaka w rainsted, gdzie jest priorytet. Nie wspomnę o ustawieniach sterownika karty graficznej bo tam priorytety można nadać.

Rainsted chyba ustawia ten sam parameter, tylko wyswietla wartosc 0 jako "1" itd. Jak to sie ma do ustawien karty to nie wiem, bo to chyba zalezy tez w czesci od oprogramowania karty -- np NVidia ma w opcjach odrebne ustawienia "popraw jesli exe ustawia mniej" i "ustaw tyle, i niewazne czego chce exe".

2487

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 10 Marca 2017, 21:17:44 »

Zrobiłem update do najnowszej wersji i niestety, w przeciwieństwie do reszty zanotowałem spadek FPS o 50% na integrze intela. Wygląda, że na stałe włączone jest wygładzanie krawędzi.

Tzn. multisampling? To sie chyba da wylaczyc przy ustawieniu parametru w .ini na 0 albo jakos tak. Ale nie probowalem.

2488

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 10 Marca 2017, 20:02:46 »

No ja wlasnie mam watpliwosci czy to jest cos do zostawienia w rekach zwyklego uzytkownika ;)  ale mozna zmienic, zobaczymy.

edit: aha, a tak zupelnie z innej beczki. Przelacznik przyciemnienia reflektorow, na ile to w rzeczywistosci przyciemnia swiatla? O polowe, mniej, wiecej?

2489

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 10 Marca 2017, 19:57:53 »

Czemu tylko w debugu? Jak nie sprawia problemów, to w podstawowym też by się przydało, zwłaszcza jak rewizja pozycji kamer nastąpiła.

ZTCP to rolka jest przez niektorych uzywana do kontroli nastawnika itp, wiec wolalbym tutaj za bardzo nie mieszac. To i tak prowizorka do czasu gdy bedzie normalny ekran z ustawieniami, ktory powinien przejac tego typu sprawy. (a przelaczyc debug na szybko ctrl+shift+f12 to chyba tez nie taki straszny problem)

2490

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 10 Marca 2017, 17:31:17 »

Nowe uaktualnienie w nowym watku ( http://eu07.pl/forum/index.php/topic,28920.0.html ) zeby nie trzeba sie bylo przekopywac przez 40 stron. W zasadzie bez zmian od wczoraj, oprocz dodanej mozliwosci zmiany FoV przy uzyciu Ctrl + kolko myszy, w trybie debug. Aktualna wartosc FoV jest tez w tym trybie wyswietlana na ekranie F8, powinno ulatwic dobranie wartosci do indywidualnych preferencji itp.