Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - tmj

Strony: 1 ... 24 25 [26] 27 28
751
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 23 Marca 2017, 12:47:27 »
W przypadku EU07 bledem jest to, ze sciana wnetrza low poly zwyczajnie nie ma chyba wycietego srodkowego okna po prawej stronie. Wiec patrzac z lewej na prawo widzisz lita sciane. Z prawej na lewo widac jak trzeba, bo tam okno zostalo wyciete.

edit: co do przedsionka en57-2000 zaslaniajacego elementy przezroczyste, patrzac na szybko, to bierze sie z chyba tego ze te przedsionki sa wspawane w pudlo i renderowane razem z pudlem, w trakcie rysowania obiektow dynamicznych, a nie jako "kabina na samym koncu) Gdyby wszystko bylo zaaranzowane poprawnie to nie przeszkadzaloby to specjalnie -- obiekty przezroczyste powinny byc renderowane od najdalszych do najblizszych -- ale zdaje sie exe robi to dosc srednio, i np druty itp rysowane sa na koncu. Czyli w tym wypadku po tym, jak narysowane zostalo pudlo z przedsionkami, a na tym etapie karta graficzna stwierdza ze nie warto rysowac drutow ktore z jej punktu widzenia "zasloniete" sa sciana przedsionka ktory z jej punktu widzenia przezroczysty nie jest.

edit2: do pewnego stopnia blad drzwi mozna usunac, poprawiajac maske alfa tekstury pojazdu -- na etapie obiektow z przezroczystosciami exe traktuje jako "nieistniejace" wszystko oteksturowane z wartoscia kanalu alpha 10/255 lub mniejsza. Szyby przedsionka EN57 sa minimalnie "mniej przezroczyste" i jako takie sa renderowane.

752
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 22 Marca 2017, 23:42:02 »
Cytat: queuedEU w 22 Marca 2017, 23:04:35
Ale czemu one nie sa zrobione na glPoint()? glPoint() mozna kontrolowac, rozmiar, zanikanie i inne i moze byc ich s dziesiatki tysiecy a FPS nie spadnie. Wiem bo snieg mialem na trzech typach obiektow do wyboru - glTriangle(), glLine i glPoint i ten ostatni pozwalal nawet na kilka set tysiecy platkow przy malym spadku FPS.
- nie trzeba bawic sie z recznym skalowaniem wymiarow na podstawie odleglosci
- bardziej przyjazne dla starego sprzetu, nie wiem jak wyglada teraz obsluga 'punktow' wielkosci 200-300 i wiecej pikseli, ale kiedys raczej nie bylo z tym rozowo
- widocznosc point sprites jest okreslana na podstawie widocznosci punktu centralnego. czyli np w ujeciu jak na zalaczniku aureola po prawej zostalaby obcieta
- spadek fps spowodowany byl obliczaniem punktu centralnego przez wyciaganie matrycy modelview dla kazdego punktu (co jest swoja droga kiepskim rozwiazaniem, ale w kodzie nie ma chyba kalkulacji pozycji poszczegolnych submodeli, ani w ogole danych dla poszczegolnych egzemplarzy, wszystko jest robione w oparciu o pozycje modelu bazowego i matrix push/pop 'w locie' dla poszczegolnych elementow) Czyli samo zastosowanie punktow nie zmieniloby wydajnosci -- co zreszta latwo sprawdzic, podstawowe spotlights to sa glPoints wlasnie, i przy starym kodzie kalkulacje ich pozycji mialo zauwazalny efekt na ogolnej wydajnosc, nawet gdy punktow nie bylo wiecej niz 50-100 :d

Natomiast do rzeczy takich jak snieg czy inne tego typu czasteczki to jak najbardziej. Na upartego aureole tez mozna pozniej przerobic praktycznie w calosci na shader, jak juz beda.

753
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 22 Marca 2017, 23:02:53 »
Cytat: Krzysiek626 w 22 Marca 2017, 22:59:42
Na TD mam taki widok, na Kaliskiej i Bałtyku jest ładnie. Widoczność tej zjawy zależy od kąta patrzenia. W każdym razie z kabiny widać. Na razie taki efekt jest tylko na TD, jeśli gdzieś jeszcze znajdę, dopiszę.
Ten efekt pojawia sie, gdy exe nie uda sie zaladowac tekstury aureoli. Zobacz czy cos tam nie stalo sie z plikiem w folderze textures/fx bo normalnie nie powinno sie to zdarzyc :)

754
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 22 Marca 2017, 21:39:40 »
Przy okazji grzebania w kodzie rzucil mi sie w oczy komentarz przy swiatlach punktowych...
Kod: [Zaznacz]
// dorobić aureolę!
No to dorobilem. Efekt nawet ok, ale ze kalkulacje robione byly z wykorzystaniem glGet() to wydajnosc na wiekszych stacjach spadla o jakies 25% co, biorac pod uwage ze efekt nie jest az tak dobry, bylo zdecydowanie zbyt wysoka cena. Podpialem wiec skonczone "wirtualne matryce" dla openGL, zeby sie pozbyc odwolan do glGet() i teraz zamiast spadku o 25% mamy jakas ~10% poprawe wydajnosci (bo odciazylo to tez stary kod rysujacy punkty swietle) przy wlaczonych aureolach. Efektow ubocznych byc nie powinno, ale wiadomo jak to jest w praktyce :s

tl,dr: powinno byc troche szybciej, i troche ladniej.

(aureole uzywaja tekstury nazwanej lightglare i umieszczonej w katalogu textures/fx Na ta chwile exe nie pozwala definiowac tekstur dla swiatel punktowych, ani wymiarow aureoli, kiedys moze sie to zmieni)

edit:
aha, aureole uzywaja definicji koloru swiatla punktowego, w rezultacie swiatla semaforow zrobily sie bardziej zolte niz pomaranczowe, bo taki jest kolor zdefiniowany dla punktow w tych komorach. Ktos sie bedzie musial poswiecic i je wreszcie poporawiac :d

755
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 22 Marca 2017, 11:20:54 »
To moze szybciej by wyszlo od razu przeprojektowac jak zorganizowane sa tory zastapic eventy czyms normalnym, skoro i tak trzeba to zrobic ;)

756
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 19 Marca 2017, 19:16:56 »
Planowalem poprawiac cos innego ale dobra, nowe uaktualnienie jest w ramach koncertu zyczen :P

- Dodane nowe parametry dla 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)

- brak czcionek jest teraz przez exe ignorowany, zamiast na twardo zamykac program

757
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 19 Marca 2017, 12:45:11 »
Cytat: jakubg1 w 19 Marca 2017, 11:25:39
Exe w nowej wersji w końcu się uruchomiło. Niestety nie czekałem na rozczarowanie długo, po ułamku sekundy symulator się wyłączył. W logu znalazłem coś takiego:
Kod: [Zaznacz]
Font init failed
Domyślam się, że nie mam jakiejś czcionki. Log i errors w załączniku.
PS. Zaznaczenie "Napisy z GLUT32.DLL" nie rozwiązuje problemu.
Uzywana czcionka jest wbudowana w kazdy windows chyba od xp w gore, wiec powinna byc :)  byc moze jest to wina karty Ati -- o ile dobrze rozumiem, to w przeszlosci byly problemy z wyswietlaniem czcionek przez display list na tych kartach. Myslalem ze moze zostalo to w miedzyczasie naprawione w sterownikach, ale mozliwe ze nie. Zrobie tutaj zmiane, zeby brak czcionki byl traktowany raczej jak niedogodnosc, a nie blad -- napisow nie bedzie (przynajmniej do czasow normalnego UI) ale reszta powinna dzialac.

Cytat: HTD w 19 Marca 2017, 09:52:28
Pytanie, czy jest w planach dodanie wyświetlania bieżącej prędkości i parametrów lokomotywy w trybie gracza? Chodzi mi o typowo użytkowy widok, jak w komercyjnych symulatorach pociągów typu Trainz / MSTS.
Nie bylem pewien, czy jest to cos co opinia publiczna chcialaby miec dodane, bo to podobno powazny symulator jest, a nie zabawka jak tamte ;)  Dodac ekran jak najbardziej mozna, zdecydujcie sie tylko czy i co powinno sie na nim znalezc.

758
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 17 Marca 2017, 13:20:28 »
Cytat: AtapiCl w 17 Marca 2017, 00:35:45
EDIT: Po różnych walkach mam wrażenie, że symulator sobie nie radzi z tak dużą scenerią.

No widzisz, ale gdyby tak rzeczywiscie bylo, to te same efekty bylyby tez obserwowane przez innych. A tymczasem na roznych innych komputerach, w tym moim, sceneria obslugiwana jest normalnie. Z tym ze rzeczywiscie Kaliska /jest/ duza -- to jest ~1.2-1.3 gb zajetej pamieci na sam simulator wiec mozliwe ze na slabszych konfiguracjach i/lub przy zaladowanych innych programach moga zaczac pojawiac sie klopoty. Podobne ograniczenie dotyczy karty graficznej -- przepisany symulator zuzywa wiecej pamieci na kazda teksture, wiec moze jej zaczac brakowac szybciej niz na starym exe (zobacze czy da sie tutaj wprowadzic jakies ulepszenia, ale na razie jest jak jest)

Niestety, te crashdumpy generowane przy wymuszonym zamknieciu okna raczej nie pomoga, bo wyskakuja wtedy z innej przyczyny -- aplikacja jest zmuszona by sie zamknac i robi to troche "nie po kolei", probujac np zwalniac zasoby ktorych juz nie ma. Czyli to akurat nie pomoze w dojsciu, co tam u ciebie idzie nie tak :/

edit:
OK, w dzisiejszym uaktualnieniu mamy:
- poprawiony blad ciaglego syczenia w sytuacji, gdy symulator byl uruchamiany z zalaczona pauza.
- przywrocone roznicowanie oswietlenia w tunelach, wykopach itp. Tutaj uwaga, efektem ubocznym jest ponowne dzialanie swiatel 'zawsze', by prowizorycznie umozliwic oswietlanie tuneli itp bez skomplikowanej zabawy w skanowanie torow naprzod by sprawdzic, czy jest tam tunel itp.
- nie pamietam czy naprawa falownikow zmiescila sie w poprzednim uaktualnieniu, czy jest w tym, ale tak czy owak tez powinny dzialac

W sumie oznacza to, ze stan uzywalnosci jest teraz z grubsza taki jak starego exe. Oprocz kierowcow-samobojcow, ale zeby wyciac tamten krzak potrzebny jest tor testowy. Wiec ten blad bedzie usuniety kiedy tor sie pojawi (albo kiedy zaimplementujemy w symulatorze edycje z poziomu exe, bo raczej nie widze mozliwosci ze sobie sam taki tor inaczej wyprodukuje :d

759
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 16 Marca 2017, 16:22:55 »
Jeszcze nie patrzylem. Aha, zapomnialbym, w tym ostatnim uaktualnieniu jest jeszcze:
- klawisz Esc pauzuje symulacje rowniez w trybie debug
- w trybie debug klawisz F1 pokazuje informacje dla najblizszego pojazdu, zamiast byc na sztywno przywiazanym do tego, ktory kontrolujemy.

760
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 15 Marca 2017, 19:01:52 »
OK, w dzisiejszym uaktualnieniu mamy skonczone w 95% przenosiny paneli UI. Ostatnie 5% to dodatkowa tabelka w trybie debug dla traxxa itp. Czy ktos tych danych potrzebuje/uzywa?
Aha, i mamy drobna zmiane w nazwie pliku exe, bo po skompilowaniu wersji 64 bit jakos trzeba je bylo odroznic :P

(wersja 64bit wymaga troche innych bibliotek, wrzuce paczke do watku zbiorczego za moment)

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

762
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


763
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 12 Marca 2017, 18:07:37 »
Cytat: HTD w 12 Marca 2017, 17:56:23
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.

764
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:
Cytat: Siecool w 12 Marca 2017, 13:09:10
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.

Cytat: Krzysiek626 w 12 Marca 2017, 08:11:10
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.

765
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 12 Marca 2017, 12:54:05 »
Cytat: HTD w 12 Marca 2017, 07:51:04
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.

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

767
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

Cytuj
* 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

768
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 10 Marca 2017, 22:30:51 »
Dzieki, mniej wiecej tyle ustawilem, czyli moze dobrze bedzie.

Cytat: Krzysiek626 w 10 Marca 2017, 21:20:44
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".

769
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 10 Marca 2017, 02:09:45 »
Dodalem przelacznik oswietlenia pod Ctrl + F7 w trybie debug. Przelacza miedzy standardowa, dynamiczna kalkulacja oswietlenia, i stalym polozeniem slonca tak, jakby byla godzina 10:30. Stan przelacznika widoczny jest na ekranie F2 (poza pojazdem) jako (*) obok parametru Light Level.

Z wiekszych, ale mam nadzieje niewidocznych zmian czesciowo rozgrzebany jest kod renderujacy grafike. Konkretnie, funkcje renderujace wycinane sa z obiektow i przenoszone do jednego modulu, zamiast obecnego rozwloczenia po calym exe. Jesli wszystko poszlo dobrze, to nie powinno to produkowac zadnych wizualnych krzakow (poza tymi znanymi do tej pory :d) ale jesli ktos zauwazy cos nie tak, prosze krzyczec.

770
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 09 Marca 2017, 18:47:06 »
Obie wersje sa fajne, ale zastanawiam sie, czy nie byloby praktyczniej zeby stacje byly posortowane razem z pozostalymi elementami, ale zaznaczone tym zoltym kolorem? W ten sposob nie trzeba sie zastanawiac, w ktorym miejscu sie znajduja w stosunku do pozostalych skanowanych elementow... ale nie znam sie, wiec moze z punktu robienia tras itp taka wiedza nie jest do niczego potrzebna :)

771
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 09 Marca 2017, 13:40:44 »
Cytat: Krzysiek626 w 09 Marca 2017, 13:35:22
ciekawe, czy było to do uzyskania w Borlandzie?
O ile sie nie myle to ten ostatnio odkryty krzak z kalkulacja zakresu widocznosci siedzial sobie w oryginalnym exe od niewiadomo kiedy, a usuniecie nie wymagalo zadnych nowosci c++ wiec potencjalnie mozna by przyspieszyc renderowanie w wersji Borlandowej o ~50% wprowadzajac ta jedna poprawke i rekompilujac. Natomiast wczytywanie itp, to juz raczej zasluga nowszych kompilatorow i lepszej optymalizacji ktora wykonuja. Tego Borland raczej nie nadrobi.

772
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 09 Marca 2017, 00:15:55 »
Cytat: CX MANIAK w 08 Marca 2017, 21:44:35
Czyli uruchomiać bez ptaszka przy VBO.
VBO jest na chwile obecna nie ruszane, jako ze jest dosc niekompletne. Srednio-dystansowy plan jest taki, ze najpierw zaimplementowana bedzie obsluga materialow (ulatwi docelowo wprowadzenie shaderow, ale przyda sie do kilku rzeczy takze wczesniej), a wtedy zamiast dwoch odrebnych sciezek zrobi sie jedna (na VBO, w oparciu o biezace zmiany w sciezce DL) ale dzialajaca poprawnie.

Na krotka mete przywrocilem w exe ignorowanie przelacznika na VBO, coby falszywych alarmow nie bylo :d

W dzisiejszym uaktualnieniu;
- naprawione aktualizacja/wyswietlanie kabiny, wszystko powinno teraz pracowac z normalna predkoscia/czestotliwoscia
- wstepnie przebudowany system kalkulacji widocznosci; teoretycznie powinno to zakonczyc klopoty ze znikajacymi pojazdami, niewazne czy ogladane patrzac w dol, do gory nogami itp
- w ramach glupich eksperymentow wlaczone jest wygladzanie punktow swietlnych. w rezultacie sa teraz troche mniejsze, ale ladniejsze :P  jesli okaze sie, ze pogarsza to widzialnosc zbyt bardzo, to prosze krzyczec

773
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« dnia: 08 Marca 2017, 15:54:10 »
Cytat: firleju w 08 Marca 2017, 12:14:36
Żeby nie dociążać exe takimi zadania lepiej mieć odrębny kawałek softu, który mógłby służyć też jako miejsce rozsyłania plików / scenerii (wtedy jest pewność, że wszyscy mają taką samą).
Sek w tym, ze ten odrebny kawalek i tak bedzie musial miec w zasadzie pelna funkcjonalnosc symulatora (oprocz moze strony wizualnej, dlatego m.in. wspominalem ze jednym z celow zmian powinno byc rozdzielenie symulacji od renderingu) wiec czy dolozy sie do exe pare klockow, czy tez dolozy sie symulator do tej samej pary klockow i nazwie sie to "odrebny kawalek softu", to i tak wyjdzie na to samo :) Ale w przypadku odrebnego softu dojdzie koniecznosc wprowadzania zmian do dwoch programow i utrzymywania tychze, zamiast tylko jednego... co chyba nie jest zbyt praktyczne.

774
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 08 Marca 2017, 01:21:14 »
OK, pogrzebalem troche w kodzie, probujac poprawic widzialnosc freespotlights, i znalazla sie ciekawostka, jeszcze z czasow oryginalu...

W kodzie jest cos, co nazywa sie "wspolczynnik odleglosci", i sadzac po wartosci domyslnej (768) i komentarzy, intencja tutaj bylo zwiekszanie zakresu widocznosci na ekranach/oknach wiekszych niz standardowe 1024x768. Tyle ze zamiast tego, zmienna byla uzyta jako sztywny mnoznik, dla zdefiniowanych minimalnego i maksymalnego zakresu widzialnosci, dla kazdego obiektu.

W praktyce oznaczalo to, ze punkty swietlne ze zdefiniowanym minimalnym zakresem widzialnosci 20m nie byly renderowane w ogole, dopoki nie znalazly sie przynajmniej ~500m od kamery :d  Jedyne co renderowalo sie poprawnie, to obiekty ze zdefiniowanym minimalnym zakresem 0.

Z jednej strony, po poprawce wszystko wyswietla sie w zakresach odleglosci takich, jakie zostaly zdefiniowane. Tzn objekt o zakresie 50-1000m widoczny jest w zakresie 50-1000m w oknie o wysokosci 768 pikseli, na wiekszym pojawia sie troche wczesniej i znika troche pozniej. Zaryzykuje opinie, ze swiatla znacznie na tym zyskuja -- te male punkty robia duza roznice.

Z drugiej strony oznacza to, ze do tej pory symulator renderowal takze elementy umieszczone dalej niz ich zdefiniowany 'zakres maksymalny'. Czyli po naprawie na ekranie moze byc widac mniej, niz przedtem. Jest to do skorygowania (zasieg moze byc dynamicznie zwiekszany na podstawie fps) i teoretycznie istnieje w kodzie, ale takze do przejrzenia.

Z trzeciej strony, oprocz poprawionej widocznosci swiatel efektem ubocznym strony drugiej jest dosc zauwazalnie poprawiona wydajnosc -- na Kaliskiej tam, gdzie do tej pory mialem 60-80 fps teraz renderowalo sie 200-250.


775
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 15:49:47 »
Rozwiazalem to w ten sposob, ze w przypadku takiego porownania do nieistniejacych danych symulator umieszcza wpis w logu errors, na wypadek gdyby byl to faktyczny blad, ale traktuje warunek jako spelniony, w ten sposob zachowujac sie jak stare exe. Na ile moge powiedziec, to przy takiej aranzacji wszystko dziala, udalo mi sie przeprowadzic pociagi w scenariuszu z jednego konca na drugi, w obu kierunkach. Poprawki beda w nastepnym uaktualnieniu. Do czasu gdy Milek skonstruuje komunikacje po tcp powinno wystarczyc.

776
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« dnia: 03 Marca 2017, 23:39:40 »
OK, chyba udalo mi sie przywrocic komunikacje, ale nie wiem czy na 100% -- programy lacza sie, stan zajetosci torow jest uaktualniany, i rozkazy takie jak ustawianie zwrotnic czy kontrola przejazdow dzialaja, ale kazda proba ustawienia przebiegu konczy sie komunikatem "Nie mozna ustawic przebiegu" bez proby wyslania komunikatu przez SCS. Byc moze robie tutaj cos zle.

Dolaczone uaktualnione exe, jesli mozesz, sprawdz czy bedziesz mial wiecej szczescia.

777
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 03 Marca 2017, 12:47:13 »
Cytat: HTD w 03 Marca 2017, 06:43:44
To co prawda nie jest jeszcze "jak w Doomie" - ale już 100x lepiej. Koniec szarpania kamerą. Płynna animacja.
Dowcip polega na tym, ze mniej wiecej tak jest to robione w tym momencie. Problemy biora sie glownie z tego, ze czesc kodu obslugi kamery kabinowej (takie jak tlumienie 'szarpania' itp) jest wywolywane bez uwzglednienia czynnika dt, co prowadzi do sytuacji w ktorej wzrost fps oznacza mniejszy efekt szarpania i wolniejszy ruch kamery (bo tlumienie predkosci ruchu jest szybsze) Chyba najprostszym sposobem by to ogarnac bedzie obliczanie zmian ze stalym krokiem, podobnie jak robiona jest glowna czesc fizyki. Nie bedzie to idealne, bo dla idealnego efektu powinna byc jeszcze interpolacja miedzy wyliczonym stamen poprzednim i obecnym, ale powinno troche pomoc.

Cytuj
Oprócz tego bardzo bardzo bardzo przydałoby się, aby rolka myszy działała na FOV (kąt widzenia kamery) - czyli zoom z użyciem rolki.

Dalej, jeśli już ruszać kamerę: obecnie lewy i prawy przycisk myszy robią praktycznie to samo. Środkowy działa jako zoom. Opcja bardzo niewygodna. Ten sam chwilowy zoom powinien działać na prawym przycisku myszy, który jest po prostu łatwiejszy do wciśnięcia na większości myszek, co więcej, w większości gier jest właśnie wykorzystywany jako zoom. Niech lewy resetuje kamerę, albo jeszcze lepiej - np podwójne kliknięcie lewym, żeby nie wywoływało się tego przypadkowo. Środkowy przycisk myszy (klik rolką) powinien być raczej użyty do resetu samego FOV, który tą samą rolką się reguluje.
Zooma pod rolka nie umiescilem z dwoch powodow: po pierwsze, ze wzgledu na glosy ze niektorzy uzywaja rolki do obslugi nastawnika itp. Po drugie, jest to imo zwyczajnie mniej ergonomiczne -- zooma uzywam by zweryfikowac stan odleglego sygnalu i tutaj pojedynczy klawisz chwilowo przelaczajacy miedzy widokiem 'na dystans' i normalnym jest sporo szybsze, niz zabawa za kazdym razem z kreceniem kolkiem w przod i w tyl. Regulacja fov to cos, co widze raczej umieszczone w panelu Settings, jak juz bedzie jakies prawdziwe UI, bo takie rzeczy ustawia sie dosc rzadko. Chociaz zapewne mozna by to w miedzyczasie podpiac pod jakis klawisz w trybie debug.

Natomiast czemu srodkowy klawisz a nie prawy -- bo po wprowadzeniu obslugi mysza sensowna imo bylaby konwencja 'lewy klawisz zwieksza efekt/zalacza, prawy klawisz zmniejsza efekt/wylacza' co jest bardziej precyzyjne i szybsze niz alternatywa "trzymaj lewy i ciagnij mysz".

778
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 02 Marca 2017, 23:51:04 »
Cytat: Krzysiek626 w 02 Marca 2017, 23:35:48
2015 można odinstalować, obydwa dzisiejsze pliki obchodzą się bez tego. Po odinstalowaniu 2013 poranny i popołudniowy zawołał msvcr120.dll. na początek.
Aha, pewnie i tak potrzebuje jej jedna z pozostalych bibliotek. Czyli w sumie moge darowac sobie wlaczanie jej do .exe, plik bedzie mniejszy.

Podsumowujac wiec, cala paczka instalacyjna sprowadzalaby sie do:
http://eu07.pl/userfiles/24014/bugs-170303.rar

jest w niej biezace .exe i dodatkowe pliki modeli dla nieba, biblioteki glfw.dll i glew.dll, i pliki instalacyjne dla vc 2008 i 2013. Instalacja powinna sie sprowadzic do wypakowania zawartosci do katalogu z maszyna, jednorazowym uruchomieniu kazdego z dwoch plikow vcredist.exe i mozna jechac.

Co do nowego watku to moze najlepiej jesli popelni go Firleju, to w sumie najbardziej jego praca a i ludzie wiecej uwagi zwroca na to co starszyzna robi ;d

779
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 01 Marca 2017, 20:34:06 »
Cytat: Krzysiek626 w 01 Marca 2017, 20:19:48
Okazało się jednak, że tekstura nieba
Kod: [Zaznacz]
sky sky_dynamic_stratus.t3d endskymruga w tempie 2 może 3 razy na sekundę. To potwierdza wpis EP08-015. Niestety nie wiem jak to pokazać, nie dysponuje możliwością nagrania filmu. Różnica jasności jest znaczna.
Filmik EP mi wystarczy, ale niestety nie moge tego zaobserwowac u siebie. Jesli to nie problem, czy mozesz sprawdzic czy migotanie wystepuje rowniez przy wpisie
Kod: [Zaznacz]
sky skydome_clouds.t3d endsky
I przy wylaczonych w ogole chmurach? (wpisem skyenabled no w .ini)

780
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 01 Marca 2017, 17:24:47 »
OK, uaktualnienie z poprawkami:
- fullscreen powinien teraz pozwalac na umieszczenie na nim innych okien, zamiast decydowac sobie ze bedzie TOPMOST i juz
- eksperymentalnie, fullscreen nie przelacza monitora na rozdzielczosc podana w .ini, a zachowuje aktualnie ustawiona rozdzielczosc desktopu. Jak sie nie podoba, prosze krzyczec.
- opcja glutfont yes wyswietla cienka wersje czcionki, dla uzytkownikow z sokolim wzrokiem i/lub masochistow
- bardziej zaakcentowana roznica oswietlenia kabiny po uzyciu przelacznika przyciemnienia
- zmieniona nieco kalkulacja sily swiatel, pojedyncze swiatlo powinno miec teraz wiekszy efekt
- prawidlowa numeracja wesji exe :P

edit:
aha, tak na marginesie, program mozna tez zamknac standardowym alt+f4, nie ma koniecznosci klikania na okienko konsoli.

Strony: 1 ... 24 25 [26] 27 28