Exe - konwersja na C++

[firleju]

Ja za to robię już prawdopodobnie ostatni plik. Choć teraz idzie trochę po grudzie, bo muszę się bawić w sprawdzanie ręczne każdej zmiany. Poczeka do jutra, idę spać.

[youBy]

ZTCW to Size i tak nie bylo uzywane -- funkcja ma swoj wlasny licznik i zwieksza go z kazdym przebiegiem, i dopisuje do tabeli nowe wartosci tak dlugo, jak jest jeszcze miejsce. W przyszlosci mozna faktycznie zrobic tabele np. na vector zwiekszanym dynamicznie, jesli 30+ wpisow to za malo.

Okazalo sie, ze nie ladowalo tez sekcji "MotorParamTable:" bo mialo na sztywne ustawione zeby szukac tylko "MotorParamTable0:"  Czy te dwie wersje sie czyms roznia, poza brakiem ostatniego parametru? W kazdym razie SU juz sobie jezdzi, chociaz nie wiem czy na 100% jak trzeba:

Co do Size - w Pascalu działało i w ten sposób można było zaczytać np. tylko 8 wierszy z 10.

MPT0 umożliwia podanie dodatkowej wartości (oidp fi0) dla lepszego dopasowania charakterystyki. MPT przypisywało jej wartość 0.

[tmj]

MPT0 umożliwia podanie dodatkowej wartości (oidp fi0) dla lepszego dopasowania charakterystyki. MPT przypisywało jej wartość 0.

Hmm tu w ogole bajzel troche jest:

h9-21 (DieselEngine)

Kod: [Zaznacz]

MotorParamTable: minVelfullengage=9.5 engageDia=0.352 engageMaxForce=2000 engagefriction=0.8
0 0 0 -1
1 6.93 -1 10
2 4.03 4 28
3 2.36 15 50
4 1.40 25 88
5 1.00 47 100
END-MPT 

301d (DieselElectric)

Kod: [Zaznacz]

MotorParamTable:
0 20 100 3000 20.8 1340 1713
1 18.5 110 2700 25 1340 1713
2 17.2 135 2500 30 1340 1713
3 14.3 170 2000 48.5 1340 1713
END-MPT 

rozumiem, ze parametry sa rozne w zaleznosci od typu silnika, ale trzeba to jakos uporzadkowac, bo parser glupieje. Albo switch mozna dac, ale ktore parametry i w jakiej kolejnosci sa wpisane w jednej i drugiej wersji?

[youBy]

To wszystko wynika stąd, że zmienne są współdzielone między różnymi rodzajami silników.

[tmj]

OK, ale ktore zmienne sa podane w ktorej wersji, bo teraz sa co najmniej 3 warianty, i kazdy inny. Z tego co moge znalezc w wersji Pascalowej to jest:

MotorParamTable
ElectricSeries: (wiersz) mfi, mIsat, fi, Isat, (opcja autoswitch)
DieselElectric: (wiersz) mfi, mIsat, fi, Isat, MPTRelay[k].Iup, MPTRelay[k].Idown
DieselMotor: (wiersz) mIsat, fi, mfi, (opcja autoswitch)

MotorParamTable0
(wiersz) mfi, mIsat, mfi0, fi, Isat, fi0, (opcja autoswitch)

czy to sie wszystko zgadza, czy cos zle czytam?

[tmj]

OK, jeszcze jedno glupie pytanie, jak juz przy tym jestem. Do ladowania zawartosci tablicy DList w wersji Pascalowej uzyte jest:

(wiersz), RList[k].Relay, RList[k].R, RList[k].Mn

To sa cztery parametry, ale we wszystkich plikach .fiz sa podawane tylko 3. Czy 4-ty jest opcjonalny, czy jest to jakos inaczej obslugiwane?

[firleju]

Do zrobienia zostały mi dwa pliki z głównego katalogu (DynObj.cpp i EU07.cpp) i do sprawdzenia wszystkie podkatalogi. Jest weekend więc prace prawie nie idą. Pewnie skończę dopiero w tygodniu.

[tmj]

W takim razie, jesli mozesz, pchnij to co jest zrobione do tej pory? Podlacze sobie na swoim koncu, i bedzie mniej roboty jak skonczysz reszte.

[firleju]

Dopiero jak wrócę do domu. Teraz w gościach bawię się w domowego informatyka.

[tmj]

Z ciekawostek: po wprowadzeniu bardziej kompletnego ladowania plikow .fiz i poprawek dla najbardziej widocznych bledow .exe uruchamia sie takze i nawet dziala w trybie release. Release to w tej chwili jazda po bandzie, bo w kodzie na 100% sa jeszcze kwiatki w stylu czytania danych nie stamtad, gdzie trzeba, ale skok wydajnosci jest calkiem niezly -- np scenariusz Calkowo, ktory oficjalny .exe z paczki laduje u mnie 90 sekund, w nowym .exe wchodzi w 35 ;)

[firleju]

No mam nadzieję, że nie startowałeś na exe z paczki na zimno, a na nowym na ciepło. Wrzuciłem te pliki, które już zrobiłem.

[tmj]

No mam nadzieję, że nie startowałeś na exe z paczki na zimno, a na nowym na ciepło.

Bogdan, ja Cie prosze :) Uruchamiane naprzemiennie kilka razy; na zimno to .exe z paczki meczy sie jakies 2 minuty.

[firleju]

Heh, tylko wiesz, że c4 już skompilowałem w release i działało ;) I nie mam na imię Bogdan :P
Ale dobrze wiedzieć, że wreszcie widać jakieś konkretne efekty wywalenia Borlanda.
Mnie pozostały jeszcze tylko podkatalogi, więc jeśli nie zasnę zaraz po obiedzie to może uda się dzisiaj to zrobić.

[tmj]

Ja wlaczylem u siebie exceptions dla bledow koprocesora, wiec release wylatywal praktycznie natychmiast :d  Teraz jest juz troche lepiej, chociaz w duzej mierze losowo, bo ZTCW funkcje zwiazane z konstrukcja geometrii lubia sobie pisac gdzie chca, wiec czasem wszystko dziala, a czasem jest sieczka. Debug w zasadzie chodzi przyzwoicie caly czas.
Polaczylem to co zrobiles z moimi poprawkami i na razie lezy i czeka na reszte.
A Bogdan to z takiej glupiej reklamy, jakos tak wbila mi sie w pamiec ;)

[firleju]

Wszystkie pliki na utf-8 już na repo. Mogę spokojnie iść spać.
Ahh, jeśli masz jakieś poprawki do solucji to je wrzuć na repo a nie kasuj całej solucji z repo ;)

[tmj]

OK, polaczylem poprawki, pull request wyslany.
Przepuscilem przez ta wersje scenerie z paczki calosciowej, wyglada na to ze (prawie) wszystko dziala. Z rzeczy do sprawdzenia jest prawdopodobnie konwersja z t3d -> e3d, symulator sie na tym (lub w okolicach) wysypuje, przy ladowaniu linii 61. Jesli wylacze konwersje w pliku .ini to wchodzi.
Aha, plikow solucji nie dotykalem, ale mam lokalnie *.sln i inne rzeczy z VS wrzucone do ignore, wiec moze git cos tam miesza. Jak znowu sprobuje cos tam kasowac to daj znac, dodam tez do swojej wersji na wszelki wypadek.

[firleju]

Tak specjalnie zrobiłeś pull-a na mastera a nie na mover_c++ ???

[tmj]

Nie, sorry, kliknalem tylko w "compare & pull" i nawet nie spojrzalem, do glowy mi nie przyszlo ze on to tam wrzuci, bo poprzednim razem ustawil wszystko prawidlowo, i to jest branch od mover_in_c++ a nie od master. Moze GitHub cos sam wymyslil jak zobaczyl, ze nie ma konfliktow. Zaraz poprawie.

[tmj]

Aha, przy okazji. Nie bede robil kolejnego commita tylko dla takiego drobiazgu, ale jak mozesz to zmien deklaracje w VBO.h na:

Kod: [Zaznacz]

class CVertNormTex
{
  public:
    float x = 0.0; // X wierzchołka
    float y = 0.0; // Y wierzchołka
    float z = 0.0; // Z wierzchołka
    float nx = 0.0; // X wektora normalnego
    float ny = 0.0; // Y wektora normalnego
    float nz = 0.0; // Z wektora normalnego
    float u = 0.0; // U mapowania
    float v = 0.0; // V mapowania
};
wyglada na to, ze inicjalizacja usuwa wiekszosc smieci z renderingu w trybie release, i staje sie on calkiem uzywalny, takze przy wylaczonym uzyciu VBO.

[firleju]

Widzę, że dalej usuwa solucję. Ale zostaw, po prostu ją wrzucę z powrotem.
EDIT:
Połączyłem. W jednym pliku zaposiała się niepolska literka, ale to już poprawię. Wieczorkiem dorzucę zmiany do VBO i wystawię exe do testów. No i zacznę w końcu szukanie zgłoszonych błędów. I ewentualne poprawki dla Kaliskiej.

[tmj]

Wiekszosc zgloszonych bledow nt. niefunkcjonujacych lokomotyw itp. powinna byc juz usunieta w tej wersji, przyczyna bylo niekompletne ladowanie definicji z plikow .fiz i pare bledow w komponentach. Tak wiec po nowych testach mozesz miec mniej do szukania ;)

[firleju]

Testów nie będzie, gdyż nie kompiluje projektu ze względu na

Kod: [Zaznacz]

Severity Code Description Project File Line Suppression State
Error C2338 The C++ Standard forbids containers of const elements because allocator<const T> is ill-formed. (compiling source file EU07.cpp) maszyna c:\program files (x86)\microsoft visual studio 14.0\vc\include\xmemory0 665
Kompiluje w VS2015. Błąd się pojawił w commicie 6ab550831dc4fd8508362ff075f476ec46c6bd4c "basic patches for most of discovered memory leaks, fixes for brake system components"

EDIT:
Zmiany dotyczące elementów const były tylko w hamulcach i pythonie. Wstępnie hamulce odrzuciłem więc został tylko python do sprawdzenia. Teraz niestety przerwa z mojej strony gdyż wychodzę i wrócę pewnie dopiero wieczorem, więc następne prace pewnie rano w pociągu.

[tmj]

W PyInt.h zmien

std::set<std::string const> _classes;
na
std::set<std::string> _classes;

i powinno pomoc.

[firleju]

No tak przypuszczałem, że to pomoże. Przy okazji wyszło, że twój pull wywalił także glew.lib z katalogu opengl. Przywracam i po modernizacji funkcji losującej (przejście na <random> i normalne losowanie z wybranego zakresu, a nie taka prowizorka jaka jest) wrzucę exe na testy.
Info dla tych, którzy dziwili się, że dostają radiostop za każdym razem na l61. Nie dziwota jeśli funkcja losująca w paszczalu były błędnie użyta i za każdym uruchomieniem exe losowała te same liczby :)

[firleju]

Najnowsze exe to sprawdzenia. Tmj twierdzi, że część błędów już nie powinna być obecna.

[RoboBatman]

Przy próbie przetestowania exe na scenerii TD razem z EU07-195, po wciśnięciu przycisku "Uruchom symulator" wywala mi oto taki komunikat o braku pliku:

[Krzysiek626]

U mnie na początek taki: brak msvcp140.dll
W zasadzie mogę brakujące pliki pościągać, tyle że robiąc to nie mam pewności źródła. Stąd myślę, że warto dodawać do nowych kompilacji biblioteki które są nowością dla danego numerku.

[tmj]

glew.dll na oficjalnej stronie glew: http://glew.sourceforge.net/ (wersja 'binaries', bezposredni link: https://sourceforge.net/projects/glew/files/glew/2.0.0/glew-2.0.0-win32.zip/download )
biblioteki msvc z oficjalnej paczki Microsoft: https://www.microsoft.com/en-us/download/details.aspx?id=48145

[firleju]

Wymaga redist-a także dla release? Hmmm...

[tmj]

Mozesz  to zmienic w opcjach projektu: C++ > Code Generation > Runtime Library, domyslnie jest DLL w wersji debug albo release (dlatego release tez wymaga)  Jesli ustawisz tam tylko "multi-threaded/multi-threaded debug" to procedury z DLL beda wlaczone do .exe... ale moim zdaniem to niepotrzebne, VC Runtime jest standardowo dolaczany do instalacji kazdej profesjonalnie wydanej gry, wiec wiekszosc uzytkownikow albo juz bedzie to miala, albo jesli jest dolaczone do paczki to sobie bez problemu zainstaluje, nie jest to jakies szczegolne wymaganie.