Planowane zmiany w exe

[firleju]

Otwieram dyskusję o tym w których miejscach należy zmienić kod oraz jak to zrobić, żeby osiągnąć cele. Na początek szybka lista tego co moim zdaniem wymaga zmian:

• Rozbicie mover na klasy odpowiadające typom (prądu stałego, asynchrony, diesel, diesel electric, itp) a następnie poszczególnym modelom (obecnie rozróżnienie przez dt_xx). Za tym idą zmiany w parserze plików fiz, bo będzie można wywalić wszystkie niepotrzebne zmienne. Nie mówiąc już, że jakiekolwiek dodanie nowego typu pojazdu będzie łatwiejsze. Z minusów wymaga to zmian w interfejsie do pythona na pobieranie przez skrypt wybranych danych, ale samych ekranów nie jest jeszcze na tyle, żeby nie dało się tego wykonać.
• Rozbicie Driver na część tylko dla człowieka oraz tylko dla AI, być może AI dla specjalnych okazji jeśli mają być takowe.
• Implementacja protokołu do wymiany danych z SCS. Wywalenie eventów. Dość trudne, gdyż już teraz na etapie zmian w tabelce dochodzę do kwestii kompatybilności z tym co obecnie można robić, a co będzie możliwe po zmianach. Tu jest pytanie czy tylko naprawić co jest na potrzeby Kaliskiej w obecnej wersji i po prostu zrobić to od nowa, ale wtedy wszystkie scenariusze będą do zrobienia na nowo (chociaż zapewne odtworzenie będzie bardzo łatwe przy pomocy SCS).
• Serializacja danych w celu zapisu i odtworzenia stanu sesji jest możliwa, szczególnie jeśli porozbijamy monolityczne klasy jak obecnie.

[tmj]

Dokleje tylko moj wczesniejszy kawalek z watku c++ zeby nie zginal

Co do grubszych zmian, zastanawiajac sie nad tym, co powinno byc zrobione, wyszla mi nastepujaca lista:

* rozdzielenie symulacji od wizualizacji. Czesc z tego jest juz chyba zrobiona, ale docelowo kompletny uklad torow i lista poruszajacych sie po nich obiektow, obsluga eventow + kalkulacje fizyki dla tych obiektow powinna pracowac praktycznie niezaleznie jako odrebny modul. Stan obiektow symulacji moze byc podawany zainteresowanym sluchaczom, a czy tym sluchaczem jest silnik graficzny (czy wrecz caly klient w systemie multiplayer), przekaznik informacji dla pulpitu, modul kontroli ruchu czy jeszcze cos innego, to juz symulacji nie obchodzi.

* powiazane z powyzszym i opcjonalna, reorganizacja sterowania symulacja na uklad dwustopniowy -- pomijajac siec trakcyjna, stopien pierwszy czyli 'swiat' symulacji zredukowany jest do ukladu torow i uniwersalnych 'punktow sygnalowych' ktore sa zrodlem instrukcji dla AI pojazdow, i z reguly umieszczone sa tam, gdzie znajduja sie fizyczne wskaznikow/sygnalow/itp. Konkretne jakie instrukcje emitowane przez punkty sygnalowe zalezy od stopnia 2-ego, tj. skryptu i/lub modul(ow) spietych z danym punktem. Uprosciloby to tworzenie scenerii -- uklad torow i wskaznikow robiony jest raz, a kontrola sygnalow zajmuje sie juz modul kontrolera, w zaleznosci od otrzymanego scenariusza. I czy tym kontrolerem jest modul AI, czy zywy czlowiek albo nawet kilku, to juz symulacji nie obchodzi.

* opcjonalne, uporzadkowanie zmiennych w glownych klasach. Te wieksze maja cos z 50+ parametrow, wszystko wrzucone na jedna kupe. Trudno dojsc co jest pobierane z plikow konfiguracji, co jest kalkulowane, co nie jest uzywane w ogole. Pogrupowanie tego w sensowne struktury ulatwiloby punkt nastepny

* krytyczne, wprowadzenie zapisu 'swiata' z poziomu symulatora, i wczytywanie tego zapisu. Glownie majace na celu uproszczenie i przyspieszenie edycji scenerii; zamiast zabawy edytorami tekstu, zewnetrznymi narzedziami itp powinno to byc cos, co robisz bezposrednio w programie i "what you see is what you get". Zamiast zgadywac, jak prezentuje sie obiekt umieszczony w scenerii, po prostu mozna to od razu zobaczyc, tak jak i wprowadzane poprawki. W polaczeniu ze zmianami powyzej pozytywnym efektem ubocznym mogloby byc tutaj przyspieszenie ladowania scenariuszy -- program moglby wczytac od razu uklad torow i zestaw pojazdow, a nastepnie doczytac sobie w locie dane potrzebne do wizualizacji.

A tak z zupelnie innej beczki, to ile dobrze pamietam Q zaczal robic jakas wersje kodu z przepisana grafika itp, tylko sie to rozbilo na przepisywaniu fizyki. Skoro fizyka w c++ teraz zaczyna jako tako chodzic, moze daloby sie to jakos polaczyc?

[firleju]

Do spraw, do zrobienia jest sterowanie pociągiem. To co yB wyłuszczył jest dość istotne dla prowadzenia symulacji. Więc trzeba zaprojektować nową architekturę, która uwzględni nowe pojazdy. Może coś takiego:
Pociąg -> Pojazd / Wagon -> Fizyka
Wtedy poszczególne elementy zawierają:

• Pociąg: zawiera wszystkie pojazdy / wagony, przechowuje rozkład jazdy, przechowuje AI / człowieka dla wszystkich pojazdów, które mają sterowanie (np. podwójna trakcja).
• Pojazd / Wagon jest dość ciekawą konstrukcją. Z punktu widzenia Pociągu to to jest to samo. Z punktu widzenia Wagonu Pojazd jest pociągiem. Czyli Pojazd jest specyficzną konstrukcją, która przechowuje poszczególne Wagony oraz logikę przekazującą polecenia AI dla poszczególnych Wagonów. Pojazd byłby lepiej napisanym odpowiednikiem obecnego sprzęgu depotowego.
• Fizyka: zawiera obliczanie zmiennych fizycznych dla danego Wagonu. Np. dla wagonów to może być tylko liczenie sił na sprzęgach oraz układ hamulcowy. Dla części EZT to może być różna fizyka zależnie od posiadania lub nie odpowiednich elementów.

Kwestia umiejscowienia kabiny i miejsca przechwytywania sterowania jest do rozwiązania.

[tmj]

Nazwalbym to moze raczej pociag->zespol->pojazd, bo na poziomie podstawowym niekoniecznie musi byc to wagon, ale tez np. lokomotywa, ale to kosmetyka ;) a samo podejscie wyglada sensownie.

Co do kabin, chyba rozdzielibym je troche od pojazdu i uogolnil, w porownaniu do obecnego pdejscia. Konkretnie, kabina jako osobny obiekt z konfiguracja dyktujaca spis przelacznikow ktore zawiera, link do modelu podstawowego i wersji lowpoly, plus pozostale parametry. Takich obiektow 'wnetrz' mozna podlaczyc do pojazdu kilka, bez biezacego roznicowania na kabine, przedsionek itp -- tym sposobem mozna by latwo skonstruowac/obsluzyc kazdy rodzaj pojazdu, w tym kombinacje z kabinami i modulem pasazerskim w jednym pudle, nawet z indywidualnym stanem oswietlenia kazdej sekcji, widocznym w wizualizacji. Potencjalnie upraszcza tez to takie mechanizmy jak przechodzenie miedzy rolami pasazera i mechanika w skladzie, jesli kogos to bawi.

Sterowanie umiescilbym na poziomie pociagu, w calosci przy pomocy komend, odpowiednikow biezacych komend rozsylanych po skladzie. W ten sposob obsluga moze byc jednakowa bez wzgledy czy zrodlem jest uzytkownik walacy w klawisze, AI obslugujace sklad albo jakies zewnetrzne zrodlo -- otrzymane komendy sa (opcjonalnie) przepuszczane przez aktualnie obsadzona kabine, i jesli ma ona odpowiednie dzwignie/przyciski to sa wykonywane i przekazywane dalej. Tym sposobem jesli uzytkownik jest w kabinie mechanika to dostaje kontrole nad wiekszoscia funkcji, a gdy siedzi w wagonie pasazerskim to moze sobie najwyzej wlaczyc swiatlo albo pociagnac za hamulec bezpieczenstwa :d

[firleju]

Chciałbyś umieścić fizykę w klasie pojazdu?
Chciałbym uniknąć niepotrzebnego tworzenia klasy zespół dla pojedynczych pojazdów. Tak naprawdę zespół jest potrzebny tylko do ezt. Cała reszta tego nie potrzebuje.

Teraz eventy. Ogólnie mamy konsensus, że trzeba to wywalić, ale na potrzeby aktualnych prac myślałem nad tym jak AI współpracuje z modelem scenerii. Wpływ na prowadzenie postrzeganie trasy mają dwie rzeczy: tory oraz wszelakiego typu wskaźniki i semafory. Obecnie AI skanuje tor przed sobą i czyta czy jest do niego przypisany event od strony od której nadjeżdża. Potem event jest sprawdzany na okoliczność uznania go za "pasywny". Do tego punktu wszystko jest ok. Następnie wszystko jest wrzucane do wspólnego worka pod nazwą SpeedTable, która ma własne algorytmy przeliczania odległości od obiektów. Niestety, te algorytmy działają tylko przy założeniu, że urządzenia są przypisane do torów przy których stoją i w kolejności w jakiej stoją. Wszelkie błędy powodują nieprawidłowe przeliczanie odległości.
cdn..

[youBy]

Bipa i przegubowe platformy kontenerowe też są pojazdem wielowagonowym.

[AtapiCl]

ET41? ET42? etc...

[tmj]

Chciałbyś umieścić fizykę w klasie pojazdu?

No raczej tak, bo w zasadzie wszelkie kalkulacje trzeba bedzie przeprowadzac na poziomie poszczegolnych czlonow/wagonow/whatever. Gdyby sie strasznie chcialo, to mozna wydzielic z tego wozek jako sub-component, i np. prowadzic wozki po torze indywidualnie, i na podstawie tego kalkulowac, gdzie jest pudlo (dopoki sie nie rozerwie jak na rozjezdzie kazdy wozek pojdzie sobie na inny tor) Ale to tak opcjonalnie.

Chciałbym uniknąć niepotrzebnego tworzenia klasy zespół dla pojedynczych pojazdów. Tak naprawdę zespół jest potrzebny tylko do ezt. Cała reszta tego nie potrzebuje.

Ja bym to potraktowal troche bardziej ogolnie -- z punktu widzenia pociagu wszystko, co ma pod soba to zespoly, a juz tylko sam zespol obchodzi ile ma w sobie komponentow, i jakie. Tzn. mozna by sie tez alternatywnie bawic w aranzacje typu pociag -> pojazd, a dla pojazdow wyprowadzamy osobno zespol wariant, ale tego typu dziedziczenie na dluzsza mete bardziej chyba komplikuje sprawe, niz ulatwia.

Teraz eventy. Ogólnie mamy konsensus, że trzeba to wywalić, ale na potrzeby aktualnych prac myślałem nad tym jak AI współpracuje z modelem scenerii. Wpływ na prowadzenie postrzeganie trasy mają dwie rzeczy: tory oraz wszelakiego typu wskaźniki i semafory. Obecnie AI skanuje tor przed sobą i czyta czy jest do niego przypisany event od strony od której nadjeżdża. Potem event jest sprawdzany na okoliczność uznania go za "pasywny". Do tego punktu wszystko jest ok. Następnie wszystko jest wrzucane do wspólnego worka pod nazwą SpeedTable, która ma własne algorytmy przeliczania odległości od obiektów. Niestety, te algorytmy działają tylko przy założeniu, że urządzenia są przypisane do torów przy których stoją i w kolejności w jakiej stoją. Wszelkie błędy powodują nieprawidłowe przeliczanie odległości.
cdn..

Tutaj zastanawialem sie, czy sprawy nie uproscilo by faktyczne zalozenie, ze zrodla komunikatow sa wszystkie przypisywane do konkretnych torow. Tzn masz cos w rodzaju: uklad torow dzielimy na wierzcholki (semafory) i krawedzie (odcinki torow od jednego wierzcholka do drugiego), plus trzeci element jakim jest 'skrzyzowanie' czyli krawedz laczaca kilka wierzcholkow na specjalizowanych zasadach, uzywana do realizowania zwrotnic, obrotnic, skrzyzowan drog itp.  Bazujac na tym, zrodlo komunikatow jest traktowane jako punkt w danej odleglosci od konca/poczatku odcinka toru -- moze ich byc wiecej nie jeden, i tor trzyma sobie (posortowana) liste takich punktow wewnetrznie, i przekazuje zainteresowanym pociagom. W tym momencie odpada caly problem skanowania, bo po takim przekazaniu pociag wie dokladnie w jakiej odleglosci znajduja sie najblizsze komunikaty, i uaktualnia sobie te odleglosci po prostu na podstawie przejechanego dystansu.

Na potrzeby wizualizacji zrodla komunikatow powiazane sa z obiektami 3d, ktore uzytkownik ustawia sobie gdzie mu pasuje. W pewnym sensie jest to odwrocenie obecnej sytuacji, w ktore event jest wstawiany do sceny 3d a potem dopiero przypisywany luzno do toru, bez konkretnego okreslenia , gdzie.

[firleju]

eventy cd.
Obecnie robię to tak, że rozdzieliłem tabelkę na dwie. Jedna trzyma informacje o zeskanowanych torach, druga o zeskanowanych wskaźnikach. W tej chwili obie to std::deque gdyż doszedłem do wniosku, że modyfikacja kolejek odbywa się raz na parenaście sekund więc narzut związany z ewentualną alokacją pamięci jest pomijalny. Takie rozbicie pozwala np. sprawdzać szybciej sobie ograniczenia ze wskaźników (tabelka jest o wiele mniejsza). Modyfikacja odległości w tabelkach odbywa się przez odjęcie odległości przejechanej przez pociąg co wszystko upraszcza. Całe clue zabawy polega na prawidłowym policzeniu odległości do obiektu podczas skanowania z czym aktualnie walczę.
Wydaje się, że sposób łączenia torów z wskaźnikami zostanie bardzo podobny do obecnego. Po prostu nie będzie uruchamiania tego punktu przez najeżdżający wózek.

Co do pojazdów z fizyką, to zważ że jeśli zmiksujesz DynamicObject z TMoverParameters ze stworzeniem tego dla każdej klasy pojazdu osobno to w przypadku jeśli zawsze pociąg będzie zawierał zespoły i te dopiero pojazdy to dla typowego składu cargo sytuacja nie rożni się od obecnej.

[tmj]

Całe clue zabawy polega na prawidłowym policzeniu odległości do obiektu podczas skanowania z czym aktualnie walczę.

Z tego co pamietam, zarowno sklad jak i eventy maja zdefiniowane absolutne wspolrzedne 3d, czy nie sprowadza sie to wiec po prostu do stworzenia wektora miedzy tymi dwoma punktami, i policzenia dlugosci? Czyli cos jak distance = vector3( vehicle.position, event.position ).length().

(to sie moze rozleciec w sytuacji gdy np tor jest ostro zakrecony, i skanowany element jest na drugim koncu takiej 'podkowy', stad propozycja innego podejscia w zmienionej strukturze)

Co do pojazdów z fizyką, to zważ że jeśli zmiksujesz DynamicObject z TMoverParameters ze stworzeniem tego dla każdej klasy pojazdu osobno to w przypadku jeśli zawsze pociąg będzie zawierał zespoły i te dopiero pojazdy to dla typowego składu cargo sytuacja nie rożni się od obecnej.

Roznice pojawilyby sie na poziomie interakcji kontrolera ze skladem; w chwili obecnej to jest jedna wielka kupa instrukcji warunkowych -- jesli silnik typu x to zrob to, a jak y to tamto, a jak lokomotywa jest okreslonego typu.. itd. Po zmianach to wszystko byloby rozdzielone do konkretnych typow pojazdow, a obsluga zblizona do tego, co w tej chwili oferuje uklad hamulcowy. W pewnym sensie uklad zespol->pojazd(y) bylby analogiczny do biezacego ukladu pojazd->hamulec, tylko o poziom wyzej.

[firleju]

Zrobiłem funkcję rzutującą pozycję komórki na tor. Narazie w wersji wstępnej niezoptymalizowanej wygląda to jak:
1. Weź punkt1 toru.
2. Policz odległość od eventu.
3. Policz punkt na bezierze w odległości +0.1 od poprzedniego
3. Policz odległość od eventu
4. Jeśli mniejsza wróć do punktu 3. Jeśli koniec toru przejdź na następny.
Algorytm łopatologiczny, nieoptymalny, dający odległość w rozdzielczości obecnie ok. 10m ale eventów jest na tyle mało, że nie powinien specjalnie rzutować na wydajność a na ruch też nie. W następnej wersji zwiększę rozdzielczość sprawdzania dla znalezionej pary punktów pomiędzy którymi jest event do mniej więcej 1m.
Ponadto zmieniłem deque dla wskaźników na std::list ze względu na to, że potrafię sobie wyobrazić przypisanie wskaźników w odwrotnej kolejności i w dziwnych miejscach. Obecnie przerabiam funkcję TableUpdate. Przy okazji pytanie czy nie lepiej konwertować czas przyjazdu i odjazdu w rozkładzie na czas, nie trzymać jak obecnie. Jak do tej pory po zmianie poprzednich funkcji schodzę o mniej więcej 2 do 3 "wcięć" w kodzie. Szczególnie, że teraz rozbijam sprawdzanie pozycji osobno na tabelę tylko z torami i tylko ze wskaźnikami.
Aktualizacja wpisów w tabelce teraz polega tylko na sprawdzeniu stanów, a aktualizacja dystansu jest osobno za pomocą odległości przejechanej przez pierwszy pojazd. Czyli po bożemu. Do zrobienia jest zaktulizowanie przeliczania długości toru podczas jego inicjalizacji na propozycję @HTD co powinno polepszyć przemieszczanie taboru po torach i aktualizację tabelki, aczkolwiek obecna metoda jest wystarczająco dokładna to raczej nieoptymalna.

Co do fizyki, to z podziałem TMover to jak najbardziej. Tu się troszkę nie zrozumieliśmy. Mnie chodzi to, żeby nie powstała sytuacja w której masz taki układ:

Kod: [Zaznacz]

pociąg   -> pojazd -> wagon
                       -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagon
             -> pojazd -> wagoni tak 40 razy. Czym to się różni w architekturze od obecnego:

Kod: [Zaznacz]

Train -> DynamicObject
      -> TCab
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParameters
DynamiObject -> TMoverParametersitd.

[tmj]

Mnie chodzi to, żeby nie powstała sytuacja w której masz taki układ:
(..)
Czym to się różni w architekturze od obecnego:
(..)[/code]
itd.

Akurat ta sytuacja nie rozni sie wiele, przynajmniej w tym ujeciu. Roznice wystepuja, gdy masz aranzacje np

Kod: [Zaznacz]

Train->
    dynamic, en57a
    dynamic, en57s
    dynamic, en57b
    dynamic, en57a
    dynamic, en57s
    dynamic, en57b
bo taki uklad widziany jest wtedy jako

Kod: [Zaznacz]

pociag->
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
Nie sa to byc moze sytuacje czeste, niemniej wystepuja, podobnie jak lokomotywy uokrotnione itp, wiec mysle ze warto miec taki uklad, ktory pozwala na ich obsluge bez wymuszania na pociagu babrania sie z indywidualnymi elementami, i sprawdzania czy sa one pojedyncze, czy w jakis sposob laczone.

Alternatywa byloby, teoretycznie, wyprowadzenie zespolu z pojazdu, jako taki wariant ktory wewnetrznie trzyma swoje wlasne pojazdy, ale to akurat imo wprowadza wiecej komplikacji niz usuwa, bo oznacza to ze zamiast miec w zespole jednynie obsluge ogolnych instrukcji od kontrolera i przekazywanie/tlumaczenie tego na bardziej konkretne instrukcje dla elementow, i tylko te dane ktore tego dotycza, mamy przynajmniej w zespole rowniez te funkcje i dane, ktore posiada indywidualny pojazd. To chyba niepotrzebny balagan.

[Krzysiek626]

Trudno, nie znam się na programowaniu, ale z pewnych względów napiszę. Jakiś czas temu i to nie raz, wybucha dyskusja co w exe poprawić. Jednym z wielu takich propozycji bardzo lobbowanych przez ze mnie jest oświetlenie scenerii. Oświetlenie, gdzie strumień światła ze źródła oświetla obiekty bez ustawienia badziewnych tekstur i strumień ten, jest w stanie być przysłonięty przez obiekty, a więc także chodzi o cienie. Ze źródeł świateł w symulatorze wymienię słońce, latarnie, reflektory lokomotyw i samochodów, okna wagonów i lokomotyw, oraz okna budynków. Z wymienionych źródeł w tej chwili najlepiej sprawuje się oświetlenie słoneczne. W związku budową exe C++, pytam, jak wygląda w tej materii poprawa grafiki symulatora, jaka jest możliwość rozbudowy silnika o takie oświetlenie. Być może takie pytanie nie jest odpowiednie w tym wątku, ale proszę o odpowiedź. Przy czym zaznaczam, że nie mam zamiaru namawiać i dyskutować zbędnie o tej kwestii, zależy mi na odpowiedzi bez zbędnego spamu, czy takie coś jest nam potrzebne i bez zbędnego trolowania kto ma rację.

[tmj]

W związku budową exe C++, pytam, jak wygląda w tej materii poprawa grafiki symulatora, jaka jest możliwość rozbudowy silnika o takie oświetlenie.

Nie wnikajac w szczegoly i niczego tutaj nie obiecujac, przygladam sie :)  Nawiasem mowiac, bardziej zdecydowane rozdzielenie czesci symulacyjnej od wizualizacji, zaproponowane na wstepie, ma miedzy innymi na celu stworzenie na dluzsza mete mozliwosci polaczenia z jakims innym silnikiem graficznym, a bardziej zaawansowanych mozliwosciach.

Na krotka mete, na ile biezacy renderer mozna przebudowac i/lub ulepszyc, okaze sie.

[Stele]

Z rzeczy w tym aspekcie, które zdaje się Q jakoś zrobił, tylko ostatecznie kodu mi nie dał, było wyprowadzenie emisyjności materiału obiektu 3d. Tak by dynamic mógł sterować świeceniem swoich obiektów.
W planach miałem też próbę wyprowadzenia obiektu do nowej fazy renderowania z blendem w takim trybie, jak obecna smuga pojazdu. By bez shaderów zrobić trochę lepsze oświetlenie statyczne. Koncepcyjnie skisło na ustaleniu uzależnienia i jak by to miało się sortować z całą resztą.

[firleju]

Roznice wystepuja, gdy masz aranzacje np

Kod: [Zaznacz]

Train->
    dynamic, en57a
    dynamic, en57s
    dynamic, en57b
    dynamic, en57a
    dynamic, en57s
    dynamic, en57b
bo taki uklad widziany jest wtedy jako

Kod: [Zaznacz]

pociag->
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
Nie sa to byc moze sytuacje czeste, niemniej wystepuja, podobnie jak lokomotywy uokrotnione itp, wiec mysle ze warto miec taki uklad, ktory pozwala na ich obsluge bez wymuszania na pociagu babrania sie z indywidualnymi elementami, i sprawdzania czy sa one pojedyncze, czy w jakis sposob laczone.

Tylko jeśli mialbyś dwie alternatywy:

Kod: [Zaznacz]

pociag->
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
oraz alternatywnie

Kod: [Zaznacz]

pociąg
    pojazd
    pojazd
    pojazd
W takim układzie zespół jest specjalizowaną odmianą pojazdu, która jest kontenerem do zbierania, przetwarzania i rozsyłania następnie informacji po pojazdach przypisanych do niego.

[tmj]

W takim układzie zespół jest specjalizowaną odmianą pojazdu, która jest kontenerem do zbierania, przetwarzania i rozsyłania następnie informacji po pojazdach przypisanych do niego.

No ale to jest chyba wlasnie ta teoretyczna alternatywa, ktora opisalem w ostatnim paragrafie -- tzn. masz wtedy sytuacje, ze taki wariant wywiedziony z pojazdu dziedziczy wszystkie struktury i funkcje regularnego pojazdu, mimo ze z nich nie korzysta bo jego funkcja jest ograniczona do rozsylania komend to 'podzespolow'. A jednoczenie takze nie-specjalizowany pojazd trzyma interfejs komunikacji z pociagiem, bo inaczej mamy do czynienia z sytuacja, ze pociag musi komunikowac sie inaczej z pojazdem zwyklym, a inaczej ze specjalizowanym. Tak ze nie wiem, troche wydaje mi sie to bardziej balaganiarskie, a czy zyskujemy cos na tym rozwiazaniu..? Tzn redukujemy abstrakcje/podzial o jeden poziom, ale ja chcialbym go wprowadzic wlasnie dlatego, ze w obecnej sytuacji go brakuje i mamy reczne uzeranie sie ze sztucznymi rozwiazaniami w stylu wskaznikow na pojazd okupowany i kontrolowany, itp.

[firleju]

Tylko, że jeśli klasa zespół ma być obecna dla każdego rodzaju pojazdu, to czym będzie się zajmować w przypadku wagonów towarowych, gdzie co najwyżej używasz hamulca? Rozsyłaniem komend do zespołów zajmuje się pociąg. Koniec końców kończysz z ilomaś wersjami klasy zespół, gdyż musisz mieć osobne dla każdego typu zespołu jaki Ci się zdarzy żeby obsługiwać te wszystkie dziwne wyjątki jakie masz obecnie w fizyce i w dynamic + klasa dla wagonu.
Czym interakcja pociąg - zespół ma się różnić od interakcji bezpośredniej pociąg - wagon?
Nie widzę potrzeby trzymania nadmiarowych informacji w zespole w mojej wersji, gdyż pojazdy dla takiego zawsze będą miały dedykowane klasy i można takie napisać w wersji uproszczonej.

[tmj]

Tylko, że jeśli klasa zespół ma być obecna dla każdego rodzaju pojazdu, to czym będzie się zajmować w przypadku wagonów towarowych, gdzie co najwyżej używasz hamulca? Rozsyłaniem komend do zespołów zajmuje się pociąg.

No zajmowala by sie tym samym, czym zajmuje sie dla zespolow wiecej niz jednego pojazdu -- w tym konkretnym scenariuszu kolejkowaniem i przesylaniem komend do kolejnego zespolu, na podstawie typu sprzegu miedzy nimi (to nie jest imo robota pociagu, pociag wydaje komende raz i szczegoly rozsylania go nie obchodza) jak rowniez, tam gdzie ma to sens, przekazywaniem ich 'w dol' czyli do indywidualnych pojazdow (w tym wypadku jednego pojazdu)

Caly sek wprowadzenia klasy jest w tym, ze mamy elastyczny 'wrapper' ktory dla swoich zadan nie wymaga specjalizowanych wariantow, a ktory przejmuje czesc funkcji zarowno ze specjalizowanych pojazdow jak i nadrzednego pociagu, zmniejszajac obecny stopien skomplikowania tych dwoch elementow; a przy tym sam nie jest jakos specjalnie skomplikowany.

[youBy]

Moim zdaniem zespół nie może być pojazdem i trzymać pod sobą pojazdów, bo wtedy jeden z tych tworów będzie musiał być wykastrowany z wózków, osi, hamulców, sprzęgów. Docelowo widzę to w ten sposób, że zespół ma pod sobą zbiór hamulców, zbiór pudeł (pojazdów), zbiór wózków, sprzęgi zewnętrzne i na ich podstawie stara się prowadzić interakcję ze światem.

[firleju]

@tmj: no ale po co Ci elastyczny wrapper który zajmuje się tylko przekazywaniem danych dalej. Ponadto wagony skrajne w zespole muszę mieć wskaźniki na wagony skrajne w innych zespołach, gdyż inaczej nie policzysz hamulców oraz sił na sprzęgach. Oczywiście można inaczej zorganizować dane, żeby nie było wskaźników bezpośrednio do pojazdów tylko do potrzebnych danych, ale wtedy te dane trzeba trzymać na poziomie pociągu a nie zespołu (co nie znaczy, że pociąg ma robić z nimi cokolwiek poza trzymaniem). Nie widzę sensu istnienia dodatkowego poziomu abstrakcji, który w 99% przypadków będzie się sprowadzał do zwiększania opóźnień a nie będzie nic wnosił.
Moją myślą było to, żeby zespół miał taki sam interfejs jak pojazd, ale nie był pojazdem. Tak, żeby pociąg miał zestaw zespołów / pojazdów o tym samym interfejsie. W przypadku zespołu dochodziłoby odpowiednie zarządzanie informacją w stosunku do pojazdów wewnątrz. W przypadku pojazdów nie ma takiej potrzeby żeby coś tam było wyżej. Przynajmniej ja takiej nie widzę.
Troszkę się zapętliliśmy w dyskusji. Trzeba konkretnie rozpisać co dana klasa miałaby trzymać za informację i jakie mieć API do poszczególnych warstw wyższej i niższej oraz między tym samym poziomem. Inaczej do niczego nie dojdziemy.
@yB: a co z liczeniem sił pomiędzy pojazdami wewnątrz zespołu? To też trzeba liczyć bo przecież to nie jest monolit.

[Milek7]

Moim zdaniem trzeba pozbyć się zależności od windowsizmów i wykorzystać wieloplatformowe biblioteki:
- okienka, mysz i klawiatura, tworzenie kontekstu GL: Trzeba wywalić to dziwne tworzenie kontekstu WGL, jak i windowsową obsługę komunikatów. GLUT to już trochę zabytek, więc pewnie lepsze będzie popularne GLFW. Ze względu na to że WM_COPYDATA jest wykorzystywane do jakiegoś IPC, to będzie trzeba je czymś zastąpić, najprościej pewnie zwykłym socketem. (na win pewnie zwykły tcp na localhoście, na unixach można socketem na pliku). Chociaż właściwie to nie wiem czy to WM_COPYDATA jest wykorzystywane do czegoś praktycznego, czy jakaś nieużywana pozostałość?
- renderowanie fontów: Jak nie będzie ani WGL ani GLUT, to trzeba sobie jakoś poradzić z wyświetlaniem tekstu. Zwykle wykorzystuje się FreeType żeby wyrenderować tekst do tekstury.
- dźwięk: Oczywiście trzeba pozbyć się DirectSound. OpenAL wygląda sensownie.
- LPT: AD 2017 i LPT? To bym wywalił w ogóle.
- UART: Tu coś trzeba pewnie wymyślić. Albo znaleźć jakąś wieloplatformową libkę, albo napisać po prostu dwie implementacje pod windowsa i unixy, z tym nie powinno być dużo problemów.
- PoKeys55: Nie patrzyłem dokładnie co to za wynalazek, ale wygląda na jakieś proste USB. Jeżeli czyste usb to libusb-1.0, jeżeli hid to HIDAPI.

Co do modernizacji silnika graficznego, to koniecznie trzeba pozbyć się fixed pipeline. Absolutne minimum jakie można wspierać to OpenGL 2.0, chociaż trzeba by się zorientować czy komuś to w ogóle potrzebne, bo nowocześniej i wygodniej by było robić na 3.2 core profile. Trzeba też wywalić rendering na displaylistach. Jak już wszystko będzie na współczesnym GL to myślę że dodanie współczesnego oświetlenia, cieni, ładnej wody, light blooma od lamp, może odbić, nie powinno być już dużym problemem.

Oczy mi krwawią od tego kodu, ale obecnie bawię się żeby przenieść sterowanie i tworzenie kontekstu na GLFW. Za tydzień pewnie napiszę co udało mi się zrobić.

[Balaclava]

Ja proponuję przy rozbijaniu modułów oraz dodawaniu nowych pisać dla nich jakieś testy jednostkowe. Co prawda wymaga to większych nakładów pracy, ale w przyszłości ten czas spędzony na ich pisaniu zwróci się poprzez skrócenie czasu wyszukiwania bugów.

[firleju]

WM_COPYDATA jest używane do multiplayera. Docelowo idzie bezpośrednio na TCP/IP.
LPT i COM muszą zostać bo są używane do sterowania pulpitami fizycznymi.
Dźwięk: czytałem i OpenAL nie jest już w zasadzie rozwijane, są też lepsze biblioteki ale mają taką wadę jak Unity, tj. można za free użyć to projektów niekomercyjnych. Licencja może się kiedyś zmienić (ale to dotyczy chyba wszystkiego).
Fonty: mnie jest obojętne, byleby dało się to normalnie ubrać w jakąś strukturę, a nie tak jak teraz że musisz ręcznie ustalać pozycję na ekranie gdzie to wyrenderować.
Co do minimum OpenGL to się nie wypowiem. Ostatnie badanie kto co ma było ze 5 lat temu. Ja mam min. 4.0 więc mnie osobiście to wsio radno.

[Milek7]

Dźwięk: czytałem i OpenAL nie jest już w zasadzie rozwijane, są też lepsze biblioteki ale mają taką wadę jak Unity, tj. można za free użyć to projektów niekomercyjnych.

Opensourcowa implementacja openal wygląda na dosyć żywą: https://github.com/kcat/openal-soft

[tmj]

Opensourcowa implementacja openal wygląda na dosyć żywą: https://github.com/kcat/openal-soft

Nie ma tez specjalnie w czym wybierac jesli chodzi o alternatywy. Tzn. jest WWise, ktory jest uzywany znacznie szerzej i rowniez cross-platform, ale darmowa licencja ma dosc ostre ograniczenia. Druga opcja bylby prawdopodobnie FMOD, ale tutaj tez ewentualnie moga pojawic sie ograniczenia.

edit:

@tmj: no ale po co Ci elastyczny wrapper który zajmuje się tylko przekazywaniem danych dalej. Ponadto wagony skrajne w zespole muszę mieć wskaźniki na wagony skrajne w innych zespołach, gdyż inaczej nie policzysz hamulców oraz sił na sprzęgach. Oczywiście można inaczej zorganizować dane, żeby nie było wskaźników bezpośrednio do pojazdów tylko do potrzebnych danych, ale wtedy te dane trzeba trzymać na poziomie pociągu a nie zespołu (co nie znaczy, że pociąg ma robić z nimi cokolwiek poza trzymaniem).

Chcialbym go wprowadzic glownie po to, zeby zredukowac obecne klasy-monolity do bardziej sensownych rozmiarow. Takie rzeczy jak przekazanie sil/napiec/polaczen do sasiednich zespolow to jest wlasnie cos, co jak najbardziej mogloby sie znalezc w zespole, bo pociagowi to na nic, wiec nie ma powodu zeby tam to wpychac, a i pojazd/modul nie musi takich rzeczy robic osobiscie wiec po wyjeciu ich staje sie lzejszy. Na dluzsza mete ulatwiloby to tez synchronizacje wymiany danych miedzy elementami ktore licza fizyke, co moze sie przydac przy przejsciu na model wielowatkowy z obecnego 'kazdy wagon po kolei jeden po drugim'.
Masz calkowita racje co do rozpisania tego dokladniej, trzeba by nad tym pomyslec.

[Milek7]

Są w ogóle jakieś zalecenia co do stylu kodu? PascalCase, camelCase, c_case?

[firleju]

Szczerze to nie ma. Aczkolwiek większość kodu jest w PascalCase. Ja ogólnie nazwy klas i funkcji staram trzymać się w obecnej konwencji a zmienne w klasach to już róznie, ale najczęściej one są w camelCase. Zdarzają się też małe litery z podkreślnikami.

[El Mecánico]

Pod kierunkiem LD:

• rozróżnić kabiny A i B w pojazdach dwukabinowych, łącznie ze wszystkimi kontrolkami elektrycznymi (nawet wyświetlacze),
• pojazdy jednokabinowe jednopulpitowe (jak SM42, SM48): przygotować do wywalenia "tylną kabinę" (jeden obiekt kabiny i jeden pulpitu, trza to rozbić),
• pojazdy jednokabinowe dwupulpitowe (jak 6Dg, ST48): zmienić podejście do obiektu jaką jest kabina i pulpit, tak, aby zmiana pulpitu była już bez ładowania czegokolwiek i resetowania jakichkolwiek zmiennych (gdyby tylko sterownik hamulca nie zwalał powietrza przy przełączaniu pulpitów, to zmianę by się nawet na biegu dało zrobić...)

Dziękować:)

[tmj]

Pytanie z troche innej beczki. Czy ma ktos jakies przemyslenia co do ewentualnych mozliwosci zmian/ulepszenia systemu sterowania pojazdem, z punktu widzenia uzytkownika? Konkretnie chodzi o ogarniecie istniejacych licznych skrotow, na ktore juz praktycznie zaczyna brakowac sensownych kombinacji klawiszy. Potencjalnie dwa podejscia, ktore przychodza mi na mysl to:

-- dodanie obslugi przez klikniecia na elementy bezposrednio w kabinie. Czyli np wciskamy Alt czy cos, symulator pokazuje kursor myszy i zamiast krecic glowa dookola mozemy sobie kliknac w kontrolki, przelaczajac je. Z jednej strony przydane, ale z drugiej wymagaja troche celowania, wiec moze okazac sie niewygodne.

-- dodanie czegos w rodzaju 'trybu' interfejsu, ktory zmienia funkcje klawiszy. Np. w trybie 'normalnym' pod klawiszami jest obsluga elementow uzywanych podczas jazdy (hamulce, nastawnik, czuwak itp), natomiast w trybie 'elektryka' pod klawiszami jest regulacja poszczegolnych swiatel, przyciemnienie wlaczanie ekranow itp, rozlozona bardziej intuicyjnie i bez kombinowanych skrotow w rodzaju shift+ctrl. Nie jestem pewien, czy nie byloby to jednak zbyt skomplikowane.

Jesli ktos ma lepsze pomysly, to prosze pisac :)