Exe - konwersja na C++

[firleju]

Znalazłem czuwak. Wyszło, że błąd był w funkcji SetFlag, która przetłumaczyłem jakieś 2 miechy temu. Jeśli dwukrotnie ustawiałem flagę to za drugim razem była kasowana. Jeszcze kółeczko po TD z hamowaniem, żeby sprawdzić czy na pewno wszystko gra i chyba włączę jakiś scenariusz.
  Dodano: [time]08 Stycznia 2017, 20:21:21[/time] Scenariusz: failed. Źle ładuje się EP09 i kibelki.
Przy okazji wyłączyłem okienko błędów.
  Dodano: [time]08 Stycznia 2017, 21:39:56[/time] Poprawiam teraz funkcje wczytywania fizyki, bo się komuś zapomniało dodać paru wyjątków.
  Dodano: 10 Stycznia 2017, 06:57:27 Fizyka ładuje się już poprawnie. Ale scenariusz dalej nie działa, gdyż odezwał się stary błąd z nieskończonym przesuwaniem pojazdu. Tym razem przyczyna jest inna, gdyż zmienna w debugerze wyświetla -NAN i teraz dochodzę w którym momencie przyjmuje taką wartość (jest inicjowana, więc to nie to raczej).

[tmj]

NaN z reguly (moga byc roznice zaleznie od kompilatora, niektore to wylapia) wyskakuje przy dzieleniu zero przez zero, albo gdy probujesz liczyc sqrt() z liczby ujemnej. Bardziej prawdopodobny jest ten drugi wariant.

do wylapania gdzie to sie dzieje mozesz uzyc assert( foo == foo ); zatrzyma sie kiedy foo = NaN

[firleju]

No to jest ciekawe, gdyż zmienną inicjuję dzieląc wartość wejściową konstruktora przez 3.6. Więc nawet jak jest 0.0 na wejściu to nie powinno być NaN. Musi być coś jeszcze gdzieś indziej. Najlepsze, że tak się dzieje nie przy każdym uruchomieniu a to by wskazywało na brak inicjacji zmiennej.

[tmj]

Nie wiem, czy ma to zwiazek, ale zwroc uwage na ComputeCollision()

Kod: [Zaznacz]

v1 = w1 * sqrt(1 - beta); // niejawna zmiana predkosci wskutek zderzenia
v2 = w2 * sqrt(1 - beta);
Nie ma tu zadnego zabezpieczenia przed sytuacja gdzie beta > 1 i nie zdziwilbym sie, gdyby wyszlo ze wywolanie z CollisionDetect() produkuje takie wlasnie wartosci od czasu do czasu, takie rzeczy jak Couplers[CouplerN].Connected->Couplers[Couplers[CouplerN].ConnectedNr].beta az prosza sie o klopot, i omylkowe czytanie danych z miejsc, gdzie zadnych danych nie ma :)

[firleju]

To nie jest w CollisionDetect. Znalazłem już przyczynę, ale to nie będzie łatwe do obejścia. Wygląda, że przekręcam licznik podczas obliczeń. Podejrzewam, że w Delphi przy wyjściu poza zakres nadawał wartość min/maks, a teraz już nie.

[tmj]

Co on tam tak liczy, ze mu sie w double albo long nie miesci? o.O

[firleju]

Z porannej sesji dowiedziałem się tylko, że przeskok wartości następuje na sprzęgu. Z wartości 0.00004 wrzuca na -1.00+e45 w następnym kroku dla pojazdu. Jako, że wartość na sprzęgach jest liczona wzajemnie to teraz będę przechodził krok po kroku każdy pojazd i sprawdzał skąd to się bierze.

[HTD]

Ja tylko zaczynam się bać, czy z takiego "makaronu" powstanie w tym kroku sensowny kod? Tzn po przepisaniu - jak działanie tego jest tak anty-intuicyjne - to nadal nie będzie rozwijalne. Kod którego działanie jest anty-intuicyjne to "makaron" właśnie. Nie nadaje się do dalszego rozwoju. No, chyba, że teoretycznie, to będziemy mieli teoretyczny rozwój.

C++ to przeżytek na miarę Internet Explorera! Nie wiem czy nie da się tego zrobić w C++ tak, żeby obliczenia i ich wyniki były jasne dla osoby, która rozumie samą matematykę w nich użytą. Jeśli tak, to będzie trzeba tak to przerobić. Jeśli nie, to chyba warto pomyśleć o języku, w którym 2+2 zawsze jest 4, a idiotyczne i niebezpieczne konwersje typów będą odrzucane przez kompilator.

Jak dla mnie to kompletny brak rozwijalności - jeśli programista próbujący rozwijać kod musi tracić godziny na kombinowanie czemu 2 + 2 nie działa. Jak 2 + 2 nie działa i wymaga wgłębiania się w detale komponentów zupełnie niezwiązanych z realizowanym zadaniem - coś jest grubo nie tak.

Jak potrzebujemy rakiety kosmicznej żeby odpalić MaSzynę na kalkulatorze czy zegarku - są do tego nowoczesne języki niskopoziomowe. Jest Rust. Jest Haskell. I kilka innych. Wszystkie powstały z podobnych powodów. Komuś znudziło się zarywanie kolejnej nocki na debugowaniu 2 + 2.

Na mój gust do całej fizyki w MaSzynie wystarczyłby C#. Matematyka w C# liczy się tak samo szybko jak w C++, pod warunkiem sensownego gospodarowania pamięcią. Jedyne co będzie w C# wolniejsze (i to o rzędy wielkości) to operacje typu "weź 2GB danych i przemiel". Wolniejsze będzie I/O i takie tam. Rzeczy, które można zamknąć w osobnym niskopoziomowym module/dll. Module, który nic nie będzie liczył, chyba że hurtowe przekształcenia dla shaderów.

Mamy ramkę. Dla uproszczenia 1/60 sekundy. Jeśli mamy w tej ramce przeliczyć tysiące rzeczy - runtime nam w tym nie przeszkodzi. Nawet na zabytkowym kompie. Problem byłby dopiero wtedy, gdybyśmy musieli przeliczyć miliony czy miliardy rzeczy. Ale od tego są niskopoziomowe moduły właśnie. Tia. Przy takiej konstrukcji kod byłby rozwijalny.

[szczawik]

@HTD, póki co Twoje posty są tyle warte co ten mój. Zwykłe rozważania o tym jak fajnie by było gdyby to i tamto. Ani nie pomożesz @firleju, ani nie przyczynisz się do pchnięcia tego w jakąkolwiek stronę.

[Mariusz1970]

Coś jest na rzeczy, o czym pisze HTD, jednak przypomina mi to to:

t=05m00s

[tmj]

C++ to przeżytek na miarę Internet Explorera! Nie wiem czy nie da się tego zrobić w C++ tak, żeby obliczenia i ich wyniki były jasne dla osoby, która rozumie samą matematykę w nich użytą. Jeśli tak, to będzie trzeba tak to przerobić. Jeśli nie, to chyba warto pomyśleć o języku, w którym 2+2 zawsze jest 4, a idiotyczne i niebezpieczne konwersje typów będą odrzucane przez kompilator.

Idiotyczne i niebezpieczne konwersje typow zawsze generuja ostrzezenia. Jak ktos chce, to moze sobie wlaczyc zasade, ze ostrzezenie = blad, i kompilacja nie pojdzie. Tyle, ze w kodzie maszyny ostrzezen jest pewnie tyle, ze usuwanie ich potrwaloby do przyszlej wiosny. Takich rzeczy trzeba pilnowac i usuwac je na biezaco, inaczej to sie szybko nawarstwia.

Czy c++ jest przezytkiem... troche mylisz tutaj dwie rzeczy -- maszyna jest w duzej mierze pisana pod Borland c++ ktory skonczyl rozwoj przed rokiem 2000. To jest faktycznie przezytek, ale tez ma on malo wspolnego z c++11 ( https://en.wikipedia.org/wiki/C%2B%2B11 ) i nowszymi wersjami jezyka. To troche tak jakby mowic ze openGL jest przezytkiem, bo opieramy sie na wersji 1.2 gdy tymczasem standard rozwinal sie do wersji 4.5 i posuwa sie dalej.

No, ale nic nie stoi na przeszkodzie, bys przepisal maszyne na C# jesli uwazasz ze to jedyna perspektywiczna droga rozwoju :)

@firleju podaj troche szczegolow jesli mozesz. Co to za funkcja, ktora liczy i chrzani te sprzegi?

[firleju]

ComputeCollision i ComputeCouplerForce jak sądzę (nie pamiętam dokładnie nazw). Wywoływane z TGround::Update. Zmieniana jest zmienna CForce.
  Dodano: 11 Stycznia 2017, 13:48:37 @HTD: zrób prosty eksperyment. Zainicjuj zmienną małą wartością, np, 2.3e-5. Potem dziel ją powoli przez jakieś 50, najlepiej tak żeby kompilator nie mógł sobie tego policzyć przed uruchomieniem programu i tak ze 100 razy. Powiedz jaki jest wynik w C#.

[HTD]

Dobrze wiedzieć, temat tylko obserwowałem, nigdy nie używałem C++, chyba że absolutnie musiałem. To nie panikuję już, w końcu jak VS pokaże te wszystkie ostrzeżenia, to da się to ogarnąć. Nie twierdzę, że C# to jedynie słuszna opcja. No byłoby szybciej, a dlatego teraz tego nie robię, bo czas, czas i jeszcze raz czas. Robię teraz 5 projektów na raz, od 5 rano do północy dzień w dzień, tak że nie mam nawet czasu jeździć ;) Ale dalej i tak nie mam w planach grzebać przy exe, wolę zaatakować temat narzędzi graficznych. Mam sporo rozgrzebanego kodu i szkoda wyrzucać tego do kosza, bo może zaoszczędzić w przyszłości całe miesiące dłubania w sceneriach.

Podziwiam cierpliwość Grześka, ja bym chyba wyskoczył przez okno od takich bugów ;)

Kod: [Zaznacz]

var x = 2.3e-5d;
for (int i = 0; i < 10000; i++) x /= 50d;
Console.WriteLine($"x = {x}");
Console.ReadKey(true);

Wynik 0 dla double. Dla float tak samo wynik 0.

[firleju]

Dla mnie trochę niezrozumiała jest natura błędu. W jednym obliczeniu mam delikatną ujemną siłę, a w następnym jakby ktoś rypnął w wagon. Najlepsze, że potem oblicza przejechaną odległość w kategoriach kosmicznych ;)

[tmj]

Zainicjuj zmienną małą wartością, np, 2.3e-5. Potem dziel ją powoli przez jakieś 50, najlepiej tak żeby kompilator nie mógł sobie tego policzyć przed uruchomieniem programu i tak ze 100 razy. Powiedz jaki jest wynik w C#.

visual c++ 2013

Kod: [Zaznacz]

double x = 2.3e-5;
for( int i = 0; i < 100; ++i ) {

x /= 50.0;
assert( x == x );
}
przy typie double x = 2.9155963805249270e-175
przy typie float x = 0

Borland to liczy, czy sie wysypuje?

jesli ComputeCollision() ma swoj udzial, to zwroc uwage na ten kawalek 1 - beta o ktorym wspomnialem (o ile to jeszcze tam jest) CouplerForce() wyglada jak spaghetti, ale nie ma tam nic strasznie podejrzanego, no chyba ze probuje gdzies czytac cos, co akurat nie jest danymi.

Chyba naprawde najlepiej byloby w tym momencie wywalic borlandowy parser, zeby to sie wszystki zaczelo kompilowac w jakims sensowniejszym srodowisku, i wtedy spokojnie szukac bledow

[firleju]

Wygląda to strasznie dziwnie. Porobiłem logowanie zmiennych i wygląda, że nadawana wartość CForce jest normalna. A mimo wszystko w następnej funkcji liczy jakieś kosmiczne wartości przyspieszenia. Najlepsze, że tak się dzieje tylko w jednym wagonie i tylko jak jest więcej składów na scenerii. Jak wytnę resztę składów to liczy normalnie.
Ja bardzo chętnie zrezygnuję z Borlanda. Mogę udostępnić całość skonwertowaną i trzeba tylko wywalić ten parser i pousuwać resztę AnsiStringów (został chyba tylko zapis e3d z tego co pamiętam) i powinno się skompilować bez problemów (trzeba zakomentować funkcję abs i to_string w mctools, specjalnie zrobione żeby nie powielać później funkcji z STL). Przyjmę każdą pomocną dłoń w tym zakresie.

[tmj]

Jesli tam zostal tylko parser do zrobienia, to pchnij jak mozesz aktualna wersje na githuba. Na 100% nie moge obiecac, ale postaram sie zerknac w weekend czy da sie zrobic zamiane i doprowadzic to do kompilacji w czyms innym.

[firleju]

Znalazłem miejsce błędu, wiem jak naprawić, ale nie wiem dlaczego on się pojawia. Analizuję co tam się dzieje teraz.
  Dodano: [time]12 Stycznia 2017, 19:59:12[/time] A jednak okazało się, że była jeszcze jedna nie zainicjowana zmienna w moverze. Naprawdę nie wiem jak ją minąłem.
  Dodano: [time]12 Stycznia 2017, 20:37:13[/time] Hehe, kolejny "błąd". Okazuje się, że nie czyta dodatkowych wpisów do hamulców taboru w scenerii by yB.
  Dodano: 12 Stycznia 2017, 20:56:15 Tak sobie pomyślałem, że to pewnie efekt uboczny usuwania AnsiStringów z wcześniejszych etapów.
Ponadto pchnąłem wszystko co do tej pory zrobiłem na git-a. Wygląda, że da się już jeździć i oprócz tych wagonów Quark wystartował.

[firleju]

Wczesnym rankiem zrobiłem poprawkę na poprawne parsowanie flagi bitowej sprzęgu. Teraz już działa. Wieczorkiem puszczam kontrolnie Quarka i jak się nic nie będzie sypało to idzie do was na większe testy. Przy okazji zerknąłem na kod pod kątem kompilacji w VS i jest tam jeszcze troszkę rzeczy do poprawienia, np. zmienne typu Byte i takie tam. VS lubię ze względu na fajny sposób zaznaczania linijek z błędami.

[tmj]

Przy okazji zerknąłem na kod pod kątem kompilacji w VS i jest tam jeszcze troszkę rzeczy do poprawienia

To jest delikatnie powiedziane :)  Zajrzalem tam sobie dzisiaj, i niestety na samym wycieciu parsera sie nie skonczy, sporo tam jeszcze sie paleta ansistringow, borlandowych naglowkow i innych takich. Ale jak juz zaczalem grzebac, to skoncze (chociaz ladnie jeszcze nie bedzie, na to przyjdzie czas pozniej)

[firleju]

Ładnie, proszę Cię, całość jest do refaktoringu. Ale po kolei. Ci którzy chcieli pisać wszystko na nowo kończyli smętnie.
Ja kończę jak widać z samą konwersją. Jak już pójdzie to zrobię merga z najnowszymi zmianami na masterze i dalej do testów. Jak będzie ok, to wrzucam na upstream-a i dalsze prace to:
1. Zejście z BCB
2. Opracowanie grafu zależności danych, czyli gdzie jakie klasy są trzymane.
3. Zmiana organizacji przechowywania danych na prostszą:
a. Pojazdy są w 4 różnych klasach, trzy odpowiadają za reakcję pojazdu na różne zdarzenia i jedna steruje. Brak podziału na poszczególne typy pojazdów nie mówiąc o różnicach w sterowaniu poszczególnych modeli. To samo tyczy rozróżnienia AI / człowiek.
b. Trzeba przemyśleć sposób przechowywania danych geometrycznych w kolejnych poziomach. Mnie tam wygląda, że jest dużo miejsca do optymalizacji, no i większej przejrzystości.
c. Należy się zastanowić nad zejściem z DisplayList na rzecz tylko VBO. Wtedy wprowadzić shadery, będzie można zrobić normalne oświetlenie.
4. Po drodze jeszcze są kwestie:
a. Wymiany danych z innymi systemami, w szczególności SCS i koncepcyjnym VD (implementacja komunikacji międzyprocesowej za pomocą Message Quequing)
b. Poprawy błędów na obecnych sceneriach
5. Nie ma żadnych testów i to naprawdę boli. Niestety kod jest tak napisany, że w niektórych momentach trudno wykonać zaimplementować testy.

[tmj]

Ładnie, proszę Cię, całość jest do refaktoringu. Ale po kolei. Ci którzy chcieli pisać wszystko na nowo kończyli smętnie.

Nie no bez przesady, ja nie planuje tutaj nic dotykac w samej strukturze. Probuje tylko doprowadzic do kompilacji w VC to, co jest. Na razie sprowadza sie to do parsera, stringow i usuniecia odwolan do pozostalych resztek po Borlandzie. Tylko mowie, ze zostalo tego troche wiecej niz mialem nadzieje, ze bedzie; ale trudno :)

[firleju]

Też tak myślałem, że to tylko tyle i szybko pójdzie ;)

A w załączniku prezent poświąteczny. Wprost z kompilatora, zagrzało mi procek ;)

[szogun]

Z tego co zauważyłem po krótkiej jeździe na TD - nie działa woltomierz baterii, przyhamowanie przy poślizgu, piasecznica daje tylko dźwięk a piachu nie sypie i odluźniacz nie żyje. Ciekawy efekt się też pojawia po powrocie do pojazdu z freefly, jest takie płynne lekkie bujnięcie kamerą jakby maszynista się poprawiał w fotelu ;)

[matek123]

U mnie miota w kabinie prawie cały czas, jakby "maszynista" miał padaczkę. Nie zamyka mi WS. A jak dałem autopilota, to mrugała lampka od WSa.

[Stele]

Wersja skompilowana wysypuje się zaraz po starcie. Dodaje kilka eventów do kolejki, słychać luzowanie hamulca i wysyp. Siódemka na TD czy Bałtyk.
Źródła się nie kompilują. Nie widzi klasy Hamulce.

[tmj]

Train.cpp jak na razie rozwalil konwersje -- okazuje sie, ze kompilator ma twardy limit 127 blokow else-if, a InitializeCab() nic sobie z tego nie robi. Trzeba sie bedzie przyjrzec, jak to przerobic na cos rozsadnego... 90% daloby sie ladnie zautomatyzowac, ale nie wiem jak to jest potem obslugiwane w symulacji. Tez wszystko recznie, jedna kontrolka po drugiej?

[El Mecánico]

Nie da się tego zestawu else-if'ów przerobić na switch-case?

[tmj]

Nie bardzo, bo sa oparte na porownywaniu stringow. Plus, calkiem mozliwe ze switch() ma podobne ograniczenie. Tymczasowo rozbije to na dwa osobne bloki, powinno wystarczyc, a w przyszlosci mozna sie pobawic przebudowaniem kodu kabiny na cos bardziej sensownego.

[El Mecánico]

Stringów? Zazwyczaj wale tam int'a (ew. enum'a, który wewnętrznie i tak jest konwertowany na int'a) i jakoś działa. Czyżby kompilator napotykając switch'a robił konwersję zmiennej niejawnie do stringa?